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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 03 Aug 2016 08:31:12 -0700

Stephen Farrell 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:
----------------------------------------------------------------------

First, I have to say that I'm pretty ignorant about
practical routing operations, so my plan is to briefly
discuss this and to then probably move to an abstain
position, unless the issues I raise resonate with folks
who are expert in this space.

(1) I agree with the points raised in IETF LC that the
transitive nature of this proposal has dangers that may
outweigh its utility. Was there discussion in the WG about
potential solutions that do not have the transitivity
property? If so, can you point me at those? If not, is
there a reason to think no such solution is feasible?  (I
suspect the answer may be "no" which is the main reason I
plan to move to an abstain ballot.)

(2) IIUC, this proposal envisages BGP speakers commonly
telling others to blackhole specific /32's or /128's. And
of course as the draft says BGP doesn't provide us with a
way to "prevent the unauthorized modification of
information by the forwarding agent." Given those two
things, this scheme seems to be an ideal new way to cause
any service that advertises a fallback to actually fall back,
e.g to use a secondary MX or DNS resolver rather than a
primary. That seems like a fine way to try and possibly
succeed in attacking many possible things.  The discuss
point here is to ask if this really is a new attack
vector, and if so, if the appropriate level of analysis of
its impact has been done? If this is new, then I don't see
that the security considerations text adequately describe
the range of possible attacks that could be mounted using
this scheme. (As an aside, I wonder if asking to blackhole
/32's and /128's might impact on routing table sizes and
if something ought be said about that?)

(3) Given that there are dangers associated with this
mechanism, why is there no statement in the draft that
actions taken based on this scheme ought be logged or
otherwise publicised as a possible way to provide some
level of accountability, even if only after the fact?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- 3.2: It isn't clear to me how one might exercise
"extreme caution" here - can you explain? Or is that
obvious to the intended audience of this?

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 3 Aug 2016 12:02:36 -0400

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

your tools to do signaling in bgp are ... limited you can toggle/adjust/etc
things such as:
  community
  origin
  metric
  prefix-itself

In the scenario where we want to enable one provider to signal to the other
provider: "please take this action"

community is the 'best' option... you can signal somethign meaningful with
a commnuity where origin/metric don't really allow you to do more than
binary decisions.

In a scenario on the wider network NOT at a peering fabric that has a
route-server thingy... you don't really need a 'transitive' attribute
because you're just telling your neighbor: "pls do this" to which they
presumably have policy to do the right thing (or they may choose to ignore
you, of course).

In the scenario that includes a peering-fabric and route-server, you need
either:
  1) route-server to do some kinky things (ignore some forms of
non-transitive, re-map something to the non-transitive, etc)
  2) pass the attribute through because it is transitive.

the route-server is the remote network's bgp peer, so you have to ask the
route-server to ship stuff across to other peers...

> information by the forwarding agent." Given those two

err, there is MD5 auth for tcp... which SHOULD prevent modification
in-flight.
of course (ha!) there's notionally tcp-AO which should do the same thing,
perhaps in the 'year 2000' (say with proper gravitas) when we... wait,
darn! no implementations of AO exist.

> any service that advertises a fallback to actually fall back,

with bgp being in a state where there is no method (there is, md5 auth) to
prevent/notice modifications... all bgp sessions are at risk (some risk).

> vector, and if so, if the appropriate level of analysis of

doesn't look new to me, no. and 'worse', today someone COULD just (if they
are in the right place and can do bgp packet creation,etc) just tag all of
your announcments to your provider(s) with the local provider version of
this community, blackholing all of your traffic... or they could change the
announcements to withdrawals... or other mean things. the addition of this
blackhole community doesn't change this problem, at all.

> if something ought be said about that?)
'prefix limits' are standard protections for this on your bgp peerings.
so are (ha!) prefix filters so that they can't announce things they ought
not announce.

> level of accountability, even if only after the fact?
most actions like this are taken at the behest of the customer... so you're
telling them what they did, right?

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 3 Aug 2016 17:06:22 +0000

> On Wed, Aug 3, 2016 at 11:31 AM, Stephen Farrell <[email-masked]> wrote:

> your tools to do signaling in bgp are ... limited you can toggle/adjust/etc things such as:

> In the scenario where we want to enable one provider to signal to the other provider: "please take this action"

> community is the 'best' option... you can signal something meaningful with a community where origin/metric don't really allow you to do more than binary decisions.

> In a scenario on the wider network NOT at a peering fabric that has a route-server thingy... you don't really need a 'transitive' attribute because you're just telling your neighbor: "pls do this"

>to which they presumably have policy to do the right thing (or they may choose to ignore you, of course).

Exactly, as I see it this would only be to peers. And probably needs to be covered in your peering contract.

How many, how long would Destination based BHFing (DBHF) requests be accepted between two peers would be the main concept here.

Note everywhere this says BHF I assumed DBHF not Source based BHFing. I suspect SBHF is out of scope for this effort. I could be wrong.

Should the draft be modified to state that or is it intended to allow SBHFing also?

> In the scenario that includes a peering-fabric and route-server, you need either:

> 1) route-server to do some kinky things (ignore some forms of non-transitive, re-map something to the non-transitive, etc)

> the route-server is the remote network's bgp peer, so you have to ask the route-server to ship stuff across to other peers...

> err, there is MD5 auth for tcp... which SHOULD prevent modification in-flight.

> of course (ha!) there's notionally tcp-AO which should do the same thing, perhaps in the 'year 2000' (say with proper gravitas) when we... wait, darn! no implementations of AO exist.

> with bgp being in a state where there is no method (there is, md5 auth) to prevent/notice modifications... all bgp sessions are at risk (some risk).

> doesn't look new to me, no. and 'worse', today someone COULD just (if they are in the right place and can do bgp packet creation,etc) just tag all of your announcments to your provider(s) with the local provider

>version of this community, blackholing all of your traffic... or they could change the announcements to withdrawals... or other mean things. the addition of this blackhole community doesn't change this problem, at all.

So the risk looks the same, and should be mitigated with the same methods (md5 and GTSM?)

I didn't hear a recommendation for GTSM but I think it should be in here.

> if something ought be said about that?)

Thus my suggestion that it be in the peering contract for how many and how long?

> so are (ha!) prefix filters so that they can't announce things they ought not announce.

> otherwise publicized as a possible way to provide some

> most actions like this are taken at the behest of the customer... so you're telling them what they did, right?

01100101000010|10011010111101?
Hint 7 bit ascii
[email-masked]<mailto:[email-masked]>

This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

---

From: Job Snijders <[email-masked]>
Date: Wed, 3 Aug 2016 19:20:28 +0200

On Wed, Aug 03, 2016 at 05:06:22PM +0000, Smith, Donald wrote:
> Note everywhere this says BHF I assumed DBHF not Source based BHFing.
> I suspect SBHF is out of scope for this effort. I could be wrong.

Correct, the draft is very explicit in the first sentence:

    "This document describes the use of a well-known Border Gateway
    Protocol (BGP) community for destination based blackholing in IP
    networks. "                  ^^^^^^^^^^^

> Should the draft be modified to state that or is it intended to allow

No. IMHO that should be a different draft / community.

> I didn't hear a recommendation for GTSM but I think it should be in

The document is supposed to define a codepoint, not to be a BCP. While I
value and somewhat agree these are useful techniques, I consider them
out of scope.

> > if something ought be said about that?)

We don't put in every single BGP draft that you need to ensure that you
need adequate RAM, CPU, FIB, ASIC, Capacity, or $magic_powder. Whether
prefixes are colored with attributes or not, routing table size is a
consideration in every aspect of BGP life.

> Thus my suggestion that it be in the peering contract for how many and

Any contractual terms are up to the network operator that implements a
routing policy that honors (or does not honor) the BLACKHOLE community,
that can't be part of the document.

Kind regards,

Job

---

From: heasley <[email-masked]>
Date: Wed, 3 Aug 2016 17:45:44 +0000

> darn! no implementations of AO exist.

I do not believe that is the intended meaning; I think it is reference
to a device's route policy, intentional or accidental.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 3 Aug 2016 13:56:53 -0400

> plan to move to an abstain ballot.)

This mechanism exists within the existing ecosystem of RFC 1997 communities.
These communities control a significant amount of routing behavior and are
commonly set by upstream routers, perhaps from a different AS, attempting to
influence behavior or provide information to downstream ASes.

Common operational practices include removing undesirable communities at
one's AS border.  While these practices are not written about in the RFC
series, they're well understood.  My suggestion is to proceed with the
knowledge that this is a known operational behavior as are the underlying
security considerations.

-- Jeff

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 3 Aug 2016 15:51:37 -0400

> to a device's route policy, intentional or accidental.

interesting, I didn't read/take-in the 'agent' part... (perhaps I read
'forwarding path' :( )

If 'agent' is to mean 'route server' then sure, neither md5/ao/gtsm will
help... and yes, that 'agent' can mangle routes as it sees fit.

thanks!
-chris

---

From: David Farmer <[email-masked]>
Date: Wed, 3 Aug 2016 15:22:27 -0500

On Wed, Aug 3, 2016 at 11:02 AM, Christopher Morrow <
[email-masked]> wrote:

>
> ....
> In the scenario where we want to enable one provider to signal to the
> other provider: "please take this action"
>
> community is the 'best' option... you can signal something meaningful with
> a community where origin/metric don't really allow you to do more than
> binary decisions.
>

There are other scenarios where cleanly having the BLACKHOLE community be
transitive, it the right thing.  Besides the peering-fabric/route-server
scenario you just described, there are a number of cooperative transit
relationships, where you would properly want to transitively pass the
BLACKHOLE community.

Such as;

Two ASes we sharing transit with each other up, something like this;

(ISP1) --- (AS64500) --- (AS64501) --- (ISP 2)

 Let's say AS64500 was under attack, it could announce the /32 under attack
with the BLACKHOLE community to ISP1 directly and to ISP2 through it
sharing partner AS64501.  AS64501 has to transitively pass the route with
the BLACKHOLE community to ISP2.

Similarly the sharing could be done through a aggregating transit AS;

(AS64501)    (ISP 1)
          |            /
      (AS64500) -- (ISP 2)
          |            \
(AS64502)    (ISP 3)

Similarly, AS64500 has to transitively pass the route with the BLACKHOLE
community to ISPs 1, 2, and 3;

Therefore, limiting the propagation by defining the BLACKHOLE community as
non-transitive would either inappropriately limit it's use in a number of
valid scenarios or require people to do "kinky things" like ignoring the
fact that is is suppose to be non-transitive.

I prefer it be transitive and tell people to use it carefully!

But that's my $0.02.

-- 
===============================================
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: joel jaeggli <[email-masked]>
Date: Wed, 3 Aug 2016 15:46:48 -0700

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

transitivity is a required property if n > 2 ASNs are involved in the
propagation of the message...

There are deployed examples that depend on this property.

> information by the forwarding agent." 

The applies to all learned routes in the internet. operational practices
that prevent leakage and limit the damage of prefix hijacking also
prevent the opportunity for leakage of more specific routes or
inappropriately sourced advertisements. any member of the of the routing
system may simply synthesize a routing update for any prefix and
propagate it subject to the policy constraints imposed by their
neighbors every interceding ASN must necessarily modify the update
before propagating it..

> Given those two
> its impact has been done?

it is not, imho, an attack using a prefix tagged with the community is a
prefix hijacking. if you accept the route with our without the community
you are installing it in you table and selecting a nexthop in one case
the nexthop is your discard, in the other the nethop is a another router.

> If this is new, then I don't see

a transit ASN might accept but generally will not without coordination
propagate prefix's longer than a  /24 or a /48. so in a global sense no.
configured max prefix limits which providers use a circuit breaker are
likely to discourage spamming updates at your neighbor, as does the fact
that by definition you want connectivity for your prefix.

---

From: Gert Doering <[email-masked]>
Date: Thu, 4 Aug 2016 11:04:07 +0200

Hi,

> Note everywhere this says BHF I assumed DBHF not Source based BHFing. I suspect SBHF is out of scope for this effort. I could be wrong.

source-based blackholing in remote networks is something I do not consider
viable - what customer A might consider an attacker might be an important
source of information to customer B, so you can permit customer A to 
drop packets *to A*, but not "from X, no matter if destined to A or B"
(in some case the network provider might decide "I drop all traffic from
X, because it's causing problems to my infrastructure", but even then,
his upstreams will not permit to do this transitively)

I do not think the draft needs to be extended to say so - we only
define a code point, not define a new mechanism for blackholing.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 6 Aug 2016 00:11:49 +0300

> On 3 Aug 2016, at 19:02, Christopher Morrow <[email-masked]> wrote:
> doesn't look new to me, no. and 'worse', today someone COULD just (if they are in the right place and can do bgp packet creation,etc) just tag all of your announcments to your provider(s) with the local provider version of this community, blackholing all of your traffic... or they could change the announcements to withdrawals... or other mean things. the addition of this blackhole community doesn't change this problem, at all.

You're technically correct to say that there is nothing new about this attack vector but in practice, this draft will end up changing the /24 and /48 default maximum prefix length on all bh-enabled peering sessions to /32 and /128 and will encourage configs to be created to make it easy to propagate BH'd prefixes around the place. Everyone understands that policy can be written to tie this down to be safer and that this will be done on competently managed networks, and that for those networks, this draft will be both safe and useful. All the operators plugging for this draft in the grow wg fall into this category of competence.

In reality, a huge number of networks are spaghetti-built on a jumble of incompetently configured devices hacked together by people who don't really know what they're doing. Many network operators are going to screw this sort of config up and will end up shooting themselves and others in the foot.

This ignores those network operators who have malicious intent. In their case, this draft adds another blade to their Swiss Army knife, particularly in situations where prefix limits are routinely not used. 

Stepping back a bit, the ietf has an unfortunate tendency to write off certain categories of operator problem as "out of scope" or "config/implementation error", and this has happened in this case. The problem is, the draft is saying "hey guys, if you bypass a bunch of rcds in the distribution board, you can do some really cool stuff". You sure can, but the person who gets electrocuted in the shower as a result isn't going to care much about whether their shock was out of scope at the protocol level or caused by an implementation problem. Globally scoped damage will have been done either way, whether through malice or incompetence. 

Using a non transitive community (eg rfc4360) instead of a standard bgp community from the iana well-known range could limit this problem, because that would constrain the scope of any potential damage by enforcing non-transitivity at the bgp stack level. Without at least this safeguard, this draft is imho inadvisable from a global internet stability point of view. 

Nick

---

From: Randy Bush <[email-masked]>
Date: Sat, 06 Aug 2016 12:43:33 +0900

> doesn't look new to me, no. and 'worse', today someone COULD just (if
> they are in the right place and can do bgp packet creation,etc) just
> tag all of your announcments to your provider(s) with the local
> provider version of this community, blackholing all of your traffic.

note the string of "if"s.  this proposal removes them.  the attacker can
be anywhere, and need forge nothing.  and there's the rub; well-known
and transitive.

randy

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 8 Aug 2016 16:39:56 +0000

This discusses neighboring networks, and local scope, so one would assume in most cases these are directly connected peers (or not many hops away), I think the security section should recommend use of GTSM on such sessions.

Then it can't easily be spoofed outside of the local network.

if (initial_ttl!=255) then (rfc5082_compliant==0)
[email-masked]<mailto:[email-masked]>
________________________________
From: GROW [[email-masked]] on behalf of Randy Bush [[email-masked]]
Sent: Friday, August 05, 2016 9:43 PM
To: Christopher Morrow
Cc: GMO Crops; The IESG
Subject: Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

randy

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

---

From: Gert Doering <[email-masked]>
Date: Mon, 8 Aug 2016 19:02:20 +0200

Hi,

> Then it can't easily be spoofed outside of the local network.

While the general recommendation is valid, I'm not seeing why it is
particularily relevant to this draft - whether or not a neighbouring
BGP session is using a well-defined or privately-agreed code point to
signal BGP black holing makes no difference wrt to attacking the local
TCP session...  (assuming that the "privately-agreed" code point is
in fact publicly documented in an IRRdb, which they usually are).

Adding a general reference to BGP security best practices won't hurt,
of course - 7454 comes to mind (which among others recommends GTSM).

Gert Doering
        -- NetMaster

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 8 Aug 2016 17:33:30 +0000

That's is even better. So agreed with referencing that rfc.

if (initial_ttl!=255) then (rfc5082_compliant==0)
[email-masked]<mailto:[email-masked]>
________________________________
From: Gert Doering [[email-masked]]
Sent: Monday, August 08, 2016 11:02 AM
To: Smith, Donald
Cc: Randy Bush; Christopher Morrow; GMO Crops; The IESG
Subject: Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

Hi,

Gert Doering
        -- NetMaster

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 8 Aug 2016 23:37:36 +0100

Sorry for the slow response here, had some distraction.

Responses to two of the bits of my discuss below. I need to read
more of the thread to figure where we are with point (1)...

> blackhole community doesn't change this problem, at all.

Sorry, I'm not seeing that. Are you saying all BGP speakers
can today commonly know exactly how to ask blackhole *any*
individual /32 or /128?

If so, then surely that calls into question the utility of
specifying this community? If not, then the combination
of common and /32 does still appear to create a new attack
vector being the ability to use BGP to cause specific services
to fall back onto their fallbacks without any other side-effects
being visible to the service provider.

If I'm wrong there can you tell me how some BGP speaker could
otherwise (without this draft) attempt to cause that same effect
with that same specificity regardless of where the actual blackholing
needs to happen?

> telling them what they did, right?

No. If we agree that this new community represents a dangerous
implement, and if we nonetheless consider it's overall utility
is positive and hence sufficient to warrant making this draft
into an RFC, then I think the onus is on us to provide some
guidance as to how to handle the dangerous implement. That ought
not specify policy, but I think ought discuss the potential
dangers and describe some ways to mitigate those. My assumption
is that some level of audit/logging of the actions taken as a
result of this community would be a part of that.

Cheers,
S.

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 8 Aug 2016 16:31:07 -0700

Sent from my iPhone

> On Aug 8, 2016, at 15:37, Stephen Farrell <[email-masked]> wrote:
> 
> 

You set the nexthop to yourself and in the event that one arrives, discard the packet.

If the neighbor accepts the route and installs it then the attack is complete. (This a a prefix hijack)

Using a more specific route over-rides as path length so so long as the source of the traffic accepts the more specific the traffic is diverted away from the victim. Also because of the more specific you can make the as path look more plausible.

---

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

Dear Stephen,

On Wed, Aug 03, 2016 at 08:31:12AM -0700, Stephen Farrell wrote:
> First, I have to say that I'm pretty ignorant about practical routing
> operations, so my plan is to briefly discuss this and to then probably
> move to an abstain position, unless the issues I raise resonate with
> folks who are expert in this space.

OK.

> (1) I agree with the points raised in IETF LC that the transitive
> nature of this proposal has dangers that may outweigh its utility. Was
> there discussion in the WG about potential solutions that do not have
> the transitivity property? If so, can you point me at those? If not,
> is there a reason to think no such solution is feasible?  (I suspect
> the answer may be "no" which is the main reason I plan to move to an
> abstain ballot.)

The short answer is no.

The authors have spent considerable time debating whether an rfc4360
codepoint is appropiate, but the lack of actual deployments using
non-transitive rfc4360 communities for blackhole signaling convinced
the authors to stick to what the operator community uses today: rfc1997
communities.

For most operators the deployment of this well-known BLACKHOLE community
will be very easy, as it in most cases closely aligns with their
existing blackhole routing policy. The operators not only have their own
networks to consider, but also their entire customer cone for whom the
signaling codepoint is intended. It is my opinion that our customer's
expectation is to use rfc1997 communities for signaling.

I won't delve into the operational complexities of getting operators to
supplement their existing transitve community with a non-transitive
variant, especially in context of route servers or sibling networks.

A few individuals do not agree with this viewpoint, so be it. We can't
please everyone. 

> (2) IIUC, this proposal envisages BGP speakers commonly telling others
> to blackhole specific /32's or /128's. And of course as the draft says
> BGP doesn't provide us with a way to "prevent the unauthorized
> modification of information by the forwarding agent." Given those two
> things, this scheme seems to be an ideal new way to cause any service
> that advertises a fallback to actually fall back, e.g to use a
> secondary MX or DNS resolver rather than a primary. That seems like a
> fine way to try and possibly succeed in attacking many possible
> things.  The discuss point here is to ask if this really is a new
> attack vector, and if so, if the appropriate level of analysis of its
> impact has been done? If this is new, then I don't see that the
> security considerations text adequately describe the range of possible
> attacks that could be mounted using this scheme.

This is not new. In addition to Christopher & Joel's comments:

We should also consider the severity in this context: If a forwarding
agent is compromised, you are likely to have far bigger problems. Long
term criminal profitablity lays with traffic mis-direction or detouring,
rarely with full outages. A blackhole is very easy to spot and react
against. A full outage (through a blackhole or something else) will
trigger investigation and the subsequent plugging of the hole. This is a
self repairing mechanism.

Currently a ton of carriers have implemented their own codepoints to
trigger blackholing, a very incomplete overview based on public data
follows of RFC1997 communities currently in use by various carriers:
2914:666, 209:0, 701:9999, 1239:66, 1273:666, 1299:999, 1759:666,
2828:1650, 3212:9999, 3257:2666, 65000:0, 3327:666, 3356:9999, 6762:666,
3561:666, 4323:187, 5580:666, 6461:5990, 7029:4506, 7922:666, 8100:6666,
8218:9999, 8220:63999, 8708:9999, 49544:666, 11537:911, 15756:666,
19401:911, 23265:666 and 286:66. All this draft does is unify those
listed above under a single codepoint for the benefit of all their
customers.

Just like adding all those communities to a single prefix does not cause
internet-wide havoc, a well-known variant won't. Again, a few (the same)
individuals won't agree with this assessment.

> (As an aside, I wonder if asking to blackhole /32's and /128's might
> impact on routing table sizes and if something ought be said about
> that?)

This well-known codepoint does not alter any of those characteristics or
considerations.

> (3) Given that there are dangers associated with this mechanism, why
> is there no statement in the draft that actions taken based on this
> scheme ought be logged or otherwise publicised as a possible way to
> provide some level of accountability, even if only after the fact?

I like your suggestion about logging, however I can't see our company to
commit to publication. Publication of blackholed IPs is not something
NTT has done in the last 10 to 15 years, I'm not aware of others doing
this either.

On the other hand, logging for internal auditing purposes is useful.
This can help triage incidents or after-the-fact verification of policy
adherence. NTT has iBGP sessions from every edge router to a central
collector, which uses quagga/mrtdump to indefinitely store all BGP
updates. In other network deployments I've used BIRDs syslog
capabilities to make a note of prefixes with special characteristics
such as a BLACKHOLE.

Under section 3.3 we can add the following (and I welcome suggestions to
improve the text):
    
    """ Operators are encouraged to store all BGP updates in their
    network carrying the BLACKHOLE community for long term analysis or
    internal audit purposes. """

> - 3.2: It isn't clear to me how one might exercise "extreme caution"
> here - can you explain? Or is that obvious to the intended audience of
> this?

The intended audience has a good understanding. One or two people on
this list will disagree.

Kind regards,

Job

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 9 Aug 2016 16:50:58 +0100

Hiya,

>> the answer may be "no" which is the main reason I plan to move to an

I figured;-)

> variant, especially in context of route servers or sibling networks.

Thanks, that's useful. As I said, I think I'll end up abstaining and
getting out your way, given the above, when we've sorted the below.

> A few individuals do not agree with this viewpoint, so be it. We can't

I'm sure what you mean is that some may end up in the rough
(e.g. as per [1]) since I'd be quite surprised to know that
there's any one thing that can please all routing folk:-)

  [1] https://tools.ietf.org/html/rfc7282

> self repairing mechanism.

I agree if what is blackholed is a /24 or more but is that equally
true if all that is blackholed is a /32 or /128?

My concern is that if such a tightly-scoped blackhole is less
likely spotted (incl. by the owner of the service at the blackholed
/32 or /128, due to a fallback) then the new aspect is that an
attacker (using BGP) can target fall back hosts in a very selective
manner. As I understand it (which is not well:-), today, the attacker
would more likely have to affect a lot more traffic to get the same
effect, (or to be more active in getting the rest of the traffic
routed in a normal looking manner) so it's just that "fine-grained
targeted" aspect that I'm arguing may be new, may become more
wide-spread due to this draft, and that is therefore worth analysis
and possibly documenting.

TBH, I'm still not sure that's not the case. (Apologies if that's
just me being dumb, which happens a lot.)

> internet-wide havoc, a well-known variant won't. 

To try be clear: it's not wide-spread havoc that's my concern here,
but the ability to very specifically target one host, e.g. as part
of an attack on a fallback host that may be less well protected,
or even just less capable.

> Again, a few (the same)

Ok - I assume that means that being able to accept a blackholed /32
doesn't therefore mean having to accept other BGP announcements for
/32's without any additional controls. Would it be sensible to say
that implementers MUST/SHOULD allow treating blackholing differently
in that respect? (e.g. to keep some different configured limits for
the length of prefix they accept for blackholes vs. other BGP stuff?)

>     internal audit purposes. """

Yes, that's plenty good enough I think. I'm fine that you are
better placed to figure out how best to express it. (And I also
think if implementers allow that and operators do that, then
that should to an extent mitigate the concern in my point #1
above as I guess it'd help capable operators detect the less
capable ones that haven't been careful enough.)

> The intended audience has a good understanding. One or two people on

That wasn't a blocking comment of mine, but fwiw, the above doesn't
explain it to me;-)

Cheers,
S.

---

From: Gert Doering <[email-masked]>
Date: Tue, 9 Aug 2016 18:04:33 +0200

Hi,

> the length of prefix they accept for blackholes vs. other BGP stuff?)

I think this is implicit by the statement that there must be a covering
prefix permitted by routing policy - so the assumption is "the blackhole
can be more specific".

All existing deployments I know do it that way - that is, for regular
traffic, prefixes are permitted as documented (like: 192.0.2.0/24 is
accepted, and no more specifics) while blackhole-tagged prefixes
go up to /32 ("if blackhole-community present, accept 192.0.2.0/24../32").

I'm not sure if we need to spell this out - it's not something this draft
is changing.

Gert Doering
        -- NetMaster

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 9 Aug 2016 17:18:30 +0100

> I'm not sure if we need to spell this out - it's not something this draft

(Noting that this was an aside that I don't consider blocking...) I
think one could argue that this draft is changing that as it's here
that we're defining this community. And I'd say it would be useful
to call it out too, if there's really no sensible way to implement
this without such an additional configuration.

Cheers,
S.

---

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

On Tue, Aug 09, 2016 at 04:50:58PM +0100, Stephen Farrell wrote:
> > I won't delve into the operational complexities of getting operators
> > to supplement their existing transitve community with a
> > non-transitive variant, especially in context of route servers or
> > sibling networks.
> 
> >> (2) IIUC, this proposal envisages BGP speakers commonly telling
> >> others to blackhole specific /32's or /128's. And of course as the
> >> draft says BGP doesn't provide us with a way to "prevent the
> >> unauthorized modification of information by the forwarding agent."
> >> Given those two things, this scheme seems to be an ideal new way to
> >> cause any service that advertises a fallback to actually fall back,
> >> e.g to use a secondary MX or DNS resolver rather than a primary.
> >> That seems like a fine way to try and possibly succeed in attacking
> >> many possible things.  The discuss point here is to ask if this
> >> really is a new attack vector, and if so, if the appropriate level
> >> of analysis of its impact has been done? If this is new, then I
> >> don't see that the security considerations text adequately describe
> >> the range of possible attacks that could be mounted using this
> >> scheme.
> > 
> > We should also consider the severity in this context: If a
> > forwarding agent is compromised, you are likely to have far bigger
> > problems. Long term criminal profitablity lays with traffic
> > mis-direction or detouring, rarely with full outages. A blackhole is
> > very easy to spot and react against. A full outage (through a
> > blackhole or something else) will trigger investigation and the
> > subsequent plugging of the hole. This is a self repairing mechanism.
> 

Yes. Except a /32 won't propagate as far as a /24 or shorter. Long
blackholes (/32 or /128) are in essence a form of propagation control. 

> My concern is that if such a tightly-scoped blackhole is less likely
> spotted 
>
> (incl. by the owner of the service at the blackholed /32 or /128, due
> to a fallback) then the new aspect is that an attacker (using BGP) can
> target fall back hosts in a very selective manner. As I understand it
> (which is not well:-), today, the attacker would more likely have to
> affect a lot more traffic to get the same effect, (or to be more
> active in getting the rest of the traffic routed in a normal looking
> manner) so it's just that "fine-grained targeted" aspect that I'm
> arguing may be new, may become more wide-spread due to this draft, and
> that is therefore worth analysis and possibly documenting.

Short or long prefix: an entry is an entry. People prefer to blackhole
the most specific prefix possible, to avoid blackholing adjacent IP
space which is not under attack. This is documented in section 3.2

My remark was meant in context of people monitoring their services
(there a gazillion ways to do this) - a monitor will detect that a
prefix or a single IP address is unreachable and then someone takes
action.

> TBH, I'm still not sure that's not the case. (Apologies if that's just
> me being dumb, which happens a lot.)

No worries.

> > Just like adding all those communities to a single prefix does not
> > cause internet-wide havoc, a well-known variant won't. 
> 

This is how people use blackholing today. In fact, NTT only accepts /32s
and /128s for blackholing and nothing shorter. You can only target
hosts due to this policy.

> > Again, a few (the same) individuals won't agree with this
> > assessment.
> > 
> >> (As an aside, I wonder if asking to blackhole /32's and /128's
> >> might impact on routing table sizes and if something ought be said
> >> about that?)
> > 

I consider that outside the scope of this document. We're trying to
document one codepoint as concise as possible.

Some operators today offer a separate BGP session solely for the purpose
of receiving blackhole requests, this way they can have different limits
for the normal session vs the blackhole session. I don't think it is
wise to document all possible deployment scenarios here.

Having "maximum prefix" settings (which I think you are referring to)
based on fine grained variables sucha as the number of prefixes tagged
with community X vs community Y or which are part of an aggregate prefix
should be a generalized mechanism, already today some vendors offer
different knobs in 'maximum received' vs 'maximum accepted' - but thats
really out of scope here.

> >     network carrying the BLACKHOLE community for long term analysis
> >     or internal audit purposes. """
> 
> Yes, that's plenty good enough I think. I'm fine that you are better
> placed to figure out how best to express it. (And I also think if
> implementers allow that and operators do that, then that should to an
> extent mitigate the concern in my point #1 above as I guess it'd help
> capable operators detect the less capable ones that haven't been
> careful enough.)

Thanks!

Kind regards,

Job