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

Yoav Nir <> Tue, 11 October 2016 16:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C6E9129609; Tue, 11 Oct 2016 09:51:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.976
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EPdpp2RzDNWc; Tue, 11 Oct 2016 09:51:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EBC49129502; Tue, 11 Oct 2016 09:51:35 -0700 (PDT)
Received: by with SMTP id z190so44977586qkc.2; Tue, 11 Oct 2016 09:51:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id pl1mr6228601wjb.81.1476204695055; Tue, 11 Oct 2016 09:51:35 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id hb5sm7832393wjc.5.2016. (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: <>
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 <>,
Subject: Re: [secdir] SecDir review of draft-ietf-straw-b2bua-rtcp-13
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

> On 11 Oct 2016, at 19:46, Lorenzo Miniero <> 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 < <>> 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.