Subject: Re: [Dots] Coding and Interoperability Challenges

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 2 Oct 2017 11:59:05 +0000

Thanks Jon for the comments, Please see inline [TR] for response.
I have posted updated DOTS signal and data channel drafts to https://github.com/tireddy2/DOTS

From: Jon Shallow [mailto:[email-masked]]
Sent: 30 September 2017 21:45
To: 'Konda, Tirumaleswar Reddy'; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] Coding and Interoperability Challenges

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?

[TR] No, removed POST from the above line. Thanks.

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

[TR] Looks good, updated draft.

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

[TR] Fixed.

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

[TR] GET request/response used to retrieve the status of the mitigation request are marked as non-confirmable messages, the DOTS server does not know if the DOTS client had successfully received response to the last status request.

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?

[TR] Yes, mitigation start time will be useful to the DOTS client; updated draft.

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

[TR] Thanks, updated the first paragraph in Section 5.3.3.1 as follows:

   The DOTS client can send the GET request at frequent intervals
   without the Observe option to retrieve the configuration data of the
   mitigation request and non-configuration data (i.e., the attack
   status).  The frequency of polling the DOTS server to get the
   mitigation status should follow the transmission guidelines given in
   Section 3.1.3 of [RFC8085].  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 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.

[TR] Fixed.

5.3.1.  Requesting mitigation
=============================

>From a previous email dialogue

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

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.

[TR] The first version with mitigation-id and lifetime, updated draft.

5.3.2.  Withdraw a DOTS Signal
==============================

>From a previous email dialogue

>> What body responses do we send back for a DELETE?

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

[TR] Agreed, updated draft.

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

[TR] Discovery introduces additional overhead of request/response during an DDoS attacks, well-known URI are used by many protocols (see EST https://tools.ietf.org/html/rfc7030 for example).

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

[TR] Thanks, updated section.

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.

[TR] Yup, fixed.

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.

[TR] Yes, updated draft to address all above comments.

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

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 3 Oct 2017 15:20:40 +0100

Hi Tiru,

Several things

1) Missing target-prefix CBOR mapping in signal spec

2) mitigation-start representation in signal spec

It does not appear in Fig 10.

It is defined as being in seconds
"   mitigation-start:  Mitigation start time is represented in seconds
      relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of
      [RFC7049])."
But as a float representation
| CurrentValue       | 29                     | 0                        |
| mitigation-start   | 30                     | 7 (floating-point)       |
\--------------------+------------------------+--------------------------/
Which is OK.  A CBOR tag of 1 followed by a value of a floating point
number.  However, there is no direct JSON equivalent of this that I can
find.

So, should it be displayed (in JSON) as UTC, local timezone or simply
seconds?

Mitigation-start: 2017-10-03T10:15:30-05:00
Or
Mitigation-start: 2017-10-03T15:15:30Z
Or 
Mitigation-start: 1507040181.567890

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 6 Oct 2017 05:18:44 +0000

> -----Original Message-----
> Sent: Tuesday, October 3, 2017 7:51 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> [email-masked]

Thanks, will fix in the next revision. 

> Which is OK.  A CBOR tag of 1 followed by a value of a floating point number.
> However, there is no direct JSON equivalent of this that I can find.
> 
> So, should it be displayed (in JSON) as UTC, local timezone or simply seconds?
> 
> Mitigation-start: 2017-10-03T10:15:30-05:00 Or

Mitigation-start: 1507040181.567890 (represented in JSON number format). 

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 6 Oct 2017 20:48:06 +0100

Hi Tiru

seconds?
>> Mitigation-start: 2017-10-03T15:15:30Z Or

> -Tiru

If you could add this " Mitigation-start: 1507040181.567890" into the spec
as part of Fig 10, this would be great.

However Tagged CBOR -> JSON is fine, but JSON -> CBOR will not create the
tagged entry in CBOR.

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 7 Oct 2017 03:07:53 +0000

> Sent: Saturday, October 7, 2017 1:18 AM
> If you could add this " Mitigation-start: 1507040181.567890" into the spec as
> part of Fig 10, this would be great.
> 

Good point, we can follow the approach taken by https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08 for NumericDate to address this problem.

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Sat, 7 Oct 2017 09:48:47 +0100

Hi Tiru,

https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08

   NumericDate
      The "NumericDate" term has the same meaning, syntax, and
      processing rules as the "NumericDate" term defined in Section 2 of
      JWT [RFC7519], except that the CBOR numeric date representation
      (from Section 2.4.1 of [RFC7049]) is used.  The encoding is
      modified so that the leading tag 1 (epoch-based date/time) MUST be
      omitted.

Omitting the leading tag 1 then means that we actually are defining it as a
float8 in the CBOR stream.  Any reason as to why we cannot just define it as
a float8 and state in the definition that is the number of seconds since 1
Jan 1970 UTC?

Or, we state that the leading tag 1 is omitted in the CBOR representation.

Regards

Jon

-----Original Message-----
From: Konda, Tirumaleswar Reddy [mailto: [email-masked]]

Sent: 07 October 2017 04:08
To: Jon Shallow; [email-masked]
Subject: RE: [Dots] Coding and Interoperability Challenges

> If you could add this " Mitigation-start: 1507040181.567890" into the 
> spec as part of Fig 10, this would be great.
> 
> However Tagged CBOR -> JSON is fine, but JSON -> CBOR will not create 
> the tagged entry in CBOR.

Good point, we can follow the approach taken by
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08 for NumericDate
to address this problem.

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 9 Oct 2017 13:15:19 +0000

> From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
> Sent: Saturday, October 7, 2017 2:19 PM
> Subject: Re: [Dots] Coding and Interoperability Challenges
> 
> Hi Tiru,
> 
> float8 in the CBOR stream.  Any reason as to why we cannot just define it as a
> float8 and state in the definition that is the number of seconds since 1 Jan
> 1970 UTC?
> 

Both options work for me, we can follow the approach taken by draft-ietf-ace-cbor-web-token (i.e. omit leading tag 1).

-Tiru

> https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08 for
> NumericDate to address this problem.
> 
> -Tiru
> 
> >
> > Regards
> >
> > Jon
> 
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots