Re: [secdir] SecDir review of draft-ietf-straw-b2bua-rtcp-13

[Yoav Nir <[e-mail]>]

> On 11 Oct 2016, at 19:46, Lorenzo Miniero <[e-mail]> wrote:
> 
> Hello Yoav,
> 
> sorry for this late reply... thanks for reviewing the document! As to
> the points you raised in your review, I've added a couple of comments
> inline.
> 
> 
> On Sun, 9 Oct 2016 09:57:26 +0300
> Yoav Nir <[e-mail] <mailto:[e-mail]>> wrote:
> 
>> Hello,
>> 
>> 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.
>> 
>> Summary: Ready with nits
>> 
>> The document defines the proper behavior for B2BUAs that, in addition
>> to being on-path for SIP, are also on-path for the media traffic,
>> whether RTP or RTCP.  Section 3 describes different scenarios for
>> B2BUAs operating on the media, and if features considerations of the
>> type “if you change this, you also have to change that, otherwise
>> this bad thing could happen.” The document is easy to read and
>> understandable even to someone who is not well versed in SIP
>> terminology.
>> 
>> The security considerations section claims that the considerations
>> are similar to those of the standards documents such as RFC 7667 (RTP
>> topologies) and RFC 7656 (A Taxonomy of Semantics and Mechanisms for
>> Real-Time Transport Protocol (RTP) Sources). This seems reasonable.
>> It also describes why encryption is not an issue (if the B2BUA can
>> make some changes to the media stream, then it can also make the
>> changes described in this document, otherwise, it can’t make the
>> original changes either), and how failing to follow this document
>> might be indistinguishable from an attack (that’s the “bad things
>> happen” part)
>> 
>> Two nits:
>> 
>> - The Abstract says: “[B2BUAs] are often envisaged to also be on the
>> media path...This means that B2BUAs often implement an RTP/RTCP
>> stack...”. That doesn’t make sense with the dictionary definition of
>> “envisage”. Perhaps “designed”?
>> 
> 
> 
> Fair point, we'll fix this in next version.
> 
> 
>> - The first paragraph of the Security Considerations is pasted
>> below. I don’t think there is much semantic difference between
>> "considerations" and “aspects”. This paragraph denies that there are
>> considerations, and then goes on to state some. I think the whole
>> first paragraph can go.
>> 
>> Yoav
>> 
> 
> 
> What we wanted to stress out in this section is that we didn't have any
> specific behaviour to mandate in that sense, as other related documents
> do, but that we mostly wanted to underline some aspects to be wary of.
> I guess that a "Security Considerations" section can itself be even
> just about considerations, rather than rules, so I agree that it might
> be worthwhile to rephrase that first sentence to make what we meant
> clearer than it currently is. Do you think that something like
> 
> 	[..] does not specify any additional rule [..]
> 
> rather than
> 
> 	[..] does not introduce any additional consideration [..]

Sure. Although dropping that paragraph would also work.

Yoav