bgpsec and confederations
allow me to try to state clearly for the list
When an update enters the first AS in a confederation, all last
internal ASBRs within the entry AS of the confederation, i.e the
first signers within the confederation, set a flag in the signature
block that says "I am the first signature within the confederation."
The update wanders around normally in the confederation and every
sending internal confederation ASBR signs it with their internal AS.
A confederation's exit router looks backwards in the AS sequence
until it finds the first, i.e. most recent, instance of that flag.
If it finds no flag, the update is treated as originated within the
confederation.
It strips the signature block containing the flag and all subsequent
signature blocks. All signs of the internals of the confederation
have now been removed.
It then forward signs to the next AS, using the identity of the
public confederation AS.
While the update is traversing the confederation, if it should hit a
peering where the peer is is not bgpsec capable, it strips all
bgpsec gloop and reconstructs a classic AS_path.
this is believed to handle the loop disease (e.g. the cisco "neighbor
allowas-in" command).
what if anything should be done if you find the confed flag when you are
not inside a confed is a topic for discussion.
does anyone see a flaw in the above? please please review so we can put
it to bed.
randy
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
