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: [email protected] [mailto:[email protected]] On Behalf Of Matt
Lepinski
Sent: Friday, June 15, 2012 3:09 PM
To: [email protected]
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.)
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
