Re: [sidr] Question about draft-ietf-sidr-pfx-validate-03

Brian Dickson <> Sat, 12 November 2011 17:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D866021F86D0 for <>; Sat, 12 Nov 2011 09:48:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.548
X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 32CXJqj2nRmj for <>; Sat, 12 Nov 2011 09:48:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 018E521F867F for <>; Sat, 12 Nov 2011 09:48:27 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so5339515bkb.31 for <>; Sat, 12 Nov 2011 09:48:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zDmcXvcABJ0hsCiEwgHW238J7N4QuwqBxy8w8bwgN+k=; b=mrsIjHLA3Exnt9X2tN3ZyRcHmiF+/8S4mP2NWSYbrigkDkdiLlpPm+Xf1EuGJtFHHl fylfvF+zZg/D1DB+hBxRfn5H55XGTW6LH0Vs15FKj5BD1VQpR4zWp11OLS8LKZhqdkWR N3qovibI8afedC+63wauL1xsffVAL86tcqEpM=
MIME-Version: 1.0
Received: by with SMTP id iq17mr5072333bkc.118.1321120106985; Sat, 12 Nov 2011 09:48:26 -0800 (PST)
Received: by with HTTP; Sat, 12 Nov 2011 09:48:26 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Sat, 12 Nov 2011 12:48:26 -0500
Message-ID: <>
From: Brian Dickson <>
To: Danny McPherson <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: sidr wg list <>
Subject: Re: [sidr] Question about draft-ietf-sidr-pfx-validate-03
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: Sat, 12 Nov 2011 17:48:29 -0000

I think the current design of BGPsec as memorialized (love that word) in the
draft-ietf-sidr-bgpsec-protocol would need to be tweaked to handle this.

I also believe that the result of the proposed tweak, will be a cleaner design
which is easier to implement and verify, as well as not incurring significant
operational cost in terms of signatures.

Local origination SHOULD occur within an AS on a permanent
basis, and only the announcements from the actual originating router need
to have unique signatures, regardless of whether they are iBGP or eBGP.

(Crypto geeks might suggest adding a random "nonce" to make the signature
a little harder to crack, since very little on the signature material
will change
over time - but that is another discussion.)

Here is the tweak:

                      Sequence of Octets to be Signed
                 | Expire Time (8 octets)                |
                 | Origin AS Number (4 octets)           |
                 | Algorithm Suite Identifier  (1 octet) |
                 | NLRI Length  (1 octet)                |
                 | NLRI Prefix  (variable)               |

The "Target AS" and "pCount" need to be added, meaning the minimum
number of signatures
changes to "one origin" and "one propagation" signature.

For iBGP within the originating AS, the signature would be "Target AS
== origin AS", and "pCount == 0".

For eBGP, it would be what you expect, "Target AS == neighbor", "pCount > 0".

I think that's all that is needed, and the rest of the validation
logic in the -protocol doc remain good,
the -ops-reqs doc allows validation for local AS, and pfx-validate also works.

Any detail or logic errors in the above can be attributed to not
enough caffeine... The gist of the above
should be solid enough, though.


On Sat, Nov 12, 2011 at 11:54 AM, Danny McPherson <> wrote:
> My read of the current draft suggests that if there's a route generated by
> the
> local AS in BGP it could never have a "Valid" state, and by definition
> would
> either posses a "Not found" or "Invalid" state -- even though the local
> AS may well have a "ROA" and reside in the mapping table as well(!).
> I do not believe the current text is Section 5 is sufficient to address this
> case,
> specifically with either this:
> "Considering invalid routes for BGP decision process is
> a pure local policy matter and should be done with utmost care."
> or this:
> "In some cases (particularly when the selection algorithm is
> influenced by the adjustment of a route property that is not
> propagated into IBGP) it could be necessary for routing
> correctness to propagate the validation state to the IBGP
> peer. This can be accomplished on the sending side by setting
> a community or extended community based on the validation
> state, and on the receiving side by matching the (extended)
> community and setting the validation state."
> I could think of a number of way to address this, but for there to exist
> the
> possibility that an internally generated prefix (for which a ROA may well
> exists)
> could NEVER have a "Valid" state needs to be corrected.
> Also, S 4:  s/to rest of the network/to the rest of the network/
> Thanks,
> -danny
> _______________________________________________
> sidr mailing list