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

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:dots-bounces@ietf.org] On Behalf Of Roland Dobbins
Sent: Thursday, March 16, 2017 7:38 PM
To: dots@ietf.org
Subject: Re: [Dots] draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

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.

-----------------------------------
Roland Dobbins <rdobbins@arbor.net>

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots