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

["Susan Hares" <[e-mail]>]

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:[e-mail]] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Wednesday, November 16, 2016 1:08 AM
To: Susan Hares; [e-mail]
Subject: Re: [Dots] FW: Why is DOTS not using NETCONF/RESTCONF for management functions

 

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:[e-mail]] On Behalf Of Susan Hares
Sent: Tuesday, November 15, 2016 4:02 PM
To: [e-mail]
Cc: [e-mail]
Subject: [Dots] FW: Why is DOTS not using NETCONF/RESTCONF for management functions

 

 

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]