Job Snijders wrote: > 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 changes in -03 doesn't fully address this issue either. I've created two github pull requests for suggested text updates: > https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/pull/1/files > https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/pull/2/files The first explicitly states that accepting/honouring BH-tagged prefixes is OPTIONAL. The second adds a note to say that both the receiving and the sending party should explicitly filter out more-specifics unless they're tagged with BLACKHOLE. I would be in favour of seeing this noted in the security considerations section, as it is a security related problem. Nick _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
