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