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
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
