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

[Magnus Westerlund <[e-mail]>]

Den 2016-04-18 kl. 16:29, skrev Ben Campbell:
> On 18 Apr 2016, at 4:33, Magnus Westerlund wrote:
>
>> 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.
>
> The AD does not object. I think it makes sense to treat this similarly
> to how we treat payload drafts.
>
>
>>
>>>
>>> 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.
>
> 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.

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.

>
>> 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.
>>

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]
----------------------------------------------------------------------