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

Matt Lepinski <mlepinski@bbn.com> Fri, 15 June 2012 20:52 UTC

Return-Path: <mlepinski@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A030311E80D7 for <sidr@ietfa.amsl.com>; Fri, 15 Jun 2012 13:52:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnxR5311jwLg for <sidr@ietfa.amsl.com>; Fri, 15 Jun 2012 13:52:30 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id BECEB11E8088 for <sidr@ietf.org>; Fri, 15 Jun 2012 13:52:28 -0700 (PDT)
Received: from mail.bbn.com ([128.33.0.48]:34532) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from <mlepinski@bbn.com>) id 1SfdUk-000F9T-Ny; Fri, 15 Jun 2012 16:51:50 -0400
Received: from [128.89.255.6] by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <mlepinski@bbn.com>) id 1SfdVL-0008Kl-Eg; Fri, 15 Jun 2012 16:52:27 -0400
Message-ID: <4FDBA094.5020906@bbn.com>
Date: Fri, 15 Jun 2012 16:52:36 -0400
From: Matt Lepinski <mlepinski@bbn.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
References: <4FDB8840.2030903@bbn.com> <D7A0423E5E193F40BE6E94126930C4930B9BA8404E@MBCLUSTER.xchange.nist.gov>
In-Reply-To: <D7A0423E5E193F40BE6E94126930C4930B9BA8404E@MBCLUSTER.xchange.nist.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] Follow-up on June 6 Interim : Confederations
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jun 2012 20:52:34 -0000

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