Re: [GROW] Terry Manderson's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Job Snijders <[e-mail]>]

On Sat, Aug 13, 2016 at 01:18:20PM +0100, Nick Hilliard wrote:
> 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

While I like the simplity of the sentence, there already is text which
makes it clear that everything is "MAY" or "OPTIONAL":

Line 24: "well-known advisory"
https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/blob/master/draft-ietf-grow-blackholing-03.txt#L24

Line 139: "this community as an advisory qualification to drop"
https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/blob/master/draft-ietf-grow-blackholing-03.txt#L139

Line 146-147: "Accepting and honoring the BLACKHOLE community, or
ignoring it, is a choice that is made by each operator."
https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/blob/master/draft-ietf-grow-blackholing-03.txt#L146-L147

Line 149-150: "use of the BLACKHOLE community MUST be agreed upon by the
two networks before advertising it"
https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/blob/master/draft-ietf-grow-blackholing-03.txt#L149-L150

Line 156 "it MAY announce an IP prefix"
https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/blob/master/draft-ietf-grow-blackholing-03.txt#L156

Line 205: "the receiving party agreed to honor the BLACKHOLE community
on the particular BGP session"
https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/blob/master/draft-ietf-grow-blackholing-03.txt#L205

Adding yet another line about the optional nature seems redundant.

So, I'm going to have to decline this specific suggestion in its current
form, however if you have a proposal to introduce the word OPTIONAL in
one of the above sentences we can consider it.

> > https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/pull/2/files
> 
> 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.

I'm not comfortable adding this line, because the moment the BLACKHOLE
community is not attached to a prefix, its out of scope for this
document. One example: NTT for instance announces longer than /24
customer prefixes to its customers, if a valid route object exists -
these more-specifics do not carry the BLACKHOLE community, but they are
legitimate route announements.

Maybe I am misunderstanding the intention of your proposed change - can
you elaborate? Are you sure that the problem case you describe isn't
already covered by the existing text?

Thank you for your time and review, much appreciated.

Kind regards,

Job