All the effort to sign the confed AS got me thinking. A route reflector cluster is like a member AS in a confed. Is there a case for signing the cluster list too?
IMHO: AS boundaries are for marking boundaries of trust. Confeds are for achieving scalability within an AS. I think signatures are only needed across trust boundaries. More is unnecessary complexity. -- Jakob Heitz. On Jun 15, 2012, at 9:50 PM, "Randy Bush" <[email protected]> wrote: > 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 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
