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

[Stephen Kent <[e-mail]>]

Sandy,

> 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.)
good point. we should use a reference rather than paraphrase.
> 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?
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