[sidr] Follow-up on June 6 Interim : Confederations

[Matt Lepinski <[e-mail]>]

We had significant discussion at the June 6 Interim on the topic of 
supporting confederation in BGPSEC without an AS-Path attribute.

My understanding was that at the interim there was some consensus for 
the following confederation solution (but this consensus has not yet 
been discussed/confirmed this consensus on the list):
1) We specify the first bit in the (signed) Flags field of the 
Secure_Path as a marker for entering a confederation.
     (Note: the Flags field is specified in -03 version of the 
bgpsec-protocol draft but all 8 Flag bits are reserved for future use in 
-03)
2) When a signed (BGPSEC) update message enters a confederation, the 
first member of the confederation who gets the update sets the first bit 
of the Flags field to 1.
    (That is, the first confederation member when adding its own AS 
number to the Secure_Path also includes a Flags octet with the first bit 
set to 1.)
3) When a signed (BGPSEC) update message is about to be sent to a peer 
outside the confederation, the BGPSEC speaker traces backward through 
the Secure_Path to find the most recently added Secure_Path segment 
containing a Flags field whose first bit is set to 1. The BGPSEC speaker 
then deletes all of the Secure_Path segments up to and including the 
segment with the Flags bit set to 1. Finally, this BGPSEC speaker then 
adds his a Secure_Path segment containing the Public AS of the 
confederation.
    (Note that this means that any BGPSEC speaker in a confederation who 
has a peer external to the confederation must have a signing key 
associated with an RPKI router certificate containing the public AS of 
the confederation.)

The advantage of this above approach to confederations is that it does 
NOT require that a BGPSEC speaker in a confederation be explicitly 
configured with the AS numbers of every AS belonging to the 
confederation. Also, this approach does not make any assumptions about 
the loop detection algorithms employed by any BGP speaker on the path.

If it would be helpful, I could push a quick -04 revision to the 
protocol specification next week that fleshes out what this change would 
look like when incorporated into the BGPSEC protocol draft. (Though not 
included in this message, the protocol draft will also need to include 
explicit instructions for re-constructing the AS_confed_segments of the 
AS_Path attribute in the case where within a confederation the update 
message is sent to a peer that does not support BGPSEC.)

Final note: At the interim, we discussed both confederations as well as 
AS number migration (and other circumstances in which a single router 
needs to use different AS numbers on different BGP sessions to different 
peers). I outlined above the protocol change that I believe is needed to 
accommodate confederations,  and I believe that no changes new protocol 
mechanisms are needed to accommodate routers that use different AS 
numbers on different BGP sessions. No one at the interim raised any 
other issues arising from the removal of AS_Path. (That is, if you 
weren't able to make it to the interim and you have a new issue that 
arises from the removal of AS_Path from BGPSEC update messages, please 
send mail to the SIDR list.)

- Matt Lepinski