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

From: Yoav Nir <[email-masked]>
Date: Sun, 9 Oct 2016 09:57:26 +0300

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

 - 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

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 11 Oct 2016 18:46:27 +0200

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 <[email-masked]> 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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 11 Oct 2016 19:51:29 +0300

> On 11 Oct 2016, at 19:46, Lorenzo Miniero <[email-masked]> wrote:
> 
> Hello Yoav,
> 
> Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hello,
>> 

Sure. Although dropping that paragraph would also work.

Yoav

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 11 Oct 2016 18:53:39 +0200

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

> > 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.
> > 
> > 
> >> 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.
> >> 
> >> 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”?
> >>   
> > 
> > 
> >> "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
> > 

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

Lorenzo