Kathleen,
On 01/09/15 16:50, "Kathleen Moriarty" <kathleen.moriarty.i...@gmail.com> wrote: >Hi Pierre, > >Thanks for your response, questions inline. > >On Tue, Sep 1, 2015 at 9:46 AM, Pierre Francois ><pierre.franc...@imdea.org> wrote: >> 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 >> >> >> 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? > >In section 4.1, you have the following text as bullet 2, which looks >like a potential DoS vector to me: > > o An operator can decide to filter out the more specific prefix at > the peering session over which it was received. In the example of > Figure 5, AS64502 would filter out the incoming prefix > 2001:DB8::/34 from the eBGP session with AS64505. As a result, > the traffic destined to that /32 would be forwarded by AS64502 > along its link with AS64501, despite the actions performed by > AS64501 to have this traffic coming in through its link with > AS64503. However, as AS64502 will no longer know a route to the > more specific prefix, it risks losing the traffic share from > customers different from AS64501 to that prefix. Furthermore, > this action can generate conflicts between AS64502 and AS64501, > since AS64502 does not follow the routing information expressed by > AS64501 in its BGP announcements. We say that AS64502 will lose traffic *share* for the /34, in the sense that it looses the market share of the transit between his customers and the rest of the topology, for the traffic whose destination is the /34. Traffic would not be lost, it will either be forwarded as per the /32, or by other ASes which received and propagated the /34. > >> >> 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. > >I don't see a pointer in the security considerations to other work >describing this threat as a consideration, should this be included? >It sounds as if it should be. Well, I have the feeling that it is quite out of the scope of this document, which is about playing with more specific prefixes injection bound with restricted propagation. I am not sure I should mention prefix hi-jacking here, as it¹s quite a different, well-document approach; I inject a more specific prefix that belongs to someone else and I drop the traffic. I don¹t know what others think about this. Cheers, Pierre. > >Thanks, >Kathleen > >> >> 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. >> >> >> > > > >-- > >Best regards, >Kathleen _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
