Dear Terry, On Wed, Aug 03, 2016 at 06:16:04PM -0700, Terry Manderson wrote: > Firstly, thank you for documenting operational practice.
Thank you for your time and reiew! I'm responding to your first in this thread, in context of the wealth of information provided as follow-ups to this email. > With regards to section 3.3: > > "BGP speakers SHOULD only accept and honor BGP announcements carrying the > BLACKHOLE community .." > > I really question why this is a "SHOULD" and not a "MUST", even in an > informational RFC. > Is the ability for a transit provider so loose that appropriate route > filters from a peer ASN can't be applied so that only a "SHOULD" is > practical? In which case I do question the sanity of making such a > recommendation and thus service available if some other ASN might be > able to inject the route and affect another service, even by mistake. > Potentially if RPKI is in use, then a peer AS might be able to > validate the announcement against a ROA. But it strikes me that this > is not the machinery you would want to tack on in this case. In https://www.ietf.org/mail-archive/web/grow/current/msg03577.html you suggest: "BGP speakers in a direct peering relationship MUST only accept and honor BGP announcements carrying the BLACKHOLE community if the announced prefix is covered by a shorter prefix for which the neighboring network is authorized to advertise. In topologies where a Route Server or other distant-peer relationships, BGP speaker SHOULD accept and honor BGP announcements under the same conditions." Combined with Nick's remark from https://www.ietf.org/mail-archive/web/grow/current/msg03581.html "although it is NOT REQUIRED for bgp speakers in a peering relationship <snip>" Nick understands the intent of the draft very well: honoring this community is optional and usually (but not always) part of a commercial supplier-customer agreement. We changed the text to the following: """ BGP speakers in a bilateral peering relationship using the BLACKHOLE community MUST only accept and honor BGP announcements carrying the BLACKHOLE community under the two following conditions: o the announced prefix is covered by an equal or shorter prefix that the neighboring network is authorized to advertise o the receiving party agreed to honor the BLACKHOLE community on the particular BGP session In topologies with a route server or other multilateral peering relationships, BGP speakers SHOULD accept and honor BGP announcements under the same conditions.""" > The same could be said for section 3.2. I would be rather wary of NOT > adding a NO_ADVERTISE (at the very least) and to be honest SHOULD still > seems far too loose for me. Almost all of the recipe's that I've gazed > upon Especially in networks composed of multiple network elements, the operator is likely to add NO_EXPORT rather than NO_ADVERTISE to ensure the DDoS traffic is dropped as early as possible after it entered the operator's routing domain. Was also noted by Christopher and Acked by you in https://www.ietf.org/mail-archive/web/grow/current/msg03558.html In https://www.ietf.org/mail-archive/web/grow/current/msg03558.html it was noted: > >RPKI probably isn't the tool to use here, for this. > > Agreed. Please explicitly state this. I could honestly see that someone > falling into the (sad) trap of: > A) we are being DDoS'd > B) we need to BLACKHOLE a.b.c.d/32 > c) Provider X says RPKI ROA first > D) DDoS'd, so can't push ROA == Fail. I've added the following text under section 3.2 "Accepting Blackholed IP Prefixes": """ An operator MUST ensure that origin validation techniques (such as [RFC6811]) to not inadvertently block legitimate announcements carrying the BLACKHOLE community. """ Do you agree? > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > >From a comment point of view, this informational document is agnostic on > any operational differences between 2-byte and 4-byte ASNs. Is that > intentional? Are there any operational differences worth calling out in > regard to using extended communities etc? David Farmer is spot on in his email here https://www.ietf.org/mail-archive/web/grow/current/msg03567.html A network needs to support RFC1997 - whether they run their network with a ASN that fits in 2-bytes or 4-bytes is not relevant. There is benefit for operators with a 4-byte ASN as they now have an RFC1997 community to use instead of muck with extended communities. I don't think we need to include text to highlight this feature. Kind regards, Job _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
