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

[Lorenzo Miniero <[e-mail]>]

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

would do that?

Thanks!
Lorenzo