Re: [Dots] FW: Why is DOTS not using NETCONF/RESTCONF for management functions

["Mortensen, Andrew" <[e-mail]>]

Hi Sue. The impression I get from reading this is that you see DOTS as a use case or subset of I2NSF. Am I misrepresenting the content dramatically?

A few comments marked [AM] inline. I’ll try to provide a more comprehensive response soon.

On Nov 15, 2016, at 5:32 AM, Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:


My question: Why is DOTS, SCAM, SECEVENT not using the same mechanisms for events, configuration control and telemetry data as NM/OPS with their own data models?
•       This email walks through the DOTS drafts indicating which of the NM/OPS services could be used, and what data is being passed.
•       What I found is that 95% of work is covered by NM/OPS with data models.

[AM] This is a remarkably specific number. :)

The DOTS workgroup has defined three main messaging models:


  *   Actionable Event Alerting

◦        Called ‘Signaling’ in the workgroup – “I’m being attacked”

[AM] While generally true, this summary appears to overlook the requirement that the signaling be operable, to the maximum degree possible, under attack conditions. In particular, the signaling must be robust and operable despite high rates of packet loss e.g. over a link congested with volumetric attack traffic, and must not fragment messages sent over the DOTS signal channel. For that reason the WG settled on the requirement that DOTS signaling use a connectionless protocol with a sub-MTU message size when calling for help. I’m not aware of a UDP-based NETCONF, though I freely admit I may have overlooked it.

The RESTCONF over QUIC work you mention below might be made to meet those requirements, but QUIC is also by design a reliable transport. However, it’s my personal opinion that a request/response convention is not the best option for the SOS signaling, given the significantly increased probability that server responses will be lost when the inbound link is congested with attack traffic.

For that reason, draft-teague-dots-protocol-00 decouples DOTS signal channel messaging from the request/response model. The DOTS client instead calls for help by sustaining mitigation requests in its heartbeats, resembling an emergency beacon at intervals broadcasting the need for aid. The DOTS server uses its unidirectional heartbeats to return mitigation request status to the client. Loss in either direction is absorbed without retransmission, since the client is concerned merely with communicating the current need for mitigation (with associated scope and supplementary data), and the server is concerned solely with returning mitigation status to the client (including refusal to begin mitigation).

Once a DOTS server has enabled mitigation, ideally the data channel is available for reliable operations.


  *   Configuration Control

◦        Called ‘Bulk Data’ in the workgroup

[AM] I’m certainly open to using existing standards here. I previously suggested RESTCONF as an option as far back as my original threat signaling requirements draft: <https://tools.ietf.org/html/draft-mortensen-threat-signaling-requirements-00#section-4.1>. The gRPC work Google’s bringing forward in <https://tools.ietf.org/html/draft-kumar-rtgwg-grpc-protocol-00> is also worth a look, though it seems like there's a degree of overlap with NETCONF there. Not a surprise given gRPC’s use by OpenConfig.

andrew