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

From: "Terry Manderson" <[email-masked]>
Date: Wed, 03 Aug 2016 18:16:04 -0700

Terry Manderson has entered the following ballot position for
draft-ietf-grow-blackholing-02: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Firstly, thank you for documenting operational practice.

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.

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

----------------------------------------------------------------------
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?

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 3 Aug 2016 22:11:46 -0400

On Wed, Aug 3, 2016 at 9:16 PM, Terry Manderson <[email-masked]>
wrote:

> https://datatracker.ietf.org/doc/draft-ietf-hestitancyhestitancygrow-blackholing/
> <https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/>
>
>
>

I'd note (and I'm surprised no one else noted already, especially you) this
odd bit of language:
(I'm mad I didn't see it earlier as well, actually)

  "It has been observed that announcements of IP prefixes larger than
   /24 for IPv4 and /48 for IPv6 are usually not accepted on the
   Internet (see section 6.1.3 [RFC7454]).  However, blackhole routes
   should be as small as possible?"

So: "Large prefixes == /24 or /48"
but: "small prefixes == /32 or /128"

err, small/large, long/short... there's inconsistent use of these terms
here, I think. At the least it's a bit confusing.
I'd have stuck with:
  "It has been observed that announcements of IP prefixes LONGER than
   /24 for IPv4 and /48 for IPv6 are usually not accepted on the
   Internet (see section 6.1.3 [RFC7454]).  However, blackhole routes
   should be as LONG as possible"

(I prefer longer/shorter for prefix stuff)

So, back to your discuss though:
  "BGP speakers SHOULD 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."

(note that 'shorter' is used here...again making the above bit more
confiusing with smaller/larger)

MUST vs SHOULD for this, I do think the MUST would be easy to handle. Is
this a problem in an RS situation? Probbaly not... on the RS, but on the
distant peer, it likely is hard(er) to deal with. I don't imagine many folk
prefix filter the RS session very tightly only because memberships come/go
and you may not always get timely notice (I have no idea when people
come/go at the IX's I connect to).

So, SHOULD makes some sense to me, at least in the RS peer/distant-peer
world. Surely for direct BGP peerings MUST is a better idea, I think.

> machinery you would want to tack on in this case.
job and I chatted a bit about this (oddly, prior to your note here) and one
thing to keep in mind with RPKI is that the ROA Owner (publisher?) would
have to first know their special-prefix was going to be attacked, then set
the ROA up (as a /32 or as a supernet -> /32). I'm skeptical of that being
done, certainly today there are virtually no /32 ROA in the system.

RPKI probably isn't the tool to use here, for this.

> seems far too loose for me. Almost all of the recipe's that I've gazed
... you trailed off... I bet it was something like:"gazed upon require/use
NO-advertise on the ISP side and no-export on the customer side

that's the recipe I setup when last i was an ISP...
I think the hesitancy for 'MUST' there is that there are cases in use today
where you would send a route-server the /32 + commnuity and WANT that to
get to the remote peers.

If the RS did 'no-advertise' the route won't make it to the remote peer :(

I can also imagine that an ISP network may just accept the /32 with
'isp-blackhole-community' and for expediency reset next-hop to their
blackhole, and ship that in IBGP so their mesh gets the data 'fast'.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 3 Aug 2016 19:28:20 -0700

On 8/3/16 7:11 PM, Christopher Morrow wrote:
> 
> 
> On Wed, Aug 3, 2016 at 9:16 PM, Terry Manderson
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Please refer to
>     https://www.ietf.org/iesg/statement/discuss-criteria.html
> I'd note (and I'm surprised no one else noted already, especially you)
> this odd bit of language:
> distant peer, it likely is hard(er) to deal with. I don't imagine many
> folk prefix filter the RS session very tightly only because memberships
> come/go and you may not always get timely notice (I have no idea when
> people come/go at the IX's I connect to).

public route servers can have quite well developed per peer prefix
filtering, if it's built on route objects, the adjacent peers on the
other hand probably do not since they don't know apriori what's on the
other side all the time.

likewise internal to a datacenter or a network under one span of control
you may have quite relaxed import filtering between a bunch of private
ASNs. but a very narrowly controlled export policy facing the world.

> job and I chatted a bit about this (oddly, prior to your note here) and
> one thing to keep in mind with RPKI is that the ROA Owner (publisher?)
> would have to first know their special-prefix was going to be attacked,
> then set the ROA up (as a /32 or as a supernet -> /32). I'm skeptical of
> that being done, certainly today there are virtually no /32 ROA in the
> system.
> 

you're not likely to do that for /128s in any event.

> ... you trailed off... I bet it was something like:"gazed upon
> require/use NO-advertise on the ISP side and no-export on the customer side
> 
> I think the hesitancy for 'MUST' there is that there are cases in use
> today where you would send a route-server the /32 + commnuity and WANT
> that to get to the remote peers.
>

---

From: Terry Manderson <[email-masked]>
Date: Thu, 4 Aug 2016 03:26:02 +0000

Ditto, and thanks for noticing that :-)

>folk prefix filter the RS session very
> tightly only because memberships come/go and you may not always get
>timely notice (I have no idea when people come/go at the IX's I connect
>to).
>

I think then there is a difference here worth pointing out. It isn't a
"one size fits all" approach and the nuances are important.

>then set the ROA up (as a /32 or as a
> supernet -> /32). I'm skeptical of that being done, certainly today
>there are virtually no /32 ROA in the system.
>
>

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.

Moreover, if the BGP peer IS RPKI validating and the ROA is structured to
have a maxLength=/24 and the prefix owner wants to blackhole a particular
/32, the validation state would be INVALID.

That implies that this technique is blocked by RPKI validation, yes? no?
I'm no expert on juniper/cisco in-code validation logic. If I am following
the logic correctly, if you want to blackhole by sending a more specific
blackhole tagged route to your BGP peer for blackhole purposes, that peer
must not do RPKI validation or the ROA needs to be setup in advance. Which
seems a non-starter for RPKI as nearly every ROA would then need a
maxLength of a /32 or /128 *JUST INCASE* an address within a least
specific prefix was targeted in a DDoS.

>require/use NO-advertise on the ISP side and no-export on the customer

Yes, I did.. coffee called and I lodged the DISCUSS before finishing my
text. Sorry. It was good coffee.

And yes. That is what I intended to say. :)

>that to get to the remote peers.

I think then that this nuanced usage needs to be captured here, and
provide the rationale for doing exactly that.

>If the RS did 'no-advertise' the route won't make it to the remote peer :(

Granted.

>blackhole, and ship that in IBGP so their mesh gets the data 'fast'.

Any feedback on the comment?

Cheers
Terry

---

From: heasley <[email-masked]>
Date: Thu, 4 Aug 2016 05:34:27 +0000

> world. Surely for direct BGP peerings MUST is a better idea, I think.

or strike the language altogether.  it is unnecessary.  if it is their
prefix and they want to blackhole it - whatever, their prerogative.

> RPKI probably isn't the tool to use here, for this.

I am not knowledgable of every facet of rpki, but I thought that it was
possible to express /length-or-longer?  But Randy has already pointed
that rpki doesnt cover communities; to middle men can alter it.

> If the RS did 'no-advertise' the route won't make it to the remote peer :(

and no-advertise is almost certainly wrong for most - it implies that you
carry the traffic from a remote location to the penultimate hop before the
customer only to /dev/null it there.

> > regard to using extended communities etc?

Not that I know of; orthogonal.

---

From: Randy Bush <[email-masked]>
Date: Thu, 04 Aug 2016 18:03:52 +0900

< pedantry alert >

> that rpki doesnt cover communities; to middle men can alter it.

rpki does not cover anything in a bgp announcement.  it is a distributed
database of address space ownership and authorization to announce (and
some other cruft).

rpki-based origin authentication doe not help here because the attacker
requesting my prefix be blackholed with merely forge my AS on the path.

rpki-based path validation, one possible future, would plug the forged
origin hole.  as you say, the current drafts do not sign over
communities.

< /pedantry >  < rant >

this proposal issues nuclear weapons to children who have repeatedly
shown an inability to reliably do the most basic hygenic practice.

the combination of being well-known and transitive means attack
amelioration relies on universal rigorous filtering which has failed
time and again.

randy

route-views>sh ip bg 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 37806771
Paths: (2 available, best #1, table default, RIB-failure(17))
  Not advertised to any peer
  Refresh Epoch 1
  58511
    103.247.3.45 from 103.247.3.45 (103.247.3.45)
      Origin IGP, metric 0, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  20771 3356
    80.241.176.31 from 80.241.176.31 (80.241.176.30)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

route-views>sh ip bg 10.0.0.0 
BGP routing table entry for 0.0.0.0/0, version 37806771
Paths: (2 available, best #1, table default, RIB-failure(17))
  Not advertised to any peer
  Refresh Epoch 1
  58511
    103.247.3.45 from 103.247.3.45 (103.247.3.45)
      Origin IGP, metric 0, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  20771 3356
    80.241.176.31 from 80.241.176.31 (80.241.176.30)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

---

From: Marco Marzetti <[email-masked]>
Date: Thu, 04 Aug 2016 11:21:23 +0200

On 2016-08-04 07:34, heasley wrote:
>> folk

Yhe weirdest things happen in the DFZ and I can see corner cases in 
which one network may desire to advertise the RTBH host only.

For instance: network "A" is peering with networks "B" and "C" and wants 
to receive legit traffic from the first (because he has more capacity) 
but wants to stop the attack closer to the source which is in "C" .

-- 
Marco

---

From: Pedro Andrés Aranda Gutiérrez <[email-masked]>
Date: Thu, 4 Aug 2016 16:25:24 +0200

<45 minute standing ovation/>

/Pedro A. Aranda

On 04 Aug 2016, at 11:03, Randy Bush <[email-masked]> wrote:

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 4 Aug 2016 11:12:37 -0400

> "one size fits all" approach and the nuances are important.
can you propose some text that the authors could inject?

> Any feedback on the comment?
nope, I think extended communities with 4byte-asn is a problem though :(

---

From: David Farmer <[email-masked]>
Date: Thu, 4 Aug 2016 10:39:03 -0500

On Thu, Aug 4, 2016 at 10:12 AM, Christopher Morrow <
[email-masked]> wrote:

>
>
> On Wed, Aug 3, 2016 at 11:26 PM, Terry Manderson <
> [email-masked]> wrote:
>
>>
>>
>> ....

> nope, I think extended communities with 4byte-asn is a problem though :(
A Well-Known RFC1997 community, that this document is defining, is usable
with both 2-byte and 4-byte ASNs.  Therefore if anything, that is another
advantage to defining a Well-Known community over the use of ASN specific
communities described in [RFC3882 <https://tools.ietf.org/html/rfc3882>]
and [RFC5635 <https://tools.ietf.org/html/rfc5635>].

There are most definitely general operational issues with 4byte-ASNs and
extended and ASN specific RFC1997 communities, however those more general
issues are mostly out of scope of this document.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: heasley <[email-masked]>
Date: Thu, 4 Aug 2016 16:14:08 +0000

> origin hole.  as you say, the current drafts do not sign over

fine, bad terminology.  was following the original.

Is it not possible to define a ROA that includes a prefix-length -or-longer
up-to and including a /128 or /32?

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 4 Aug 2016 13:35:00 -0400

> issues are mostly out of scope of this document.

oy! precoffee mails :( yes, thanks! so then 'no comment on comment'.

---

From: Randy Bush <[email-masked]>
Date: Fri, 05 Aug 2016 06:55:49 +0900

> fine, bad terminology.  was following the original.

the document is not strong on rigor

> Is it not possible to define a ROA that includes a prefix-length
> -or-longer up-to and including a /128 or /32?

quite possible.  but

>> rpki-based origin authentication doe not help here because the
>> attacker requesting my prefix be blackholed with merely forge my AS
>> on the path.

randy

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 4 Aug 2016 17:53:50 -0700

Sent from my iPhone

>>> attacker requesting my prefix be blackholed with merely forge my AS

It's a leaky bucket, peers can generate prefix list filters for their route objects. If they send spurious junk it's associated with their down-stream cone not someone else's. If they're insufficiently good at filtering, their customers can jack each other. It's transit providers there's no point in filtering the Internet cone from. 

The threat of more specific  routes arriving from your transits with wacky as paths is real but that's prefix hijacking today and 20 years ago.

---

From: Randy Bush <[email-masked]>
Date: Fri, 05 Aug 2016 09:57:43 +0900

> It's a leaky bucket, peers can generate prefix list filters for their
> route objects.

as has been gone over a few thousand times, current hardware can not
hold prefix filters for large peers.

randy

---

From: Terry Manderson <[email-masked]>
Date: Fri, 5 Aug 2016 01:03:03 +0000

On 5/08/2016, 1:39 AM, "David Farmer" <[email-masked]> wrote:

>communities described
> in [RFC3882 <https://tools.ietf.org/html/rfc3882>] and [RFC5635
><https://tools.ietf.org/html/rfc5635>].

OK.

>issues are mostly out of scope of this document.

.. is why I asked. I'm fine to see that side stepped as being out of
scope, but the usage success may well vary depending on 2 byte and 4 byte
ASNs given the IANA pool for 2 byte has been exhausted, but I would urge
GROW to consider some future work item to look at these implications. I'll
let it pass for now.

Cheers
Terry

---

From: Terry Manderson <[email-masked]>
Date: Fri, 5 Aug 2016 01:21:52 +0000

On 5/08/2016, 1:12 AM, "Christopher Morrow" <[email-masked]>
wrote:

>
>
>On Wed, Aug 3, 2016 at 11:26 PM, Terry Manderson
><[email-masked]> wrote:
>
>
>

Suggested text:

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.

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 5 Aug 2016 10:59:59 -0400

On Thu, Aug 4, 2016 at 9:21 PM, Terry Manderson <[email-masked]>
wrote:

> BGP announcements under the same conditions.
>
>
thanks!
-chris

---

From: heasley <[email-masked]>
Date: Fri, 5 Aug 2016 15:10:42 +0000

> > BGP announcements under the same conditions.

repeating myself, but it is perfectly reasonable to accept a BH route
equal to the aggregate ("shorter prefix").

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 5 Aug 2016 11:12:38 -0400

> equal to the aggregate ("shorter prefix").

I don't disagree... I sent a note (will send it shortly) with integrated
suggestions.. let's see how that works? (few mins to gen text from xml
still)

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 5 Aug 2016 11:46:05 -0400

On Fri, Aug 5, 2016 at 10:59 AM, Christopher Morrow <
[email-masked]> wrote:

>
>
> On Thu, Aug 4, 2016 at 9:21 PM, Terry Manderson <[email-masked]
> > wrote:
>
>>
>>
>> >>

oops, and I updated the xml here:
<
https://github.com/morrowc/grow-docs/commit/2dadb7b1bd21bafc69364769cc5c1c916019464f

the authors can copy/paste/merge/git-foo it I expect? if they agree with
the changes, which seemed ok to me.

oh, the authors have a better place, I'll send in that direction
momentarily.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 5 Aug 2016 21:45:46 +0300

Would it be possible to add a clause to mention that accepting + honouring bh prefixes is not mandatory?  At the moment the text sort-of implies that it might be. Eg "although it is NOT REQUIRED for bgp speakers in a peering relationship to accept and honor BGP announcements carrying the BLACKHOLE community, they MUST only accept and honor BGP announcements carrying the BLACKHOLE community if the announced prefix is covered by..."

Or something to that effect. That sentence above is a bit clumsy so please feel free to mangle as appropriate.

Nick

Sent from my iWotsit.
On 5 Aug 2016, at 18:46, Christopher Morrow <[email-masked]> wrote:
>> On Fri, Aug 5, 2016 at 10:59 AM, Christopher Morrow <[email-masked]> wrote:
>> 
>> 
>>> On Thu, Aug 4, 2016 at 9:21 PM, Terry Manderson <[email-masked]> wrote:
>>> 
>>> 
>>> >>
> <https://github.com/morrowc/grow-docs/commit/2dadb7b1bd21bafc69364769cc5c1c916019464f>
> 
> the authors can copy/paste/merge/git-foo it I expect? if they agree with the changes, which seemed ok to me.
> 
> oh, the authors have a better place, I'll send in that direction momentarily.
>

---

From: Job Snijders <[email-masked]>
Date: Tue, 9 Aug 2016 17:15:35 +0200

> equal to the aggregate ("shorter prefix").

Correct, text changed to; "...prefix is covered by an equal or shorter
prefix for which the neighboring..."

Thanks,

Job

---

From: Job Snijders <[email-masked]>
Date: Tue, 9 Aug 2016 18:02:59 +0200

Dear Terry,

> 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.

> 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."""

> seems far too loose for me. Almost all of the recipe's that I've gazed

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

> 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?

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

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 11 Aug 2016 15:34:00 +0100

> thread, in context of the wealth of information provided as follow-ups

are these changes published anywhere, e.g. ietf datatracker or github?

Nick

---

From: Job Snijders <[email-masked]>
Date: Thu, 11 Aug 2016 16:42:59 +0200

Hi Nick,

> are these changes published anywhere, e.g. ietf datatracker or github?

Thank you for your interest.

We maintain the latest (living) version here
https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/
until we receive further instructions from the AD when and how to post
a new version.

Kind regards,

Job

---

From: joel jaeggli <[email-masked]>
Date: Thu, 11 Aug 2016 11:34:41 -0700

> until we receive further instructions from the AD when and how to post
If that works for everyone. then I'm going to assume that steven will
clear at some point. and that terry wil lclear when this is posted. and
we can move on.

joel

---

From: Terry Manderson <[email-masked]>
Date: Thu, 11 Aug 2016 23:47:01 +0000

Hi Job,

>   under the same conditions."""

I like that text.

>    carrying the BLACKHOLE community. """

Yes. Thank-you.

Cheers
Terry

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 13 Aug 2016 13:18:20 +0100

>    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

---

From: Job Snijders <[email-masked]>
Date: Sat, 13 Aug 2016 15:32:31 +0200

> > 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.

> 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

---

From: heasley <[email-masked]>
Date: Sat, 13 Aug 2016 14:56:07 +0000

> security considerations section, as it is a security related problem.

though I agree with you, that seems unrelated to blackholing, and thus out
of scope.  an informational rfc about best standard practices toward being
a positive functioning member of the DFZ would be a better place for that;
which may already exist unbeknownst to me.

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 13 Aug 2016 22:24:57 +0100

> which may already exist unbeknownst to me.

the intention of this is to explicitly document good practice which some
operators are going to overlook, but I hear what you're saying.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 13 Aug 2016 22:34:41 +0100

> already covered by the existing text?

The intention is to document that if there is an existing policy to
filter at max prefix length N, then the operator needs to make sure that
when they start accepting BH-tagged prefixes which might have arbitrary
lengths, that they don't accidentally break their existing policy of
rejecting e.g. > /24 or /48 or whatever.

Nick