Subject: Re: [i2rs] FW: New Version Notification for draft-krishnan-i2rs-large-flow-use-case-01.txt

From: Jeffrey Haas <[email-masked]>
Date: Mon, 17 Feb 2014 17:43:56 -0500

Ramki,

On Mon, Jan 20, 2014 at 09:43:24PM -0800, ramki Krishnan wrote:
> Besides load balancing, we have added an additional use of case for DDoS attack mitigation in the latest draft. Looking forward to your comments.

Below, please find some comments on -03:

I'm having some difficulty reconciling the idea of typical DDoS traffic as
being considered a "large flow".  While your definition of a flow (section
1.3) leaves some latitude for which fields are used to identify a flow, that
definition doesn't quite align with that in section 4.3.1 of 
draft-ietf-opsawg-large-flow-load-balancing.  In particular, "a sequence of
packets for which ordered delivery should be maintained".  

This may be intentional since the use cases are somewhat different, however
I think it doesn't help the i2rs DDoS use case.  In such a case, the flow is
only long-lived in the sense that it is out of specification traffic for an
extended period that is unwanted.  In many cases, such traffic may only
share the destination.  This seems to stretch the definition a little bit.

In section 2.1, you're intentionally setting aside involvement of an I2RS
agent as being the entity that shares the communication of recognizing large
flows.  While I understand that existing mechanisms like IPFIX may be a
better (initial) fit, why put it out of scope?  

For my own part, I believe that IPFIX collectors are likely participants in
I2RS, long term.  This would align with the second case where sampling
collectors are used.

In section 2.3.1, I believe there's also an implicit requirement that
network elements be able to report if they are *capable* of permitting the
programming of PBR entries to specific components.  For example, if a LAG
only carries a single IP address as an endpoint, sufficient information may
not be available for layer 3 nexthop programming to distribute the traffic
across the LAG and interaction with the load balancer at a deeper level
may be required.

There is also a typo: "a mechanism  a programmable mechanism"

I believe the intention of the section with this typo is that when traffic
may be distributed over an ECMP path that the weights of the contributing
nexthops for the ECMP path can be adjusted.  If so, that's not clear in the
way the text is currently written.

Section 2.3.2.2 for MPLS Networks should probably include mention of the
Entropy Label feature (RFC 6790).

In section 3, another potential mitigation is I2RS initiating BGP Flowspec.

-- Jeff

---

From: ramki Krishnan <[email-masked]>
Date: Thu, 20 Feb 2014 16:44:05 -0800

Hi Jeff,

Many thanks for your detailed comments. Please find answers inline.

Thanks,
Ramki

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Monday, February 17, 2014 2:44 PM
To: ramki Krishnan
Cc: [email-masked]; [email-masked]
Subject: Re: [i2rs] FW: New Version Notification for draft-krishnan-i2rs-large-flow-use-case-01.txt

Ramki,

I'm having some difficulty reconciling the idea of typical DDoS traffic as being considered a "large flow".  While your definition of a flow (section
1.3) leaves some latitude for which fields are used to identify a flow, that definition doesn't quite align with that in section 4.3.1 of draft-ietf-opsawg-large-flow-load-balancing.  In particular, "a sequence of packets for which ordered delivery should be maintained".  

This may be intentional since the use cases are somewhat different, however I think it doesn't help the i2rs DDoS use case.  In such a case, the flow is only long-lived in the sense that it is out of specification traffic for an extended period that is unwanted.  In many cases, such traffic may only share the destination.  This seems to stretch the definition a little bit.

Ramki: "a sequence of packets for which ordered delivery should be maintained" -- what we mean is that the router does not re-order packets of a flow. For example, a flow could be based on destination IP which would include traffic from multiple ingress ports.

In section 2.1, you're intentionally setting aside involvement of an I2RS agent as being the entity that shares the communication of recognizing large flows.  While I understand that existing mechanisms like IPFIX may be a better (initial) fit, why put it out of scope?  

For my own part, I believe that IPFIX collectors are likely participants in I2RS, long term.  This would align with the second case where sampling collectors are used.

Ramki: Communicating the large flow to external entities can be effectively handled by IPFIX (changes may be needed to IPFIX protocol) without I2RS involvement; same with sampling technologies too. Do you see any additional benefits by collapsing the IPFIX/sFlow agent functionality into I2RS ?

In section 2.3.1, I believe there's also an implicit requirement that network elements be able to report if they are *capable* of permitting the programming of PBR entries to specific components.  For example, if a LAG only carries a single IP address as an endpoint, sufficient information may not be available for layer 3 nexthop programming to distribute the traffic across the LAG and interaction with the load balancer at a deeper level may be required.

Ramki: Agreed, will add it.

Ramki: Thanks, will fix it.

I believe the intention of the section with this typo is that when traffic may be distributed over an ECMP path that the weights of the contributing nexthops for the ECMP path can be adjusted.  If so, that's not clear in the way the text is currently written.

Ramki: Thanks, will make the text more readable.

Section 2.3.2.2 for MPLS Networks should probably include mention of the Entropy Label feature (RFC 6790).

Ramki: In this case, the entropy label feature does not apply. We are talking about an indivisible large flow.

Ramki: Makes sense, will add it.

-- Jeff

_______________________________________________
i2rs mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs

---

From: ramki Krishnan <[email-masked]>
Date: Thu, 20 Feb 2014 18:16:38 -0800

Hi Jeff,

Please find some additional answers/questions inline.

Thanks,
Ramki

-----Original Message-----
From: ramki Krishnan 
Sent: Thursday, February 20, 2014 4:44 PM
To: 'Jeffrey Haas'
Cc: [email-masked]; [email-masked]
Subject: RE: [i2rs] FW: New Version Notification for draft-krishnan-i2rs-large-flow-use-case-01.txt

Hi Jeff,

Thanks,
Ramki

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Monday, February 17, 2014 2:44 PM
To: ramki Krishnan
Cc: [email-masked]; [email-masked]
Subject: Re: [i2rs] FW: New Version Notification for draft-krishnan-i2rs-large-flow-use-case-01.txt

Ramki,

Ramki: "a sequence of packets for which ordered delivery should be maintained" -- what we mean is that the router does not re-order packets of a flow. For example, a flow could be based on destination IP which would include traffic from multiple ingress ports.
Ramki(1): For the DDoS use case, it makes sense to use the IPFIX definition of flow -- http://tools.ietf.org/html/rfc5472#page-22. We will make the appropriate changes in the draft.

Ramki: In this case, the entropy label feature does not apply. We are talking about an indivisible large flow.
Ramki (1): Can you please clarify further what you would like to be addressed ?

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 25 Feb 2014 21:01:43 -0500

Ramki,

> Ramki: "a sequence of packets for which ordered delivery should be maintained" -- what we mean is that the router does not re-order packets of a flow. For example, a flow could be based on destinat…

Thanks for the clarification.  I would suggest that you might want to point
this out as somewhat of a divergence from the opsawg draft.  I think that
while it fits within the very letter of the definition, it's pushing the
spirit of it.

> Ramki: Communicating the large flow to external entities can be effectively handled by IPFIX (changes may be needed to IPFIX protocol) without I2RS involvement; same with sampling technologies too.…

My point is that one may use I2RS notifications (mechanism, TBD) in order to
flag such things.  This also opens avenues for additional integration with
things like IPFIX; e.g. adding a new field to the template to correlate the
ejection of a particular flow record with an alert to allow foreign key
correlation of the two events.

> Ramki: In this case, the entropy label feature does not apply. We are talking about an indivisible large flow.

The thought I had was that part of the desire for entropy labels was to turn
something into a large flow - i.e. influence load balancing.

-- Jeff