Hello Kathleen, > On 20 Aug 2015, at 15:05, Kathleen Moriarty > <kathleen.moriarty.i...@gmail.com> wrote: > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-grow-filtering-threats-07: No Objection > > > ---------------------------------------------------------------------- > COMMENT: > ———————————————————————————————————
Thank you for your comments ! > > Please add in the proposed text from the SecDir review to address his > questions: > https://www.ietf.org/mail-archive/web/secdir/current/msg05855.html > <https://www.ietf.org/mail-archive/web/secdir/current/msg05855.html> The last revision of the document contains the following changes, based on consensus of community and secdir feedback, to strike balance between malicious and non malicious reasons for triggering the documented behaviour. Introduction: OLD: The objective of this draft is to shed light on possible side effects associated with more specific prefix filtering. This document presents examples of such side effects and discusses approaches towards solutions to the problem. NEW: The objective of this draft is to shed light on possible side effects associated with such more specific prefix filtering. Such actions can be explained by traffic engineering action, misconfiguration, or malicious intent. This document presents examples of such side effects and discusses approaches towards solutions to the problem. > > Additionally, I'd like to see the Security Considerations mention a point > brought up earlier in the draft, namely that the filtering could cause > traffic to be routed back through a path that doesn't have information > for that more specific AS. As such, this essentially could cause a DoS > on that traffic until the BGP route allows for the new path for the more > specific AS. Actually, the traffic to the prefix P is routed towards an AS A that does not have a path for the more specific prefix P, but this AS has a path for a prefix P' covering P. So the traffic makes it to the destination, but via some unexpected path through A. So this is not a DoS per se, is it? Now if the unexpected path through A is under-provisioned, traffic will be lost. But that would be a bit strange for the owner of P to do the documented trick to trigger a DoS of its own prefix P, wouldn’t it? So can I really talk about a DoS vector here? If someone else than the owner of P plays games with P to trigger the unexpected path for P through A, then it definitely becomes one, but there we fall in the classic cases of prefix hi-jacking. Cheers, Pierre. > The importance of mentioning this int he security > considerations section is to more explicitly call this out as a potential > DoS attack method. The time for BGP to repropagate might be short(ish), > but that could be a critical amount of time during an event and maybe the > more specific AS is a web server farm or some other critical resource. > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
