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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
