> 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 something meaningful with a > community 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). Exactly, as I see it this would only be to peers. And probably needs to be covered in your peering contract. How many, how long would Destination based BHFing (DBHF) requests be accepted between two peers would be the main concept here. Note everywhere this says BHF I assumed DBHF not Source based BHFing. I suspect SBHF is out of scope for this effort. I could be wrong. Should the draft be modified to state that or is it intended to allow SBHFing also? > > > 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. So the risk looks the same, and should be mitigated with the same methods (md5 and GTSM?) I didn't hear a recommendation for GTSM but I think it should be in here. > > 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?) Thus my suggestion that it be in the peering contract for how many and how long? > > > > > '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 publicized 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? > > > > > > 01100101000010|10011010111101? Hint 7 bit ascii [email protected]<mailto:[email protected]> This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
