Re: [GROW] WGLC: draft-ietf-grow-simple-leak-attack-bgpsec-no-help

Danny McPherson <danny@tcb.net> Wed, 14 May 2014 18:09 UTC

Return-Path: <danny@tcb.net>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5811A00E5 for <grow@ietfa.amsl.com>; Wed, 14 May 2014 11:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.551
X-Spam-Level:
X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham
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 kMDySm6Tlz4f for <grow@ietfa.amsl.com>; Wed, 14 May 2014 11:08:58 -0700 (PDT)
Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id CA5B91A00A6 for <grow@ietf.org>; Wed, 14 May 2014 11:08:58 -0700 (PDT)
Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id 1D9FB30004C for <grow@ietf.org>; Wed, 14 May 2014 18:08:52 +0000 (UTC)
Received: from mail2.tcb.net (localhost [127.0.0.1]) by mail.tcb.net (Postfix) with ESMTP id EDFC7300049; Wed, 14 May 2014 12:08:51 -0600 (MDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Wed, 14 May 2014 12:08:51 -0600
From: Danny McPherson <danny@tcb.net>
To: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <20140514164343.GC17907@pfrc>
References: <CAL9jLabRKA2gezfRdzND1TSYMJO+a_4mVV+M302cLBFTUwYmTQ@mail.gmail.com> <CF96AEDB.1B684%wesley.george@twcable.com> <CAL9jLaZ9J52Dt5n1Wk2KYTqwzmefGxvq-bRcfMfhWBNwf_6ZGg@mail.gmail.com> <CF978B01.1B737%wesley.george@twcable.com> <20140514135804.GJ16861@pfrc> <1b12d69966e5d355074c1ee5a2c32ff8@tcb.net> <20140514164343.GC17907@pfrc>
Message-ID: <8345b9d7e4316d45683c801c7def05d7@tcb.net>
X-Sender: danny@tcb.net
User-Agent: Roundcube Webmail/0.8.2
X-DSPAM-Result: Innocent
X-DSPAM-Processed: Wed May 14 12:08:52 2014
X-DSPAM-Confidence: 0.9899
X-DSPAM-Improbability: 1 in 9809 chance of being spam
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: 5373b13442071897035006
X-DSPAM-Factors: 27, 2014+05, 0.01000, Subject*Re+#+WGLC, 0.01000, the+#+#+the, 0.01000, see+if, 0.01000, we+can, 0.01000, On+#+05, 0.01000, is+#+to, 0.01000, is+#+to, 0.01000, On+2014, 0.01000, to+#+#+#+the, 0.01000, Subject*Re+#+#+draft-ietf-grow-simple-leak-attack-bgpsec-no-help, 0.01000, the+document, 0.01000, the+#+of, 0.01000, From*Danny+#+danny, 0.01000, From*Danny+#+#+tcb.net, 0.01000, Subject*GROW+#+draft-ietf-grow-simple-leak-attack-bgpsec-no-help, 0.01000, Subject*WGLC+draft-ietf-grow-simple-leak-attack-bgpsec-no-help, 0.01000, Cc*grow+ietf.org, 0.01000, From*Danny+McPherson, 0.01000, Subject*GROW+WGLC, 0.01000, of+the, 0.01000, Subject*Re+GROW, 0.01000, this+problem, 0.01000, From*McPherson+danny, 0.01000, Jeffrey+Haas, 0.01000, the+#+and, 0.01000, From*Danny McPherson <danny@tcb.net>, 0.01000
Archived-At: http://mailarchive.ietf.org/arch/msg/grow/f6_FSm_ffzV4QkgluJfec7jBfT8
Cc: grow@ietf.org
Subject: Re: [GROW] WGLC: draft-ietf-grow-simple-leak-attack-bgpsec-no-help
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 18:09:00 -0000

On 2014-05-14 10:43, Jeffrey Haas wrote:

> If you stop claiming that bgpsec is there to prevent this and reframe 
> the
> document as "bgpsec can't stop route leaks", I'm fine with that.

Indeed it's not about MITM to BGPSEC itself, it's about BGPSEC not 
solving this problem.

Perhaps "the MITM attack enabled by the route leak that even a 
fully-deployed BGPSEC is unable to prevent" is indeed the crux of the 
issue ;-) .. and I understand your point.  Let me circle back with see 
if we can find a way to accommodate this distinction.

-danny