On 8/3/16 8:31 AM, Stephen Farrell 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.)
transitivity is a required property if n > 2 ASNs are involved in the propagation of the message... There are deployed examples that depend on this property. > (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." The applies to all learned routes in the internet. operational practices that prevent leakage and limit the damage of prefix hijacking also prevent the opportunity for leakage of more specific routes or inappropriately sourced advertisements. any member of the of the routing system may simply synthesize a routing update for any prefix and propagate it subject to the policy constraints imposed by their neighbors every interceding ASN must necessarily modify the update before propagating it.. > 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? it is not, imho, an attack using a prefix tagged with the community is a prefix hijacking. if you accept the route with our without the community you are installing it in you table and selecting a nexthop in one case the nexthop is your discard, in the other the nethop is a another router. > 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?) a transit ASN might accept but generally will not without coordination propagate prefix's longer than a /24 or a /48. so in a global sense no. configured max prefix limits which providers use a circuit breaker are likely to discourage spamming updates at your neighbor, as does the fact that by definition you want connectivity for your prefix. > (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? > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
