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
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
