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

[Pierre Francois (pifranco)]

Kathleen, 


On 01/09/15 16:50, "Kathleen Moriarty" 
wrote:

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

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

[Kathleen Moriarty]

Hi Pierre,

Thanks for your response, questions inline.

On Tue, Sep 1, 2015 at 9:46 AM, Pierre Francois
 wrote:
> Hello Kathleen,
>
> On 20 Aug 2015, at 15:05, Kathleen Moriarty
>  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

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

[Pierre Francois]

Hello Kathleen,

> On 20 Aug 2015, at 15:05, Kathleen Moriarty 
>  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?

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

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

[joel jaeggli]

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

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.

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




signature.asc
Description: OpenPGP digital signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Kathleen Moriarty]

Kathleen Moriarty has entered the following ballot position for
draft-ietf-grow-filtering-threats-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-grow-filtering-threats/



--
COMMENT:
--

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

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


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow