Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .

[Ehud Doron <[e-mail]>]

Andrew

Thanks for your feedback.

Let me please clarified my points here. I totally agree with your standpoints that the signal channel restrictions should not be violated by any kind of information.

My view is that draft-doron-dots-telemetry-00 should not dictate how any kind of  telemetry information should be signaled and in which channel. I believe that this should not be discussed as part of the DOTS Telemetry work, but rather as part of the relevant protocol standard work. I see the DOTS Telemetry draft as the DOTS knowledgebase for the telemetry matter. As part do the DOTS protocol work, it should be considered what can (or can’t) be signaled, on which channel and how.

Moreover, we can think on small basic set of “essential” telemetry conveyed using the signaling channel, e.g. attack BW, PPS, dropped traffic or similar (see Tiru’s suggestions in his email), and the rest of information using the data channel.

Nevertheless, the WG need to first get to an agreement about the kind of telemetry required to facilitate a viable anti-DoS service (see please the email the DOTS telemetry authors sent to the WG).

I think this is a very good discussion.

Thanks, Ehud


From: Mortensen, Andrew [mailto:[e-mail]]
Sent: Wednesday, February 15, 2017 6:18 PM
To: Tirumaleswar Reddy (tireddy) <[e-mail]>
Cc: Ehud Doron <[e-mail]>; dots <[e-mail]>; David Aviv <[e-mail]>
Subject: Re: [Dots] Comments and feedbacks on draft-reddy-dots-signal-channel-07 and draft-reddy-dots-data-channel-03 .


On Feb 14, 2017, at 9:53 AM, Tirumaleswar Reddy (tireddy) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Ehud,

Thanks for the detailed review, Please see inline (I will respond to data channel comments in a separate mail)

From: Dots [mailto:[e-mail]] On Behalf Of Ehud Doron
 … snip...
6.       Page 14 figure 5: The mitigation request attributes are right but not enough. Need to add more telemetry info about the actual attack that it is required to mitigate, need to consider attributes in draft-doron-dots-telemetry-00 as part of the discussion in the WG.

[TR] Yes, I plan to update the draft with telemetry info based on outcome of draft-doron-dots-telemetry-00.

I understand need for and support the effort to ensure telemetry between DOTS agents, but I’m skeptical about the suggestion that the right place for it is in the signal channel. The signal channel requirements are restrictive by design (sub-MTU message size, expectation of packet loss, etc.), suggesting incompatibility with the proposed telemetry attributes in draft-doron-dots-telemetry-00. Among other things, that draft proposes CEF for attack details and the inclusion of a list of authenticated sources. Tiru’s signal channel draft suggests assuming an MTU of no more than 1280 bytes if the PMTU is not known, and concludes that a maximum datagram size of 576 bytes with a DOTS payload size of 500 bytes is best to ensure the signal channel will not be fragmented.

All of that is to say I disagree with the suggestion that the signal channel should be the primary vehicle for telemetry. Feedback, yes; unscoped telemetry, no. How do we determine if there’s enough telemetry? How much telemetry does vendor A require to function as a DOTS server or client? How much telemetry loss can either agent (and vendor implementation) withstand?

In contrast, the data channel seems like the ideal place for the sort of telemetry described in draft-doron-dots-telemetry-00. There are no restrictive size or packet loss handling requirements, and RESTCONF supports event streams that would seem to fit the need quite well.

andrew