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

["Sriram, Kotikalapudi" <[e-mail]>]

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