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

"Sriram, Kotikalapudi" <> Mon, 18 June 2012 16:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5575121F86EF for <>; Mon, 18 Jun 2012 09:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f5D0ZMAe9tfN for <>; Mon, 18 Jun 2012 09:54:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4F0CE21F85E1 for <>; Mon, 18 Jun 2012 09:54:43 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 18 Jun 2012 12:54:42 -0400
Received: from ([fe80::d479:3188:aec0:cb66]) by ([]) with mapi; Mon, 18 Jun 2012 12:54:39 -0400
From: "Sriram, Kotikalapudi" <>
To: Randy Bush <>
Date: Mon, 18 Jun 2012 12:54:37 -0400
Thread-Topic: [sidr] Follow-up on June 6 Interim : Confederations
Thread-Index: Ac1LP4NeY5j66eGZQ0GV3Ugw83k43gCLH+iw
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [sidr] Follow-up on June 6 Interim : Confederations
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Jun 2012 16:54:45 -0000

Comments below.


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

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.

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