Re: [sidr] Fwd: I-D Action: draft-ietf-sidr-pfx-validate-02.txt

Pradosh Mohapatra <> Wed, 03 August 2011 06:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23B895E8009 for <>; Tue, 2 Aug 2011 23:53:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.932
X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ALrv+DvnCUCC for <>; Tue, 2 Aug 2011 23:53:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B0F1C5E8001 for <>; Tue, 2 Aug 2011 23:53:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1786; q=dns/txt; s=iport; t=1312354408; x=1313564008; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=gnWeekvfGLEu49uhOfA/xLqYyExE68OSbhjWHyZzM3A=; b=dcZggYoJhgO8g5Ab/YZftOp/jezmAZcTV4lvd4lO0A3DyU9sahG4zy5N hFb3WbVFh4lEqEf0KEP2xflyLO6Q3FqsQt6cIOKL7rTlvo2b58PJWKeTe crECIbGO91cdjKj95uDRR7yTLKoxXHJ3ysFkpXfjjE7fE+kJnTYw28HAn 0=;
X-IronPort-AV: E=Sophos;i="4.67,309,1309737600"; d="scan'208";a="9105691"
Received: from ([]) by with ESMTP; 03 Aug 2011 06:53:26 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p736rQjx000695; Wed, 3 Aug 2011 06:53:26 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Pradosh Mohapatra <>
In-Reply-To: <>
Date: Tue, 02 Aug 2011 23:58:13 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Roque Gagliano <>
X-Mailer: Apple Mail (2.1084)
Cc: " wg" <>
Subject: Re: [sidr] Fwd: I-D Action: draft-ietf-sidr-pfx-validate-02.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Aug 2011 06:53:25 -0000

Hi Roque,

Thanks for the review and comments.

> General Comment:
>   " Depending on the lookup result, we define a property for each route,
>    called the "validity state".  It can assume the values "valid", "not
>    found", or "invalid"."
> You may want to consider calling it "Origin AS validity state" to distinguish it from the validity state in BGPSEC ("valid" and "invalid").


> Section 1:
> p2: s/verifyable/verifiable


> Section 2:
>    "An AS can originate more than one
>    prefix set.  Thus, multiple prefix sets in the database can contain
>    the same origin AS(es)."
> I believe you also need to mention that in the table there may be "multi-origin prefixes". Geoff report identifies 2400 but you may find more in local/regional environments (

I looked at the document again and I see many places where we say there can be multiple origin ASes for the prefix. E.g.:

we define terms "UPDATE prefix" and "UPDATE origin
AS number" to denote the values derived from the received UPDATE message, and
"database prefix set" and "database origin AS number set" to mean the values
derived from the database lookup.

where it's defined as "database origin AS number set" instead of just an AS number.

> Section 5:
> p5: 
> I believe you should reference draft-ietf-sidr-origin-validation-signaling-00


> Security Consideration:
> I think you need to consider what you already mentioned in section 4, if the connectivity to the local-caches is lost, invalid routes will be classified as "not-found", which could have a different set of local policies.

Is this different from current behavior?

- Pradosh