Subject: [sidr] comment on draft-ietf-sidr-bgpsec-protocol and draft-ietf-sidr-bgpsec-ops

From: Sandra Murphy <[email-masked]>
Date: Thu, 24 Jul 2014 14:54:06 -0400

Speaking as regular ol' member

The bgpsec-protocol draft has the following text:

   Next, the BGPSEC speaker verifies that the origin AS is authorized to
   advertise the prefix in question.  To do this, consult the valid ROA
   data to obtain a list of AS numbers that are associated with the
   given IP address prefix in the update message.  Then locate the last
   (least recently added) AS number in the Secure_Path portion of the
   BGPSEC_Path attribute.  If the origin AS in the Secure_Path is not in
   the set of AS numbers associated with the given prefix, then the
   BGPSEC update message is 'Not Valid' and the validation algorithm
   terminates.

This text reprises the origin validation algorithm, without some of the more detailed pieces.

I believe it would be better instead to refer to RFC6483 or RFC6811, rather than try to reprise the algorithm.  Something like:  "To do this, the speaker performs the algorithm of RFC6483/RFC6811.  If the result is not Valid, then the BGP Update is 'Not Valid'."

(This seems particularly prudent as we might be reconsidering the validation algorithm.)

This also brought to mind a point I'm curious about.  

Does a bgpsec speaking router have one configuration about the results of the bgpsec validation, or does it have two configurations, one for the results of the origin validation and a second for the results of the bgpsec validation?  Are the two validation states separated?

Should this be a point to be explained in the bgpsec-ops document? 

--Sandy, speaking as regular ol' member

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Thu, 24 Jul 2014 19:05:55 +0000

On 7/24/14, 2:54 PM, "Sandra Murphy" <[email-masked]> wrote:

>I believe it would be better instead to refer to RFC6483 or RFC6811,
>rather than try to reprise the algorithm.  Something like:  "To do this,
>the speaker performs the algorithm of RFC6483/RFC6811.  If the result is
>not Valid, then the BGP Update is 'Not Valid'."
>
>Does a bgpsec speaking router have one configuration about the results of
>the bgpsec validation, or does it have two configurations, one for the
>results of the origin validation and a second for the results of the
>bgpsec validation?  Are the two validation states separated?
>

³Does² is an interesting question.   Clearly one can. Our prototype does.
So far I thought we were not standardizing the local policy mechanisms
that could be built off of the protocol mechanisms.  Given that we permit
lazy evaluation, one might envision employing RPKI-based OV on a BGPSEC
update before getting around to doing PATH validation.

Now providing guidance that trusting origin validation when path
validation has failed might not be bad.   But even there, first the first
hop sig might be valid ...

>--Sandy, speaking as regular ol' member

‹ 
Doug Montgomery, Mgr Internet & Scalable Systems Research NIST/ITL/ANTD

---

From: Matthew Lepinski <[email-masked]>
Date: Thu, 24 Jul 2014 15:17:08 -0400

With regards to the bgpsec-protocol document, I agree with Sandy that
the protocol document should reference RFC 6811/6483. I will reference
the origin validation algorithm in next version of bpgsec-protocol.

With regards to the bpgsec-ops document, it isn't at all clear to me
what the "right" answer is for how an implementation handles
configuration of origin validation and path validation (when both are
implemented). Unless there is something that we fear implementations
might do that is clearly bad, I don't see value in adding text to
bgpsec-ops.

On Thu, Jul 24, 2014 at 2:54 PM, Sandra Murphy <[email-masked]> wrote:
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Stephen Kent <[email-masked]>
Date: Fri, 25 Jul 2014 12:21:17 -0400

Sandy,

> (This seems particularly prudent as we might be reconsidering the validation algorithm.)
good point. we should use a reference rather than paraphrase.
> Should this be a point to be explained in the bgpsec-ops document?
For origin validation, a router needs the binding between an AS and a 
set of prefixes.
For BGPsec, it needs a binding between a public key and a set of ASes. 
So I see these
as separate databases.

Steve