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

From: "Susan Hares" <[email-masked]>
Date: Tue, 15 Nov 2016 05:32:16 -0500

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.  

This email is a description of this problem.  I will be submitting a draft regarding this point. 

Sue 

===========

The DOTS workgroup has defined three main messaging models: 

*	Actionable Event Alerting

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

*	Configuration Control

◦        Called ‘Bulk Data’ in the workgroup 

*	Telemetry information 

◦        Traffic  volumes, pipe capacity, mitigation efficacy, attack details 

IETF’s Network Management and Operations (NM/OPS) group has created similar mechanisms for sending events, configuration control, and telemetry which are data-model driven.  The IETF NM/OPS group use Yang to define these data models.  The data models can either support network configuration or configuration of security policy.   The protocols used by NM/OPS for events, publication of bulk data, and configuration are NETCONF and RESTCCONF.   IPFIX sends telemetry information. 

NETCONF runs over TLS over TCP.  RESTCONF runs over HTTP 1.1 over TLS with X.509v3 certificates.  IPFIX runs over TLS and DTLS (with replay protection and anti-DOS stateless cookie mechanism).    NETCONF and RESTCONF can be encoded with XML data and JSON data.   RESTCONF MAY also be run over HTTP/2 or QUIC (work being done in the draft-ietf-netconf-restconf-notify drafts].   [draft-ietf-netconf-restconf-notify] – indicates there can be TLS heartbeat used for NETCONF/RESTCONF notifications.  If the desire is to send the NETCONF/RESTCONF over google proto-bufs, other NM/OPS are considering this as well. RESTCONF and NETCONF meta data is encoded in JSON or XML.  RESTCONF has message caching, event streams, and the ability to subscribe to event notifications.  I2RS protocol extension to NETCONF require mutual authentication (RFC7589).  

The ODL open software supports NETCONF and RESTCONF with these features.  Cisco provides a CONFD software set (free for prototyping) that also support NETCONF/RESTCONF. 

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.  

Why Do I Ask this question:  I2NSF is charter to provide management for network security functions.  

·       I2SNF is building off of the NETCONF/RESTCONF models.  It is important to know why DOTS is not using NM/OPS protocols + data models so the I2NSF and DOTS can cohabitate in the same security architecture.   

High-level details: 

·       DOTS can be replaced by: 

·       NM/OPS - I2NSF using NETCONF or RESTCONF or IPFFIX 

·       Can do bulk data channel and telemetry by just adding data model 

·       Can do mitigate start/stop by using NETCONF/RESTCONF rpc mechanism 

·       Strong identities using 802.1AR (LDevID) used by ietf-netconf-zerotouch 

                         [Bob notes that this may not be sufficiently secure for the DOTS environment.] 

·       Heart-beats via the TLS protocol (or TLS 

·       Publication of events streams for  telemetry 

·       Publication of  notification stream for key events 

·       I2NSF has defined  data models and uses NETCONF /RESTCONF 

o   registration interfaces

o   Capability data model – with all the mitigation features 

o   Management Interface between security controller and network security functions (NSF) – firewalls, IPS/IDS, mitigation services, 

o   Management interface between user and security controller. 

·        I2NSF brings along the work from I2RS that extends Netconf and RESTCONF to have higher levels of security,  mutual authentication,  confidentiality, and data integrity.   

o   I2RS extensions may create a binary encoding of NETCONF and RESTCONF packets to increase speed.  CBOR may be a good choice [Sue’s note: I need to double check this point.] 

o   I2RS upcoming work may use binary encoding or  protobufs.  

·       I2NSF approach has fast implementation track – 4-5 student project for mitigation of attacks via firewall, DPI, and VoiP filtering accomplished with ODL Software on linux. 

What is different in DOTS work  

·       Use of IPv6 header option – to get opportunistic security  

Application heart-beats [Sue’s editorial note: Bob thinks I need more comments]. 

·       Use of google protocol buffers 

·       Modified transport – unclear exactly why CoAP or other protocols. 

CoAP is UDP and Binary REST.

Sue  

=======================================

Summary of DOTS Protocols and Models 

draft-teague-dots-protocol-00- two types of messages: 

·       Signaling  data:

o   Client Message:  sequence number (current, last), ping time, mitigation-lists (active, requested, withdrawn) , session-config (loss-limit, lifetime, heart-beat interval) , extensions 

o   Client Request – sends (event ID, mitigation-requested, scope, lifetime)  

o   DOTS Server: Server message:  sequence-number (current, last), request-heart-bit,  request-error, message-redirect (IPv4/IPV6) redirect target (port), MTU limit 

o   DOTS Server Status message (event-id, mitigation-enable, drops (bytes_dropped, bps_dropped, pkts_dropped, pps_dropped), whitelist[n], filter-list[n] 

·       Data channel: Send white-list, black-list, configuration, traffic-filter-management 

·       Mutual Authentication – Like I2RS requires mutual authentication 

·       NETCONF/NETCONF equivalent is: 

o   Client message - RPC with reply

o   DOTS Server: Set-up of notify channel for subscription to server’s publication of datat (denoted as pub/sub in NETCONF) 

                          [suggest the text]: 

o   DOTS Server status: Pub/sub push of notification status on different stream

o   TLS - Heart-beat notification

o   Data Channel – configuration of white lists, black list, policy and filters is what NETCONF get-config, edit-config, copy-config, delete-config – was created to do this

o   RESTCONF – Get , post, pathc, query, 

  Status : duplicate of NETCONF/RESTCONF work with different data model 

2) draft-reddy-dots-signal-channel-02

·       Mitigation Requests:  POST, DELETE, GET, PUT 

·       Data Contents of mitigation policy  [sent by client] 

o   PUT: (policy-id, target-ip, target-port, target-protocol, FQDN, URI, alias, lifetime) 

o   Delete: (Policy-id) 

·       Client sends: GET: Dots-Signal, policy-id [0 means all]  (registration) 

·       Server responses: 

o   Notification #1 (current state: mitigation in progress) 

o   Notification #2 (mitigation complete) 

o   Notification #3 (token stopped0

     RESTCONF equivalent 

·       PUT or DELETE for policy lists 

·        Notification set-up 

·       Channel support – heart beats, error loss ratio 

Status: Duplicate of RESTCONF work with different data model 

3) draft-reddy-dots-data-channel 

      What data: 

        Provisioning policies:  (policy-id, alias, traffic-protocol, destination-protocol-port, destination-ip, 

                           Alias1: FQDN, Alias2: URI,  Alias3:  E.164)

         Filtering rules:  policy-id, traffic-protocol, source-protocol-port, destination-ip, source-ip, lifetime,

                                  dscp, traffic-rate 

         I2NSF equivalents:         

         I2NSF: Data mode has already demonstrated this working at IETF97 with 

NETCONF/RESTCONf and a data model.

          NETCONF/RESTCONF functionality: 

          NETCONF: Get-config, edit-config for data odel 

          RESTCONF:  PUT, GET, DELETE 

   Status: Already implemented in I2NSF using NETCONF/RESTCONF 

4) dots-fu-dots-ipfix-extension-01 

            What type of signaling:  Telemetry 

            What protocol:  IPFIX/PSAMP 

            What data: upstream counters, fragment statistics, response time (server, client, session),

            What extension to IPFIX:  

·       New Flow End reason error 

·       New IE status for tracking  to:  

o   Detect ICMP reflection attack 

o   Detect Fragment attack 

o   Detect slowloris attack 

o   Detect out-of-order packet attack 

Status:  IPFIX Extended with data and error reports 

Comment: Kudos to authors for maximizing re-use of protocols 

5) nishizuka-dots-inter-domain-mechanism

            Why:  DOTS client in different organization from DOTS server 

             Why automatic:  Timeliness of responding to DDoS attacks

            Architecture: 

                                                             Customer (DOTS client) 

                                                                   /

                                                        Dots-server---dots-client

                        Attack-detector—controller 

                                                          |----------  Mitigator (NSF device)

              Groups of these are in different domain 

What is needed:  confidentiality, integrity, authenticity

              Provisioning 

·       Mechanism: POST 

·       Data: 

·       Registration: 

o   Registration data: customer-name, IP version, protected zone (index, need-alias, ipv4-cider, ipv6-address, BGP-route, SIP-URI, E164_number, DNS), protected-port, protected-protocol, counter-measures, tunnel-information, next-hop. Security-profile (TLS, DTLS, COAP)

o   White-list (name, sequence number, source-ip, destination-ip, protocol, length, TTL, DSCP, ip_flags, tcp-flags) 

o   Black-list (name, sequence-number, source-ip, destination-ip, source-port, destination-port, protocol, length, TTL, DSCP, ip_flags, tcp-flags), 

·       Registration-response:

o   Data: Customer-name, customer-id, alias_of_mitigation-address (index, string), security_profile, access-token, thresholds_bps, thresdhold_pps, duration, capable_attack_type, registration_time, mitigation_time) 

·       Registration: Cancelled 

Signaling stage:  

·       Mitigation request Mechanism: POST

·       Mitigation request data: version, type, alert-id, sender-id, sender-asn, mitigation-action, lifetime, max_bandwidth, packet-header (dst_ip, alias, dst-ports, src-ips, src-ports, protocols, tcp_flags,  fragment, pkt_len, icmp_type, icmp_code, DSCP, TTL, current throughput (bps, pps), peak_throughputs (bps, pps), average_throughputs (bps, pps), info (attack_types, started, ongoing, severity, direction, health), vendor (name, version, payload(offset, content, hash) 

·       Mitigation efficacy data:  version, alert-id, send-id, sender-asn, attack_status, health 

·       Mitigation termination:  version, alert_id, sender_id, sender_asn 

·       Heart_beat: (version, send_id, sender_asn) 

            I2NSF equivalent: 

·       inter-cloud DDOS API

·        inter-cloud DDOS Yang Data Model 

·       Capability Yang data model with I2NSF interface 

·       RESTCONF – POST, PUT, Notification service 

I2NSF uses I2RS protocol security requirements 

            [draft-i2rs-protocol-security-requirements] which require:

·       Mutual authentication, 

·       Peer identity validation, 

·       confidentiality, data integrity, authentication, and replay protection 

·       role-based security 

 6) draft-mortensen-dots-over-udp-00 

Protocol: [draft-teague-dots-protocol] 

What it does: 

·       provisioning: configuration to DOTS server via DNS SRV 

·       Signaling:  - I’m being attacked/mitigation

·       Data channel: Lots of status

How: Is this secured? 

·       provisioning – DOTS clients with keying material 

o   Enrollment over secure transport (private-key and certificate) 

·       Signaling:

o   DOTS over UDP – [drat-rescolra-tls-dtls13] 

§  First insecure, then Pre-shared keys (PSKS) 

§  If no pre-shared keys, full DTLS handshake 

o   Messages: 

§  Heart-beat – DOTS protocol heart beats

§  DTLS alerts can disconnect  

·       Data Channel – TLS 

Status:  

·       Similar to: RESTCONF or NETCONF features (see #1) 

o   Rpc/reply 

o   Edit-config (NETCONF) or PUT or PATCH (RESTCONF)  

·       What is new: Keying concepts 

7) draft-francois-dots-ipv6-signal-option  

·       What: Encode DOTS signal in IPv6 Hop-by-hop header option (with no data) 

·       Data:  option-type, option-length, DOTS-signal attribute1, DOTS-signal attribute2, DOTS-Signal Attribute [3]  … DOTS Signal attribute[n] 

Attribute data:  (TTL, Flag (tcp/upd), host, port, policy-id, target-ip, target-port, target-protocol, lifetime)

·       Configuration: 

o   Set of filters over IPv6 packet headers 

o   Ratio of packets checked 

o   Timeout

·       How to process: DOTS capable router, gateway or server. 

Status:  new concept of opportunistic processing of DOTS 

·       Means integration with router, gateway, and server in seamless way with I2NSF, I2RS, and NETCONF/RESTCONF is necessary

8) draft-doron-dots-telemetry: 

·       Protocol:  ready-dots-signaling-channel, nishizuka-dots-inter-domain-mechanism

·       Pre-mitigation data:   baseline total traffic (pps, bps), total attack traffic volume (pps, bps), attack details (vendor, version, attack-id, attack-name, attack-severity, extension), total pipe capacity,  list of authenticated source-ids.

·       Client-to-Server – Telemetry attribute:  baseline total traffic (pps, bps), total attack traffic volume (pps, bps), Mitigation efficacy factor (clean traffic/normal traffic), attack details (vendor, version, attack-id, attack-name, attack-severity, extension 

·       Server to client – Telemetry attribute: Signal counter measure 

Comparison with NM/OPS:

·       Telemetry – can be done with IPFIX or Publication/Subscription streams from NETCONF and RESTCONF. 

·       Pre-mitigation data, Client-server Telemetry attribute, and Server to Client – can be replaced by a data model 

9) draft-andreasen-dots-info-data-model – Distributed DOS Open-Threat signaling IM and DM 

·       Protocol:  New protocol

o   Signal Channel:  Open/Close/Redirect signal channel, Request status, Status update, Request Mitigation, Stop mitigation 

o   Data Channel:  Open/Close/Redirect data channel, Send Data 

o   Information Elements 

§  Protocol version, attack target, Agent-ID

§  Blacklist, whitelist,

§  Attack telemetry

§  Mitigator feedback, Mitigation efficacy, Mitigation scope, Mitigation Scope Conflict, Mitigation duration 

§  Resource group alias

§  Peer health 

§  Filters

§  Filter-actions 

§  Acceptable signal lossinesss

§  Heartbeat interval 

§  Extension 

Comparison with NETCONF/RESTCONF 

o   Signal channel

§  Can use rpc/rpc-reply to enact with action of signal channel 

§  Request mitigation/ Stop mitigation – is new feature, but it can be implemented as rpc – since rpc/rpc-reply operates as new function 

o   Data channel

§  Configuration of protocol, blacklist, whitelist, filters filter-action, acceptable lossiness, heartbeat interval – is normal work for NETCONF/RESTCONF based on a data model, 

§  Attack Telemetry – is a normal part of the publication/subscription service

§  Heart-beat is current in TLS for RESTCONF, but an application heartbeat could be added.  

Status: All of the features point to NETCONF or RESTCONF with specific data protocol.  IPFIX could also be used for telemetry.  

What’s new:  Mitigator is new, but the rpc/rpc-reply in RESTCONF or NETCONF should be able to provide this. 

10) strong identities [draft-moskowitz-dots-identities] 

            Purpose: Define 2 forms of strong identities 

o   Form 1: X.509 LDevID – defined in 802.1AR 

§  DOTS mitigation provider has PKI to issue LDevID certificates to customer 

§  Can be used by Netconf-zerotouch 

o   Form 2: Raw public key:  

§  Type 1:  HIP [RFC7401] with HIP DNS Extension [RFC8005] to assert its HI to DOTS mitigation provider and use HIP to prove ownership 

§  Type 2:  Use raw key defined in RFC7250, and use DANE [RFC6698] to validate TLS key 

Problem space: 

o   Context:  business relationship between customer and DDoS mitigation provider 

§  Type: long lived over persistent session. 

§  Can have trust identity from requesting provider back to attack customer. 

o   Scope of trust: 

§  Web PKI has trust leakage challenge 

§  How can you assert trust

·       Managing trust 

o   802.1AR – type types of certificate: 

·       IDevID – installed in device (by signed by manufacturer’s CA)

·       LDevid – (locally significant Secure Device Identifier) – signed by PKI appropriate to use.  

§  [ietf-netconf-zerotouch] – uses trusted LDevID based on owner certification (IDevID) 

o   Raw public key:  hierarchical HIP can provides infrastructure of Raw Public Keys 

Status:

·       Strong trusted identities needed by NM/OPS as well as DOTS

·        ietf-netconf-zerotouch uses 802.1AR  Ldevid  

[Editorial: Bob states that zerotouch does not say LDevID – so we need to work on this point] 

·       2nd  approach is Raw public keys + Hierarchical HIP  

[Bob states:  For constrained or mobile device within the architecture]

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 15 Nov 2016 19:38:51 +0700

On 15 Nov 2016, at 17:32, Susan Hares 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?

The short answer is because those mechanisms don't work well in a 
hostile communications environment flooded with DDoS attack traffic.

Out-of-band is always preferable, but in practice, it's quite rare.  So, 
survivability and resiliency are key.

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

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Tue, 15 Nov 2016 18:20:21 +0000

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 <[email-masked]<mailto:[email-masked]>> 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. :)

[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

[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

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 15 Nov 2016 13:21:27 -0500

Roland:

Perhaps the signaling protocol that says "I'm under attack" by a DOTS client
has clear description of this point.   These small bits of information make
take a secure transport that is robust, binary and survivable under attacks.

If you are transmitting lots of data (Bulk data) or setting lots of
configuration (whitelist/blacklist) or doing telemetry, it needs to be
secure and survivable - but at a different level.  I've draw the an
inter-domain secure tunnel set-up in a trust federation.  The inter-domain
will have long-lived connects between the server with peering contracts (see
Barry's comments). 

Domain 1                                                        Domain 2 
DOTS                                                           DOTS  
Server ======================== server 
Mgr                                                            mgr
  |   \----- certificate-authority--------/     |
  |                                                                   |
Client                                                       Client 
Dots                                                            Dots 

This connection needs to be mutually authenticated (Netconf over TLS X.509 /
RESTCONF over TLS X.509).  If you have constrained environments, you may
want to improve the transport by utilizing binary (CBOR may be useful).
In extreme circumstances you may want to provide additional error
handling/packet at the transport (see Bob + Sues SLSSS proposal).   This is
an improvement over redoing the application layer programming at the server
for the configuration and telemetry.

Thank you for welcoming me to this group. 

Sue    
 
-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
Sent: Tuesday, November 15, 2016 7:39 AM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Dots] Why is DOTS not using NETCONF/RESTCONF for management
functions

> for events, configuration control and telemetry data as NM/OPS with 

The short answer is because those mechanisms don't work well in a hostile
communications environment flooded with DDoS attack traffic.

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

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 15 Nov 2016 13:55:13 -0500

Roland: 

It is appears my formatting is problematic.  I am reposting with better
formatting. 

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, November 15, 2016 1:21 PM
To: 'Roland Dobbins'
Cc: [email-masked]
Subject: Re: [Dots] Why is DOTS not using NETCONF/RESTCONF for management
functions

Roland:

Domain 1                                                        Domain 2 
DOTS                                                           DOTS  

This connection needs to be mutually authenticated (Netconf over TLS X.509 /
RESTCONF over TLS X.509).  If you have constrained environments, you may
want to improve the transport by utilizing binary (CBOR may be useful).  In
extreme circumstances you may want to provide additional error
handling/packet at the transport (see Bob + Sues SLSSS proposal).   This is
an improvement over redoing the application layer programming at the server
for the configuration and telemetry.

Sue    
 
-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
Sent: Tuesday, November 15, 2016 7:39 AM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Dots] Why is DOTS not using NETCONF/RESTCONF for management
functions

---

From: Gilbert Clark <[email-masked]>
Date: Tue, 15 Nov 2016 15:13:02 -0500

Hi:

Generally speaking, I don't see anything that necessarily *prevents* one
from making a draft to describe the use of NETCONF / RESTCONF in this
area.  I don't think it's necessarily a good idea, but ... I don't see
something that would really *prevent* it.  I mean, if I can shove all of my
internet traffic through a DNS tunnel and have it more-or-less, kind-of
work, why can't I shove DOTS messages through NETCONF?

Really, I would strongly caution against using one overly-broad hammer to
try to smash a bunch of very different nails across WGs with a multitude of
requirements and intended use-cases here ...

Also, bear in mind that NETCONF / RESTCONF would drag a lot of baggage
along with it.  NETCONF (as of 6241) has over 70 pages of practical content
in there, and the last draft of RESTCONF I saw was equally as long.  That's
a lot of extra stuff people need to understand and make sure their devices
can support / correctly implement just to be able to have the privilege of
sending a desperate plea for help ...

[rhetoric] "Hello, 911?  Yes!  Yes, my house is on fire ... wait, I have to
do *what* to communicate with the fire department?  No, I don't have two
chickens ... no, my flashlight is in the burning house right now, and ...
well, yes, I do happen to have a friend who speaks that language, b- okay.
Okay.  I'll run next door and borrow their flashlight, then get started
with the morse code in Russian ... but what were the chickens for,
again?"[/rhetoric]

> want to improve the transport by utilizing binary (CBOR may be useful).

In and of itself, switching to a binary protocol does *not* magically make
something viable in a constrained environment ...

> for the configuration and telemetry.

Yikes.  Putting substantial quantities of additional intelligence into a
transport really kind of scares me.

SLSS is an entirely separate conversation, I think, and isn't necessarily a
rabbit hole that I'm convinced would be terribly productive to explore as
part of this thread.

> Thank you for welcoming me to this group.
Hi :)

FWIW,
Gilbert Clark

---

From: "Teague, Nik" <[email-masked]>
Date: Tue, 15 Nov 2016 21:33:01 +0000

Hi,

I’m a fully paid up member of the can’t sleep contingent – so – here goes…

Firstly – Thanks for taking the time to consider the various drafts and for the analysis. I think Gilbert, Andrew and Roland detail the concerns well and coming from the stance of an implementer/operator I too have a hard time with NETCONF/RESTCONF in this case.

I perceive the signal channel as being the crux of the protocol and this channels survivability and efficiency within the conditions DDoS place on infrastructure is very much in my mind as being fundamental.  Anything that has overhead or baggage relating to implementation, reliable delivery, connection establishment and state retention is potentially going to be mired in dealing with just those mechanisms during a DDoS vs actually just getting the message out that there’s a fire – regardless of how nicely formatted all the extra unnecessary spikey xml tagging is.

From a tooling up perspective - on a day to day basis, when being asked if I can integrate customer hardware, softwarek or 3rd party monitoring solution into our mitigation and monitoring platform, I simply don’t see NETCONF/RESTCONF being present and its often not a concern of the customers that this be supported in their use cases.  The fall back tends to be ‘well it can send syslog, that’s got a chance… lets try that’…

Thanks,

-Nik

On 16/11/2016, 05:13, "Dots on behalf of Gilbert Clark" <[email-masked] on behalf of [email-masked]> wrote:

    Hi:
    
    Generally speaking, I don't see anything that necessarily *prevents* one from making a draft to describe the use of NETCONF / RESTCONF in this area.  I don't think it's necessarily a good idea, but ... I don't see something that would
     really *prevent* it.  I mean, if I can shove all of my internet traffic through a DNS tunnel and have it more-or-less, kind-of work, why can't I shove DOTS messages through NETCONF?
    
    Really, I would strongly caution against using one overly-broad hammer to try to smash a bunch of very different nails across WGs with a multitude of requirements and intended use-cases here ...

    Also, bear in mind that NETCONF / RESTCONF would drag a lot of baggage along with it.  NETCONF (as of 6241) has over 70 pages of practical content in there, and the last draft of RESTCONF I saw was equally as long.  That's a lot of extra stuff people need to
     understand and make sure their devices can support / correctly implement just to be able to have the privilege of sending a desperate plea for help ...

    [rhetoric] "Hello, 911?  Yes!  Yes, my house is on fire ... wait, I have to do *what* to communicate with the fire department?  No, I don't have two chickens ... no, my flashlight is in the burning house right now, and ... well, yes,
     I do happen to have a friend who speaks that language, b- okay.  Okay.  I'll run next door and borrow their flashlight, then get started with the morse code in Russian ... but what were the chickens for, again?"[/rhetoric]

    

    
    In and of itself, switching to a binary protocol does *not* magically make something viable in a constrained environment ...

    

    
    Yikes.  Putting substantial quantities of additional intelligence into a transport really kind of scares me.

    SLSS is an entirely separate conversation, I think, and isn't necessarily a rabbit hole that I'm convinced would be terribly productive to explore as part of this thread.

    

    Hi :)

    FWIW,
    
    Gilbert Clark

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 15 Nov 2016 16:52:05 -0500

As another member of the below referenced contingent, let me pile on as 
well:

I too have a difficult time seeing how NETCONF/RESTCONF apply to the 
signal channel both in term of problem space and solution requirements, 
and hence I would ask if you have taken a careful look at all the 
requirements as well as the architecture document. If not, I would 
suggest doing that first before investing further time in this approach.

As for the data channel, I think you have more potential alignment there 
and that may be worth taking a closer look at. A draft would go a long 
way towards making the proposal more concrete and evaluating it properly.

Thanks

-- Flemming

---

From: Roland Dobbins <[email-masked]>
Date: Wed, 16 Nov 2016 10:04:23 +0700

> rabbit hole that I'm convinced would be terribly productive to explore 

Concur.

The'it's nested standards all the way down' approach has its 
attractions, but ease of implementation and constrained environments 
such as consumer CPE, phones, et. al. (as Sue rightly notes) make this 
an impractical option, concur 100%.

DOTS must be lightweight, in terms of what's necessary for a 
client/supplicant to request DDoS mitigation assistance.  And we want it 
to be easy enough to implement that we gain wide adoption.

Scope policing is also extremely important, both in terms of the 
abovementioned goals as well as avoiding re-inventing the wheel.  This 
is why I'm such a fundamentalist with regards to asserting that the 
specifics of detection/classification/traceback and mitigation 
mechanisms (including telemetry) ought not to be addressed directly 
within DOTS.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 16 Nov 2016 06:07:45 +0000

COAP not only runs on UDP but also on TCP https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-05, DOTS signaling channel needs a protocol that can run over both UDP and TCP, compact message sizes, secure and should be able to successfully communicate with the DOTS server in constrained environment and run on devices constrained because of DDOS attacks.

DOTS signaling channel can be used both during peace time (e.g. negotiate session signal configuration and during attack time (e.g. to request DDOS mitigation).

You may want to look into the requirements for DOTS signal channel in https://tools.ietf.org/html/draft-ietf-dots-requirements-03.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, November 15, 2016 4:02 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Dots] FW: Why is DOTS not using NETCONF/RESTCONF for management functions

Sue

===========

  *   Configuration Control

  *   Telemetry information

High-level details:

·       Signaling  data:

o   Delete: (Policy-id)

·       Server responses:

     RESTCONF equivalent

·        Notification set-up

      What data:

         I2NSF equivalents:

o   Detect Fragment attack

·       Mechanism: POST

·       Data:

·       Registration:

·       Registration-response:

Signaling stage:

            I2NSF equivalent:

·       inter-cloud DDOS API

·       Mutual authentication,

·       role-based security

How: Is this secured?

·       Signaling:

o   Messages:

·       Data Channel – TLS

Status:

o   Rpc/reply

·       Configuration:

o   Timeout

Comparison with NM/OPS:

·       Protocol:  New protocol

o   Information Elements

§  Blacklist, whitelist,

§  Attack telemetry

§  Resource group alias

§  Peer health

§  Filters

§  Filter-actions

§  Heartbeat interval

§  Extension

o   Signal channel

o   Data channel

Problem space:

o   Scope of trust:

·       Managing trust

Status:

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 16 Nov 2016 17:38:58 -0500

Roland:

This need for reliability and survivability is true of routing that NM/OPS
(netconf/restconf) as well.

Sue 

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
Sent: Tuesday, November 15, 2016 7:39 AM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Dots] Why is DOTS not using NETCONF/RESTCONF for management
functions

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 17 Nov 2016 05:48:03 +0700

On 17 Nov 2016, at 5:38, Susan Hares wrote:

> This need for reliability and survivability is true of routing that 
> NM/OPS (netconf/restconf) as well.

If NETCONF comms traffic is traversing a data-plane channel choked with 
DDoS traffic, someone is Doing Something Wrong.

;>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 16 Nov 2016 17:46:52 -0500

NETCONF goes from centralized mgr to device on edge of network.  DDOS in
network. 

Sue 

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
Sent: Wednesday, November 16, 2016 5:48 PM
To: [email-masked]
Subject: Re: [Dots] Why is DOTS not using NETCONF/RESTCONF for management
functions

> NM/OPS (netconf/restconf) as well.

If NETCONF comms traffic is traversing a data-plane channel choked with DDoS
traffic, someone is Doing Something Wrong.

;>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 16 Nov 2016 17:54:24 -0500

Andrew: 

I see the bulk transfer (configuration, data) and the telemetry as NM/OPS applications that may run over a securely established and maintained inter-domain connection.  (See Bob + Daniel’s work on the secure connection).   If so, my suggestion is to define the tunnel protocol and encryption, but re-use the management application that the NM/OPS people have in the publication/subscription draft + the configuration setting.   Define the data model in yang.    

If you really think the management application is different, provide reasons why.  (I provided reasons why not). 

Now as to the DOTS signaling protocol – I am still learning.  It’s how I started out this work.   If it is handshake – I’m attack (client)/we’re helping (mgr/ctl) – then I have more to learn about the handshake.   The message is trying to tease out what is unique about the DOTS signaling protocol or data. 

From: Mortensen, Andrew [mailto:[email-masked]] 
Sent: Tuesday, November 15, 2016 1:20 PM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Dots] FW: Why is DOTS not using NETCONF/RESTCONF for management functions

On Nov 15, 2016, at 5:32 AM, Susan Hares <[email-masked]> wrote:

[Sue: Not precise – just 95/5% rule] 

Sue: If you really want to design UDP based transport that RESTCONF goes over – I will applaud and help this.  What I am concern about is replicating the application level instrumentation  (publication streams, configuration setting).  You also may consider a binary encoding (CBOR (?))> 

Sue:  What needs to clarified in your work is the transport (heart-beats, request/response, etc) – versus the application functions (I’m attacked/mitigation, event services, application services0.  

*	Configuration Control

This is good news. I think we can work together to get a UDP transport for RESTCONF that fits the DOTS.  Bob and I drew up the SLSS work as an attempt to address some of these issues.   I think a bit of discussion at lunch today (Thursday) would be helpful. 

andrew

---

From: "Teague, Nik" <[email-masked]>
Date: Wed, 16 Nov 2016 22:58:19 +0000

On 17/11/2016, 07:46, "Dots on behalf of Susan Hares" <[email-masked] on behalf of [email-masked]> wrote:

I have an OOB management vrf on my network but I don’t have one that crosses boundaries or the internet to my upstreams or cloud mitigation provider (in which the path is congested).

From a tooling perspective… I have 15000 network devices and only 60 support NETCONF…  

I think the question for me is not why aren’t we considering NETCONF but why should we? - and how does it align with the requirements and architecture drafts?

Thanks,

-Nik

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 16 Nov 2016 17:55:49 -0500

Tiru: 

I’m digging into the COAP protocol as it seems to really fit this constrained environment.   Is there any drafts on applying this to DOTS? 

Sue 

From: Dots [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Wednesday, November 16, 2016 1:08 AM
To: Susan Hares; [email-masked]
Subject: Re: [Dots] FW: Why is DOTS not using NETCONF/RESTCONF for management functions

-Tiru

 

Sue 

===========

*	Configuration Control

*	Telemetry information 

 

High-level details: 

  

Sue  

·       Signaling  data:

                          [suggest the text]: 

o   Delete: (Policy-id) 

·       Server responses: 

     RESTCONF equivalent 

·        Notification set-up 

 

      What data: 

                                  dscp, traffic-rate 

         I2NSF equivalents:         

 

            What extension to IPFIX:  

o   Detect Fragment attack 

            Architecture: 

                                                             Customer (DOTS client) 

                                                                   /

              Provisioning 

·       Mechanism: POST 

·       Data: 

·       Registration: 

·       Registration-response:

Signaling stage:  

            I2NSF equivalent: 

·       inter-cloud DDOS API

·       Mutual authentication, 

·       role-based security 

What it does: 

How: Is this secured? 

·       Signaling:

o   Messages: 

·       Data Channel – TLS 

Status:  

o   Rpc/reply 

 

·       Configuration: 

o   Timeout

Comparison with NM/OPS:

·       Protocol:  New protocol

o   Information Elements 

§  Blacklist, whitelist,

§  Attack telemetry

§  Resource group alias

§  Peer health 

§  Filters

§  Filter-actions 

§  Heartbeat interval 

§  Extension 

o   Signal channel

o   Data channel

 

Problem space: 

o   Scope of trust: 

·       Managing trust 

Status:

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 17 Nov 2016 06:00:24 +0700

On 17 Nov 2016, at 5:46, Susan Hares wrote:

> NETCONF goes from centralized mgr to device on edge of network.

It shouldn't be doing it in-band in the production data-plan network.

This is Network Infrastructure Security 101-type stuff.

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 17 Nov 2016 06:02:26 +0700

On 17 Nov 2016, at 5:58, Teague, Nik wrote:

> I think the question for me is not why aren’t we considering NETCONF 
> but why should we? - and how does it align with the requirements and 
> architecture drafts?

Concur - what we need is a lightweight, survivable signaling mechanism 
which is abstracted away from configuration semantics, which differ 
wildly.

If we thought NETCONF and the like were suitable for this application, 
we would've latched onto them.  We didn't for a reason, as you rightly 
note.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 16 Nov 2016 18:02:28 -0500

Nik:

Your last question - is what I was trying to learn from reading all the documents.  What exactly are your use cases and architecture.  It seems to vary.  

As to deployments... all newly defined protocols need to get implementations in products.  Do you have products with DOTS protocols already?  If so, what are the implementation reports on the protocol?  That's useful information in any discussion. 

ONOS, ODL, and OPNFV  has public sources for NETCONF/RESTCONF.   Many vendors sell NETCONF/RESTCONF.   That's a large base of code to download or buy from any vendor to integrate into your code. 

Cheerily,

Sue 

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Teague, Nik
Sent: Wednesday, November 16, 2016 5:58 PM
To: Susan Hares; 'Roland Dobbins'; [email-masked]
Subject: Re: [Dots] Why is DOTS not using NETCONF/RESTCONF for management functions

Thanks,

-Nik

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 17 Nov 2016 06:06:44 +0700

On 17 Nov 2016, at 6:02, Susan Hares wrote:

> Do you have products with DOTS protocols already?

Since the protocol(s) has/have yet to be defined, no.

---

From: "Teague, Nik" <[email-masked]>
Date: Wed, 16 Nov 2016 23:31:53 +0000

Sue hi,

Inline:

On 17/11/2016, 08:02, "Susan Hares" <[email-masked]> wrote:

The typical scenario for DOTS would be:

Customer has deployed an on-premise DDoS mitigation solution… the customer really doesn’t want to scale their available b/w capacity to largestAttack*2 or w/e figure… their device and network has a ceiling of capacity/capability… they wish to augment this with a cloud mitigation provider that would off-ramp attack traffic, clean it and send back only the good stuff.  That mitigation provider may be n AS hops away…  When the customer is attacked they want an automated way to trigger the cloud provider off-ramp and mitigation – this is the signal and as the customer is being attacked when they need to make the request then hostile conditions may be assumed (since in this scenario you would expect an on-prem device to be dealing easily with attacks within its own capability).

There is already a degree of prior art in this area which we have been bringing to the working group and in the case of mine and Andrew’s draft, this is informed by our experiences – these have a lot of proprietary implementation considerations that we wouldn’t generally report.

So I wouldn’t buy an implementation for my whitebox + custom linux etc.  implementation –  I _may_ consider pulling an open source instance – or I could just use ansible instead which already is embedded for our svr fleet - but I see our needs only partially serviced by netconf – firstly the distinction of network device and server is blurring and simplification of fleet management tools is attractive – similarly we’re providing a service – the network + servers + applications result in that service and they need to be reasonably tightly coupled.   I can get a little starry eyed, evangelical and overdo the netdevops koolaid about this and could pontificate all day so I’ll stop now ☺

Thanks,

-Nik

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 17 Nov 2016 06:36:25 +0700

On 17 Nov 2016, at 6:31, Teague, Nik wrote:

> There is already a degree of prior art in this area which we have been 
> bringing to the working group and in the case of mine and Andrew’s 
> draft, this is informed by our experiences – these have a lot of 
> proprietary implementation considerations that we wouldn’t generally 
> report.

Good point - I should've noted this in my previous reply in this thread.

There are existing implementations in this space, but they're 
proprietary.  We want to take the lessons learned from experiences with 
those proprietary mechanisms and build something that's open and 
extensible and generalizable, and which will gain widespread adoption.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Nov 2016 10:24:06 +0900

> we would've latched onto them.  We didn't for a reason, as you rightly

Can you point me towards the reason?
I haven't seen any technical reasons as yet.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Barry Raveendran Greene <[email-masked]>
Date: Thu, 17 Nov 2016 10:33:00 +0900

> On Nov 17, 2016, at 10:24 AM, Michael Richardson <[email-masked]> wrote:
> 
>> 

+1

---

From: "Dobbins, Roland" <[email-masked]>
Date: Thu, 17 Nov 2016 01:35:46 +0000

On Nov 17, 2016, at 7:57 AM, Susan Hares <[email-masked]> wrote:

> I see the bulk transfer (configuration, data) and the telemetry as NM/OPS applications that may run over a securely established and maintained inter-domain connection. 

Ideally, yes.  In most cases, not.

---

From: "Dobbins, Roland" <[email-masked]>
Date: Thu, 17 Nov 2016 01:37:40 +0000

> I haven't seen any technical reasons as yet.

They've been stated and restated multiple times in this thread, and in the list in general.

---

From: Gilbert Clark <[email-masked]>
Date: Wed, 16 Nov 2016 21:12:49 -0500

> > I haven't seen any technical reasons as yet.

The relatively large size of NETCONF / RESTCONF messages, a lack of
ubiquitous support for these protocols, the relative complexity of the
protocols, the requirements of signaling not meshing with the intent of a
*network configuration* protocol, the emphasis on UDP for signaling, the
reference in multiple documents to the idea that DOTS is not intended to
support remote configuration as a primary use case, ...

I've seen all of the above and more in the thread thus far *and more*.  Are
these not considered technical concerns?  'cause these are really technical
concerns.

But ya know what?  If you want to (ab)use NETCONF to signal / transfer
data, then great.  Go ahead and implement, test, and let people know how it
goes.  Write a draft or three, even!  Running code trumps conversation
every time.

With that said, given that every fiber of my being is screaming that
NETCONF / RESTCONF is the wrong way to go here, I'll happily keep working
on things that *aren't* NETCONF / RESTCONF in the meantime :)

Good luck with all of that,
Gilbert Clark

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 17 Nov 2016 02:44:16 +0000

Hi Susan,

Yes, https://tools.ietf.org/html/draft-reddy-dots-signal-channel-04 uses COAP over (D)TLS, CBOR encoded payloads, (D)TLS 1.3 and (D)TLS 1.2 profile for performance .

-Tiru

From: Susan Hares [mailto:[email-masked]]
Sent: Thursday, November 17, 2016 4:26 AM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>; [email-masked]
Subject: RE: [Dots] FW: Why is DOTS not using NETCONF/RESTCONF for management functions

Tiru:

Sue

From: Dots [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Wednesday, November 16, 2016 1:08 AM
To: Susan Hares; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] FW: Why is DOTS not using NETCONF/RESTCONF for management functions

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, November 15, 2016 4:02 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Dots] FW: Why is DOTS not using NETCONF/RESTCONF for management functions

Sue

===========

  *   Configuration Control

  *   Telemetry information

•       I2SNF is building off of the NETCONF/RESTCONF models.  It is important to know why DOTS is not using NM/OPS protocols + data models so the I2NSF and DOTS can cohabitate in the same security architecture.

High-level details:

•       DOTS can be replaced by:

•       NM/OPS - I2NSF using NETCONF or RESTCONF or IPFFIX

•       Can do bulk data channel and telemetry by just adding data model

•       Can do mitigate start/stop by using NETCONF/RESTCONF rpc mechanism

•       Strong identities using 802.1AR (LDevID) used by ietf-netconf-zerotouch
                         [Bob notes that this may not be sufficiently secure for the DOTS environment.]

•       Heart-beats via the TLS protocol (or TLS

•       Publication of events streams for  telemetry

•       Publication of  notification stream for key events

•       I2NSF has defined  data models and uses NETCONF /RESTCONF

•        I2NSF brings along the work from I2RS that extends Netconf and RESTCONF to have higher levels of security,  mutual authentication,  confidentiality, and data integrity.

•       I2NSF approach has fast implementation track – 4-5 student project for mitigation of attacks via firewall, DPI, and VoiP filtering accomplished with ODL Software on linux.

•       Use of IPv6 header option – to get opportunistic security

•       Use of google protocol buffers

•       Modified transport – unclear exactly why CoAP or other protocols.

•       Signaling  data:

•       Data channel: Send white-list, black-list, configuration, traffic-filter-management

•       Mutual Authentication – Like I2RS requires mutual authentication

•       NETCONF/NETCONF equivalent is:

•       Mitigation Requests:  POST, DELETE, GET, PUT

•       Data Contents of mitigation policy  [sent by client]

o   Delete: (Policy-id)

•       Client sends: GET: Dots-Signal, policy-id [0 means all]  (registration)

•       Server responses:

     RESTCONF equivalent

•       PUT or DELETE for policy lists

•        Notification set-up

•       Channel support – heart beats, error loss ratio

      What data:

         I2NSF equivalents:

•       New Flow End reason error

•       New IE status for tracking  to:

o   Detect Fragment attack

•       Mechanism: POST

•       Data:

•       Registration:

•       Registration-response:

•       Registration: Cancelled

Signaling stage:

•       Mitigation request Mechanism: POST

•       Mitigation request data: version, type, alert-id, sender-id, sender-asn, mitigation-action, lifetime, max_bandwidth, packet-header (dst_ip, alias, dst-ports, src-ips, src-ports, protocols, tcp_flags,  fragment, pkt_len, icmp_type, icmp_code, DSCP, TTL, current throughput (bps, pps), peak_throughputs (bps, pps), average_throughputs (bps, pps), info (attack_types, started, ongoing, severity, direction, health), vendor (name, version, payload(offset, content, hash)

•       Mitigation efficacy data:  version, alert-id, send-id, sender-asn, attack_status, health

•       Mitigation termination:  version, alert_id, sender_id, sender_asn

•       Heart_beat: (version, send_id, sender_asn)

            I2NSF equivalent:

•       inter-cloud DDOS API

•        inter-cloud DDOS Yang Data Model

•       Capability Yang data model with I2NSF interface

•       RESTCONF – POST, PUT, Notification service

•       Mutual authentication,

•       Peer identity validation,

•       confidentiality, data integrity, authentication, and replay protection

•       role-based security

•       provisioning: configuration to DOTS server via DNS SRV

•       Signaling:  - I’m being attacked/mitigation

•       Data channel: Lots of status

How: Is this secured?

•       provisioning – DOTS clients with keying material

•       Signaling:

•  First insecure, then Pre-shared keys (PSKS)

•  If no pre-shared keys, full DTLS handshake

o   Messages:

•  Heart-beat – DOTS protocol heart beats

•  DTLS alerts can disconnect

•       Data Channel – TLS

Status:

•       Similar to: RESTCONF or NETCONF features (see #1)

o   Rpc/reply

•       What is new: Keying concepts

•       What: Encode DOTS signal in IPv6 Hop-by-hop header option (with no data)

•       Data:  option-type, option-length, DOTS-signal attribute1, DOTS-signal attribute2, DOTS-Signal Attribute [3]  … DOTS Signal attribute[n]

•       Configuration:

o   Timeout

•       How to process: DOTS capable router, gateway or server.

•       Means integration with router, gateway, and server in seamless way with I2NSF, I2RS, and NETCONF/RESTCONF is necessary

•       Protocol:  ready-dots-signaling-channel, nishizuka-dots-inter-domain-mechanism

•       Pre-mitigation data:   baseline total traffic (pps, bps), total attack traffic volume (pps, bps), attack details (vendor, version, attack-id, attack-name, attack-severity, extension), total pipe capacity,  list of authenticated source-ids.

•       Client-to-Server – Telemetry attribute:  baseline total traffic (pps, bps), total attack traffic volume (pps, bps), Mitigation efficacy factor (clean traffic/normal traffic), attack details (vendor, version, attack-id, attack-name, attack-severity, extension

•       Server to client – Telemetry attribute: Signal counter measure

Comparison with NM/OPS:

•       Telemetry – can be done with IPFIX or Publication/Subscription streams from NETCONF and RESTCONF.

•       Pre-mitigation data, Client-server Telemetry attribute, and Server to Client – can be replaced by a data model

•       Protocol:  New protocol

o   Information Elements

•  Protocol version, attack target, Agent-ID

•  Blacklist, whitelist,

•  Attack telemetry

•  Mitigator feedback, Mitigation efficacy, Mitigation scope, Mitigation Scope Conflict, Mitigation duration

•  Resource group alias

•  Peer health

•  Filters

•  Filter-actions

•  Acceptable signal lossinesss

•  Heartbeat interval

•  Extension

o   Signal channel

•  Can use rpc/rpc-reply to enact with action of signal channel

•  Request mitigation/ Stop mitigation – is new feature, but it can be implemented as rpc – since rpc/rpc-reply operates as new function

o   Data channel

•  Configuration of protocol, blacklist, whitelist, filters filter-action, acceptable lossiness, heartbeat interval – is normal work for NETCONF/RESTCONF based on a data model,

•  Attack Telemetry – is a normal part of the publication/subscription service

•  Heart-beat is current in TLS for RESTCONF, but an application heartbeat could be added.

•  DOTS mitigation provider has PKI to issue LDevID certificates to customer

•  Can be used by Netconf-zerotouch

•  Type 1:  HIP [RFC7401] with HIP DNS Extension [RFC8005] to assert its HI to DOTS mitigation provider and use HIP to prove ownership

•  Type 2:  Use raw key defined in RFC7250, and use DANE [RFC6698] to validate TLS key

Problem space:

•  Type: long lived over persistent session.

•  Can have trust identity from requesting provider back to attack customer.

o   Scope of trust:

•  Web PKI has trust leakage challenge

•  How can you assert trust

•       Managing trust

•       IDevID – installed in device (by signed by manufacturer’s CA)

•       LDevid – (locally significant Secure Device Identifier) – signed by PKI appropriate to use.

•  [ietf-netconf-zerotouch] – uses trusted LDevID based on owner certification (IDevID)

Status:

•       Strong trusted identities needed by NM/OPS as well as DOTS

•        ietf-netconf-zerotouch uses 802.1AR  Ldevid
[Editorial: Bob states that zerotouch does not say LDevID – so we need to work on this point]

•       2nd  approach is Raw public keys + Hierarchical HIP
[Bob states:  For constrained or mobile device within the architecture]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Nov 2016 16:39:06 +0900

Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
    > Yes, https://tools.ietf.org/html/draft-reddy-dots-signal-channel-04
    > uses COAP over (D)TLS, CBOR encoded payloads, (D)TLS 1.3 and (D)TLS 1.2
    > profile for performance .

So, if your CBOR was derived from a YANG model, you'd be doing exactly NETCONF, btw.
And that activity happens at ID writing time, not runtime.