Subject: [Dots] Coding and Interoperability Challenges

From: "Jon Shallow" <[email-masked]>
Date: Fri, 8 Sep 2017 16:56:14 +0100

Hi there,

We are in the process of trying to code up a DOTS Client / Server
implementation based on the draft standards so far and have come up with the
following list of issues / questions.

Nttdots

=======

An excellent starting point, but

CBOR

-------

The nttdots server only accepts strings for the various parameters.  It does
not (yet) accept CBOR that uses the CBOR mapping parameters
(draft-ietf-dots-signal-channel Section 6).

Signal Channel

-------------------

Nttdots is expecting an additional path parameter in the POST/PUT etc path
(.wellknown), so instead of /v1/dots-signal/signal, it requires
/.wellknown/v1/dots-signal/signal which is not stated anywhere in the
draft-ietf-dots-signal-channel draft.  If not present, it returns a 4.05
code.

RFC6690 refers to  "/.wellknown/core" as a default entry point for
discovering what resources are available.

RESTCONF rfc8040 refers to "/.wellknown/host-meta" to determine the RESTCONF
root resource.

Data channel

-----------------

Data channel support uses CBOR / COAP, not RESTCONF (well actually it goes
over the signal channel), but that is documented as a current limitation,
but does need to be fixed.

Libcoap

=======

The currently available c libcoap library (develop branch) from
https://github.com/obgm/libcoap only supports DTLS with PreSharedKeys, not
Certificates.  Work needs to be done with this library to support PKI as
well as COAP over TLS (not yet an IETF standard) to support the signal
channel requirements.

Doing a hack to libcoap to force known PKI keys works when used against
Nttdots, so there is potential here to use a fixed version of this library.

RawPublicKey has not been tried out.

Libcoap requires openssl 1.1.0 or TinyDTLS - GnuTLS support is not currently
available.  Red Hat/Centos distributions do not have openssl 1.1.0 - DTLS
support is only version 1, not version 1.2 in their versions of openssl.
The openssl libraries cannot be replaced in Red Hat/Centos - the 1.1.0
version has to be installed in addition to the existing openssl libraries.

Libcoap assumes that all IP addresses are IPv4 (see coap_address_t), even
though there are some references to IPv6 elsewhere in the library.

Default Values

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

There is a list of configurable parameters, but no suggested defaults.

Signal Port - UDP

----------------------

COAP using DTLS default port is 5684 (RFC 7252), nttdots port is 4646.
Should DOTS be going for / defining the same port as COAP?

(https://tools.ietf.org/html/draft-mortensen-dots-over-udp-00 refers to
4646)

Signal Port - TCP

---------------------

This does not have to be the same as the UDP port, but looks like it is
going to be 5684 as per draft-ietf-core-coap-tcp-tls.  Should DOTS be going
for / defining the same default port as COAP?

Data Port

-------------

RFC8040 - "2.2 HTTPS with X.509v3 Certificates" defines RESTCONF
implementations MUST support the "https" URI scheme, which has the
IANA-assigned default port 443 for "/.wellknown/host-meta".

Data Port cannot easily be the same as the Signal Port (TCP) as new incoming
connections are either COAP or RESTCONF and it may be difficult to
differentiate.

Port 443 may clash with other GUIs or applications running on port 443 on
the same host as the DOTS server.  However, the other GUI/applications may
have to add in "/.wellknown/host-meta" to support replying that RESTCONF is
running on another port.  Is the Link 'restconf' definition sufficient, or
de we need a link definition something like 'restconf-dots' added?

What should the suggested default RESTCONF port be?

Mitigation Lifetime

------------------------

This will be DOTS Server provider specific, but should be the order of days.
Do we need to suggest a default lifetime?

DOTS Client Restarts

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

The DOTS Client will need to re-synchronize with the DOTS Server to get the
DOTS Server's current shared state (mitigation / filters etc) when it gets
restarted or reconnected.  Should this be stated?

DOTS Server Restarts

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

The DOTS Server needs some way to signal to the DOTS client that it has
restarted and that shared state needs to be re-synchronized.  Should this be
stated?

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

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 14 Sep 2017 11:46:19 +0100

Hi there,

No responses to date.

I have subsequently found that libcoap does properly support IPv6 - and have
updated my previous questions / comments.

I however have further signal channel questions / discrepancies from
https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel

Usage of PUT signal

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

Usage of "attack-status"

-------------------------------

5.3.1. PUT definition does not include '"attack-status": integer'

5.3.4. PUT definition is initially identical to 5.3.2, but includes
'"attack-status": integer' and states that it is mandatory.

If this parameter is mandatory, then it should be included in the 5.3.1
definition, or is it mandatory only if this is defining an Efficacy update?

With the 5.3.4 version, would not just sending the "mitigation-id" and
"attack-status" be sufficient?

When refreshing with a 5.3.4 PUT, does this reset the lifetime expiry
counter?

PUT refresh

---------------

When the PUT is refreshed by the client at some point before the lifetime
expires, if the signal mitigate content (e.g. target-protocol is changed) is
sent by the client, should this be allowed, ignored or rejected?

COAP Response information

------------------------------------

There is reference to the server having the ability to update the lifetime
in its response to the PUT (5.3.1). 

"The server MUST always indicate the actual lifetime in

      the response and the remaining lifetime in status messages sent to

      the client.  This is an optional attribute in the request."

However, nowhere else does it state what should be in the body of the
response (if anything) for a PUT or DELETE.  There are hints in the COAP RFC
that suitable diagnostics can be added for failure response codes.

Do we just echo back the request (with update lifetime possibly) for PUT?

What body responses do we send back for a DELETE?

Do the body responses need to be in CBOR (including diagnostic messages) ?

CBOR Key Values mapping

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

If a request comes into the server that does not use the CBOR mapping
parameters (section 6), is this to be rejected?

If the request is to be accepted, is the server response to always use CBOR
mapping, or does the server have  to reply without using the CBOR mapping?

Scope

=====

Scope has been defined as an array - presumably to allow multiple
mitigation-ids to be returned in a response.

However, if two or more mitigation-ids are used in a PUT - is this allowed?

If there are 2 or more mitigation-ids, what does the response code refer to
- especially if it would be different for the individual request
mitigation-ids?

--

I'm sure that more questions will come up as we continue to try to do an
implementation of the signal channel.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Jon Shallow
Sent: 08 September 2017 16:56
To: [email-masked]
Subject: [Dots] Coding and Interoperability Challenges

Hi there,

Nttdots

=======

CBOR

-------

Signal Channel

-------------------

Data channel

-----------------

Libcoap

=======

Not the case - Ipv6 is fully supported

Default Values

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

Signal Port - UDP

----------------------

Signal Port - TCP

---------------------

Data Port

-------------

>Mitigation Lifetime

Global Mitigation Lifetime

------------------------

>This will be DOTS Server provider specific, but should be the order of
days.  Do we need to suggest a default lifetime?

This is different to the lifetime refresh - I was thinking of a total
mitigation lifetime slot as a chargeable unit when I wrote this, but this is
really a DOTS Server domain controller decision.

DOTS Client Restarts

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

DOTS Server Restarts

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

 

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 30 Sep 2017 13:41:18 +0000

Hi Jon,

Please see inline.

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Friday, September 8, 2017 9:26 PM
To: [email-masked]
Subject: [Dots] Coding and Interoperability Challenges

Hi there,

We are in the process of trying to code up a DOTS Client / Server implementation based on the draft standards so far and have come up with the following list of issues / questions.

Nttdots
=======

CBOR
-------

The nttdots server only accepts strings for the various parameters.  It does not (yet) accept CBOR that uses the CBOR mapping parameters (draft-ietf-dots-signal-channel Section 6).

Signal Channel
-------------------

Nttdots is expecting an additional path parameter in the POST/PUT etc path (.wellknown), so instead of /v1/dots-signal/signal, it requires /.wellknown/v1/dots-signal/signal which is not stated anywhere in the draft-ietf-dots-signal-channel draft.  If not present, it returns a 4.05 code.

[TR] The draft can be updated to use well-known URI with dots-signal as URI suffix, we can discuss in the interim WG meeting.

RFC6690 refers to  "/.wellknown/core" as a default entry point for discovering what resources are available.
RESTCONF rfc8040 refers to "/.wellknown/host-meta" to determine the RESTCONF root resource.

Data channel
-----------------

Data channel support uses CBOR / COAP, not RESTCONF (well actually it goes over the signal channel), but that is documented as a current limitation, but does need to be fixed.

Libcoap
=======

The currently available c libcoap library (develop branch) from https://github.com/obgm/libcoap only supports DTLS with PreSharedKeys, not Certificates.  Work needs to be done with this library to support PKI as well as COAP over TLS (not yet an IETF standard) to support the signal channel requirements.

Doing a hack to libcoap to force known PKI keys works when used against Nttdots, so there is potential here to use a fixed version of this library.

Libcoap requires openssl 1.1.0 or TinyDTLS - GnuTLS support is not currently available.  Red Hat/Centos distributions do not have openssl 1.1.0 - DTLS support is only version 1, not version 1.2 in their versions of openssl.  The openssl libraries cannot be replaced in Red Hat/Centos - the 1.1.0 version has to be installed in addition to the existing openssl libraries.

Libcoap assumes that all IP addresses are IPv4 (see coap_address_t), even though there are some references to IPv6 elsewhere in the library.

Default Values
============

[TR]  No, all configurable parameters in the specification have default values.

Signal Port - UDP
----------------------

COAP using DTLS default port is 5684 (RFC 7252), nttdots port is 4646.  Should DOTS be going for / defining the same port as COAP?
(https://tools.ietf.org/html/draft-mortensen-dots-over-udp-00 refers to 4646)

Signal Port - TCP
---------------------

This does not have to be the same as the UDP port, but looks like it is going to be 5684 as per draft-ietf-core-coap-tcp-tls.  Should DOTS be going for / defining the same default port as COAP?

[TR] Yes.

Data Port
-------------

RFC8040 - "2.2 HTTPS with X.509v3 Certificates" defines RESTCONF implementations MUST support the "https" URI scheme, which has the IANA-assigned default port 443 for "/.wellknown/host-meta".

Data Port cannot easily be the same as the Signal Port (TCP) as new incoming connections are either COAP or RESTCONF and it may be difficult to differentiate.

Port 443 may clash with other GUIs or applications running on port 443 on the same host as the DOTS server.  However, the other GUI/applications may have to add in "/.wellknown/host-meta" to support replying that RESTCONF is running on another port.  Is the Link 'restconf' definition sufficient, or de we need a link definition something like 'restconf-dots' added?

[TR] 443 port, ALPN [RFC7301] can be used to identify DOTS data channel and distinguish from other application protocols on the DOTS server using port 443.

Mitigation Lifetime
------------------------

This will be DOTS Server provider specific, but should be the order of days.  Do we need to suggest a default lifetime?

[TR] The default value in the specification is 60 minutes.

DOTS Client Restarts
=================

The DOTS Client will need to re-synchronize with the DOTS Server to get the DOTS Server's current shared state (mitigation / filters etc) when it gets restarted or reconnected.  Should this be stated?

[TR] After restart the DOTS client can use GET to learn the mitigation requests it had conveyed to the DOTS server.

DOTS Server Restarts
=================

The DOTS Server needs some way to signal to the DOTS client that it has restarted and that shared state needs to be re-synchronized.  Should this be stated?

[TR] DOTS server should have persistent storage and HA to handle restart (otherwise DOTS client will have to go through the trouble of re-creating aliases, white-list/black-list ACL and mitigation requests during DDoS attack) .

-Tiru

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 30 Sep 2017 14:12:29 +0000

Hi Jon,

Please see inline [TR]

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Thursday, September 14, 2017 4:16 PM
To: [email-masked]
Subject: Re: [Dots] Coding and Interoperability Challenges

Hi there,

No responses to date.

I have subsequently found that libcoap does properly support IPv6 - and have updated my previous questions / comments.

I however have further signal channel questions / discrepancies from https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel

Usage of PUT signal
=================

Usage of "attack-status"
-------------------------------
5.3.1. PUT definition does not include '"attack-status": integer'
5.3.4. PUT definition is initially identical to 5.3.2, but includes '"attack-status": integer' and states that it is mandatory.

If this parameter is mandatory, then it should be included in the 5.3.1 definition, or is it mandatory only if this is defining an Efficacy update?

[TR] "attack-status" parameter is specific to efficacy update.

With the 5.3.4 version, would not just sending the "mitigation-id" and "attack-status" be sufficient?

[TR] No. PUT updates the mitigation request, Efficacy update has to convey all the parameters sent in the original mitigation request (see https://tools.ietf.org/html/rfc7252#section-5.8.3).

When refreshing with a 5.3.4 PUT, does this reset the lifetime expiry counter?

[TR] Yes, 5.3.4 PUT updates the mitigation lifetime.

PUT refresh
---------------
When the PUT is refreshed by the client at some point before the lifetime expires, if the signal mitigate content (e.g. target-protocol is changed) is sent by the client, should this be allowed, ignored or rejected?

[TR] Allowed.

COAP Response information
------------------------------------
There is reference to the server having the ability to update the lifetime in its response to the PUT (5.3.1).

However, nowhere else does it state what should be in the body of the  response (if anything) for a PUT or DELETE.  There are hints in the COAP RFC that suitable diagnostics can be added for failure response codes.
Do we just echo back the request (with update lifetime possibly) for PUT?

[TR] No, only the updated lifetime is returned in the response.

[TR] No body in DELETE for 2.xx responses.

[TR] CBOR body only for 2.xx and 3.xx responses.

CBOR Key Values mapping
======================

If a request comes into the server that does not use the CBOR mapping parameters (section 6), is this to be rejected? [TR] Yes.
If the request is to be accepted, is the server response to always use CBOR mapping, or does the server have  to reply without using the CBOR mapping?

[TR] DOTS server also uses the CBOR mapping.

Scope
=====

Scope has been defined as an array - presumably to allow multiple mitigation-ids to be returned in a response.

However, if two or more mitigation-ids are used in a PUT - is this allowed? [TR] Yes.
If there are 2 or more mitigation-ids, what does the response code refer to - especially if it would be different for the individual request mitigation-ids?

[TR]  No, there is no mechanism to send multiple response codes (Even if one mitigation-id succeeds but the other mitigation-id fails then an error is returned in the response).

-Tiru

--
I'm sure that more questions will come up as we continue to try to do an implementation of the signal channel.

Regards

Jon
From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Jon Shallow
Sent: 08 September 2017 16:56
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] Coding and Interoperability Challenges

Hi there,

Nttdots
=======

CBOR
-------

Signal Channel
-------------------

Data channel
-----------------

Libcoap
=======

Default Values
============

Signal Port - UDP
----------------------

Signal Port - TCP
---------------------

Data Port
-------------

>This will be DOTS Server provider specific, but should be the order of days.  Do we need to suggest a default lifetime?
This is different to the lifetime refresh - I was thinking of a total mitigation lifetime slot as a chargeable unit when I wrote this, but this is really a DOTS Server domain controller decision.

DOTS Client Restarts
=================

DOTS Server Restarts
=================

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Sat, 30 Sep 2017 21:44:35 +0100

Hi Tiru,

Thanks for your updates and feedback - much appreciated.

As per https://github.com/tireddy2/DOTS/ (pre
draft-ietf-dots-signal-channel-04) dated 30 Sep, along with responses to my
emails of Sep 8, Sep 14 and Sep 26, I have the following additional feedback
/ comments and suggestions.

[I see that alias is now alias-name - a clearer definition, but also needs
to be the same in the data channel spec]

https://github.com/tireddy2/DOTS/

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

5.1 Overview

"DOTS agents MUST support GET, PUT, POST, and DELETE CoAP methods."

No examples are given for POST usage, so should POST be a MUST?

5.3.1.  Requesting mitigation

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

We need to clarify what is overlapping - is it just a common IP address /
fqdn / uri and not common protocol

"Orig: ... DOTS client is determined by comparing their respective
mitigation-id values.  If two mitigation requests have overlapping
mitigation scopes the mitigation request with higher numeric mitigation-id
value will override the mitigation request with a lower numeric
mitigation-id value.  The overlapped lower numeric mitigation-id is
automatically deleted and no longer available at the DOTS server.

New:  Overlapping is true if there is a common IP, IP Prefix, FQDN, URI or
alias-name between the two mitigation-ids.

Orig:  The Uri-Path option carries ....."

5.3.3.  Retrieving a DOTS Signal (1)

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

Bps-dropped and pps-dropped as now defined can easily be computed from the
mitigation start time and the total number dropped.  Over the life of a
mitigation it would be good to report higher numbers at peak mitigation
times.  The last 1 second average, or the average since the last GET
request, or last 5 minute average could be alternative methods of
definition, but appreciate that methods of measurement and reporting make it
difficult to be precise what easily can be reported here.

Suggested replacements (included a grammar change from 'a optional' to 'an
optional')

Replacement:  "bps-dropped:  The average dropped bytes per second for the
mitigation

request since the last status request.  This is an

optional attribute."

Replacement: "pps-dropped:  The average dropped packets per second for the

mitigation request since the last status request.  This

is an optional attribute."

5.3.3.  Retrieving a DOTS Signal (2)

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

Does it make sense to add in a "mitigation-start" : time as well as the
bytes dropped etc. in the status response?

5.3.3.1.  Mitigation Status

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

The 03 -> 04 replacement text can be better worded as below (with spelling
correction):-

Orig: "A DOTS client retrieves the information about a DOTS signal at

frequent intervals to determine the status of an attack.  The DOTS

client can send the GET request at frequent intervals without the

Observe option to" 

Replacement: "retrieve the configuration and status data of the mitigation

Request. The frequency of polling the DOTS server to get the mitigation
status should follow the usage guidelines given in
https://tools.ietf.org/html/rfc8085#section-3.1.3."

Orig:  " If the DOTS server has been able to mitigate the attack and

the attack has stopped, the DOTS server indicates as such in the

status, and the DOTS client recalls the mitigation request"

Addition:  "by issuing a DELETE for the mitigation-id."

5.4.2.  Convey DOTS Signal Channel Session Configuration

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

"missing-heartbeat-interval" should be "missing-hb-allowed" in Figure 16.

5.3.1.  Requesting mitigation

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

>From a previous email dialogue

> [TR] No, only the updated lifetime is returned in the response. 

OK, the CBOR response (JSON format)  is which of the 2 versions below?

{

  "mitigation-scope": {

     "scope": [

        {

          "mitigation-id": integer,

          "lifetime": integer

        }

      ]

   }

}

Or 

{

   "lifetime": integer

}

We need this clarified in the spec.

5.3.2.  Withdraw a DOTS Signal

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

>From a previous email dialogue

> [TR] No body in DELETE for 2.xx responses. 

Spec needs to state this

Orig: "The DOTS server immediately acknowledges a DOTS client's request to

withdraw the DOTS signal using 2.02 (Deleted) response code." 

New: "There is no response payload."

Orig: "A 2.02 (Deleted) Response Code is returned even if the mitigation-id
..."

Other (1)

=====

>From a previous email dialogue

>> Nttdots is expecting an additional path parameter in the POST/PUT etc
path (.wellknown), so instead of /v1/dots-signal/signal, it requires
/.wellknown/v1/dots-signal/signal which is not stated anywhere in the
draft-ietf-dots-signal-channel draft.  If not present, it returns a 4.05
code.

> [TR] The draft can be updated to use well-known URI with dots-signal as
URI suffix, we can discuss in the interim WG meeting.

I believe that doing a Discover (GET /.well-known/core) to determine the
actual configuration paths should be used (RFC6690).  

Other (2)

=====

>> If the DOTS client receives 3 responses of 4.22 in a row on the same

session,

>> the DOTS client MUST stop trying to configure the session to prevent 

>> a continuous retry loop."

> I don't see why the client would pick unacceptable values after 

> getting

the min/max parameters from the DOTS server. 

I just wanted to prevent a continuous retry in case there is some buggy
software out there / faulty hardware based on certain bit patterns etc.

This is the only place in the spec where the client retries sending again
when a failure message is returned from the server.

Other (3)

=====

>> "heartbeat-refresh": {"MinValue": 2, "MaxValue" : 60},

>> heartbeat-refresh:   Heartbeat refresh rate in seconds.  This is an

optional

>> attribute.

> Added heartbeat-interval (e.g. {"CurrentValue": 90, "MinValue": 60,

"MaxValue" : 240}).

A lot of firewalls I have worked with in the past have a default of 30 sec
for UDP session timeouts.  Therefore the minimum value should be less than

30 - say 10 or 15 secs to prevent firewall session expiry.

Other (4)

=====

>> New: "For mitigation to continue beyond the initial negotiated
"lifetime", the

>> DOTS client will need to refresh the current mitigation request by
sending a

>> new PUT request.  The PUT request SHOULD use the same "mitigation-id",

>> and SHOULD repeat all the other parameters as sent in the original
mitigation

>> request apart from a possible change to the "lifetime"

>> parameter.  

> Any specific reason for "SHOULD" (I plan to use "MUST" instead of
"SHOULD") ?

MUST is fine by me

Other (5)

=====

>> When "observe" is set to 0, should the DOTS server send back an
unsolicited

>> information / status update

>> a) whenever there is a "status" parameter change

>> b) when there is a change to one of the "*-dropped" parameters

>> c) send a response at some regular time interval?

>> - Figure 10 implies it is just on a "status" parameter change.

> It is a), whenever there is a change to the "attack-status" parameter
value (https://tools.ietf.org/html/rfc7641 allows notification from the
server 

only when the state changes). 

Actually, only "status" is returned in the GET request. "attack-status" is
used for efficacy updates.  Perhaps "status" should be defined as
"state-status" for clarity.

draft-ietf-dots-data-channel-03

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

3.2.3.  Retrieving Installed Identifiers

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

The JSON examples do not always follow the YANG model

Container(YANG) = object(JSON) (RFC7951- 5.2)

List(YANG) = array(JSON) (RFC7951 - 5.4)

"ietf-dots-data-channel-identifier:identifier" is a container, not a list,
and therefore cannot be an array. Figure 7.  As "alias" is the array, all
the aliases should be done at that level.

3.3.1 Install Filtering Rules

Draft-ietf-netmod-acl-model-13 rev 2017-06-12 has changed the YANG
definition for "ietf-access-control-list:access-lists"

"Added feature and identity statements for different types of rule matches.
Split the matching rules based on the feature statement and added a must
statement within each container."

The feature containers (e.g. ipv4-acl) are missing from all examples for the
filter rules.

"acl-type" is now of form "ipv4-acl", not "ipv4".

All references to ietf-access-control-list:access-lists need to be updated,
including the rate-limiting / fragment extensions.

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

Regards

Jon