Re: [Idr] Stephen Farrell's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT)

"John G. Scudder" <> Mon, 20 April 2015 17:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3BB081A039B; Mon, 20 Apr 2015 10:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4YSKpulAFurZ; Mon, 20 Apr 2015 10:46:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A6011A00F6; Mon, 20 Apr 2015 10:46:34 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 20 Apr 2015 17:46:33 +0000
Authentication-Results:; dkim=none (message not signed) header.d=none;
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 20 Apr 2015 17:46:29 +0000
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: "John G. Scudder" <>
In-Reply-To: <>
Date: Mon, 20 Apr 2015 13:46:22 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: []
X-ClientProxiedBy: ( To (
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB722; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB419;
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(52314003)(50226001)(19580395003)(36756003)(76176999)(50986999)(110136001)(23746002)(82746002)(53416004)(19580405001)(66066001)(40100003)(47776003)(87976001)(83716003)(2950100001)(46102003)(33656002)(77156002)(57306001)(42186005)(230783001)(86362001)(92566002)(50466002)(62966003)(77096005)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB722;; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Microsoft-Antispam-PRVS: <>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BLUPR05MB722; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB722;
X-Forefront-PRVS: 05529C6FDB
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
Archived-At: <>
Cc: "idr@ietf. org" <>,,, The IESG <>,
Subject: Re: [Idr] Stephen Farrell's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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:
> - 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


Thanks for the comments,

– John