Subject: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec

From: kaname nishizuka <[email-masked]>
Date: Thu, 28 Dec 2017 19:01:53 +0900

Hi,

Last week, Jon and I did the second interoperability test based on the -13 version of the signal channel draft.
We made significant improvements of each implementation. Several feedbacks to the WG have been made by Jon already.

Based on the experience, I encountered the problems between CoAP libraries and the specification of the DOTS.

1. resource identification of GET methods.

In signal channel spec, the target resource in GET method is identified in the BODY of the message, that is mitigation-id (and client-identifier).
However, CoAP libraries, at least we investigated, only see the Request URI, so it cannot locate the resource because it doesn't see the BODY.

So the question is, why does the DOTS spec use CoAP Body for resource identifier?

Most of CoAP libraries only support request URI in CoAP GET/observe, which is the spec from RFC7252.
https://tools.ietf.org/html/rfc7252
5.8.1.GET
   The GET method retrieves a representation for the information that
   currently corresponds to the resource identified by the request URI.

2. Confirmable vs NonConfirmable at Mitigation Request

A CoAP library (dustin/go-coap) stops listening right after sending out the NonConfirmable message because NonConfirmable messages do not require acknowledgements.
The spec of Confirmable message already have the retransmission mechanism, so using Confirmable message is an easier way to notice that the message has been lost during the attack time.
I'm afraid I'm missing some previous discussions we made on the ML and at the WG meeting, but we have a problem with the CoAP library regarding this spec.

* At the -08 version of the signal channel draft, this change was made:
DOTS mitigation request/response are marked as non-confirmable messages.

thank you,
Kaname

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 28 Dec 2017 21:01:01 -0000

Hi Kaname,

See inline [Jon].

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of kaname nishizuka
Sent: 28 December 2017 10:02
To: [email-masked]
Subject: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec

Hi,

[Jon] A very good question.  I had just assumed that this was the way to do it, but had noted that this was not done when using HTTP etc. and so was different. See later comments

Most of CoAP libraries only support request URI in CoAP GET/observe, which is the spec from RFC7252.
https://tools.ietf.org/html/rfc7252
5.8.1.GET
   The GET method retrieves a representation for the information that
   currently corresponds to the resource identified by the request URI.
[Jon] RFC 7252 states also
5.10.1.  Uri-Host, Uri-Port, Uri-Path, and Uri-Query

   The Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options are used to
   specify the target resource of a request to a CoAP origin server.
[Jon] So it looks like the target resource should only be in Uri-Path and/or Uri-Query. 
[Jon] In my CoAP Library, I have to define each individual resource (it does a lookup against a hash of the complete Uri to find whether the resource is known or not), so, when say mitigation-id=2 is added, I need to register the resource .well-known/dots/v1/mitigate/migration-is=2 with an associated handler.  This is not difficult to do, but potentially could consume a lot of DOTS server resources if many mitigations are active.
[Jon] Doing it as a Query Option I think is my preference - Comments?
[Jon] The same is true for GET signal configuration as well.

[Jon] As there is a good chance during attack scenarios that responses may not be able to get back, it makes sense to me that these "GET mitigation" requests are non-confirmable.  Certainly "PUT mitigation" needs to be thought of as a one way signal.  There are times that the client has to run "blind" during attack scenarios.
[Jon]If they were confirmable, then the request will get sent multiple times to the DOTS server - which could be handled by the server, but then the confirmable responses would retried whilst sending back to the DOTS client and eventually retry timeout.  A large scale attack could swamp a DOTS server with all the yet to be confirmed confirmable responses.
[Jon] As per RFC7252 "2.2. Request/Response Model", a response to a non-confirmable request is expected to be handled as in:-
   If a request is sent in a Non-confirmable message, then the response
   is sent using a new Non-confirmable message, although the server may
   instead send a Confirmable message.  This type of exchange is
   illustrated in Figure 6.

                        Client              Server
                           |                  |
                           |   NON [0x7a11]   |
                           | GET /temperature |
                           |   (Token 0x74)   |
                           +----------------->|
                           |                  |
                           |   NON [0x23bc]   |
                           |   2.05 Content   |
                           |   (Token 0x74)   |
                           |     "22.5 C"     |
                           |<-----------------+
                           |                  |

       Figure 6: A Request and a Response Carried in Non-confirmable
                                 Messages
[Jon] So I would expect any CoAP library to support this non-confirmation mechanism by receiving a new non-confirmable message.  It would be the responsibility of the DOTS layer to associate the Tokens together to handle the responses with the requests.
[Jon] In addition, when Observe is enabled, the DOTS server will continue to generate non-confirmable messages with the same Token.  Again, the DOTS client will need to know what to do with the Token (which could be to update things, or to send a RST if no more packets with the same Token should be sent.

[Jon] The DOTS client will know something is wrong as it will be seeing heartbeat issues.

thank you,
Kaname

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

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 29 Dec 2017 11:15:07 -0000

Hi all,

After thinking about this, I have added some additional comments inline
[Jon1].

This response is applicable to more than just Kaname.

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Jon Shallow
Sent: 28 December 2017 21:01
To: 'kaname nishizuka'; [email-masked]
Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with
the DOTS spec

Hi Kaname,

See inline [Jon].

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of kaname nishizuka
Sent: 28 December 2017 10:02
To: [email-masked]
Subject: [Dots] [signal-channel-draft] CoAP libraries have problems with the
DOTS spec

Hi,

Last week, Jon and I did the second interoperability test based on the -13
version of the signal channel draft.
We made significant improvements of each implementation. Several feedbacks
to the WG have been made by Jon already.

Based on the experience, I encountered the problems between CoAP libraries
and the specification of the DOTS.

In signal channel spec, the target resource in GET method is identified in
the BODY of the message, that is mitigation-id (and client-identifier).
However, CoAP libraries, at least we investigated, only see the Request URI,
so it cannot locate the resource because it doesn't see the BODY.

So the question is, why does the DOTS spec use CoAP Body for resource
identifier?

[Jon] A very good question.  I had just assumed that this was the way to do
it, but had noted that this was not done when using HTTP etc. and so was
different. See later comments

Most of CoAP libraries only support request URI in CoAP GET/observe, which
is the spec from RFC7252.
https://tools.ietf.org/html/rfc7252
5.8.1.GET
   The GET method retrieves a representation for the information that
   currently corresponds to the resource identified by the request URI.
[Jon] RFC 7252 states also
5.10.1.  Uri-Host, Uri-Port, Uri-Path, and Uri-Query

   The Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options are used to
   specify the target resource of a request to a CoAP origin server.
[Jon] So it looks like the target resource should only be in Uri-Path and/or
Uri-Query. 
[Jon] In my CoAP Library, I have to define each individual resource (it does
a lookup against a hash of the complete Uri to find whether the resource is
known or not), so, when say mitigation-id=2 is added, I need to register the
resource .well-known/dots/v1/mitigate/migration-is=2 with an associated
handler.  This is not difficult to do, but potentially could consume a lot
of DOTS server resources if many mitigations are active.
[Jon] Doing it as a Query Option I think is my preference - Comments?
[Jon] The same is true for GET signal configuration as well.

[Jon1] I am now leaning towards doing it in the Uri-Path but still not sure.
The CoAP layer responds with a 4.04 with my CoAP library if the resource
(Uri-Path) is unknown.
[Jon1] We need to define the order in the path - e.g. client-identifier (or
request-none etc. if that is accepted) then mitigation-id, so that resources
are built consistently from a mitigation request.
[Jon1] However doing this means we also need to include PUT and DELETE with
the resource specified in the Uri-Path.  My library then runs into a chicken
and egg situation with PUT - the PUT is defining the new resource, but as
the resource is not defined (yet) in the CoAP layer, it gets rejected with a
4.04 in the CoAP layer (as mentioned above).  The way around this is to use
POST to create new mitigation requests (and will respond with appropriate
Location-Path to give the new UI) and PUT if we are refreshing the resource.

[Jon1] Thoughts?

A CoAP library (dustin/go-coap) stops listening right after sending out the
NonConfirmable message because NonConfirmable messages do not require
acknowledgements.

[Jon] As there is a good chance during attack scenarios that responses may
not be able to get back, it makes sense to me that these "GET mitigation"
requests are non-confirmable.  Certainly "PUT mitigation" needs to be
thought of as a one way signal.  There are times that the client has to run
"blind" during attack scenarios.
[Jon]If they were confirmable, then the request will get sent multiple times
to the DOTS server - which could be handled by the server, but then the
confirmable responses would retried whilst sending back to the DOTS client
and eventually retry timeout.  A large scale attack could swamp a DOTS
server with all the yet to be confirmed confirmable responses.
[Jon] As per RFC7252 "2.2. Request/Response Model", a response to a
non-confirmable request is expected to be handled as in:-
   If a request is sent in a Non-confirmable message, then the response
   is sent using a new Non-confirmable message, although the server may
   instead send a Confirmable message.  This type of exchange is
   illustrated in Figure 6.

                        Client              Server
                           |                  |
                           |   NON [0x7a11]   |
                           | GET /temperature |
                           |   (Token 0x74)   |
                           +----------------->|
                           |                  |
                           |   NON [0x23bc]   |
                           |   2.05 Content   |
                           |   (Token 0x74)   |
                           |     "22.5 C"     |
                           |<-----------------+
                           |                  |

       Figure 6: A Request and a Response Carried in Non-confirmable
                                 Messages [Jon] So I would expect any CoAP
library to support this non-confirmation mechanism by receiving a new
non-confirmable message.  It would be the responsibility of the DOTS layer
to associate the Tokens together to handle the responses with the requests.
[Jon] In addition, when Observe is enabled, the DOTS server will continue to
generate non-confirmable messages with the same Token.  Again, the DOTS
client will need to know what to do with the Token (which could be to update
things, or to send a RST if no more packets with the same Token should be
sent.

The spec of Confirmable message already have the retransmission mechanism,
so using Confirmable message is an easier way to notice that the message has
been lost during the attack time.

[Jon] The DOTS client will know something is wrong as it will be seeing
heartbeat issues.

I'm afraid I'm missing some previous discussions we made on the ML and at
the WG meeting, but we have a problem with the CoAP library regarding this
spec.

thank you,
Kaname