Hiya, On 09/08/16 16:05, Job Snijders wrote: > 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.
I figured;-) > > 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. 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 > please everyone. 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 > >> (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. 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.) > > 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. 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) > 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. 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?) > >> (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. """ 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.) > >> - 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. That wasn't a blocking comment of mine, but fwiw, the above doesn't explain it to me;-) Cheers, S. > > Kind regards, > > Job >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
