Subject: Re: [OPSEC] widely adopted communities presentation at nanog 49

From: Danny McPherson <[email-masked]>
Date: Thu, 22 Jul 2010 09:07:13 -0600

On Jun 21, 2010, at 11:33 PM, Christopher Morrow wrote:

> On Tue, Jun 22, 2010 at 12:49 AM, Joel Jaeggli <[email-masked]> wrote:
>> While I have some personal ambivialence to the idea of specifiying
>> well-known communities, I noted this presentation with some interest at
>> nanog and since the subject has been discussed here before I would drop
>> a pointer to the presentation.
>> 
>> http://www.nanog.org/meetings/nanog49/presentations/Tuesday/Raszuk-Wide_BGP_Communities_00_2.pdf
> 
> i vote, again, no 'well known communities' ... the guarantee that they
> exist and will be used as intended isn't currently working with
> no-export (as you stated at the mic I think). Having a contractually
> obligated set of communities (even if it's different per provider)
> with proscribed behaviours should be the target (which each customer
> should pursue).

My thoughts were mostly aligned with this.  Here's a response I sent to 
a related discussion on NANOG..

FWIW, from a codifying position I definitely get what Robert is trying to do,
I just share the concerns that Chris pointed out, coupled with the ones below.

-danny

Begin forwarded message:

> From: Danny McPherson <[email-masked]>
> Date: July 20, 2010 9:34:40 AM MDT
> To: "[email-masked] >> nanog list" <[email-masked]>
> Subject: Re: Standard for BGP community lists
> 
> 
> On Jul 20, 2010, at 1:26 AM, Saku Ytti wrote:
> 
>> On (2010-07-19 23:45 -0500), Brad Fleming wrote:
>> 
>> Hey,
>> 
>>> 9999:9999 for local rtbh
>>> 9999:8888 for local + remote rtbh
>>> 
>>> I didn't have much reason for selecting 9999 other than it was easy
>>> to identify visually. And obviously, I have safe-guards to not leak
>>> those communities into other networks.
>> 
>> I would recommend against using other public ASNs for internal signalling,
>> ASN part should be considered property of given ASN. AS9999 might want to
>> use 9999 to signal particular source where route was learned and your
>> customer might want to do TE with it. Now you must delete them on ingress
>> and rob your customers of this possibility.
> 
> IMO, any reasonable routing policy would reset all BGP communities on 
> ingress (and MEDs for that matter), whether from a customer or peer, 
> as transiting stuff that has varying semantic interpretations, unknown 
> propagation scope, or relying on others to act on non-mandatory 
> not-well-known communities that may not even be propagated in some 
> BGP configurations as a matter of default behavior, is a simple recipe 
> for nondeterministic behavior, more senseless path attribute tuples in 
> the global routing system, resulting in less efficient BGP update packing, 
> and may even result in security issues. 
> 
> And customer ingress policy can always be crafted to accommodate the
> upstream special handling policies for RFC1998+ functions, as well as
> source and destination-based RTBH and other capabilities, across one
> or more ISPs, even if they vary.  
> 
> There have been some spirited discussions on the specification of 
> more well-known communities for functions related to this and other 
> applications in various IETF working groups, from IDR and GROW to 
> OPSEC and L3VPN, for those interested in having a gander...
> 
> -danny
>