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.
>
> 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.
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
