Subject: Re: [avtext] secdir review of draft-ietf-avtext-sdes-hdr-ext

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Apr 2016 11:33:10 +0200

Hi Samuel,

(CC the WG)

Thanks for the review.

Den 2016-04-17 kl. 13:45, skrev Samuel Weiler:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
>
> I am mostly satisfied with this document's security analysis.  I am
> worried that implementors will weasel their way around the "SHOULD"s,
> but the appropriate "SHOULD"s are in the doc.
>
> The doc says "...there SHOULD be strong integrity protection and source
> authentication of the header extensions" -- I would like to also see
> specific citation(s).  (e.g. "Use X for integrity protection."  "Use X
> for authenticity.")

So I will claim that the common problem that exists with minor RTP 
extension and RTP payload formats (see RFC 7202) do apply here, we 
should at least reference RFC 7201 for the options in the security 
consideration section.

I will edit our source and likely push out such a change quite soon so 
that it is in place in good time before the IESG call. Unless our AD 
objects.

I propose to add the below to end of the last paragraph.

"For information regarding options for securing RTP, see [RFC7201]."

And add RFC7201 as an informative reference.

>
> It would be nice to see some discussion of whether these headers
> increase the utility of RTP as a DOS vector - either by enabling a
> reflector attack or by triggering heavy computation on a receiving
> host.  I suspect that there's not much to see here, particularly if
> there really is integrity protection, but it would be nice to see the
> analysis.

Yes, this is a reasonable thing to consider. I suggest that we add the 
below paragraph before the last paragraph in the Security Consideration.

The general RTP header extension mechanism does not itself contain any 
functionality that is a significant risk for a denial of service attack, 
nor from processing or storage requirements. This specific extension for 
SDES items, could potentially be a risk. If the received SDES item and 
its content causes the receiver to perform larger amount of processing, 
create significant storage structures, or emit more network traffic such 
a risk do exist. The CNAME SDES item is only a minor risk as reception 
of a CNAME item will create an association between the stream carrying 
the SDES item and other RTP streams with the same SDES item. As this can 
result in time synchronizing the media streams some additional 
processing may result. However, the applications media quality appear 
will be likely more affected of the wrongly or changing association, 
than from the impact caused by the additional processing.

>
>
> Editorial comment:
>
> For the RTP-naive reader, I suggest adding an early mention that SDES
> is (normally) a special packet type within RTP.  Specifically: it
> would be helpful for Section 1 to also say "RTP has a special packet
> type for Source Description (SDES) items."

I guess what you are intersted is an expansion of the following text:

OLD:

    This specification defines an RTP header extension [RFC3550][RFC5285]
    that can carry RTCP source description (SDES) items.  By including
    selected SDES items in a header extension the determination of
    relationship and synchronization context for new RTP streams (SSRCs)
    in an RTP session can be optimized.   Which relationship and what
    information depends on the SDES items carried.  This becomes a
    complement to using only RTCP for SDES Item delivery.

NEW (Second sentence):

This specification defines an RTP header extension [RFC3550][RFC5285]
that can carry RTCP source description (SDES) items. Normally the SDES 
items are carried in their own RTCP packet type. By including
selected SDES items in a header extension the determination of
relationship and synchronization context for new RTP streams (SSRCs)
in an RTP session can be optimized.  Which relationship and what
information depends on the SDES items carried. This becomes a
complement to using only RTCP for SDES Item delivery.

Does this addresses the editorial issue?

Any feedback on the proposed changes?

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: Samuel Weiler <[email-masked]>
Date: Mon, 18 Apr 2016 05:48:56 -0400 (EDT)

> And add RFC7201 as an informative reference.

That makes sense to me.

> Yes, this is a reasonable thing to consider. I suggest that we add the below 
> paragraph before the last paragraph in the Security Consideration. 
....

This is the right idea.  It would be good for someone else in the WG 
to weigh in on its correctness and completeness.  The proposed text 
needs minor editting, but that can wait for the RFC Editor, if needed.

> Does this addresses the editorial issue?

Yes, perfectly.

Thank you for the quick and receptive response.

-- Sam

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 18 Apr 2016 09:29:38 -0500

> And add RFC7201 as an informative reference.

The AD does not object. I think it makes sense to treat this similarly 
to how we treat payload drafts.

> functionality that is a significant risk for a denial of service 
> attack, nor from processing or storage requirements. This specific 
> extension for SDES items, could potentially be a risk.

Do you mean that _this_ extension might be a risk, or that any specific 
SDES item might be a risk? The sentence sounds like it means the former, 
but the rest of the paragraph suggests the latter.

> If the received SDES item and its content causes the receiver to 
> perform larger amount of processing, create significant storage 
> structures, or emit more network traffic such a risk do exist. The 
> CNAME SDES item is only a minor risk as reception of a CNAME item will 
> create an association between the stream carrying the SDES item and 
> other RTP streams with the same SDES item. As this can result in time 
> synchronizing the media streams some additional processing may result. 
> However, the applications media quality appear will be likely more 
> affected of the wrongly or changing association, than from the impact 
> caused by the additional processing.
>
>
>
>>
[...]

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Apr 2016 10:03:03 +0200

> but the rest of the paragraph suggests the latter.

So the SDES item header extension in its basic mechanism does not appear 
to be a risk. However, the semantics of the SDES item itself may be a 
cause for concerns. It is really the next sentence below that attempts 
to clarify from where this risk comes. I will try to wordsmith this with 
help of my co-authors.

Cheers

Magnus Westerlund