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

From: Pierre Francois <[email-masked]>
Date: Tue, 1 Sep 2015 15:46:51 +0200

Hello Kathleen,

> On 20 Aug 2015, at 15:05, Kathleen Moriarty <[email-masked]> 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.
> 
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 1 Sep 2015 10:50:17 -0400

Hi Pierre,

Thanks for your response, questions inline.

On Tue, Sep 1, 2015 at 9:46 AM, Pierre Francois
<[email-masked]> wrote:
> Hello Kathleen,
>
> On 20 Aug 2015, at 15:05, Kathleen Moriarty
> <[email-masked]> wrote:
>
> 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
> 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.
> This document presents examples of such side effects and discusses
> approaches towards solutions to the problem.
>
>
>
> 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.

> A, then it definitely becomes one, but there we fall in the classic cases

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

-- 

Best regards,
Kathleen

---

From: Peter Schoenmaker <[email-masked]>
Date: Tue, 1 Sep 2015 16:16:13 +0100

>>> trick to trigger a DoS of its own prefix P, wouldn¹t it?
>>>
>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.

I would agree this is out of scope for the document.  The traffic makes it to the intended and correct destination.  There are no rogue players involved (at least more than normal which is covered extensively in other documents as pierre points out.)  The main point is how traffic is routed through different networks.

peter

---

From: joel jaeggli <[email-masked]>
Date: Tue, 1 Sep 2015 09:11:05 -0700

On 9/1/15 8:16 AM, Peter Schoenmaker wrote:
> 
>> 
>>> 
>>>> 
>>>> 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.
>> 
>> 
>> 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 would agree this is out of scope for the document.  The traffic
> makes it to the intended and correct destination.  There are no rogue
> players involved (at least more than normal which is covered
> extensively in other documents as pierre points out.)  The main point
> is how traffic is routed through different networks.

We worked pretty hard to keep both the attack terminology out of the
document and to keep the focus on the non-malicious action of ordinary
actors. I think it's better that we don't lump that in with malicious
action of varying varieties.

>>> Thanks, Kathleen
>>>> 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
>> 
> 
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 1 Sep 2015 12:17:31 -0400

> action of varying varieties.

My comments were just comments and not a discuss, so I appreciate the
discussion and you can decide what to do or not do with it.  It
basically was a set of questions I wound up with in reading the draft
to make sure security considerations were included.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Pierre Francois (pifranco)" <[email-masked]>
Date: Tue, 1 Sep 2015 15:06:17 +0000

Kathleen, 

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

>> ‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹
>>
>>

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.

Cheers, 

Pierre.