Return-Path: 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 5C6E9129609; Tue, 11 Oct 2016 09:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.976 X-Spam-Level: X-Spam-Status: No, score=-0.976 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_SBL=1.623, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EPdpp2RzDNWc; Tue, 11 Oct 2016 09:51:36 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC49129502; Tue, 11 Oct 2016 09:51:35 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id z190so44977586qkc.2; Tue, 11 Oct 2016 09:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=m9eQnJSO8v0SuozsBEgCA5n/Hr9E9QhExdZz0J+/dzA=; b=XEjFTszto1f0JXOFEEJM+ZN60i+H3bvFN3AlzyI0mo28RCJ/fE9rBO2bYFAVz8E9wS yglKrUzeUWD7xG40+9hoV6HqofWT4PRyu6PtxxFqlJ2q08JbUy7R8VPrQf677JWBux9N f8MOvLS3J1HG0E5rdgwIPAIWYJfZ02BEYFIzxnyQGV4c/ZiUfmwXG16FelgBBvy5mEX8 okJUqLgZ2e97dQFJlrp8witxvf0HJyOTbhPXukW6bqk+cyqFRrukXUe3NwEC9OOfh/q2 XcYl3MaQke4bzNB2v+/b0DquMBN26g7X/tQLtB3MK1jt4II9MJbFCMyqMcUHe5eDZkZp IXVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=m9eQnJSO8v0SuozsBEgCA5n/Hr9E9QhExdZz0J+/dzA=; b=cvt9Udha6FfPd/l9cX77XKIPTHUebQhRDBlcxR/ytQasSGxLMeApx7ijXzEu9dQ9vr APb8Wf96MU91w5BzfK+fo41c1sQHEUvuSPd/oGab9deTEijDRctkLbUuQJbhxQAdGY84 jmHiFoOqfu0UFAAWH+gcxoPwxg7f2AimUJN/L5g2fOIIrfNBu42aLcvM7ZxOEp1bEvpW dZou5AbdTyhzJwIFm1mjsqS+JWxI5vzLHv5UvblO9LLu8kfsMSU636Lw+iS4wrAyf6WL GpIIEtNpjSepsQbUTMsHji/3jKRt2qxydrFya9h04WaVfK6TcuLnKTokF0PfJFZnb+Ge osAQ== X-Gm-Message-State: AA6/9RniXZ6js41hjAQLMNvhbG4pTcQSmG84MqKki9CZcUGqjvXfLEVhMXO7AoYmSJQG8A== X-Received: by 10.194.134.161 with SMTP id pl1mr6228601wjb.81.1476204695055; Tue, 11 Oct 2016 09:51:35 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id hb5sm7832393wjc.5.2016.10.11.09.51.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Oct 2016 09:51:33 -0700 (PDT) From: Yoav Nir Message-Id: <08FE41B8-679D-45A7-855D-C6C51780D278@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_52A86740-5E1D-4A34-8721-45B10A60C2D4" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Tue, 11 Oct 2016 19:51:29 +0300 In-Reply-To: <20161011184627.19a46214@lminiero> To: Lorenzo Miniero References: <20161011184627.19a46214@lminiero> X-Mailer: Apple Mail (2.3226) Archived-At: Cc: secdir , The IESG , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 16:51:38 -0000 --Apple-Mail=_52A86740-5E1D-4A34-8721-45B10A60C2D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Oct 2016, at 19:46, Lorenzo Miniero = wrote: >=20 > Hello Yoav, >=20 > 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. >=20 >=20 > On Sun, 9 Oct 2016 09:57:26 +0300 > Yoav Nir > wrote: >=20 >> Hello, >>=20 >> I have reviewed this document as part of the security directorate=E2=80= =99s >> 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. >>=20 >> Summary: Ready with nits >>=20 >> 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 =E2=80=9Cif you change this, you also have to change that, = otherwise >> this bad thing could happen.=E2=80=9D The document is easy to read = and >> understandable even to someone who is not well versed in SIP >> terminology. >>=20 >> 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=E2=80=99t make = the >> original changes either), and how failing to follow this document >> might be indistinguishable from an attack (that=E2=80=99s the =E2=80=9C= bad things >> happen=E2=80=9D part) >>=20 >> Two nits: >>=20 >> - The Abstract says: =E2=80=9C[B2BUAs] are often envisaged to also be = on the >> media path...This means that B2BUAs often implement an RTP/RTCP >> stack...=E2=80=9D. That doesn=E2=80=99t make sense with the = dictionary definition of >> =E2=80=9Cenvisage=E2=80=9D. Perhaps =E2=80=9Cdesigned=E2=80=9D? >>=20 >=20 >=20 > Fair point, we'll fix this in next version. >=20 >=20 >> - The first paragraph of the Security Considerations is pasted >> below. I don=E2=80=99t think there is much semantic difference = between >> "considerations" and =E2=80=9Caspects=E2=80=9D. This paragraph denies = that there are >> considerations, and then goes on to state some. I think the whole >> first paragraph can go. >>=20 >> Yoav >>=20 >=20 >=20 > 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 >=20 > [..] does not specify any additional rule [..] >=20 > rather than >=20 > [..] does not introduce any additional consideration [..] Sure. Although dropping that paragraph would also work. Yoav --Apple-Mail=_52A86740-5E1D-4A34-8721-45B10A60C2D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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> wrote:

Hello,

I have reviewed this document as part of the security = directorate=E2=80=99s
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 =E2=80=9Ci= f you change this, you also have to change that, otherwise
this bad thing could happen.=E2=80=9D 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=E2=80=99t= make the
original changes either), and how failing to = follow this document
might be indistinguishable from an = attack (that=E2=80=99s the =E2=80=9Cbad things
happen=E2=80=9D= part)

Two nits:

- The Abstract says: =E2=80=9C[B2BUAs] are often envisaged to = also be on the
media path...This means that B2BUAs often = implement an RTP/RTCP
stack...=E2=80=9D. That doesn=E2=80=99= t make sense with the dictionary definition of
=E2=80=9Cenvisage=E2=80=9D. Perhaps =E2=80=9Cdesigned=E2=80=9D?=



Fair point, we'll fix this in next = version.


- The first paragraph of the = Security Considerations is pasted
below. I don=E2=80=99t = think there is much semantic difference between
"considerations" and =E2=80=9Caspects=E2=80=9D. 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

= --Apple-Mail=_52A86740-5E1D-4A34-8721-45B10A60C2D4--