Subject: [avtext] AD Evaluation of draft-ietf-avtext-sdes-hdr-ext-02

From: "Ben Campbell" <[email-masked]>
Date: Fri, 11 Dec 2015 22:11:57 -0600

Hi,

Here is my AD evaluation of draft-ietf-avtext-sdes-hdr-ext-02. I have a 
few questions and comments that I would like to resolve prior to IETF 
last call, as well as some editorial comments that can be handled 
whenever is convenient:

Thanks!

Ben.

=== Substantive:

- 4.2.1, last paragraph:
The guidance about RTP middleboxes seems to apply to header extensions 
in general. Is this not already documented somewhere else?

- 4.2.6, 2nd paragraph: "... issues can be avoid by performing ..."

Do you mean "... the receiver performing..."?

- 5.1:

Please elaborate on what you mean by sub-space. I don't think RFC 5285 
contemplated this idea. How would IANA indicate that things in this 
sub-space have additional rules beyond those of 5285? Or more 
concretely, how do we indicate that 
urn:ietf:params:rtp-hdrext:sdes:cname is bound by the rules for 
urn:ietf:params:rtp-hdrext:sdes?

Paragraph 2 says "preferably in a publically available reference." I 
think that's a hard requirement in 5285. This seems to relax that--I 
assume that is not the intent. Security considerations are also already 
required by 5285 (but there is no mention of privacy considerations.)

-6, general:

The requirements here are pretty abstract. Would it make sense to say 
something to the effect of "If you SRTP it you MUST encrypt the RTP 
extension header"?

-6, paragraph 2:
- "In RTP sessions where any type of confidentiality protection is
    enabled for RTCP, the SDES item header extensions MUST also be
    protected per default. "

Why “per default”? That tells me that an implementation would, if 
not configured otherwise, protect the header extension if it protected 
RTCP. Do you intend to allow the “configured otherwise” loophole?

- "users of SRTP need to implement encrypted header extensions"
Do you mean to say “implementers must also implement” or “users 
must also use”? Or both?

- "Commonly, it is expected that the same security level is
    applied to RTCP packets carrying SDES items, and to an RTP header
    extension containing SDES items. "

The phrase “Commonly, it is expected…” seems to water down the 
guidance. Any reason not to say SHOULD or MUST here?

- 6, paragraph 3:
- "there SHOULD be strong
    requirements on integrity and source authentication"

What needs to have that strong requirement? The specs for extensions in 
the sub-space? Or does this mean to say that "there SHOULD be strong 
integrity protection and source authentication"?

=== Editorial:

- General: There's a fair number of instances of noun/verb agreement 
issues. I will point out the ones I found, but there's enough that I 
would suggest proofreading for more.

- 1, 2nd paragraph:

--"Some SDES items performs binding or identifies synchronization 
context"
Singular/plural disagreements among [items, performs, identifies, 
context]

-- "No use case has identified where this information is required at the 
same time as the first RTP packets arrive."
I think it would be helpful to mention that this extension actually 
allows information deliver in the first RTP packets in the first 
paragraph. Leaving it to an in-passing remark here sort of buries the 
lede.

-1, last paragraph:
With the heavy use of passive voice in this paragraph, it was not 
immediately obvious to me that it talked about the following sections of 
the document itself. Please consider something more of the form of 
“Section 2 defines requirements language and terminology…”

-3, 2nd paragraph: "because an end-point is adding"
s/is adding/adds

-3, 3rd paragraph: "Thus an RTP header extension for carrying SDES items 
like CNAME is a powerful combination..."
What combination do you have in mind? When in combination with 6051? Or 
do you just mean to say it's a powerful tool?

-3, 4th paragraph:
s/does provide/provides

-3, 2nd to last paragraph:

You mean to say that that the MID spec already defines the header 
extension, not that _this_ draft defined it, right?

-4.2.2, 2nd paragraph:"If the packet expansion cannot be taken into 
account..."
Do you mean "... is not taken into account..."?

-5, first bullet:
Consider reordering this a bit: “… the URN sub-space…for SDES 
items”"

-5.1, first paragraph:"some additional considerations are provided here 
that needs to be considered"
noun/verb disagreement (considerations is plural, needs is singular)

- 5.1, 2nd paragraph: "security and privacy consideration"
s/consideration/considerations

-6, 2nd paragraph:
"If the security level is different,
    it is important to consider the security properties as the worst in
    each aspect for the different configurations."

I find this sentence hard to understand. I _think_ you are saying that 
the protection of the SDES item is equal to the protection of RTCP or 
that of the RTP header extension, whichever is lower?

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Dec 2015 17:29:29 +0100

Hi Ben,

See below my answer and feedback on your evaluation. I think it is 
fairly clear that we need to do a new revision prior to the IETF last call.

> in general. Is this not already documented somewhere else?

Not, what I can remember. It is definitely not in RFC5285, and this 
should be considered to be added to RFC5285bis draft.

> Do you mean "... the receiver performing..."?

Yes, these are all receiver side actions.

> urn:ietf:params:rtp-hdrext:sdes?

What I mean is that any URN starting with 
"urn:ietf:params:rtp-hdrext:sdes" is under these rules. And I think that 
IANA is already handling different set of rules for different parts of 
the URN space. The rules for "urn:ietf" is different from the ones for 
"urn:ietf:params:rtp-hdrext".

> required by 5285 (but there is no mention of privacy considerations.)

Yes, you are right, for RTP header extensions RFC5285 do require 
publicly available specification. I think we might have primarily looked 
at the rules for SDES items which are according to RFC3550:

    To facilitate review of requests and to
    promote shared use of new types among multiple applications, requests
    for registration of new values must be documented in an RFC or other
    permanent and readily available reference such as the product of
    another cooperative standards body (e.g., ITU-T).  Other requests may
    also be accepted, under the advice of a "designated expert."

Which gives some leeway for non public available references which 
RFC5285 do.

I think the easy fix here is to be clear that it must fulfil the rules 
of RFC5285, and then have this document in addition note the need for 1) 
being a registered SDES item (implies following the rules in RFC3550 for 
SDES items), 2) being explicit about privacy considerations and 3) the 
motivation for timely deliver.

> something to the effect of "If you SRTP it you MUST encrypt the RTP

    In RTP sessions where any type of confidentiality protection is
    enabled for RTCP, the SDES item header extensions MUST also be
    protected per default.  This implies that to provide confidentiality,
    users of SRTP need to implement encrypted header extensions per
    [RFC6904].

I thought the above was basically saying this, with the exception that 
it gates on encrypting RTCP, rather than using SRTP. And I think you 
actually want to consider if using just SRTP for integrity protection, 
i.e. null encryption shall force encryption on the SDES header 
extension. I am fine to edit this to say that if you confidentiality 
protect either RTP or RTCP, then you MUST confidentiality protect also 
this header extension.

But, I think for the SRTP parties, if we want to be clearer then we 
should simpley add "and use" to the second sentence.

> Why “per default”? That tells me that an implementation would, if not
> configured otherwise, protect the header extension if it protected RTCP.
> Do you intend to allow the “configured otherwise” loophole?

I am happy to loose the "per default" here. I can't remember a reason 
for it.

> Do you mean to say “implementers must also implement” or “users must
> also use”? Or both?

The first sentence says you must use it if RTCP is protected. If using 
SRTP, then this implies that you must implement and use RFC6904 to 
achieve the normative statement. And as said above, I am happy to 
clarify that this is really implement and use.

> The phrase “Commonly, it is expected…” seems to water down the guidance.
> Any reason not to say SHOULD or MUST here?

Yes, we can loose the "commonly ..." part. I think SHOULD is good, and 
and basically ask the ones trying to invoke the exception to motivate 
themselves.

> integrity protection and source authentication"?

The later.

> would suggest proofreading for more.

Noted. I will press my native speaking co-authors to do this.

>
> - 1, 2nd paragraph:
>
> --"Some SDES items performs binding or identifies synchronization context"
> Singular/plural disagreements among [items, performs, identifies, context]
>
> paragraph. Leaving it to an in-passing remark here sort of buries the lede.

Yes, that should be added as a new sentence after the one ending with 
"... can be optimized".

> “Section 2 defines requirements language and terminology…”

Yes, can do.

> do you just mean to say it's a powerful tool?

Actually the combination of CNAME and RFC6051. I guess, that last 
sentence should be focused on only motivating CNAME, rather than 
attempting to state that certain SDES items are very useful at startup, 
for example see CNAME.

> extension, not that _this_ draft defined it, right?

Yes.

> Do you mean "... is not taken into account..."?

Nope, but we should rewrite the sentence. If the header extension is not 
taken into account its packet expansion can cause MTU issue.

>
> -5, first bullet:
> Consider reordering this a bit: “… the URN sub-space…for SDES items”"
>

Yes, if different the one that provides lower protection per aspect is 
the one that gives that particular aspect. Then one have to combine the 
aspects to consider the complete properties.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Roni Even" <[email-masked]>
Date: Tue, 15 Dec 2015 08:52:04 +0200

Inline
Roni

> Not, what I can remember. It is definitely not in RFC5285, and this should be
> considered to be added to RFC5285bis draft.
> 
> >
[Roni Even] RFC5285bis allows mixing of one byte and two bytes header extensions in the same RTP stream but not in the same RTP packet so I think the issue here is that if an intermediary needs to add an header extension to an existing packet it may be limited by current header extensions, maybe it will be good to discuss it as guidelines for senders in the RFC5285bis document
Roni

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 22 Dec 2015 16:27:33 -0600

> should be considered to be added to RFC5285bis draft.

Okay.

> Yes, these are all receiver side actions.

That's probably obvious, but it wouldn't hurt to be explicit.

> "urn:ietf:params:rtp-hdrext:sdes" is under these rules. And I think 
> that IANA is already handling different set of rules for different 
> parts of the URN space. The rules for "urn:ietf" is different from the 
> ones for "urn:ietf:params:rtp-hdrext".

Okay, let me take another approach. RFC 5285 has a set of registration 
rules for the RTP compact header extension registry. This draft says 
that some entries that contain the string "hdrext:sdes"..." will have 
additional rules. But this doesn't create a new registry, does it? Is 
there some expectation that a new registrant who wants to register 
"...hdrext:sdes:foo" will even read this draft?

I'm curious why the group did not define a new table for things like 
"urn:ietf:params:rtp-hdrext:sdes:foo", with the additional registration 
rules from this draft.

> publicly available specification. I think we might have primarily 
> looked at the rules for SDES items which are according to RFC3550:
>
> of RFC5285, and then have this document in addition note the need for 
> 1) being a registered SDES item (implies following the rules in 
> RFC3550 for SDES items), 2) being explicit about privacy 
> considerations and 3) the motivation for timely deliver.

I agree.

> should simpley add "and use" to the second sentence.

That works for me.

>> not

Okay.

>> must

Okay.

>> guidance.

Okay.

>> integrity protection and source authentication"?

Okay. If it's not obvious, I propose removing "requirements on"

[...]