Re: [sidr] Confeds and clusters

In addition to Wes and Randy's observations about trust boundaries, it's also the case that mechanically, the confederation embeds its loop prevention information in the AS path, so we have to have *some* way of dealing with it since bgpsec is monkeying with the AS path. The same problem doesn't exist for the cluster list since it's a separate attribute.

--John

On Jun 16, 2012, at 3:31 AM, Jakob Heitz wrote:

> All the effort to sign the confed AS got me thinking.
> A route reflector cluster is like a member AS in a confed.
> Is there a case for signing the cluster list too?
> 
> IMHO: AS boundaries are for marking boundaries of trust.
> Confeds are for achieving scalability within an AS.
> I think signatures are only needed across trust boundaries.
> More is unnecessary complexity.
> 
> --
> Jakob Heitz.
> 
> 
> On Jun 15, 2012, at 9:50 PM, "Randy Bush" <randy@psg.com> wrote:
> 
>> bgpsec and confederations
>> 
>> allow me to try to state clearly for the list
>> 
>>   When an update enters the first AS in a confederation, all last
>>   internal ASBRs within the entry AS of the confederation, i.e the
>>   first signers within the confederation, set a flag in the signature
>>   block that says "I am the first signature within the confederation."
>> 
>>   The update wanders around normally in the confederation and every
>>   sending internal confederation ASBR signs it with their internal AS.
>> 
>>   A confederation's exit router looks backwards in the AS sequence
>>   until it finds the first, i.e. most recent, instance of that flag.
>>   If it finds no flag, the update is treated as originated within the
>>   confederation.
>> 
>>   It strips the signature block containing the flag and all subsequent
>>   signature blocks.  All signs of the internals of the confederation
>>   have now been removed.
>> 
>>   It then forward signs to the next AS, using the identity of the
>>   public confederation AS.
>> 
>>   While the update is traversing the confederation, if it should hit a
>>   peering where the peer is is not bgpsec capable, it strips all
>>   bgpsec gloop and reconstructs a classic AS_path.
>> 
>> this is believed to handle the loop disease (e.g. the cisco "neighbor
>> allowas-in" command).
>> 
>> what if anything should be done if you find the confed flag when you are
>> not inside a confed is a topic for discussion.
>> 
>> does anyone see a flaw in the above?  please please review so we can put
>> it to bed.
>> 
>> randy
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr