Internet2 Network Security SIG

[Jeff Bartig <>]

On 7/26/16, 8:52 AM, Michael H Lambert wrote:

On 26 Jul 2016, at 05:34, Paul Howell  wrote:
 
There have been some preliminary discussions about moving to the RFC community tags internally to Internet2.    In general, Internet2 is supportive of David’s suggestions however we would welcome others thoughts on the questions of adopting the new tags and propagation within the R&E community.

As long as it doesn't require heroic efforts by the NOC to make the changes, I think a transition to the well-known community while keeping the current communities in place for a "while" makes sense.

It shouldn't be an issue for Internet2 to add the proposed 65535:666 tag for blackholing.  Currently, Internet2 uses 11537:911 (R&E) and 11164:53666 (TR-CPS), which have been called out by the authors of draft-ietf-grow-blackholing in their arguments for stopping the proliferation of provider specific blackhole community tags.

Questions:

1.  Transition:  How long do we take to transition away from 11537:911 and 11164:53666?  Do we continue to support these old communities forever or should their use be deprecated and eventually removed from the configurations?  While adding the new community wouldn't be a big task for Internet2, eliminating the old communities will require work for some Internet2 connectors.  My preference would be to eventually clean up the configuration and remove the old communities.

2.  Transiting BGP blackhole communities:  This is a much bigger question.  I know we already have regional networks that accept community tags from their participants and transit/translate these communities to their upstream providers such as Internet2.  In both of these cases, though, there is a business relationship that generally involves maintaining prefix-lists of allowed prefixes that will be accepted.  Accepting and acting on a blackhole community tag requires a level of trust that generally exists in a customer->provider relationship due to these prefix lists, but doesn't exist in peer-peer or customer<-provider relationships.

Blackholing is often done by advertising a host route (v4 /32 or v6 /128).  Networks that support blackholing generally have a special routing policy in place to accept these advertisements that are more specific than will normally be accepted for readvertisement.  I know some regionals and TR-CPS generally filter accepting any v4 prefixes at the /24 boundary and v6 prefixes at the /48 or maybe /64 boundary as a protection in their transit, peer, and customer route policies.

Jeff

--
Jeff Bartig
Interconnection Architect
Internet2  AS11164 / AS11537
+1-608-616-9908