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

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 2 Jan 2018 10:47:17 +0000

Please see inline 

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
> Sent: Friday, December 29, 2017 4:45 PM
> To: kaname nishizuka <[email-masked]>; [email-masked]
> Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with
> the DOTS spec
> 
> 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.
> 
> 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?
> 
> [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.

Yes, will update draft to use Query option for GET method. 

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

Agreed. 

> [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?

PUT can also be used to create a new resource, and the draft uses PUT instead of POST because it is  idempotent and during a volumetric DDoS attack saturating the incoming link to the DOTS client, DOTS client will most likely not 
receive the server-side responses. Is this an implementation bug ?

-Tiru

> 
> 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.
> 
> [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.
> 
> * 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
> 
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 2 Jan 2018 11:20:18 -0000

Hi all,

Please see inline [Jon2].

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 02 January 2018 10:47
To: Jon Shallow; kaname nishizuka; [email-masked]
Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with
the DOTS spec

Please see inline 

> Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have 
> problems with the DOTS spec
> 
> Hi all,
> 
> After thinking about this, I have added some additional comments 
> inline [Jon1].
> 
> Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have 
> problems with the DOTS spec
> 
> Hi Kaname,
> 
> See inline [Jon].
> 
> Regards
> 
> Jon
> 
> 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.
> 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.
> [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.
> [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.

Yes, will update draft to use Query option for GET method. 
[Jon2] This works for me, but does not feel right when this is extended for
"PUT .../mitigate Query mitigation-id-2" to create the mitigation-id.  I
think that the complete "resource" should be specified for consistency and
just leave the c=? as being the required valid Query option.

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

Agreed. 
[Jon2] then something similar to the above specifying ordering needs to be
put into the draft.

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

PUT can also be used to create a new resource, and the draft uses PUT
instead of POST because it is  idempotent and during a volumetric DDoS
attack saturating the incoming link to the DOTS client, DOTS client will
most likely not receive the server-side responses. Is this an implementation
bug ?

[Jon2] I agree that it is a bug in the libcoap I am using
[https://github.com/obgm/libcoap].  RFC7252 5.8.3. PUT states "The PUT
method requests that the resource identified by the request URI be updated
or created".  I can try to fix the library to keep on stripping off the last
UriPath and then doing a hash lookup on the sub path until a match is found
in the case of doing a PUT.  It would then (in my case - not needed in the
draft) be the responsibility of creating a new resource if needed in the
DOTS layer.

-Tiru

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 2 Jan 2018 11:29:03 +0000

Hi Jon,

Please see inline

> From: Jon Shallow [mailto:[email-masked]]
> Sent: Tuesday, January 2, 2018 4:50 PM
> To: Konda, Tirumaleswar Reddy
> <[email-masked]>; [email-masked]; kaname
> nishizuka <[email-masked]>
> Subject: RE: [Dots] [signal-channel-draft] CoAP libraries have problems with
> the DOTS spec
> 
> Hi all,
> 
> From: Dots [mailto: [email-masked]] On Behalf Of Konda,
> Tirumaleswar Reddy
> "PUT .../mitigate Query mitigation-id-2" to create the mitigation-id.  I think
> that the complete "resource" should be specified for consistency and just
> leave the c=? as being the required valid Query option.

PUT method does not need to convey the Query Option (for example please see https://tools.ietf.org/html/rfc7967#section-4.1.1, the resource is specified in the URI-path option itself).

> [Jon2] then something similar to the above specifying ordering needs to be

Yes. 

> attack saturating the incoming link to the DOTS client, DOTS client will most
> likely not receive the server-side responses. Is this an implementation bug ?
> 
> or created".  I can try to fix the library to keep on stripping off the last UriPath
> and then doing a hash lookup on the sub path until a match is found in the
> case of doing a PUT.  It would then (in my case - not needed in the
> draft) be the responsibility of creating a new resource if needed in the DOTS
> layer.

Thanks.

Cheers,
Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 2 Jan 2018 11:43:13 -0000

Hi all,

See inline [Jon3]

I've striped out a lot of .. "See inline" ..

Regards

Jon

> > 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.
> > [Jon] So it looks like the target resource should only be in 
> > Uri-Path and/or Uri-Query.
> > the resource is known or not), so, when say mitigation-id=2 is 
> > added, I need to register the resource
> [Jon2] This works for me, but does not feel right when this is 
> extended for "PUT .../mitigate Query mitigation-id-2" to create the 
> mitigation-id.  I think that the complete "resource" should be 
> specified for consistency and just leave the c=? as being the required
valid Query option.

PUT method does not need to convey the Query Option (for example please see
https://tools.ietf.org/html/rfc7967#section-4.1.1, the resource is specified
in the URI-path option itself).

[Jon3]  Agreed - and think that the full resource needs to be specified for
the DELETE (need to fix my libcoap library to not respond with 4.04 if
resource does not exist as per RFC7252) as well that the GET.  However, "GET
.../mitigate" should return all current mitigations if the mitigation-id is
not specified in the Uri-Path..

[Jon3] The same is for configuration (GET, PUT & DELETE) - which then begs
the question - do we really need "session-id" ?

> 
> >
> > [Jon1] I am now leaning towards doing it in the Uri-Path but still 
> > not
> sure.
> [Jon2] then something similar to the above specifying ordering needs 
> to be put into the draft.

Yes. 

> 
> > [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
> attack saturating the incoming link to the DOTS client, DOTS client 
> will most likely not receive the server-side responses. Is this an
implementation bug ?
> method requests that the resource identified by the request URI be 
> updated or created".  I can try to fix the library to keep on 
> stripping off the last UriPath and then doing a hash lookup on the sub 
> path until a match is found in the case of doing a PUT.  It would then 
> (in my case - not needed in the
> draft) be the responsibility of creating a new resource if needed in 
> the DOTS layer.

Thanks.

Cheers,
Tiru

> > [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.
> >                                  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.
> > (which could be to update things, or to send a RST if no more 
> > packets with the same Token should be sent.
> >
> >
> > 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.
> >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 2 Jan 2018 13:29:20 +0000

Hi Jon,

Please see inline

> Sent: Tuesday, January 2, 2018 5:13 PM
> PUT method does not need to convey the Query Option (for example please
> see https://tools.ietf.org/html/rfc7967#section-4.1.1, the resource is
> specified in the URI-path option itself).
> 
> [Jon3]  Agreed - and think that the full resource needs to be specified for the
> DELETE (need to fix my libcoap library to not respond with 4.04 if resource
> does not exist as per RFC7252) as well that the GET.  However,
> "GET .../mitigate" should return all current mitigations if the mitigation-id is

Yes. 

> the question - do we really need "session-id" ?

session-id is introduced to handle out-of-order delivery of PUT requests, the PUT
request with a higher numeric 'session-id' value overrides the DOTS
signal channel session configuration data installed by a PUT request
with a lower numeric 'session-id' value.

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 2 Jan 2018 14:05:50 -0000

Hi Tiru,

See inline [Jon4]

Regards

Jon

> > > Subject: [Dots] [signal-channel-draft] CoAP libraries have 
> > > Most of CoAP libraries only support request URI in CoAP 
> > > GET/observe, which is the spec from RFC7252.
> > > [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
> PUT method does not need to convey the Query Option (for example 
> please see https://tools.ietf.org/html/rfc7967#section-4.1.1, the 
> resource is specified in the URI-path option itself).
> 
> [Jon3]  Agreed - and think that the full resource needs to be 
> specified for the DELETE (need to fix my libcoap library to not 
> respond with 4.04 if resource does not exist as per RFC7252) as well 
> that the GET.  However, "GET .../mitigate" should return all current 
> mitigations if the mitigation-id is not specified in the Uri-Path..

Yes. 

[Jon4] mitigation-id needs to be included as a parameter in the body in
response to "GET .../mitigate".  I assume for consistency, it should also be
returned as a parameter for "GET .../mitigate/mitigation-id=ZZ".
[Jon4] So when doing "PUT .../mitigate/mitigation-id=ZZ", do we also include
in the PUT data body the parameter mitigation-id = ZZ?  What happens if they
are different?

> 
> [Jon3] The same is for configuration (GET, PUT & DELETE) - which then 
> begs the question - do we really need "session-id" ?

session-id is introduced to handle out-of-order delivery of PUT requests,
the PUT request with a higher numeric 'session-id' value overrides the DOTS
signal channel session configuration data installed by a PUT request with a
lower numeric 'session-id' value.

[Jon4] Understood.  And the lesser session-id resource would be no more
(i.e. the resource is deleted).
[Jon4] As this signal configuration is only defining a specific session
(there may be multiple sessions) between 2 DOTS peers, "client-identifier"
(or "request-nonce") are not really needed to be supported as a part of the
resource.
[Jon4] We need a "GET .../config" to get the server sides (initial) notion
of what is supported for configuration.  We would then support "GET
.../config/session-id=YY" (only can be done following a PUT otherwise
session-id is unknown).  The PUT would definitely have to be "PUT
../config/session-id-YY".  The DELETE would be either "DELETE .../config" or
"DELETE .../config/session-id=YY" where both of them reset the signal
configuration back to the defaults.  "DELETE .../config" would get rid of
any session-ids for that particular session.

-Tiru

> > > 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?
> >
> > PUT can also be used to create a new resource, and the draft uses 
> > PUT instead of POST because it is  idempotent and during a 
> > volumetric DDoS attack saturating the incoming link to the DOTS 
> > client, DOTS client will most likely not receive the server-side 
> > responses. Is this an
> implementation bug ?
> >
> > [https://github.com/obgm/libcoap].  RFC7252 5.8.3. PUT states "The 
> > PUT method requests that the resource identified by the request URI 
> > be updated or created".  I can try to fix the library to keep on 
> > stripping off the last UriPath and then doing a hash lookup on the 
> > sub path until a match is found in the case of doing a PUT.  It 
> > would then (in my case - not needed in the
> > > A CoAP library (dustin/go-coap) stops listening right after 
> > > sending out the NonConfirmable message because NonConfirmable 
> > > messages do
> > not
> > > be thought of as a one way signal.  There are times that the 
> > > client has to run "blind" during attack scenarios.
> > > large scale attack could swamp a DOTS server with all the yet to 
> > > be confirmed confirmable
> > responses.
> > > responsibility of the DOTS layer to associate the Tokens together 
> > > to handle the responses with
> > the requests.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 2 Jan 2018 15:10:13 +0000

> Sent: Tuesday, January 2, 2018 7:36 PM

Yes. 

> in the PUT data body the parameter mitigation-id = ZZ?  What happens if
> they are different?

I don't see the need to convey "mitigation-id=ZZ" in the PUT body if it is conveyed in the Uri-Path. 

> session-id is introduced to handle out-of-order delivery of PUT requests, the
> PUT request with a higher numeric 'session-id' value overrides the DOTS
> [Jon4] As this signal configuration is only defining a specific session (there
> may be multiple sessions) between 2 DOTS peers, "client-identifier"

Yes. 

> [Jon4] We need a "GET .../config" to get the server sides (initial) notion of
> what is supported for configuration.  We would then support
> "GET .../config/session-id=YY" (only can be done following a PUT otherwise
> session-id is unknown).  The PUT would definitely have to be
> "PUT ../config/session-id-YY".  The DELETE would be either
> "DELETE .../config" or "DELETE .../config/session-id=YY" where both of them
> reset the signal configuration back to the defaults.  "DELETE .../config" would
> get rid of any session-ids for that particular session.

Agreed.

-Tiru

> > > >    is sent using a new Non-confirmable message, although the
> > > > server
> may

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 2 Jan 2018 15:50:00 -0000

Hi Tiru,

Thanks - I think we are good to go with this one.  Thanks Kaname for
pointing this issue out.

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 02 January 2018 15:10
To: Jon Shallow; [email-masked]; kaname nishizuka
Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with
the DOTS spec

> <[email-masked]>; [email-masked]; kaname nishizuka 
> <[email-masked]>
> Subject: RE: [Dots] [signal-channel-draft] CoAP libraries have 
> > > > [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.
> > > >    currently corresponds to the resource identified by the 
> > > > request
> URI.
> > > extended for "PUT .../mitigate Query mitigation-id-2" to create 
> > > the mitigation-id.  I think that the complete "resource" should be 
> [Jon4] mitigation-id needs to be included as a parameter in the body 
> in response to "GET .../mitigate".  I assume for consistency, it 
> should also be returned as a parameter for "GET
.../mitigate/mitigation-id=ZZ".

Yes. 

> [Jon4] So when doing "PUT .../mitigate/mitigation-id=ZZ", do we also 
> include in the PUT data body the parameter mitigation-id = ZZ?  What 
> happens if they are different?

I don't see the need to convey "mitigation-id=ZZ" in the PUT body if it is
conveyed in the Uri-Path. 

> 
> >
> > [Jon3] The same is for configuration (GET, PUT & DELETE) - which 
> > then begs the question - do we really need "session-id" ?
> 
> session-id is introduced to handle out-of-order delivery of PUT 
> requests, the PUT request with a higher numeric 'session-id' value 
> overrides the DOTS signal channel session configuration data installed 
> by a PUT request with a lower numeric 'session-id' value.
> 
> [Jon4] Understood.  And the lesser session-id resource would be no 
> more (i.e. the resource is deleted).
> [Jon4] As this signal configuration is only defining a specific 
> session (there may be multiple sessions) between 2 DOTS peers,
"client-identifier"
> (or "request-nonce") are not really needed to be supported as a part 
> of the resource.

Yes. 

> [Jon4] We need a "GET .../config" to get the server sides (initial) 
> notion of what is supported for configuration.  We would then support 
> "GET .../config/session-id=YY" (only can be done following a PUT 
> otherwise session-id is unknown).  The PUT would definitely have to be 
> "PUT ../config/session-id-YY".  The DELETE would be either "DELETE 
> .../config" or "DELETE .../config/session-id=YY" where both of them 
> reset the signal configuration back to the defaults.  "DELETE 
> .../config" would get rid of any session-ids for that particular session.

Agreed.

-Tiru

> 
> -Tiru
> 
> >
> > >
> > > >
> > > > [Jon1] I am now leaning towards doing it in the Uri-Path but 
> > > > still not
> > > sure.
> > > > client-identifier (or request-none etc. if that is accepted) 
> > > > then mitigation-id, so that resources are built consistently 
> > > > from a mitigation
> > > request.
> > >
> > > Agreed.
> > > [Jon2] then something similar to the above specifying ordering 
> > > needs to be put into the draft.
> >
> > Yes.
> >
> > >
> > > > 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?
> > >
> > > PUT method requests that the resource identified by the request 
> > > URI be updated or created".  I can try to fix the library to keep 
> > > on stripping off the last UriPath and then doing a hash lookup on 
> > > the sub path until a match is found in the case of doing a PUT.  
> > > It would then (in my case - not needed in the
> > > draft) be the responsibility of creating a new resource if needed 
> > > in the DOTS layer.
> >
> > Thanks.
> >
> > Cheers,
> > Tiru
> >
> > >
> > > -Tiru
> > >
> > > >
> > > > requests are non-confirmable.  Certainly "PUT mitigation" needs 
> > > > to be thought of as a one way signal.  There are times that the 
> > > > 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.
> > > >                                  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.
> > > > 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.
> > > >
> > > >
> > > > 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:

---

From: kaname nishizuka <[email-masked]>
Date: Thu, 4 Jan 2018 10:56:30 +0900

Hi Jon, Tiru,

Sorry for late reply. I was out for the New Year Holidays.
I've read all of the replies and I think we are going to a right direction.

thanks,
Kaname