Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: "John G. Scudder" <jgs@juniper.net>
In-Reply-To: <20150310141226.24491.44397.idtracker@ietfa.amsl.com>
Date: Mon, 20 Apr 2015 13:46:22 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <AB9347AD-C41C-4384-B91E-4A099B003F55@juniper.net>
References: <20150310141226.24491.44397.idtracker@ietfa.amsl.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2015 17:46:29.8919 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB722
X-OriginatorOrg: juniper.net
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/VEpZcevbd7MpZoKHWaeAF4IxkL8>
Cc: "idr@ietf. org" <idr@ietf.org>, rob.shakir@bt.com,
 draft-ietf-idr-error-handling.all@ietf.org, The IESG <iesg@ietf.org>,
 idr-chairs@ietf.org
Subject: Re: [Idr] Stephen Farrell's No Objection on
 draft-ietf-idr-error-handling-18: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>,
 <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>,
 <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Apr 2015 17:46:39 -0000

Hi Stephen,

I'm doing a final update of the draft to cover comments in IE SG review. =
I'd like to discuss yours a bit.

On Mar 10, 2015, at 10:12 AM, Stephen Farrell =
<stephen.farrell@cs.tcd.ie> wrote:

> - There is a perhaps missing security consideration. I think
> this kind of protocol behaviour argues that any kind of
> BGPSEC encryption needs to use an AEAD ciphersuite.  (Which
> we'd likely do these days anyway, so that's not a biggie.)
> The reason is if say CBC or a stream cipher were used, then
> an attacker could play with ciphertext is various ways that
> might interact with this error handling behaviour so as to
> expose information that is intended to be protected by the
> BGPSEC mechanism. Such an attack would probably be
> pooh-poohed by all but tin foil hat folks, but it could
> still be worth noting (maybe in section 8?) and as we've
> seen recently, many of the tin foil hat fears turn out to be
> realistic, sadly.

Since you balloted "no objection", would I be right to think you won't =
have a cow if we don't make this change? I confess to not knowing the =
difference between AEAD and a hole in the ground nor do I understand the =
attack you allude to, so at the least I would have to find someone to =
either educate me or write the text for me. So far we haven't considered =
confidentiality to be important for BGP security -- although you =
reference encryption in connection with BGPSEC, BGPSEC is actually =
entirely about integrity and authenticity and specifically disclaims =
confidentiality, see draft-ietf-sidr-bgpsec-threats-09.

If you feel strongly about having this covered, I'd appreciate if you =
pointed me at someone who could help with education and/or specific =
text.

> I noted a few nitty nits:
>=20
> - section 2: AFI/SAFI are used without expansion

Will fix.

> - 3.d: "well-known mandatory attributes" sort of yells for a
> reference, doesn't it.

At first I was going to agree with you, but then I reminded myself that =
the entirety of section 3 is a set of amendments to RFC 4271, Section =
6.3, and says so in its first paragraph. As such, one might think the =
reference in the first paragraph ought to be sufficient. I'm not dead =
set against the extra reference if you feel strongly, but it does seem =
redundant so for now I'm not adding it.

> - 3.e: "cases that specify" - specify where? I think you
> mean in the updated RFCs but it might be nice to say that

Actually we mean the cases enumerated in RFC 4271 Section 6.3, again as =
indicated in the first paragraph. I do think this would be clear to =
someone who had reviewed that reference (which I don't fault you for not =
having done) so again, I'm going to refrain from repeating the reference =
here unless you want to make a further case for it.

> - 5: NRLI is expanded after 1st use

Okay.

Thanks for the comments,

=96 John=