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

[Matt Lepinski <[e-mail]>]

If we want to make it optional for ASes to sign internally to a confed, 
that is perfectly fine with me. As long as they add their AS number to 
the Secure_Path, it would be easy to modify this solution so that ASes 
within a confed can optionally leave the digital signature field empty.

With regard processing requirements and  the AS_Path attribute. I 
believe that carrying the AS_Path attribute in BGPSEC messages slightly 
increases the amount of processing that must be done when receiving a 
signed update message (since the receiver must perform some additional 
checks to verify that the secured data in the Path_Signatures_Attribute 
is consistent with the AS_Path attribute), but slightly decreases the 
amount of work that must be done when sending to a non-BGPSEC peer 
(since stripping the signatures attribute is easier than recomputing the 
AS_Path). However, in either case, I don't think it a big difference in 
the amount of processing required. Also, I haven't thought enough about 
this to know to what extent processing changes in the "lazy" case or the 
confederation case.

- Matt Lepinski

On 6/15/2012 4:07 PM, Sriram, Kotikalapudi wrote:
> 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.)
>>