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)...
On 03/08/16 17:02, Christopher Morrow wrote: > On Wed, Aug 3, 2016 at 11:31 AM, Stephen Farrell <[email protected]> > wrote: > >> 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.) >> > > 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... > > >> >> (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 >> > > 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. > > >> things, this scheme seems to be an ideal new way to cause >> 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). > > >> 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 >> > > 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. 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? > > >> 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?) >> >> > '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. > > >> (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? >> >> > most actions like this are taken at the behest of the customer... so you're > 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. > > >> >> ---------------------------------------------------------------------- >> 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? >> >> >> >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
