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

From: Matt Lepinski <[email-masked]>
Date: Fri, 15 Jun 2012 15:08:48 -0400

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

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Fri, 15 Jun 2012 16:07:36 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Matt
>Lepinski
>Sent: Friday, June 15, 2012 3:09 PM
>To: [email-masked]
>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.)
>

---

From: Matt Lepinski <[email-masked]>
Date: Fri, 15 Jun 2012 16:52:36 -0400

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

---

From: Randy Bush <[email-masked]>
Date: Sat, 16 Jun 2012 06:43:07 +0900

> Do we want to provision this choice into the protocol?

sure, if they strip bgpsec and reconstruct the as-path.

in bgpsec, all ass sign.  end.

randy

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 18 Jun 2012 12:54:37 -0400

Comments below.

Sriram

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

Quoting from the sidr-bgpsec-ops-05 document:
"To prevent exposure of the internals of BGP Confederations [RFC5065],
   a BGPsec speaker which is a Member-AS of a Confederation MUST NOT
   sign updates sent to another Member-AS of the same Confederation."

You might like to reword the above but ...
Our position all along (for at least two years, except for the recent shift) had been 
that we did not require confed AS members to sign internally within the confed.
http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-01#section-7.3

Concern for the confed operator:
If updates enter a confed with 3 sigs in them, and if the confed adds another 
3 sigs internally, then the updates are getting pretty bulky and 
the processing/memory costs are going much higher for the confed operator. 
May not like that when they know their confed ASs are within a trust boundary.
(Also see Jakob's comment.)

Sriram

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Jun 2012 01:56:46 +0900

>    sign updates sent to another Member-AS of the same Confederation."

good catch.  matt, when you put the confed stuff in, i am sure you will
remember to remove that one.

randy