Subject: Re: [Dots] Coding and Interoperability Challenges

From: "Jon Shallow" <[email-masked]>
Date: Tue, 26 Sep 2017 12:07:05 +0100

Hi there,

I now have implemented a working DOTS Server supporting the signal channel
over UDP and is CoAP TCP ready.  The data channel work has still to be done.
The DOTS Client is still a work in progress, but was used to test the DOTS
server.  This however has highlighted some vague, open to interpretation,
definitions in the signal spec draft-ietf-dots-signal-channel-03, several of
which I have previously raised.

If there is insufficient time to address the issues before the virtual
meeting on 2nd October, then it may make sense to discuss them at that
meeting.

Given the interrelation of the draft IETF dots documents, other RFCs, there
is a reasonable chance that I may have misinterpreted something, or not
realised as consequence of what needs to be done.

The following is not in order of importance - it is following the signal
specification order.  Instead of getting bogged down in a section, skip it
and read the other sections and come back to the one you are having trouble
with - the wider context may help you.  In particular, Sections covering 5.1
may need to be initially skipped.

draft-ietf-dots-signal-channel-03
=================================

5.1 Overview (1)
=============
In general, what should be in, or could be expected in the response is not
that clear. This should be tightened up - this section 5.1 with a new
penultimate paragraph at the end of this section may be a good place.  The
following comments / descriptions in this section highlight some areas that
have raised concerns.

Original: (End of section 5.3.1) "For responses indicating a client or
server error, the payload explains the error situation of the result of the
requested action (Section 5.5 in [RFC7252])."

[RFC 7572 5.5 Payloads and Representations
Both requests and responses may include a payload, depending on the Method
or Response Code, respectively.  If a Method or Response Code is not defined
to have a payload, then a sender MUST NOT include one, and a recipient MUST
ignore it.]

If the response is not 2.xx, is the diagnostic message that is sent back a
CoAp Diagnostic Message with no content format and a simple plain-text
message (RFC 5.5.2 Diagnostic Payload)?

If so, what happens with the 4.22 (Unprocessable Entity) response in 5.4.1
which states the acceptable values - which are encoded in CBOR?
- I think this should be a Diagnostic Payload response (perhaps with the bad
value), thus inviting the DOTS Client to (re-)do a GET Request to discover
the valid values.
- It is also not possible to determine which is the value that has failed
with just the current defined payload response - whereas a Diagnostic
message can give a hint as to the failing value.

In 5.3.1, the only thing mentioned for a successful PUT response is the
"lifetime" parameter is required.  It is unclear whether the rest of the
parameter/values that were part of the PUT request should also be in the
response.  What should be returned?

Suggested update to 5.1 to handle "RFC 7572 5.5 Payloads and
Representations" sandwiched between 2 Originals to set the context:-

Original: ". Mitigation remains active until the DOTS client explicitly
terminates mitigation, or the mitigation lifetime expires."

New Addition: "The following CoAP requests and responses MUST be supported
by the DOTS agents.

+------------+-------------+
|Method Code |Usage        | 
+------------+-------------+
|0.00        |Heartbeat    | 
|0.01        |GET          | 
|0.03        |PUT          | 
|0.04        |DELETE       | 
+------------+-------------+
Figure XXX: Supported CoAP Method Codes"

All CoAP responses with codes that are 2.xx MUST have a CoAP payload,
content type "application/cbor" that is a "resource representation" [RFC7252
5.5.1 Representation].

All CoAP responses with codes that are not 2.xx MUST be a Diagnostic Payload
[RFC7252 5.5.2 Diagnostic Payload] with no content type.  The Diagnostic
Payload can contain additional information to aid troubleshooting.

+-------------+---------------------+----------+-------+
|Response Code|Usage                |Diagnostic|Payload|
+-------------+---------------------+----------+-------+
|2.01         |Created              |No        |Yes    |
|2.02         |Deleted              |No        |Yes    |
|2.04         |Changed              |No        |Yes    |
|2.05         |Content              |No        |Yes    |
|3.00         |Alternative Server   |No        |Yes    |
|4.00         |Bad Request          |Yes       |No     |
|4.01         |Unauthorized         |Yes       |No     |
|4.02         |Invalid Query        |Yes       |No     |
|4.04         |Not Found            |Yes       |No     |
|4.22         |Unprocessable Entity |Yes       |No     |
|5.00         |Internal Server Error|Yes       |No     |
|5.02         |Bad Gateway          |Yes       |No     |
|5.03         |Service Unavailable  |Yes       |No     |
|5.04         |Gateway Timeout      |Yes       |No     |
+-------------+---------------------+----------+-------+
Figure XXX: Supported CoAP response Codes
"

Original: "Messages exchanged between DOTS client and server are serialized
..."

5.1 Overview (2)
=============
Nowhere is mentioned what ports should be used.  RFC7252 suggest a default
of 5684/udp for CoAP DTLS.  draft-ietf-core-coap-tcp-tls suggests 5684/tcp.

Should this be stated?

5.1 Overview (3)
=============
No mention is made of doing any signal channel recovery if a DOTS agent
restarts for any reason.  Things potentially could get out of sync unless
there is some functionality to make sure that information held by each DOTS
agent is properly synchronized (even if it a simple "flush out all that you
know").

5.3.1 Requesting Mitigation
===========================
Original: ". The relative order of two mitigation requests from a 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."

This raises several implementation questions.

Question 1
----------
Say a PUT mitigation-id with a value of #99 is followed by a PUT
mitigation-id of #100 which overlaps, so #99 is ignored/overridden.  Then
there is a DELETE #100.  Do we revert back to #99?

If yes, then do we need to remember #1 through #98 to revert back to them if
needed - the logical extension of this is remembering all 2^31 entries -
which probably is a DOS attack.

My suggestion would be that #99 is dropped/deleted if #100 overlaps, and the
subsequent deleting #100 withdraws that particular mitigation and so
mitigation stops.  The new wording could be:-

Replacement: "The relative order of two mitigation requests from a 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 for
querying against."

Question 2
----------
It is unclear as to how this overlapping works, say with #99 target-ip
[1.1.1.1,1.1.1.2] and #100 target-ip [1.1.1.2,1.1.1.3]. Is it correct that
1.1.1.1 should no longer be mitigated, but 1.1.1.3 should start?

What about overlapping protocols, but not overlapping target-ips etc?

Question 3
----------
If there is an overlap, why cannot both mitigation scopes (both lower and
higher mitigation-ids) still continue?

Question 4
----------
Handling mitigation request refreshes.
When the lifetime expires with the active mitigation-id, the mitigation
stops unless there is a refreshed mitigation request of some sort.  Does the
refresh mitigation request to keep the mitigation going use the same
mitigation-id, or must it be a new (incremented?) mitigation-id?

If the refresh requires a new incremented id, then this will wrap at some
point and the "mitigation request with higher numeric mitigation-id value
will override" test will fail.

Original: "If the DOTS server finds the mitigation-id parameter value
conveyed in the PUT request in its configuration data then the server MAY
update the mitigation request, and a 2.04 (Changed) response is returned to
indicate a successful update of the mitigation request."

This implies the same mitigation-id is used for doing the refresh.
My suggestion is to add in a new paragraph at the end of section 5.3.1 for
clarity.

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.  The DOTS server MAY refuse the refresh request if any of the
request parameters (apart from "lifetime") have changed."

Question 5
----------
When the PUT is refreshed with the same mitigation-id 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?

My suggestion is in the "New:" update under Question 4 just above.

Question 6
----------
As Scope has been defined as an array, are multiple mitigation-ids allowed
with a single PUT request?
- I think only one should be allowed.  The replacement is for the
mitigation-id definition - the addition is at the end.

Replacement: "mitigation-id:  Identifier for the mitigation request
represented using an integer.  This identifier MUST be unique for each
mitigation request bound to the DOTS client, i.e., the mitigation-id
parameter value in the mitigation request needs to be unique relative to the
mitigation-id parameter values of active mitigation requests conveyed from
the DOTS client to the DOTS server.  This identifier MUST be generated by
the DOTS client. This document does not make any assumption about how this
identifier is generated.  This is a mandatory attribute.  There can only be
one mitigation-id request per Scope per single PUT request."

5.3.2 Withdraw a DOTS Signal
============================
Can multiple mitigation-ids be sent in a single DELETE request (scope is an
array)?

What gets sent back in the payload?

If the mitigation-id found, then that can easily be the mitigation-id
information.

If not found, is there no payload, or should there be an empty scope array
something like
{
  "mitigation-scope": {
    "scope": [
    ]
  }
}

We need to define what the client will expect (especially if it is going to
make a decision on a 2.02 response for a non-existent mitigation-id).

My suggestion is to add in a new paragraph at the end of this section.

New: "Multiple mitigation-ids MAY be included in the DELETE "scope". The
"resource representation" response payload always includes
"mitigation-scope" and "scope" with zero or more mitigation-ids that were
found and deleted.  If the DELETE is repeated for one or more mitigation-ids
during the active-but-terminating period, then the matching mitigation-ids
continue to get returned."

5.3.3 Retrieving a DOTS Signal (1)
==============================
When/what to send back an unsolicited response when running with an Observe.
Some questions that need to be answered.

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.

If at a regular interval (c), should this be a configurable value (as per
configuration under 5.4?) or a defined fixed value?

What should the recommended frequency of update be (1 per n seconds")?

If Observe is not used to set up a regular frequency update, and therefore
it is the responsibility of the DOTS client to poll as required (perhaps for
graphing the data), should the DOTS Client set the Observe option (which
will set up/cancel either (a) or (b) above) when polling?
-If Observe is set to 1 during the polling, then it will cancel any
notifications set up.

Is Observe a MUST with a signal GET?
 - All examples have this Observe option included in Figure 10

I think that adding in an extra parameter "refresh-rate" would help here if
there is to be a continuous refresh of information.  However, this would
only work for the explicit "mitigation-id" request. Alternatively, the
generic request (no payload) could be replaced with one where the
mitigation-id is -1 (following the same usage as the challenges over using
the GET configuration signal-id in 5.4.1).  Thoughts?

5.3.3 Retrieving a DOTS Signal (2)
==============================
There is inconsistency in the definition of the "mitigation-scope" parameter
- it is either an object/map or an array (for the responses back from the
GET with no payload).  The usage needs to be consistent throughout the
specification to avoid errors creeping in.

As "scope" is an array, then the multiple responses should be:-

Replacement: "
{
  "mitigation-scope":{
    "scope": [
      {
        "mitigation-id": 12332,
        "target-protocol": [
           17
         ],
        "lifetime":1801,
        "status":2,
        "bytes-dropped": 134334555,
        "bps-dropped":  43344,
        "pkts-dropped": 333334444,
        "pps-dropped": 432432
      },
      {
        "mitigation-id": 12333,
        "target-protocol": [
           6
         ],
        "lifetime":1749,
        "status":3,
        "bytes-dropped": 0,
        "bps-dropped":  0,
        "pkts-dropped": 0,
        "pps-dropped": 0
      }
    ]
  }
}
"

5.3.3 Retrieving a DOTS Signal (3)
==============================
"bytes-dropped" and "pkts-dropped". Are these counters from the start of the
original initial PUT mitigate requests, or are these reset to 0 whenever
there is a PUT mitigate refresh?

My inclination is to go with the count from the initial PUT mitigate request
(with a potential wrap around for long mitigations).
 
It is possible that a DOTS client may have been restarted, but the
mitigation request continues for the remainder of the lifetime
Replacement: "bytes-dropped:  The total dropped byte count for the
mitigation request since the mitigation was initially requested.  This is an
optional attribute.

bps-dropped:  The average dropped bytes per second for the mitigation
request.  This is an optional attribute.

pkts-dropped:  The total dropped packet count for the mitigation request
since the mitigation was initially requested.  This is an optional
attribute.

pps-dropped:  The average dropped packets per second for the mitigation
request.  This is an optional attribute."

5.3.3 Retrieving a DOTS Signal (4)
==============================
The "lifetime" returned value is not defined in the mitigation status
parameters.  Is this the remaining time (in seconds?) of the current
mitigation request?

Replacement: "The mitigation status parameters are described below.

lifetime:  The remaining lifetime in seconds of the current mitigation-id
request.

bytes-dropped:  The total dropped byte count.."

5.3.4 Efficacy Update from DOTS Client (1)
--------------------------------------
Original: "The PUT request MUST include all the parameters used in the PUT
request to convey the DOTS signal (Section 5.3.1)."
This also implicitly implies that this must be done in 5.3.1 as well.

What is the DOTS server supposed to do if any of the parameters (apart from
perhaps "lifetime") are different - does this invoke a 4.02?

The same question is true for 5.3.1.

Replacement: "While DDoS mitigation is active, a DOTS client MAY frequently
transmit DOTS mitigation efficacy updates to the relevant DOTS server.  An
PUT request (Figure 11) is used to convey the mitigation efficacy update to
the DOTS server.  The PUT request MUST include all the parameters used in
the PUT request to convey the DOTS signal (Section 5.3.1) unchanged apart
from "lifetime".  The DOTS server MUST reject the request with a 4.02 code
if this is not the case.  The If-Match Option (Section 5.10.8.1 of
[RFC7252]) with an empty value is used to make the PUT request conditional
on the current existence of a mitigation request with the same
mitigation-id.  If UDP is used as ...

5.3.4 Efficacy Update from DOTS Client (2)
--------------------------------------
Original:" The 5.xx response codes are returned if the DOTS server has erred
or is incapable of performing the mitigation."

Should there be any definitions of what 5.xx code should be used where?

5.3.4 Efficacy Update from DOTS Client (3)
--------------------------------------
Does a PUT with "attack-status" refresh the outstanding lifetime on the
current mitigation request?

Or is the "lifetime" parameter optional, despite the MUST statement at the
beginning of this session "The PUT request MUST include all the parameters
used in the PUT request to convey the DOTS signal (Section 5.3.1)."?

For clarity, I think the following should be added in as a paragraph at the
end of this section:-

New: "The current mitigation does not have the lifetime refreshed when using
a Efficacy Update PUT as per section 5.3.4, but does have the lifetime
refreshed when using a Mitigation Request PUT as per section 5.3.1."

5.4 DOTS Signal Channel Session Configuration
---------------------------------------------
Original:"   a.  Heartbeat timeout: DOTS agents regularly send heartbeats
(Ping/ Pong) to each other after mutual authentication in order to keep the
DOTS signal channel open, heartbeat timeout is the time to wait for a Pong
in milliseconds."

Nowhere is the frequency defined for "regular send" and should this also be
configurable in 5.4.1?

5.4.1 Discover Acceptable Configuration Parameters (1)
--------------------------------------------------
Original: "A GET request is used to obtain acceptable configuration
parameters on the DOTS server for DOTS signal channel session
configuration."

So, when making a configuration change, is this specific to the Signal
Channel between the DOTS Server and DOTS client, or is it specific to each
CoAP session where potentially there could be multiple sessions for the same
signal channel?

Replacement: ""A GET request is used to obtain acceptable configuration
parameters on the DOTS server for current session using the DOTS signal
channel."

5.4.1 Discover Acceptable Configuration Parameters (2)
--------------------------------------------------
Figure 13.  Does it also make sense to return Default values as well?
- It may make sense for these to be Current as opposed to Default values.

Replacement: "Content-Format: "application/cbor"
{
  "heartbeat-timeout": {"MinValue": integer, "MaxValue" :
integer,"DefaultValue":integer},
  "max-retransmit": {"MinValue": integer, "MaxValue" :
integer,"DefaultValue":integer },
  "ack-timeout": {"MinValue": integer, "MaxValue" :
integer,"DefaultValue":integer },
  "ack-random-factor": {"MinValue": number, "MaxValue" :
number,"DefaultValue":integer }
}

5.4.2. Convey DOTS Signal Channel Session Configuration (1)
--------------------------------------------------
Original: "The RECOMMENDED values of transmission parameter values are
ack_timeout (2 seconds), max-retransmit (7), ack-random-factor (1.5) and
heartbeat-timeout (371 seconds)."

RFC7252 has max-retransmit set to 4, not 7. (RFC 7252 4.8 Transmission
Parameters).

With the exponential back off for retries of CON messages, using 4 gives an
expiration of the request after about 1.5 minutes, with a value of 7 this is
almost 10 minutes.  The 10 minutes does seem excessively long to me -
especially when it is for a CON Heartbeat.
Unless there is a good reason for 7, I suggest we go with the RFC7572
recommendations of 4.

Replacement: "The RECOMMENDED values of transmission parameter values are
ack_timeout (2 seconds), max-retransmit (4), ack-random-factor (1.5) and
heartbeat-timeout (371 seconds)."

Replacement: "
Header: PUT (Code=0.03)
Uri-Host: "www.example.com"
Uri-Path: "v1"
Uri-Path: "dots-signal"
Uri-Path: "config"
Content-Format: "application/cbor"
{
  "signal-config": {
    "session-id": 1234534333242,
    "heartbeat-timeout": 30000,
    "max-retransmit": 4,
    "ack-timeout": 5,
    "ack-random-factor": 1.5,
    "trigger-mitigation": false
  }
}
"

5.4.2. Convey DOTS Signal Channel Session Configuration (2)
--------------------------------------------------
Original: The PUT request with higher numeric session-id value over-rides
the DOTS signal channel session configuration data installed by a PUT
request with a lower numeric session-id value."

Say a PUT session-id with a value of #99 is followed by a PUT session-id of
#100 which overlaps, so #99 is ignored.  Then there is a DELETE #100.  Do we
revert back to #99?

If yes, then do we need to remember #1 through #98 to revert back to them if
needed - the logical extension of this is remembering all 2^31 entries -
which probably is a DOS attack.

My suggestion would be that #99 is dropped if #100 overlaps, and deleting
#100 deletes that particular session-id.  The new wording would be:-

Replacement:" The PUT request with higher numeric session-id value
over-rides the DOTS signal channel session configuration data installed by a
PUT request with a lower numeric session-id value.  The overlapped lower
numeric session-id is automatically deleted and no longer available for
querying against.".

Footnote: I cannot think of any reason why there is a need to support
(incrementing) session-ids for configuring a CoAP session - am I missing
something?

5.4.2. Convey DOTS Signal Channel Session Configuration (3)
--------------------------------------------------
Original:"heartbeat-timeout:   Heartbeat timeout is the time to wait for a
response in milliseconds to check the DOTS peer health.  This is an optional
attribute."

So, heartbeat-timeout is configured in milliseconds.  However, Figure 15
example below only has a value of 30.  This example value of 30 in
milliseconds is small.

Original: "
Header: PUT (Code=0.03)
Uri-Host: www.example.com
Uri-Path: "v1"
Uri-Path: "dots-signal"
Uri-Path: "config"
Content-Format: "application/cbor"
{
  "signal-config": {
  "session-id": 1234534333242,
  "heartbeat-timeout": 30,
  "max-retransmit": 7,
"

This needs to be updated to, say, 30000 instead of 30.

Replacement: "
Header: PUT (Code=0.03)
Uri-Host: www.example.com
Uri-Path: "v1"
Uri-Path: "dots-signal"
Uri-Path: "config"
Content-Format: "application/cbor"
{
  "signal-config": {
  "session-id": 1234534333242,
  "heartbeat-timeout": 30000,
  "max-retransmit": 4,
"

5.4.2. Convey DOTS Signal Channel Session Configuration (4)
--------------------------------------------------
Original: "Response code 4.22 (Unprocessable Entity) will be returned in the
response if any of the heartbeat-timeout, max-retransmit, target-protocol,
ack-timeout and ack-random-factor attribute values is not acceptable to the
DOTS server.  The DOTS server in the error response conveys the minimum and
maximum attribute values acceptable by the DOTS server. The DOTS client can
re-try and send the PUT request with updated attribute values acceptable to
the DOTS server.

Content-Format: "application/cbor"
{
  "heartbeat-timeout": {"MinValue": 15, "MaxValue" : 60},
  "max-retransmit": {"MinValue": 3, "MaxValue" : 15},
   "ack-timeout": {"MinValue": 1, "MaxValue" : 30},
  "ack-random-factor": {"MinValue": 1.0, "MaxValue" : 4.0}
 }
      Figure 16: Error response body
"

The 4.22 response should, I believe for consistency, only be generating a
CoAP Diagnostic response, which does not contain payload data.  I think this
paragraph should be re-worded to be consistent in the CoAP responses:

Replacement:"Response code 4.22 (Unprocessable Entity) will be returned in
the response if any of the heartbeat-timeout, max-retransmit,
target-protocol, ack-timeout and ack-random-factor attribute values are not
acceptable to the DOTS server.  On receipt of the 4.22 response, the DOTS
client should re-request the maximum and minimum parameters acceptable by
the DOTS server as described in 5.4.1.  The DOTS client can re-try and send
the PUT request with updated attribute values acceptable to the DOTS server.
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."

5.4.2. Convey DOTS Signal Channel Session Configuration (5)
--------------------------------------------------
If a DOTS client wants to re-alter the session configuration with a
subsequent PUT, should this use the same session-id?

5.4.4. Retrieving DOTS Signal Channel Session Configuration
-----------------------------------------------------------
Unlike the signal GET, it is not possible to get the current configuration
unless the session-id is known, but the session-id can only be created by a
PUT, at which point the configuration is already known and can be confirmed
by the GET.

As signal-id cannot easily be guessed unless hard coded in the DOTS client,
a suggestion is that a session-id of -1 allows you to determine the current
configuration.  As "signal-config" is not an array, it is not be possible to
return multiple session-ids, but possibly the session-id of the current
configuration could be returned in the payload response to a session-id of
-1.  A new paragraph at the end of this section.

New: "If "session-id" is set to -1, then the current signal configuration is
returned.  If the session has previously been configured, then the
appropriate session-id is returned with the current configuration
parameters, otherwise -1 is returned for the session-id along with all the
default configuration parameters."

5.6 Heartbeat Mechanism
-----------------------
The frequency of the heartbeats is not mentioned.  This should be
configurable in 5.14.2 and have a default value / max-min boundaries
discoverable in 5.4.1 or 5.4.4 or have a recommended fixed value.

My preference is that it should be configurable as one of the signal channel
session configuration parameters, with a default value of 10 seconds.

e.g. to be inserted in the appropriate places.

"heartbeat-refresh": {"MinValue": 2, "MaxValue" : 60},
heartbeat-refresh:   Heartbeat refresh rate in seconds.  This is an optional
attribute.

6 Mapping parameters to CBOR (1)
----------------------------
It is possible additional parameters may need to be added to this table -
e.g. DefaultValue and heartbeat-refresh.

6 Mapping parameters to CBOR (2)
----------------------------
If a client does not use the mapping parameters in a request, how should the
DOTS server send back any responses - CBOR mapping encoded or just encoded
as strings?

Should an endpoint refuse to access non CBOR mapping encoded strings?

Replacement: "All parameters in the payload in the DOTS signal channel MUST
be mapped to CBOR types as follows and are given an integer key to save
space.  The recipient of the data MAY reject the information if it is not
suitably mapped."  

6 Mapping parameters to CBOR (3)
----------------------------
What happens if a sender uses CBOR mapping that are not defined in the
signal channel specification?
- If additional ones are needed in the future, then there will need to be a
protocol version increase (from v1 to v2).

New: "A DOTS agent MUST not use any additional Mapping parameters that are
not defined in Figure 21."

10.2.2 Initial Registry Contents
--------------------------------
It is possible additional parameters may need to be added to this table -
e.g. DefaultValue and keepalive-refresh.

11.1 nttdots
------------
When testing against the nttdots server / client, the following issues were
found:-

CBOR mapping is not in use - it is using the original strings.

COAP path requires /.wellknown/ in the UriPath. 

Data Channel uses CBOR/COAP, not RESTCONF (already documented in DOTS signal
draft)

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

Regards

Jon

---

From: kaname nishizuka <[email-masked]>
Date: Fri, 29 Sep 2017 12:47:42 +0900

Hi Jon,

Sorry for taking time to respond to your post due to my vacation.
As an implementer of DOTS protocol, I'm very glad to hear that you implemented your DOTS Server.

I feel we are on the same page especially about the clarification of the signal-channel spec .
Your comments help us a lot on improvement of our software.
I added a few comments inline.

> draft-ietf-dots-signal-channel-03
Response to 5.1 will be replied later.

> 5.1 Overview (2)
We just used 4646/udp as a default port for signal-channel but leave it configurable in our implementation.
DOTS WG should determine the port number for signal-channel and data-channel, and request it to IANA if required.

> 5.1 Overview (3)
In our implementation, a DOTS server keeps its information, so duplicated request will be rejected by DOTS server after restart of DOTS client.

> 5.3.1 Requesting Mitigation

In our service (DOTS has not been used yet though), we are keeping old mitigation request and revert back if new mitigation was withdrawn.
Our implementation has not been caring about the case, but reverting back would be an operational requirement.
> Question 2
I support this change.

> Question 5
I support this change.

> 5.3.2 Withdraw a DOTS Signal
It looks good to me, we will check the implementation.

> 5.3.3 Retrieving a DOTS Signal (1)
will be replied later.

> 5.3.3 Retrieving a DOTS Signal (2)

How to count the dropped packet depends on mitigation methods.
Adding bps-dropped and pps-dropped as an optional attribute will make a room for reporting capability of various mitigation methods like ACL on routers.

> 5.3.3 Retrieving a DOTS Signal (4)
We haven't implemented efficacy update features, but your proposing texts looks good to us.
Please give us time to look into them.
Also we'd like to reply later about signal channel session configuration topics(5.4) below.

> 5.4 DOTS Signal Channel Session Configuration

I've realized issues you found.
We(our dev members) are more than happy to hear from you that we can test interoperability each other at some time.
Before that, we'd like to look into your proposals and reply to you(and WG) in detail later, and we are willing to discuss those implementation details.
Thank you!

regards,
kaname

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 29 Sep 2017 05:05:11 +0000

Hi Jon,

Thanks for the detailed review. We plan to update the draft and respond to your comments asap.

Cheers,
-Tiru

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
> Sent: Tuesday, September 26, 2017 4:37 PM
> To: [email-masked]
> Subject: Re: [Dots] Coding and Interoperability Challenges
> 
> Hi there,
> 
> I now have implemented a working DOTS Server supporting the signal
> channel over UDP and is CoAP TCP ready.  The data channel work has still to
> be done.
> If there is insufficient time to address the issues before the virtual meeting
> on 2nd October, then it may make sense to discuss them at that meeting.
> 
> Given the interrelation of the draft IETF dots documents, other RFCs, there is
> a reasonable chance that I may have misinterpreted something, or not
> specification order.  Instead of getting bogged down in a section, skip it and
> read the other sections and come back to the one you are having trouble
> Original: (End of section 5.3.1) "For responses indicating a client or server
> error, the payload explains the error situation of the result of the requested
> action (Section 5.5 in [RFC7252])."
> 
> [RFC 7572 5.5 Payloads and Representations Both requests and responses
> may include a payload, depending on the Method or Response Code,
> respectively.  If a Method or Response Code is not defined to have a payload,
> then a sender MUST NOT include one, and a recipient MUST ignore it.]
> 
> If the response is not 2.xx, is the diagnostic message that is sent back a CoAp
> Diagnostic Message with no content format and a simple plain-text message
> (RFC 5.5.2 Diagnostic Payload)?
> 
> value), thus inviting the DOTS Client to (re-)do a GET Request to discover the
> valid values.
> - It is also not possible to determine which is the value that has failed with
> just the current defined payload response - whereas a Diagnostic message
> can give a hint as to the failing value.
> 
> New Addition: "The following CoAP requests and responses MUST be
> supported by the DOTS agents.
> 
> Figure XXX: Supported CoAP response Codes "
> 
> Original: "Messages exchanged between DOTS client and server are
> serialized ..."
> 
> 
> 5.1 Overview (2)
> =============
> Nowhere is mentioned what ports should be used.  RFC7252 suggest a
> default of 5684/udp for CoAP DTLS.  draft-ietf-core-coap-tcp-tls suggests
> 5684/tcp.
> 
> Should this be stated?
> 
> 
> 5.1 Overview (3)
> =============
> restarts for any reason.  Things potentially could get out of sync unless there
> is some functionality to make sure that information held by each DOTS agent
> is properly synchronized (even if it a simple "flush out all that you know").
> 
> 
> Original: ". The relative order of two mitigation requests from a DOTS client is
> determined by comparing their respective mitigation-id values.  If two
> mitigation requests have overlapping mitigation scopes the mitigation
> Say a PUT mitigation-id with a value of #99 is followed by a PUT mitigation-id
> of #100 which overlaps, so #99 is ignored/overridden.  Then there is a DELETE
> #100.  Do we revert back to #99?
> 
> If yes, then do we need to remember #1 through #98 to revert back to them
> if needed - the logical extension of this is remembering all 2^31 entries -
> My suggestion would be that #99 is dropped/deleted if #100 overlaps, and
> the subsequent deleting #100 withdraws that particular mitigation and so
> When the lifetime expires with the active mitigation-id, the mitigation stops
> unless there is a refreshed mitigation request of some sort.  Does the refresh
> mitigation request to keep the mitigation going use the same mitigation-id,
> or must it be a new (incremented?) mitigation-id?
> 
> point and the "mitigation request with higher numeric mitigation-id value will
> override" test will fail.
> 
> 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"
> - I think only one should be allowed.  The replacement is for the mitigation-id
> definition - the addition is at the end.
> 
> mitigation request bound to the DOTS client, i.e., the mitigation-id parameter
> value in the mitigation request needs to be unique relative to the mitigation-
> id parameter values of active mitigation requests conveyed from the DOTS
> client to the DOTS server.  This identifier MUST be generated by the DOTS
> client. This document does not make any assumption about how this
> identifier is generated.  This is a mandatory attribute.  There can only be one
> mitigation-id request per Scope per single PUT request."
> 
> 
> something like {
> We need to define what the client will expect (especially if it is going to make
> a decision on a 2.02 response for a non-existent mitigation-id).
> 
> "resource representation" response payload always includes "mitigation-
> scope" and "scope" with zero or more mitigation-ids that were found and
> deleted.  If the DELETE is repeated for one or more mitigation-ids during the
> active-but-terminating period, then the matching mitigation-ids continue to
> get returned."
> 
> 
> If Observe is not used to set up a regular frequency update, and therefore it
> is the responsibility of the DOTS client to poll as required (perhaps for
> graphing the data), should the DOTS Client set the Observe option (which will
> set up/cancel either (a) or (b) above) when polling?
> -If Observe is set to 1 during the polling, then it will cancel any notifications
> set up.
> 
> there is to be a continuous refresh of information.  However, this would only
> work for the explicit "mitigation-id" request. Alternatively, the generic
> request (no payload) could be replaced with one where the mitigation-id is -1
> (following the same usage as the challenges over using the GET configuration
> signal-id in 5.4.1).  Thoughts?
> 
> 
> - it is either an object/map or an array (for the responses back from the GET
> with no payload).  The usage needs to be consistent throughout the
> "bytes-dropped" and "pkts-dropped". Are these counters from the start of
> the original initial PUT mitigate requests, or are these reset to 0 whenever
> It is possible that a DOTS client may have been restarted, but the mitigation
> request continues for the remainder of the lifetime
> since the mitigation was initially requested.  This is an optional attribute.
> 
> from "lifetime".  The DOTS server MUST reject the request with a 4.02 code if
> this is not the case.  The If-Match Option (Section 5.10.8.1 of
> on the current existence of a mitigation request with the same mitigation-id.
> If UDP is used as ...
> 
> 
> For clarity, I think the following should be added in as a paragraph at the end
> of this section:-
> 
> New: "The current mitigation does not have the lifetime refreshed when
> using a Efficacy Update PUT as per section 5.3.4, but does have the lifetime
> DOTS signal channel open, heartbeat timeout is the time to wait for a Pong in
> milliseconds."
> 
> So, when making a configuration change, is this specific to the Signal Channel
> between the DOTS Server and DOTS client, or is it specific to each CoAP
> session where potentially there could be multiple sessions for the same
> signal channel?
> 
> Replacement: "The RECOMMENDED values of transmission parameter values
> are ack_timeout (2 seconds), max-retransmit (4), ack-random-factor (1.5)
> and heartbeat-timeout (371 seconds)."
> 
> Replacement: "
> Header: PUT (Code=0.03)
> Original: The PUT request with higher numeric session-id value over-rides the
> DOTS signal channel session configuration data installed by a PUT request
> with a lower numeric session-id value."
> 
> If yes, then do we need to remember #1 through #98 to revert back to them
> if needed - the logical extension of this is remembering all 2^31 entries -
> Replacement:" The PUT request with higher numeric session-id value over-
> rides the DOTS signal channel session configuration data installed by a PUT
> request with a lower numeric session-id value.  The overlapped lower
> DOTS server.  The DOTS server in the error response conveys the minimum
> and maximum attribute values acceptable by the DOTS server. The DOTS
> client can re-try and send the PUT request with updated attribute values
> acceptable to the DOTS server.
> 
>   "ack-random-factor": {"MinValue": 1.0, "MaxValue" : 4.0}  }
> the response if any of the heartbeat-timeout, max-retransmit, target-
> protocol, ack-timeout and ack-random-factor attribute values are not
> client should re-request the maximum and minimum parameters acceptable
> by the DOTS server as described in 5.4.1.  The DOTS client can re-try and send
> 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."
> 
> 
> If a DOTS client wants to re-alter the session configuration with a subsequent
> PUT, should this use the same session-id?
> 
> 
> Unlike the signal GET, it is not possible to get the current configuration unless
> the session-id is known, but the session-id can only be created by a PUT, at
> which point the configuration is already known and can be confirmed by the
> GET.
> 
> As signal-id cannot easily be guessed unless hard coded in the DOTS client, a
> suggestion is that a session-id of -1 allows you to determine the current
> configuration.  As "signal-config" is not an array, it is not be possible to return
> multiple session-ids, but possibly the session-id of the current configuration
> could be returned in the payload response to a session-id of -1.  A new
> paragraph at the end of this section.
> 
> appropriate session-id is returned with the current configuration parameters,
> otherwise -1 is returned for the session-id along with all the default
> configuration parameters."
> 
> 
> 5.6 Heartbeat Mechanism
> -----------------------
> It is possible additional parameters may need to be added to this table - e.g.
> DefaultValue and heartbeat-refresh.
> 
> 
> DOTS server send back any responses - CBOR mapping encoded or just
> encoded as strings?
> 
> Replacement: "All parameters in the payload in the DOTS signal channel
> MUST be mapped to CBOR types as follows and are given an integer key to
> save space.  The recipient of the data MAY reject the information if it is not
> suitably mapped."
> 
> 
> New: "A DOTS agent MUST not use any additional Mapping parameters that
> are not defined in Figure 21."
> 
> 
> It is possible additional parameters may need to be added to this table - e.g.
> DefaultValue and keepalive-refresh.
> 
> 
> 11.1 nttdots
> ------------

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 30 Sep 2017 11:54:37 +0000

Hi Jon,

Thanks for the detailed review. I have uploaded the updated draft to https://github.com/tireddy2/DOTS/ 
Please see inline

> draft-ietf-dots-signal-channel-03

Yes (except for 3.00 (alternate server)). 

> can give a hint as to the failing value.

Agreed, updated draft. 

> response.  What should be returned?

No need to convey rest of the parameter values, other than "lifetime" no other mitigation parameter 
will be modified by the server. 

> supported by the DOTS agents.

Thanks, simplified the above text as follows :

   DOTS agents MUST support GET, PUT, POST, and DELETE CoAP methods.
   The payload included in CoAP responses with 2.xx and 3.xx
   Response Codes MUST be of content type "application/cbor"
   (Section 5.5.1 in [RFC7252]). CoAP responses with 4.xx and 5.xx
   error Response Codes MUST include a diagnostic payload (Section 5.5.2
   in [RFC7252]).  The Diagnostic Payload can contain additional
   information to aid troubleshooting.
> Original: "Messages exchanged between DOTS client and server are

Yes, updated draft. 

> 5.1 Overview (3)

If the DOTS client reboots and does not have a persistent storage then it can use GET request without payload to learn all mitigation requests conveyed by the DOTS client 
to the DOTS server. DOTS server will typically have HA and persistent storage. 

> 5.3.1 Requesting Mitigation

No, overriding means #99 will be replaced with #100. 

> numeric mitigation-id is automatically deleted and no longer available for

Thanks, updated text.

> Question 2

Yes. 

> What about overlapping protocols, but not overlapping target-ips etc?

Protocols can overlap. For example, mitigation-id #99 with "target-ip [1.1.1.1] target-protocol [6,17]" and mitigation-id #100 with "target-ip [1.1.1.2] target-protocol [17]" then 
there is no overlap and both mitigation requests will co-exist.

> Question 3

Merging and maintaining overlapping mitigation scopes increases the complexity of managing conflicting mitigation requests. 

> Question 4

The refresh mitigation request must use the same mitigation id. 

> parameter.  

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

> The DOTS server MAY refuse the refresh request if any of the

PUT can be used to update the mitigation request (https://tools.ietf.org/html/rfc7252#section-5.8.3). If the DOTS server finds the mitigation-id parameter value conveyed in the PUT request in its configuration data then the server MAY update the mitigation request, and a 2.04 (Changed) response is returned to indicate a successful update of the mitigation request.

> Question 5

Allowed. 

> My suggestion is in the "New:" update under Question 4 just above.

Yes, allowed.

> 5.3.2 Withdraw a DOTS Signal

Yes. 

> a decision on a 2.02 response for a non-existent mitigation-id).

The client gets a 2.02 response even if the mitigation-id is not present (as explained in https://tools.ietf.org/html/rfc7252#section-5.8.4). 
I don't see the need to return the mitigation-ids in the response. 

> 5.3.3 Retrieving a DOTS Signal (1)

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). 

> set up/cancel either (a) or (b) above) when polling?

The client simultaneously can use GET with Observe (1) to receive notifications and poll periodically using GET (without including OBSERVE option). 

> Is Observe a MUST with a signal GET?

No.

>  - All examples have this Observe option included in Figure 10

Updated draft to clarify that Observe option is not required for polling. 

> signal-id in 5.4.1).  Thoughts?

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. 

> 5.3.3 Retrieving a DOTS Signal (2)

Agreed, updated draft. 

> 5.3.3 Retrieving a DOTS Signal (3)

The counters are from the start of the initial PUT mitigate request. 

> (with a potential wrap around for long mitigations).

The counter is unsigned integer and it will wrap around; added text to clarify. 

> request continues for the remainder of the lifetime

Yes. 

> request.  This is an optional attribute."

Fixed. 

> 5.3.3 Retrieving a DOTS Signal (4)

Yes.

> lifetime:  The remaining lifetime in seconds of the current mitigation-id

Updated draft. 

> 5.3.4 Efficacy Update from DOTS Client (1)

Yes. 

> this is not the case.

Thanks, updated draft. 
  
> The If-Match Option (Section 5.10.8.1 of

Yes, 5.03 error response code looks appropriate. Updated Section 5.3.4.

> 5.3.4 Efficacy Update from DOTS Client (3)

Yes, it will also refresh the lifetime. 

> refreshed when using a Mitigation Request PUT as per section 5.3.1."

I don't see any harm if efficacy update is also used to refresh the mitigation lifetime, it will be useful in a scenarios where the DDoS attack 
is resulting in high packet loss and latency. 

> 5.4 DOTS Signal Channel Session Configuration

Yes, updated draft. 

> 5.4.1 Discover Acceptable Configuration Parameters (1)

DOTS Signal channel is the current CoAP session (see the definition of signal channel in https://tools.ietf.org/html/draft-ietf-dots-requirements-04). 

> 5.4.1 Discover Acceptable Configuration Parameters (2)

Yes, updated to add current values.

> 5.4.2. Convey DOTS Signal Channel Session Configuration (1)

Updated, instead of heartbeat timeout used heartbeat-interval (91 seconds, derived from MAX_TRANSMIT WAIT counter) and 
introduced missing-heartbeats-allowed (default value set to 3). 

> 5.4.2. Convey DOTS Signal Channel Session Configuration (2)

No.

> (incrementing) session-ids for configuring a CoAP session - am I missing

It is used to handle out-of-order delivery of DOTS Signal Channel Session Configuration messages. 

> 5.4.2. Convey DOTS Signal Channel Session Configuration (3)

Updated draft to use seconds instead of milliseconds.

> 5.4.2. Convey DOTS Signal Channel Session Configuration (4)

Thanks, updated draft. 

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

I don't see why the client would pick unacceptable values after getting the min/max parameters from the DOTS server. 

> 5.4.2. Convey DOTS Signal Channel Session Configuration (5)

No, use a higher-numeric session id in the subsequent PUT request. 

> 5.4.4. Retrieving DOTS Signal Channel Session Configuration

Section 5.4.1 has been updated to return current and acceptable configuration range. 

> 5.6 Heartbeat Mechanism

Added heartbeat-interval (e.g. {"CurrentValue": 90, "MinValue": 60, "MaxValue" : 240}).

> 6 Mapping parameters to CBOR (1)

Yes, added heartbeat-interval, missing-heartbeats-allowed and CurrentValue for DOTS signal channel configuration. 

> 6 Mapping parameters to CBOR (2)

Yes. 

> save space.  The recipient of the data MAY reject the information if it is not

Updated draft. 

> 6 Mapping parameters to CBOR (3)

No, vendors can add vendor-specific parameters (The key values in the range of 32768 to 65536 are assigned for Vendor-Specific parameters). DOTS agents can safely ignore Vendor-Specific parameters
they don't understand.

> 10.2.2 Initial Registry Contents

Yes, updated section. 

Cheers,
-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Sat, 30 Sep 2017 13:54:12 +0100

Hi Tiru,

I will look at the updated draft later.  However, in response to some of
your comments

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

> 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.

> 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.

Regards

Jon