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

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

This solution for confeds *requires* each AS within a confed to sign internally 
(i.e., from AS to AS within the confed). It does not allow the choice to 
a confed operator to sign or not sign the updates internally. 
For instance, the operator may be satisfied with the level of mutual trust 
within the confed, and therefore may choose to not sign updates internally. 

Do we want to provision this choice into the protocol?

Discussion points:

Having this choice helps the operator to avoid the extra processing burden for 
the confed ASes when they have sufficient trust within the confed.

If we decide that the protocol must be flexible enough to offer this choice, 
then one solution would be to keep the AS_PATH. 
Then the confed sequence info is carried in the AS_PATH as normal, 
and the operator can choose to sign or not sign updates internally. 

A secondary advantage of the AS_PATH based approach is that 
in the lazy mode or super lazy mode (which we discussed at the last meeting), 
the processing of updates in the confed ASes becomes less complex. 
The processing cost also decreases for the case when a BGPSEC router 
needs to do conversion to regular BGP update for a non-BGPSEC peer. 

Sriram  

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of Matt
>Lepinski
>Sent: Friday, June 15, 2012 3:09 PM
>To: [e-mail]
>Subject: [sidr] Follow-up on June 6 Interim : Confederations
>
>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.)
>