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

Lorenzo Miniero <lorenzo@meetecho.com> Tue, 11 October 2016 16:53 UTC

Return-Path: <lorenzo@meetecho.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC47612965A for <secdir@ietfa.amsl.com>; Tue, 11 Oct 2016 09:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.898
X-Spam-Level:
X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_SBL=1.623, URIBL_SBL_A=0.1] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBcDYiUPXI18 for <secdir@ietfa.amsl.com>; Tue, 11 Oct 2016 09:53:45 -0700 (PDT)
Received: from smtpcmd05149.aruba.it (smtpweb149.aruba.it [62.149.158.149]) by ietfa.amsl.com (Postfix) with ESMTP id 4291712965E for <secdir@ietf.org>; Tue, 11 Oct 2016 09:53:41 -0700 (PDT)
Received: from lminiero ([93.44.60.74]) by smtpcmd05.ad.aruba.it with bizsmtp id uGtg1t0071c60R101GtgwA; Tue, 11 Oct 2016 18:53:40 +0200
Date: Tue, 11 Oct 2016 18:53:39 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Message-ID: <20161011185339.51bd9947@lminiero>
In-Reply-To: <08FE41B8-679D-45A7-855D-C6C51780D278@gmail.com>
References: <BD4F5033-7DF8-4D3C-996B-7DB06EB0CC88@gmail.com> <20161011184627.19a46214@lminiero> <08FE41B8-679D-45A7-855D-C6C51780D278@gmail.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/UA6qSM0gVtImKRZFU94D-62PHIM>
Cc: secdir <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-straw-b2bua-rtcp.all@tools.ietf.org
Subject: Re: [secdir] SecDir review of draft-ietf-straw-b2bua-rtcp-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Oct 2016 16:53:48 -0000

On Tue, 11 Oct 2016 19:51:29 +0300
Yoav Nir <ynir.ietf@gmail.com> wrote:

> > On 11 Oct 2016, at 19:46, Lorenzo Miniero <lorenzo@meetecho.com>
> > 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 <ynir.ietf@gmail.com <mailto:ynir.ietf@gmail.com>> 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