Subject: [Idr] questions to draft-eddy-idr-flowspec-exp-00

From: Linda Dunbar <[email-masked]>
Date: Thu, 11 Feb 2016 02:33:04 +0000

Wes, et al,

I have some questions to your draft-eddy-idr-flowspec-exp-00:

2.1. Packet Rate Action:

Is the "packet rate" described here intended for "matching condition"? (same way as the matching types proposed by RFC5575?

2.2. Tunnel Description:
-  To match a flow with specific outer tunnel and inner TCP or UDP, "logical operators (AND, OR, NOR)" should be enough. Why need to specifically state "tunnel"?

-        The "Offset-Value-Mask" matching is not intended to be propagated to other peers , is it?

-        Page 7 last sentence: what does "A" mean in "to address A within a GRE flow to address Pout ..."?

3. Other discussion:

You stated that RFC5575 can be translated easily to ACL. The Matching & Action can. But ACL is local to the node, which are not propagated to peers as specified by RFC5575.

For the Anti-DDoS use case, Controller may only wants to impose the ACL for a specific node, instead of sending a big wave to all the ASs.  Other ASs may have its own Anti-DDoC controller temporarily steering some suspicious traffic to its own security scrubbing center. Propagating Anti-DDoS steering policies to other ASs can make the large network oscillate violently (& unnecessarily) .

To contain the unnecessary complexity, there should be two types of Flow Spec control:

-        Distributed, i.e. flowSpec coming from (or propagated to) peers.

-        Centralized, i.e. "Flow Specs" coming from its designated "controller".

Under the "Centralized" mode, there should be a mode that doesn't propagate received route policies to peers (i.e. localized policy).  Under this "Centralized & no propagating" mode, a lot of tricky issues (like security) goes away.

Thank you very much.

Linda

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 22 Feb 2016 15:31:27 -0500

Hi Linda, thanks for the feedback, here are some answers inline:

On 2/10/2016 9:33 PM, Linda Dunbar wrote:
> Is the “packet rate” described here intended for “matching condition”? 
> (same way as the matching types proposed by RFC5575?
>

No, it is intended as an action applied to traffic matching the filter.  
In flowspec/5575, the community attributes are used to indicate the 
action, whereas the NLRI indicates the matching criteria.

> 2.2. Tunnel Description:
>
> -  To match a flow with specific outer tunnel and inner TCP or UDP, 
> “logical operators (AND, OR, NOR)” should be enough. Why need to 
> specifically state “tunnel”?
>
> -The“Offset-Value-Mask” matching is not intended to be propagated to 
> other peers , is it?
>

Yes, if not propagated to other peers, it wouldn't be useful to include 
in BGP :)

> -Page 7 last sentence: what does “A” mean in “to address A within a 
> GRE flow to address Pout …”?
>

That was just intended as a variable "A".  It could have been any other 
symbol.

> 3. Other discussion:
>
> You stated that RFC5575 can be translated easily to ACL. The Matching 
> & Action can. But ACL is local to the node, which are not propagated 
> to peers as specified by RFC5575.
>

Agreed.

> For the Anti-DDoS use case, Controller may only wants to impose the 
> ACL for a specific node, instead of sending a big wave to all the ASs. 
> Other ASs may have its own Anti-DDoC controller temporarily steering 
> some suspicious traffic to its own security scrubbing center. 
> Propagating Anti-DDoS steering policies to other ASs can make the 
> large network oscillate violently (& unnecessarily) .
>

The logic for controlling distribution of updates is a separate problem, 
and actually more difficult than just defining a wire format.  You are 
definitely correct that this logic and the configuration settings in 
practice are very important to successfully deploying something like 
this.  That logic doesn't really need to be standardized IMO, though, 
since it can be different in various ASes or products, as long as they 
can communicate over the wire.

> -Distributed, i.e. flowSpec coming from (or propagated to) peers.
>
> -Centralized, i.e. “Flow Specs” coming from its designated “controller”.
>
> Under the “Centralized” mode, there should be a mode that doesn’t 
> propagate received route policies to peers (i.e. localized policy). 
>  Under this “Centralized & no propagating” mode, a lot of tricky 
> issues (like security) goes away.
>

That would be one possible implementation approach, IMO, though there 
may be others, for instance with subsets of rules to redistribute 
indicated in policies on a neighbor-by-neighbor basis.

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 23 Feb 2016 00:01:39 +0000

Wes,

Thank you very much for the reply. Since my  writing to you a week ago, I've done some study of other IDR FlowSpec related drafts (there are many of them).

I think it is worthwhile to look at all flow Spec approach holistically like https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/

First of all, I believe that Flow Spec is  very useful for influencing routes (as described by the Section 3 of https://datatracker.ietf.org/doc/draft-li-idr-flowspec-rpd/ ). It is great to see many extensions to make IDR FlowSpec more comprehensive.

However,  Flow Spec is far from enough for mitigating today's sophisticated DDoS attacks. As in Amazon's AWS service where attackers are from leased virtual machines, more and more DDoS attacks do originate from legitimate sources (i.e. the approach described by RFC5635 has more chance of dropping legitimate traffic than the DDoS attack packets) .

Therefore, IMHO, the "Introduction section" of your draft shouldn't  focus on what  Flow Spec is missing when used for Anti-DDoS, because there are a lot more missing. The "extension" you described is not enough in mitigating the modern DDoS attacks. There is a working Group DOTS whose purpose is for DDoS mitigation.

Instead the "Introduction" should describe the general structure of IDR FlowSpec, to make RFC5575 more complete in influencing routes.

For example, I think the following items should be described for Flow Specs:

-       Flow Specs consists of two major components:  Matching criteria and Actions. The Matching criteria are carried by NRLI, the Actions are carried by BGP extended Community.
-       For Actions: there are two major categories (Separating Control Plane policy from the data plane policy )
o       Data Plane action: The Actions for local node, i.e.  ACL actions to routers, such as Rate Limiting, forwarding, egress, tunnel, etc
o       Control Plane action: The Actions for how the routes is propagated to peers and its priority (or the precedence) if conflicting with other routes.

-       Your draft is to describe the extension of Matching Criteria & Actions for Packet Rate action, the Tunnel Description, Flow Spec identifier, etc.

Attached is my suggested wording for the introduction of your draft.

Best regards, Linda Dunbar

From: Wesley Eddy [mailto:[email-masked]]
Sent: Monday, February 22, 2016 2:31 PM
To: Linda Dunbar; Justin Dailey; [email-masked]
Subject: Re: questions to draft-eddy-idr-flowspec-exp-00

Wes, et al,

2.1. Packet Rate Action:

No, it is intended as an action applied to traffic matching the filter.  In flowspec/5575, the community attributes are used to indicate the action, whereas the NLRI indicates the matching criteria.

2.2. Tunnel Description:

Yes, if not propagated to other peers, it wouldn't be useful to include in BGP :)

That was just intended as a variable "A".  It could have been any other symbol.

3. Other discussion:

Agreed.

The logic for controlling distribution of updates is a separate problem, and actually more difficult than just defining a wire format.  You are definitely correct that this logic and the configuration settings in practice are very important to successfully deploying something like this.  That logic doesn't really need to be standardized IMO, though, since it can be different in various ASes or products, as long as they can communicate over the wire.

That would be one possible implementation approach, IMO, though there may be others, for instance with subsets of rules to redistribute indicated in policies on a neighbor-by-neighbor basis.

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 23 Feb 2016 09:08:26 -0500

Hi Linda, some replies are inline below:

On 2/22/2016 7:01 PM, Linda Dunbar wrote:
> Wes,
> Thank you very much for the reply. Since my writing to you a week ago, 
> I’ve done some study of other IDR FlowSpec related drafts (there are 
> many of them).
> I think it is worthwhile to look at all flow Spec approach 
> holistically like 
> https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/

I agree completely with this, and think that a "flowspec v2" such as 
that draft proposes is probably a good idea, given the mass of 
modifications people are proposing.

> First of all, I believe that Flow Spec is very useful for influencing 
> routes (as described by the Section 3 of 
> https://datatracker.ietf.org/doc/draft-li-idr-flowspec-rpd/ ). It is 
> great to see many extensions to make IDR FlowSpec more comprehensive.
> However, Flow Spec is far from enough for mitigating today’s 
> sophisticated DDoS attacks. As in Amazon’s AWS service where attackers 
> are from leased virtual machines, more and more DDoS attacks do 
> originate from legitimate sources (i.e. the approach described by 
> RFC5635 has more chance of dropping legitimate traffic than the DDoS 
> attack packets) .

This seems to me like yet more rationale for interdomain communication 
that allows the abuse to be notified and appropriate filters to be 
applied as close to the source as possible.

The "collateral damage" effect of over-broad filtering can enable new 
attack vectors, designed to cause some third-party target to fall within 
the same filter specification as a dummy attack.

> Therefore, IMHO, the “Introduction section” of your draft shouldn’t 
> focus on what Flow Spec is missing when used for Anti-DDoS, because 
> there are a lot more missing. The “extension” you described is not 
> enough in mitigating the modern DDoS attacks. There is a working Group 
> DOTS whose purpose is for DDoS mitigation.

The scope of DOTS is significantly different, IMO.  I think it is 
complementary work and not at odds with flowspec and flowsepc enhancements.

> Instead the “Introduction” should describe the general structure of 
> IDR FlowSpec, to make RFC5575 more complete in influencing routes.
>   * Flow Specs consists of two major components: Matching criteria and
>     Actions. The Matching criteria are carried by NRLI, the Actions
>     are carried by BGP extended Community.
>
>   * For Actions: there are two major categories (*Separating Control
>     Plane policy from the data plane policy *)
>
>   * Data Plane action: The Actions for local node, i.e. ACL actions to
>     routers, such as Rate Limiting, forwarding, egress, tunnel, etc
>   * Control Plane action: The Actions for how the routes is propagated
>     to peers and its priority (or the precedence) if conflicting with
>     other routes.
>
>   * Your draft is to describe the extension of Matching Criteria &
>     Actions for Packet Rate action, the Tunnel Description, Flow Spec
>     identifier, etc.
>

Thanks! We'll consider this when updating the draft.  I'm not actually 
sure if it will be updated, or needs to be updated at the moment, as it 
was really just to generate discussion and describe some ideas (not all 
of which are very practical). For instance, the tunnel specification has 
some real problems.  We did already split out the description of the 
packet rate action into draft-eddy-idr-packet-rate, since it seemed 
immediately practical and relatively trivial.

I think in Sue's omnibus draft that you cited above, she did a good job 
of pulling out the couple pieces that are applicable in the near-term, 
and I believe the other topics that we discussed in 
draft-eddy-idr-flowspec-exp are still just interesting research topics 
that are pretty far from being ready to consider for standardization.