Re: [Idr] draft-heitz-idr-large-community

[Jared Mauch <[e-mail]>]

> On Sep 8, 2016, at 5:03 AM, Robert Raszuk <[e-mail]> wrote:
> 
> 
> /* Renaming this conversation as this is no longer about accepting it as WG doc, but rather general discussion about this proposal. */
> 
> 
> > ​Q2. If your ISP offers the service to transit communities,
> 
> The point was that we have learned since RFC1997 published 10 years back that there is no trust in the Internet any longer. But this is perhaps more of an SIDR issue so let's talk about it when this draft becomes WG doc. 

There isn’t really anything to talk about, communities are additive, and any relationship with SIDR should happen in that WG or in the follow-up activities if it’s merged.


> But how to assure integrity and correctness of originating AS intention via untrusted transit ASes … 

As i’ve said to others, things like AS_PATH are a bit-string, a malicious actor can stuff whatever they want in it.  There is no new risk here unless you process these communities, and having no well-known attributes makes the risk nearly zero.

> The security aspect of wide communities have been discussed in the past. I am interested in this as will be very glad to use the same solution as we accept for large communities in the wide community document. Both are transitive via multiple ASes hence the issue. 

This isn’t about the current wide-communities draft that seems to have low traction in the WG.  Sorry.  Your draft is trying to normalize the values operators have already defined to meet their needs, this is not always universally helpful.  I understand the motive, but I’ve failed to see the consensus with the existing draft coalesce and there are no implementations I’m aware of, while this seems to be making steady progress to resolve the very real issues we as operators face.

> > Q3. The spec must not enforce any stripping.
> 
> I respectfully disagree. 

The good new is you are wrong. :-)

> Sending community containing in the first 4 octets of an AS outside of a given AS over eBGP session to me is a clear and direct indication that such community is meaningless any longer. If so why then to allow to send it ? 
> 
> Local policy of send-all would not help. Would we need soon another draft along the lines of draft-mauch-bgp-reject to deal with large community default pollution ? 

I’m confused as, communities are not sent by default, making them part of being conservative in what is sent, eg: cisco requires you to configure send-community which requires session tear-down to initalize.  I’ve seen no proposal in GROW or IDR to change this, nor recommendation.  

Also the proper version of the draft is https://tools.ietf.org/html/draft-ietf-grow-bgp-reject.  Feedback on that draft is much appreciated.  Let me know if I missed your e-mail.


> If you rename this entire text into 4:4:4 all being of mutual agreement between parties then my point is gone ... but till that happen I am willing to understand the rationale. 
> 
> > ​BTW, this all works the same way as it does with regular communities.
> 
> Is that supposed to be a feature or a bug ? ;-)
> 

The fact the communities have no defined structure is a feature and why there have been interesting innovations which did not require the IETF to standardize things.  We lack the proper size canvas in a rfc4893 world, this was an oversight which must be corrected.  There are reasons it’s not been critical along the way, but this is the tipping point where IDR must take action.


> Cheers,
> R.
> 
> 
> On Thu, Sep 8, 2016 at 3:08 AM, Jakob Heitz (jheitz) <[e-mail]> wrote:
> Q1. My implementation as it stands uses ios-regex to filter, so you can filter whatever you want. I have an optimization in mind that will make it easier to match on each field individually, but it's not done yet.
> Your example: delete largecommunity not in (ios-regex '^2914:')
> 
> ​​Q2. If your ISP offers the service to transit communities, then that ISP will be able to transmit the large communities unchanged with my implementation.
> 
> Q3. The spec must not enforce any stripping. It is up to a receiver to strip whatever it does not want to receive. In my implementation, large communities are dropped by default by EBGP senders. You must configure send-community-ebgp if you want it to send large communities. You can use the delete statement of Q1 in a neighbor outbound route-policy if you want to selectively remove large communities.
> 
> ​​BTW, this all works the same way as it does with regular communities.
> 
> Thanks,
> Jakob.
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr