Re: [GROW] last call for draft-ietf-grow-unique-origin-as-00
John Kristoff <jtk@cymru.com> Wed, 22 December 2010 22:50 UTC
Return-Path: <jtk@cymru.com>
X-Original-To: grow@core3.amsl.com
Delivered-To: grow@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EB113A68D6 for <grow@core3.amsl.com>; Wed, 22 Dec 2010 14:50:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJmveuc--D4D for <grow@core3.amsl.com>; Wed, 22 Dec 2010 14:50:46 -0800 (PST)
Received: from obelisk11.ord01.cymru.com (obelisk11.ord01.cymru.com [38.229.66.8]) by core3.amsl.com (Postfix) with ESMTP id 64E6F3A68BE for <grow@ietf.org>; Wed, 22 Dec 2010 14:50:46 -0800 (PST)
Received: from t61p (vpn-21-32.svcs.iad01.cymru.com [192.168.21.32]) by obelisk11.ord01.cymru.com (Postfix) with ESMTP id 1B26EB02FB; Wed, 22 Dec 2010 22:52:45 +0000 (GMT)
Date: Wed, 22 Dec 2010 16:52:44 -0600
From: John Kristoff <jtk@cymru.com>
To: Peter Schoenmaker <pds@lugs.com>
Message-ID: <20101222165244.43538b0f@t61p>
In-Reply-To: <050e01cb9da6$95d88c80$c189a580$@lugs.com>
References: <050e01cb9da6$95d88c80$c189a580$@lugs.com>
X-Mailer: Claws Mail
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: grow@ietf.org
Subject: Re: [GROW] last call for draft-ietf-grow-unique-origin-as-00
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 22 Dec 2010 22:50:47 -0000
On Fri, 17 Dec 2010 12:54:55 +0800 "Peter Schoenmaker" <pds@lugs.com> wrote: > Please review the draft and provide any last comments. My thanks to Danny for prodding me to review it and comment. There are a handful of spelling mistakes and some words that are if not found in the OED, are at least uncommon (e.g. influencer's). Some sentences are also quite lengthy and come across awkward, at least to me. For instance, Tools such as traceroute are also used to determine which location a given query is being routed to, although it may not reveal local-scope anycast instances, or if there are multiple servers within a given anycast node, which of the servers responded to a given query, in particular when multiple servers within an anycast node are connected to a single IP router. could perhaps be rewritten as: Tools such as traceroute are also used to help determine which location a given query is being routed to. However, they may not reveal local-scope anycast instances, if there are multiple servers within a given anycast node or which of the servers responded to a given query. This sentence: This detection model would need to be expanded to account for unique origin ASNs per node if a given service operators chooses to employ such as a model, and given that AS paths are trivial to manipulate, the above technique would only assist in the event of unintentional configuration errors that reoriginate the route (e.g., it doesn't even detect leaks that preserve the initial path elements). could perhaps be rewritten as: This detection model would need to be expanded to account for unique origin ASNs per node. Given that AS paths may be manipulated, the above technique would only assist in the event of unintentional configuration errors that re-originate the route. That is, the technique doesn't detect leaks that preserve the initial path elements. The abstract states this is for "critical" infrastructure and only eludes to what that is by later mentioning DNS root and TLD servers as examples. Perhaps either make this explicitly for root and TLD servers, deal with what critical means or just make this is a generally accepted practice. That said, is there any current deployment of this technique? I'd be interested in reviewing any papers or case studies. If not, I think it would be prudent to have some before publication. I want to make sure the following paragraph is justified: Furthermore, inconsistent origin AS announcements associated with anycasted services for critical infrastructure SHOULD NOT be deemed undesirable by routing system reporting functions, but should instead be embraced in order to better identify the connectedness and footprint of a given anycasted service. This document is making the case for this technique around management and policy improvements, but I have some questions with how complete the arguments are. First, there is no discussion of BGP attributes, particular communities, which would seem to be a viable policy alternative to unique origin ASNs. Second, the document isn't convincing when it claims unique origin ASNs "would enable detection of leaked or hijacked instances more quickly". Adding more origin ASNs would just seem to complicate matters, because now you not only need to know the path, but also which origin ASN goes with each path. It may also actually broaden the attack surface. Examples might help me better understand what I'm missing. I think the following statement is irrelevant and best removed: Additionally, critical infrastructure employment of 32-bit ASNs for new nodes might well help to foster adoption of native 32-bit ASN support by network operators. The discussion about potential benefits for RPKI is interesting, but seems to be putting the cart before the horse. I'm not up on the SIDR work, but if along the lines of my earlier comment, communities along with the announced prefix were validated, would that help? John
- [GROW] last call for draft-ietf-grow-unique-origi… Peter Schoenmaker
- Re: [GROW] last call for draft-ietf-grow-unique-o… Terry Manderson
- Re: [GROW] last call for draft-ietf-grow-unique-o… Shane Amante
- Re: [GROW] last call for draft-ietf-grow-unique-o… Robert Raszuk
- Re: [GROW] last call for draft-ietf-grow-unique-o… Roland Dobbins
- Re: [GROW] last call for draft-ietf-grow-unique-o… Ben Niven-Jenkins
- Re: [GROW] last call for draft-ietf-grow-unique-o… Warren Kumari
- Re: [GROW] last call for draft-ietf-grow-unique-o… Matsuzaki Yoshinobu
- Re: [GROW] last call for draft-ietf-grow-unique-o… marcelo bagnulo braun
- Re: [GROW] last call for draft-ietf-grow-unique-o… Roland Dobbins
- Re: [GROW] last call for draft-ietf-grow-unique-o… marcelo bagnulo braun
- Re: [GROW] last call for draft-ietf-grow-unique-o… Roland Dobbins
- Re: [GROW] last call for draft-ietf-grow-unique-o… marcelo bagnulo braun
- Re: [GROW] last call for draft-ietf-grow-unique-o… Roland Dobbins
- Re: [GROW] last call for draft-ietf-grow-unique-o… marcelo bagnulo braun
- Re: [GROW] last call for draft-ietf-grow-unique-o… Gaurab Raj Upadhaya
- Re: [GROW] last call for draft-ietf-grow-unique-o… Joe Abley
- Re: [GROW] last call for draft-ietf-grow-unique-o… John Kristoff
- Re: [GROW] last call for draft-ietf-grow-unique-o… Arturo Servin