Re: [sidr] is a longer announce invalid or not found?

"Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov> Mon, 03 October 2011 17:20 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
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 AA69F21F8C70 for <sidr@ietfa.amsl.com>; Mon, 3 Oct 2011 10:20:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.849
X-Spam-Level:
X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 gVBPzQpKPWgA for <sidr@ietfa.amsl.com>; Mon, 3 Oct 2011 10:20:58 -0700 (PDT)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id B3E8321F8C3F for <sidr@ietf.org>; Mon, 3 Oct 2011 10:20:57 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 3 Oct 2011 13:23:51 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 3 Oct 2011 13:23:54 -0400
From: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
To: sidr wg list <sidr@ietf.org>
Date: Mon, 03 Oct 2011 13:23:53 -0400
Thread-Topic: [sidr] is a longer announce invalid or not found?
Thread-Index: Acx/Hw2RLMAZtozmSV2Ax3OT7xaxPgCz+oKA
Message-ID: <D7A0423E5E193F40BE6E94126930C49308E30ED214@MBCLUSTER.xchange.nist.gov>
References: <m2d3eilpnq.wl%randy@psg.com> <FDCBC152-8720-4C9C-AD81-0CFC780DB341@cisco.com>
In-Reply-To: <FDCBC152-8720-4C9C-AD81-0CFC780DB341@cisco.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [sidr] is a longer announce invalid or not found?
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: Mon, 03 Oct 2011 17:20:58 -0000

For the benefit of the WG members,
I would like to point out that the Use Cases and Interpretation
doc (draft-ietf-sidr-usecases-02) should also be quite useful
in the context of this discussion (complementing Pradosh's/Randy's 
explanations (below) and Section 3 in draft-ietf-sidr-origin-ops-10).

In Sections 3.3 and 3.4 in the Use Cases doc -
http://tools.ietf.org/html/draft-ietf-sidr-usecases-02#section-3.3  
it is pointed out by examples that max-length should be used
in a restrained manner (similar to Randy's example below)
when more specific prefixes are intended to be originated from 
the same AS or a different (say, customer) AS.

Also, if you are interested in enumeration of use cases pertaining to
validation outcomes vis-à-vis existence of certain ROAs and
max-length in the ROAs, then Section 7.1 is worth a read as well.
http://tools.ietf.org/html/draft-ietf-sidr-usecases-02#section-7.1 

Sriram

> -----Original Message-----
> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Pradosh
> Mohapatra
> Sent: Thursday, September 29, 2011 11:21 PM
> To: Randy Bush
> Cc: sidr wg list
> Subject: Re: [sidr] is a longer announce invalid or not found?
> 
> > there has been a bit of confusion over whether announcement of a longer
> > prefix than is covered by a roa is valid, invalid, or not found.  so let
> > me try to clarify the underlying decision process for valid, invalid,
> > and not found so we are all on the same page.  i believe this is as it
> > is documented in pfx-validate.
> 
> 
> I concur.
> 
> From a partial deployment perspective, it does mean that once a ROA is
> published for an address block (and follows the ops guideline of being precise),
> further sub-allocations NEED to have the ROA published. Otherwise, they
> would be marked invalid and risk being not routed.
> 
> - Pradosh
> 
> >
> > ---
> >
> > if i publish a roa for 10.0.0.0/16-16 for AS 42 (and there are no other
> > roas for 10/...)
> >
> > no announcement of 10.0.0.0/16 or any longer prefix thereof from any AS
> > may be marked NOT FOUND, after all, a covering roa is there.
> >
> > any announcement of any prefixes in that space, from /16 to /32, from an
> > AS other than 42 are INVALID.  this is the purpose of the exercise.
> >
> > and, an announcement of 10.0.666.0/24 from AS 42 is INVALID, as it has a
> > prefix length not specified by the roa.  someone is trying to punch a
> > hole, not allowed.  this could be an origin forger trying to punch a /24
> > in my /16.
> >
> > but if i publish a roa for 10.0.0.0/16-24 for AS 42, then an
> > announcement for 10.0.666.0/24 from AS 42, would be marked VALID.
> >
> > randy