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

["Sriram, Kotikalapudi" <[e-mail]>]

My notes / suggested wording changes inline below, marked with "KS:".

One other observation:
We also discussed Lazy and Super Lazy modes of router operation at 6/6/12 meeting.
If we were to include descriptions for those cases for the confed ASBRs,
the description gets a bit more complicated.
Especially because the ASBR has to perform operations that are different depending on 
whether it is in an AS in the middle of the confed or in an exit AS connecting to an external peer.

Sriram
________________________________________
From: [e-mail] [[e-mail]] On Behalf Of Randy Bush [[e-mail]]
Sent: Saturday, June 16, 2012 12:50 AM
To: sidr wg list
Subject: [sidr] bgpsec and confeds [was: Minutes of 6/6/12 meeting uploaded]

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."

KS: Please add:
However, the flag MUST NOT be set if the update entered the confed
at an AS and also exits from the same AS to go to an external peer AS.
(In this case, the update is not traversing any eBGP peering links internal to
the confed.)

    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.

KS: The last sentence above is not true. Explanation as follows.
Consider: 
AS1 --- (AS2 --- AS3 --- AS4) --- AS5
AS2, AS3, AS4  form a confed. AS1 and AS5 are external peers.
Consider an update that is exiting the confed at AS4 and being forward signed to AS5.
If the update originated from AS2 or AS3, then it is an update that indeed
originated from within the confed but it *will* come with the flag set.
And if the update originated in AS4, it should not have any signatures yet;
AS4 will add the first signature when it forward signs to AS5.
So I suggest the following change of wording: 
"If the ASBR finds no flag, then it means that the update has entered the
confed at this AS (i.e., the same AS where the ASBR is) and hence
it has not traversed any confed internal eBGP links."

    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.

KS: Please add the following:
It also strips from the Secure_Path segment the sequence of 
ASN and pCount fields corresponding to the internal ASs in the confed.

    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.

KS: Suggest adding the following for clarity:
The classic AS_path will include the standard confed sequence that is 
reconstructed from the Secure_Path and includes the sequence of 
ASNs starting with the ASN with the flag set and all ASNs that follow.