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

[Lorenzo Miniero <[e-mail]>]

On Tue, 11 Oct 2016 19:51:29 +0300
Yoav Nir <[e-mail]> wrote:

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


Thanks! I'll do that in the next version of the document, then.

Lorenzo