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

"John G. Scudder" <> Tue, 21 April 2015 14:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E303B1ACD44; Tue, 21 Apr 2015 07:05:02 -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 HLyBT9vGnzBt; Tue, 21 Apr 2015 07:04:56 -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 2DD891ACD5A; Tue, 21 Apr 2015 07:04:52 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 21 Apr 2015 14:04:51 +0000
Authentication-Results:; dkim=none (message not signed) header.d=none;
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 21 Apr 2015 14:04:47 +0000
Content-Type: multipart/mixed; boundary="Apple-Mail=_2540DD39-1C7B-4883-8DB0-8C09F92C7E8D"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: "John G. Scudder" <>
In-Reply-To: <>
Date: Tue, 21 Apr 2015 10:04:36 -0400
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:BLUPR05MB420;
X-Microsoft-Antispam-PRVS: <>
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(51704005)(33656002)(77156002)(87976001)(40100003)(2950100001)(46102003)(83716003)(62966003)(57306001)(92566002)(77096005)(42186005)(5890100001)(36756003)(568964001)(230783001)(86362001)(50226001)(19580395003)(4610100001)(122386002)(84326002)(53416004)(19580405001)(66066001)(512944002)(50986999)(76176999)(82746002)(110136001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB722;; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BLUPR05MB722; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB722;
X-Forefront-PRVS: 0553CBB77A
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Apr 2015 14:04:47.0292 (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: Tue, 21 Apr 2015 14:05:03 -0000

Stephen, thanks very much for the text.

All, unless there are any objections, I'd like to adopt Stephen's text as written. I've attached a version 19 that I believe takes in all the requested and agreed-to changes. I'll post it at the end of today unless there are further comments.

– John

On Apr 20, 2015, at 3:56 PM, Stephen Farrell <> wrote:

> I'd suggest this, but am fine if you prefer to omit it, or edit it:
> "The improved error handling of this specification could in theory
> interact badly with some now-known weaker cryptographic mechanisms
> should such be used in future to secure BGP. For example, if a
> (fictional) mechanism that did not supply data integrity was used,
> an attacker could manipulate ciphertext in any attempt to change
> or observe how the receiver reacts. Absent this specification, the
> BGP session would have been terminated, while with this specification
> the attacker could make potentially many attempts. While such a
> confidentiality-only mechanism would not be defined today, we have
> in the past seen mechanism definitions that result in similar though
> not as obviously exploitable vulnerabilities. [RFC7366] The approach
> recommended today to avoid such issues is to prefer use of
> Authenticated Encryption with Additional Data (AEAD) ciphers [RFC5116]
> and (thus) to discard messages that don't verify."