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