Re: [GROW] Kathleen Moriarty's No Objection on draft-ietf-grow-filtering-threats-07: (with COMMENT)

["Pierre Francois (pifranco)" <[e-mail]>]

Kathleen, 


On 01/09/15 16:50, "Kathleen Moriarty" <[e-mail]>
wrote:

>Hi Pierre,
>
>Thanks for your response, questions inline.
>
>On Tue, Sep 1, 2015 at 9:46 AM, Pierre Francois
><[e-mail]> wrote:
>> Hello Kathleen,
>>
>> On 20 Aug 2015, at 15:05, Kathleen Moriarty
>> <[e-mail]> 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