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

[Magnus Westerlund <[e-mail]>]

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  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------