Subject: [Dots] draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

From: "Zhenghui (Marvin)" <[email-masked]>
Date: Mon, 13 Mar 2017 07:37:17 +0000

Hello DOTS WG,

We have submitted a draft draft-fu-dots-ipfix-tcp-tracking-00, which is the succession of draft-fu-dots-ipfix-extension-01.
The original draft has been reviewed internally. As a result,  the IPFIX Information Elements inside the draft have been revised, and some of the IEs are removed.

However, we’ve realized what our draft intends to do is not what currently DOTS WG is focusing on.
So, we’d like to hear from the WG, is that some pointers can be given on the next step of the draft, or where we can continue the discussion of the issue that the draft addresses.

We submitted this draft to DOTS because IPFIX WG had been closed, and DOTS was the best match we found.

Thanks.

Marvin Zhenghui
Best Regards

---

From: Roland Dobbins <[email-masked]>
Date: Mon, 13 Mar 2017 15:41:48 +0700

On 13 Mar 2017, at 14:37, Zhenghui (Marvin) wrote:

> So, we’d like to hear from the WG, is that some pointers can be 
> given on the next step of the draft,

The draft belies a lack of understanding of how current IPFIX 
capabilities are utilized every day to detect, classify, and traceback 
DDoS attacks.  It makes factually incorrect statements such as 'not 
suitable for attack detection, and impractical suggestinos such as 
'connection sampling' which a) won't work on routers/layer-3 switches of 
any size and b) are unnecessary.

It is suggested that the authors of the draft gain operational 
experience using existing IPFIX implementations and IPFIX 
collection/analysis systems in order to fully understand the utility of 
IPFIX as presently defined as well as the full range of capabilities of 
IPFIX collection/analysis systems.  It would also be a good idea for the 
authors of the draft to understand the division of labor between IPFIX 
exporters and IPFIX collectors/analyzers, as well as the capabilities 
and limitations of hardware-based routing/switching platforms.

> We submitted this draft to DOTS because IPFIX WG had been closed

It is entirely possible to re-open the IPFIX WG, if it is deemed useful 
to do so.  The authors of the draft should contact the appropriate Area 
Director in order to discuss.

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 13 Mar 2017 16:08:01 +0000

Hello Marvin!

Thanks for sharing this update. 

> Sent: Monday, March 13, 2017 3:37 AM
> Subject: [Dots] draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking
>
[snip]

> what currently DOTS WG is focusing on.
[snip]
> We submitted this draft to DOTS because IPFIX WG had 
> been closed, and DOTS was the best match we found.

To confirm, you do not see this draft as mapping to the existing WG architecture [1] or the protocol requirements [2] (as in part of a signal or data channel)?

Regards,
Roman

[1] draft-ietf-dots-architecture-01
[2] draft-ietf-dots-requirements-03

---

From: "Zhenghui (Marvin)" <[email-masked]>
Date: Tue, 14 Mar 2017 03:37:06 +0000

Thanks Roland, your comment is well received.

The description of 'connection sampling' in the previous draft has been removed. In the new draft, currently we are focusing on the concept of TCP connection tracking.

Best Regards,
Zhenghui (Marvin)

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
Sent: Monday, March 13, 2017 4:42 PM
To: [email-masked]
Subject: Re: [Dots] draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

On 13 Mar 2017, at 14:37, Zhenghui (Marvin) wrote:

> So, we’d like to hear from the WG, is that some pointers can be given 
> on the next step of the draft,

The draft belies a lack of understanding of how current IPFIX capabilities are utilized every day to detect, classify, and traceback DDoS attacks.  It makes factually incorrect statements such as 'not suitable for attack detection, and impractical suggestinos such as 'connection sampling' which a) won't work on routers/layer-3 switches of any size and b) are unnecessary.

It is suggested that the authors of the draft gain operational experience using existing IPFIX implementations and IPFIX collection/analysis systems in order to fully understand the utility of IPFIX as presently defined as well as the full range of capabilities of IPFIX collection/analysis systems.  It would also be a good idea for the authors of the draft to understand the division of labor between IPFIX exporters and IPFIX collectors/analyzers, as well as the capabilities and limitations of hardware-based routing/switching platforms.

> We submitted this draft to DOTS because IPFIX WG had been closed

It is entirely possible to re-open the IPFIX WG, if it is deemed useful to do so.  The authors of the draft should contact the appropriate Area Director in order to discuss.

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

---

From: "Zhenghui (Marvin)" <[email-masked]>
Date: Tue, 14 Mar 2017 04:34:55 +0000

Hi Roman,

We used to believe that IPFIX can serve as a way for DOTS telemetry. 
However, an impression I've got in the past few weeks following the WG discussion, it is agreed that telemetry is an issue to be postponed.

Basically, we'd like to hear from the WG, about their opinions on this draft, so we can figure out what to do next.

For now, we do not see this draft as strongly mapping to the existing WG architecture or the protocol requirements.

Best Regards,
Zhenghui (Marvin)

-----Original Message-----
From: Roman Danyliw [mailto:[email-masked]] 
Sent: Tuesday, March 14, 2017 12:08 AM
To: Zhenghui (Marvin) <[email-masked]>; [email-masked]
Subject: RE: draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

Hello Marvin!

[snip]

[snip]

Regards,
Roman

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 14 Mar 2017 20:34:37 +0700

On 14 Mar 2017, at 10:37, Zhenghui (Marvin) wrote:

>  currently we are focusing on the concept of TCP connection tracking.

Same comments apply.

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 14 Mar 2017 20:40:50 +0700

On 14 Mar 2017, at 11:34, Zhenghui (Marvin) wrote:

> Basically, we'd like to hear from the WG, about their opinions on this 
> draft, so we can figure out what to do next.

1.  The draft itself is predicted upon invalid assumptions about the 
capabilities inherent in IPFIX as it stands today.

2.  The draft itself is predicated upon invalid assumptions about the 
capabilities inherent in IPFIX collectors/analyzers today.

3.  The draft itself is predicated upon invalid assumptions about the 
capabilities inherent in IPFIX exporters today and anticipated in the 
foreseeable future.

4.  The draft itself is predicated upon invalid assumptions about the 
division of labor between IPFIX exporters and IPFIX 
collectors/analyzers.

5.  The best forum for this discussion is within the Operations and 
Management Area of the IETF.

6.  The way to initiate a discussion about re-opening the IPFIX WG is to 
engage the IETF Area Director for Operations and Management.

---

From: "Zhenghui (Marvin)" <[email-masked]>
Date: Wed, 15 Mar 2017 01:44:23 +0000

Hi Roland,

Don't worry, if the draft really doesn't suit in this WG, we will move away.
But, I think we just to hear some voice before doing so, due to the original draft was submitted here.

It'd been more appreciated if you could give some details about your statements 1 to 4.

Best Regards,
Zhenghui (Marvin)

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
Sent: Tuesday, March 14, 2017 9:41 PM
To: [email-masked]
Subject: Re: [Dots] draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

> draft, so we can figure out what to do next.

1.  The draft itself is predicted upon invalid assumptions about the capabilities inherent in IPFIX as it stands today.

2.  The draft itself is predicated upon invalid assumptions about the capabilities inherent in IPFIX collectors/analyzers today.

3.  The draft itself is predicated upon invalid assumptions about the capabilities inherent in IPFIX exporters today and anticipated in the foreseeable future.

4.  The draft itself is predicated upon invalid assumptions about the division of labor between IPFIX exporters and IPFIX collectors/analyzers.

5.  The best forum for this discussion is within the Operations and Management Area of the IETF.

6.  The way to initiate a discussion about re-opening the IPFIX WG is to engage the IETF Area Director for Operations and Management.

---

From: Roland Dobbins <[email-masked]>
Date: Wed, 15 Mar 2017 09:08:00 +0700

> It'd been more appreciated if you could give some details about your 

I've already commented in detail on previous iterations of the draft, 
both on this list as well as privately to one of the authors of its 
previous incarnations.  Those comments hold true for this one, as well.

---

From: "Zhenghui (Marvin)" <[email-masked]>
Date: Wed, 15 Mar 2017 02:12:32 +0000

Thanks, I will seek that out.

Best Regards,
Zhenghui (Marvin)

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
Sent: Wednesday, March 15, 2017 10:08 AM
To: [email-masked]
Subject: Re: [Dots] draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

> It'd been more appreciated if you could give some details about your 

I've already commented in detail on previous iterations of the draft, both on this list as well as privately to one of the authors of its previous incarnations.  Those comments hold true for this one, as well.

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 16 Mar 2017 00:49:41 +0000

Hi Marvin!

Thanks for this clarification.

Since the draft appears to want to add seven entries to the "IPFIX information elements" registry [1], have you considered directly asking for the additions?  The registration process for new IEs is expert review.

Roman

[1] http://www.iana.org/assignments/ipfix/ipfix.xhtml

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Zhenghui (Marvin)
Sent: Tuesday, March 14, 2017 12:35 AM
To: Roman Danyliw <[email-masked]>; [email-masked]
Subject: Re: [Dots] draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

Hi Roman,

Best Regards,
Zhenghui (Marvin)

-----Original Message-----
From: Roman Danyliw [mailto:[email-masked]]
Sent: Tuesday, March 14, 2017 12:08 AM
To: Zhenghui (Marvin) <[email-masked]>; [email-masked]
Subject: RE: draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

Hello Marvin!

[snip]

[snip]

Regards,
Roman

---

From: "Zhenghui (Marvin)" <[email-masked]>
Date: Thu, 16 Mar 2017 06:56:57 +0000

Hi Roman!

Thanks for the information. We had been made aware of that.

The reason for submitting the draft is that, a) this is a successive work of draft-fu-dots-ipfix-extension, so we would like to declare it here, before moving to a more suitable place; b) we think DOTS WG's opinions matter to us, prior to expert review.

Best Regards,
Zhenghui (Marvin)

-----Original Message-----
From: Roman Danyliw [mailto:[email-masked]] 
Sent: Thursday, March 16, 2017 8:50 AM
To: Zhenghui (Marvin) <[email-masked]>; [email-masked]
Subject: RE: draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

Hi Marvin!

Roman

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Zhenghui (Marvin)
Sent: Tuesday, March 14, 2017 12:35 AM
To: Roman Danyliw <[email-masked]>; [email-masked]
Subject: Re: [Dots] draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

Hi Roman,

Best Regards,
Zhenghui (Marvin)

-----Original Message-----
From: Roman Danyliw [mailto:[email-masked]]
Sent: Tuesday, March 14, 2017 12:08 AM
To: Zhenghui (Marvin) <[email-masked]>; [email-masked]
Subject: RE: draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

Hello Marvin!

[snip]

[snip]

Regards,
Roman

---

From: Dave Dolson <[email-masked]>
Date: Thu, 16 Mar 2017 11:01:15 +0000

‎Zhenghui,
I just took a look at the draft, and the document makes a lot of sense to me. The TCP features being measured are important.

Clearly these are intended to be collected by stateful devices that do see both directions of traffic, not generic routers.  (Such stateful devices do exist and are widely deployed.) Perhaps your introduction should use the term "stateful layer4 device" instead of "router" to make your assumptions clearer.

One thing you might look at is whether "TCP" is too specific. Some of these may apply to QUIC in the near future. For example, have you seen ‎https://tools.ietf.org/id/draft-trammell-plus-statefulness-02.html ?

-Dave

  Original Message
From: Zhenghui (Marvin)
Sent: Wednesday, March 15, 2017 11:57 PM
To: Roman Danyliw; [email-masked]
Subject: Re: [Dots] draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

Hi Roman!

Best Regards,
Zhenghui (Marvin)

-----Original Message-----
From: Roman Danyliw [mailto:[email-masked]]
Sent: Thursday, March 16, 2017 8:50 AM
To: Zhenghui (Marvin) <[email-masked]>; [email-masked]
Subject: RE: draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

Hi Marvin!

Roman

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Zhenghui (Marvin)
Sent: Tuesday, March 14, 2017 12:35 AM
To: Roman Danyliw <[email-masked]>; [email-masked]
Subject: Re: [Dots] draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

Hi Roman,

Best Regards,
Zhenghui (Marvin)

-----Original Message-----
From: Roman Danyliw [mailto:[email-masked]]
Sent: Tuesday, March 14, 2017 12:08 AM
To: Zhenghui (Marvin) <[email-masked]>; [email-masked]
Subject: RE: draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

Hello Marvin!

[snip]

[snip]

Regards,
Roman

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 16 Mar 2017 18:37:35 +0700

On 16 Mar 2017, at 18:01, Dave Dolson wrote:

> Clearly these are intended to be collected by stateful devices that do 
> see both directions of traffic, not generic routers.

 From draft-fu-dots-ipfix-extension:

'For a network device, such as a router, to detect anomaly TCP traffics, 
it has to understand the semantics of TCP operations, more specifically, 
it has to be able to track TCP connection states.  If a router has 
implemented such ability, it can export characteristics information 
regarding the TCP connections.'

It's pretty clear that the draft authors were in fact explicitly talking 
about generic routers, which is the source of some (but not all) 
previously-expressed objections.

There are also multiple incorrect statements and implied statements in 
the draft, which indicate a lack of awareness of the current state of 
the art in attack detection/classification utilizing existing telemetry 
capabilities.  Furthermore, the amount of state required to try and 
track the things highlighted in the draft is way more than even a 
stateful middlebox could handle for even a relatively small amount of 
traffic.

It's a lot more efficient to export the relevant telemetry to a 
collection/analysis system (which could in fact be an on-board 
power-sucking-alien general-purpose computer) and do this sort of thing 
there.  Trying to do these calculations and maintain this state in the 
data-plane is a non-starter at any kind of speed/scale.

Again, all this is out of scope for DOTS.  It would be more appropriate 
to talk to the appropriate AD and/or submit these to the registry for 
review, as Roman indicated.  It would be even more appropriate to 
implement them and see how well they actually work in practice before 
doing either.

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 16 Mar 2017 18:52:14 +0700

> From draft-fu-dots-ipfix-extension:

Sorry, that should read 'draft-fu-dots-ipfix-tcp-tracking'.

---

From: "Zhenghui (Marvin)" <[email-masked]>
Date: Fri, 17 Mar 2017 01:39:52 +0000

Hi Dave!

Thanks for the suggestion.

As for QUIC, I've just started looking at it. I'll certainly take your advice into consideration.

Best Regards,
Zhenghui (Marvin)

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Thursday, March 16, 2017 7:01 PM
To: Zhenghui (Marvin) <[email-masked]>; Roman Danyliw <[email-masked]>; [email-masked]
Subject: Re: [Dots] draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

‎Zhenghui,

-Dave

  Original Message
From: Zhenghui (Marvin)

Hi Roman!

Best Regards,
Zhenghui (Marvin)

-----Original Message-----
From: Roman Danyliw [mailto:[email-masked]]
Sent: Thursday, March 16, 2017 8:50 AM
To: Zhenghui (Marvin) <[email-masked]>; [email-masked]
Subject: RE: draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

Hi Marvin!

Roman

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Zhenghui (Marvin)
Sent: Tuesday, March 14, 2017 12:35 AM
To: Roman Danyliw <[email-masked]>; [email-masked]
Subject: Re: [Dots] draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

Hi Roman,

Best Regards,
Zhenghui (Marvin)

-----Original Message-----
From: Roman Danyliw [mailto:[email-masked]]
Sent: Tuesday, March 14, 2017 12:08 AM
To: Zhenghui (Marvin) <[email-masked]>; [email-masked]
Subject: RE: draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

Hello Marvin!

[snip]

[snip]

Regards,
Roman

---

From: "Zhenghui (Marvin)" <[email-masked]>
Date: Fri, 17 Mar 2017 01:51:21 +0000

Hi Roland,

Telemetry performance is definitely a concern. We've actually implemented a prototype and hooked it to a domestic ISP's network in China.  I haven't received the performance report from them yet. So, no detailed information to share with you at the moment.

Again, I understand your concern about the scope thing. We will handle it with discretion. 

Best Regards,
Zhenghui (Marvin)

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
Sent: Thursday, March 16, 2017 7:38 PM
To: [email-masked]
Subject: Re: [Dots] draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

'For a network device, such as a router, to detect anomaly TCP traffics, it has to understand the semantics of TCP operations, more specifically, it has to be able to track TCP connection states.  If a router has implemented such ability, it can export characteristics information regarding the TCP connections.'

It's pretty clear that the draft authors were in fact explicitly talking about generic routers, which is the source of some (but not all) previously-expressed objections.

There are also multiple incorrect statements and implied statements in the draft, which indicate a lack of awareness of the current state of the art in attack detection/classification utilizing existing telemetry capabilities.  Furthermore, the amount of state required to try and track the things highlighted in the draft is way more than even a stateful middlebox could handle for even a relatively small amount of traffic.

It's a lot more efficient to export the relevant telemetry to a collection/analysis system (which could in fact be an on-board power-sucking-alien general-purpose computer) and do this sort of thing there.  Trying to do these calculations and maintain this state in the data-plane is a non-starter at any kind of speed/scale.

Again, all this is out of scope for DOTS.  It would be more appropriate to talk to the appropriate AD and/or submit these to the registry for review, as Roman indicated.  It would be even more appropriate to implement them and see how well they actually work in practice before doing either.

---

From: Roland Dobbins <[email-masked]>
Date: Fri, 17 Mar 2017 08:55:45 +0700

On 17 Mar 2017, at 8:51, Zhenghui (Marvin) wrote:

>  We've actually implemented a prototype and hooked it to a domestic 
> ISP's network in China.  I haven't received the performance report 
> from them yet. So, no detailed information to share with you at the 
> moment.

What speed link(s)?

As Dave Dolson indicated, this makes more sense for non-router/-switch 
middleboxes than for routers/layer-3 switches.  The performance and 
scale concerns still apply for links of any real speed.

> Again, I understand your concern about the scope thing. We will handle 

Greatly appreciated!