[sidr] bgpsec and confeds [was: Minutes of 6/6/12 meeting uploaded]

[Randy Bush <[e-mail]>]

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