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.) (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. (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?) (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? ---------------------------------------------------------------------- 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
