Hi Job, On 10/08/2016, 2:02 AM, "Job Snijders" <[email protected]> wrote:
> >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.""" I like that text. > >> 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? Yes. Thank-you. Cheers Terry
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
