Re: [sidr] 4-byte vs 2 byte ASN (was re: I-D Action: draft-ietf-sidr-pfx-validate-03.txt)

"George, Wes" <wesley.george@twcable.com> Wed, 02 November 2011 16:38 UTC

Return-Path: <wesley.george@twcable.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E33411E8090 for <sidr@ietfa.amsl.com>; Wed, 2 Nov 2011 09:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.295
X-Spam-Level:
X-Spam-Status: No, score=-0.295 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irl4qtcp0Iun for <sidr@ietfa.amsl.com>; Wed, 2 Nov 2011 09:38:38 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4B511E80C1 for <sidr@ietf.org>; Wed, 2 Nov 2011 09:38:37 -0700 (PDT)
X-SENDER-IP: 10.136.163.14
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.69,443,1315195200"; d="scan'208";a="277382845"
Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 02 Nov 2011 12:34:21 -0400
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 2 Nov 2011 12:38:36 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: Randy Bush <randy@psg.com>
Date: Wed, 02 Nov 2011 12:38:35 -0400
Thread-Topic: [sidr] 4-byte vs 2 byte ASN (was re: I-D Action: draft-ietf-sidr-pfx-validate-03.txt)
Thread-Index: AcyZFI4qQ/iuoR5/RLKr+JxDf05Y5gASCZ5g
Message-ID: <DCC302FAA9FE5F4BBA4DCAD46569377914517EE7BA@PRVPEXVS03.corp.twcable.com>
References: <20111031182058.24592.70473.idtracker@ietfa.amsl.com> <DCC302FAA9FE5F4BBA4DCAD4656937791451740474@PRVPEXVS03.corp.twcable.com> <m2wrbj6ugq.wl%randy@psg.com>
In-Reply-To: <m2wrbj6ugq.wl%randy@psg.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] 4-byte vs 2 byte ASN (was re: I-D Action: draft-ietf-sidr-pfx-validate-03.txt)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Nov 2011 16:38:39 -0000

> -----Original Message-----
> From: Randy Bush [mailto:randy@psg.com]
>
> aven i, an old fuddy duddy, kinda assume that an AS number is two or
> four bytes, an ip address is ipv4 or ipv6, etc.  i can understand
> clarifying once in a document where it is critical to do so, but would
> not be inclined to make it explicit everywhere AS is used or ip address
> is used.
>
> randy
[WEG] And I agree with the notion that unless specified as one or the other, it means the combination. However, especially in documents dealing with the mechanics of wrangling the bits on the router, that is not an implementation detail I want to leave purely to assumption/interpretation. Doesn't have to be stated and restated ad infinitum, I simply mention the other docs because I wasn't 100% certain where it made the most sense to cover it.

Based on the comments thus far, sounds like the questions are:

Q1) is RFC4893 support a prerequisite for those routers supporting SIDR Origin and Path validation
A: Yes.
I believe that this needs to be explicitly documented, where is the most appropriate location?

Q2) Do we need to incorporate something like: "MUST validate the AS Path _after_ reconstruction using AS4_PATH in the case where routing information comes from a peer which doesn't recognize 4-byte ASNs" as John suggested?

Q3) do we need some sort of language recommending a method to handle AS23456 as an origin (or in a path in the case of BGPSec), especially if it does not coincide with valid AS4_PATH info?
Technically if we're saying 4893 is a prereq, this shouldn't happen, but I could see it as a possible attack vector if we don't explicitly cover it.


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.