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. > > 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. > > >> (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?
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. > > 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. 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?) > > > > 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?) 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. > >> (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.) Thanks! Kind regards, Job _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
