Subject: [core] Conflict endpoint idenfier for resource directory draft

From: Likepeng <[email-masked]>
Date: Mon, 20 Oct 2014 09:21:19 +0000

Hello Zach and all,

I have one suggestion to the resource directory draft:
https://tools.ietf.org/html/draft-ietf-core-resource-directory-01

Section 3.2:

      ep :=   Endpoint (mandatory).  The endpoint identifier or name of

         the registering node, unique within that domain.  The maximum

         length of this parameter is 63 bytes.

If an Endpoint registered itself to Resource Directory Server with a conflicted ID, RD Server should return an error code to ask the endpoint to choose another identifier.

Maybe we can add an error code to indicate the registered endpoint ID is conflict. Something like this:

Failure:  5.0X  "Endpoint Identifier Conflict".  Endpoint identifier is conflict.

Thanks,

Kind Regards
Kepeng

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 Oct 2014 11:33:22 +0200

Hi Kepeng,

> Failure:  5.0X  "Endpoint Identifier Conflict".  Endpoint identifier is conflict.

Since this is not a server error, but a client error, this should be a 4.xx.

HTTP has 409, Conflict.

RFC 7231:

6.5.8.  409 Conflict

   The 409 (Conflict) status code indicates that the request could not
   be completed due to a conflict with the current state of the target
   resource.  This code is used in situations where the user might be
   able to resolve the conflict and resubmit the request.  The server
   SHOULD generate a payload that includes enough information for a user
   to recognize the source of the conflict. […]

Should we aim at assigning 4.09?
And what would be a good error payload?
(cf. draft-ietf-appsawg-http-problem-00.txt)

Grüße, Carsten

---

From: Likepeng <[email-masked]>
Date: Mon, 20 Oct 2014 09:36:06 +0000

Hi Carsten,

>Should we aim at assigning 4.09?

Agree.

>And what would be a good error payload?

Maybe the RD Server can give back a recommended identifier.

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Carsten Bormann [mailto:[email-masked]]
> 发送时间: 2014年10月20日 17:33
> 收件人: Likepeng
> 抄送: [email-masked]
> 主题: Re: [core] Conflict endpoint idenfier for resource directory draft
> 
> Hi Kepeng,
>

---

From: Oliver Kleine <[email-masked]>
Date: Mon, 20 Oct 2014 14:09:02 +0200

Hi Carsten,

Kepeng and I already had a short discussion on the "level of uniqueness"
for endpoint identifiers, i.e. unique per resource directory or global.

> Maybe the RD Server can give back a recommended identifier.

I think, that is a good approach to ensure unique identifiers per
resource directory. Furthermore, I think, such an ID can be reused to
replace the "additional address information" for request/response
matching according to Section 5.3 of the CoAP RFC.

I will update my draft on endpoint identification accordingly.

Best,
Oliver

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

-- 

Oliver Kleine, M.Sc.

UNIVERSITÄT ZU LÜBECK
    INSTITUT FÜR TELEMATIK

    Ratzeburger Allee 160
    23538 Lübeck

    Tel +49 451 500 5396
    Fax +49 451 500 5382
    [email-masked]

    www.itm.uni-luebeck.de/people/kleine

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 21 Oct 2014 13:38:53 +0000

> If an Endpoint registered itself to Resource Directory Server
> with a conflicted ID, RD Server should return an error code to
>  ask the endpoint to choose another identifier.

My question here is: How should the RD know that this is a conflict?
The point of using this ID is to identify the same endpoint over changing addresses or even transports (e.g., UDP and SMS).

The natural reaction would be to assume the endpoint crashed and is now registering after a reboot. As Zach mentioned in the other thread, this ID is somehow linked to the endpoint certificate. So the assumption is that there is another entity that ensures uniqueness.

> And what would be a good error payload?

Considering 4.09 is used in the OMA Lightweight M2M specification, we probably should define it. At least there is a use case out there, given that we can figure out how to know that something is a conflict :)

Ciao
Matthias

---

From: Oliver Kleine <[email-masked]>
Date: Tue, 21 Oct 2014 16:09:27 +0200

>> If an Endpoint registered itself to Resource Directory Server with
>> a conflicted ID, RD Server should return an error code to ask the
>> endpoint to choose another identifier.
> 
> The point of using this ID is to identify the same endpoint over
> changing addresses or even transports (e.g., UDP and SMS).

It is my understanding of the RD draft that there is no need for global
uniqueness of IDs but only uniqueness per RD. Thus, it is easy for an RD
to determine if the ID in an inbound registration request is already in
use with another server.

> The natural reaction would be to assume the endpoint crashed and is
> now registering after a reboot. As Zach mentioned in the other
> thread, this ID is somehow linked to the endpoint certificate. So the
> assumption is that there is another entity that ensures uniqueness.

Is it really a good idea to more or less "bind" the ID to some kind of
certificate? Wouldn't that exclude servers without certificates from
registration at an RD?

Wouldn't it instead be possible for a server to autonomously choose a
(maybe even random) ID to register at the RD? If that ID is already in
use on the RD the registration request is answered with a 4.09 and a
proposal for another ID which is not yet in use.

Best,
Oliver
-- 

Oliver Kleine, M.Sc.

UNIVERSITÄT ZU LÜBECK
    INSTITUT FÜR TELEMATIK

    Ratzeburger Allee 160
    23538 Lübeck

    Tel +49 451 500 5396
    Fax +49 451 500 5382

---

From: Zach Shelby <[email-masked]>
Date: Tue, 21 Oct 2014 08:28:56 -0700

Hi Matthias,

Thanks for picking this up, you are correct. The Endpoint Name is required to be unique per RD, however it is used to update the Context (protocol, IP, port) of the endpoint. Thus the RD is not able to determine if this is a conflicting endpoint or the same endpoint with a new IP address when using plain CoAP or HTTP.

However, we do recommend the use of DTLS or TLS with an RD and there is always a binding between the endpoint name and the security credential (whether it is a PSK, RPK or Certificate). Trying to register as an endpoint name without the matching credentials would result in a failed authentication rather than a duplicate RD. Uniqueness of endpoint names goes hand-in-hand with security management in practice.

Now that I am working on an RD update this week (finally, I know!), I'll check through the clarity of this in the draft. If anyone has some text to contribute or comments for improvement that would of course be helpful.

Yes, 4.09 should be registered in general as per OMA Lightweight M2M (the whole spec really needs an IANA review, as there are plenty of things still to be registered).

Zach

> Considering 4.09 is used in the OMA Lightweight M2M specification, we probably should define it. At least there is a use case out there, given that we can figure out how to know that something is a…

Zach Shelby
Director of Technical Marketing
ARM Internet of Things BU
www.arm.com
US: +1 (408) 203-9434
Finland: +358 407796297
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: Michael Koster <[email-masked]>
Date: Tue, 21 Oct 2014 09:21:43 -0700

Rebooting an endpoint with a new IP address is very common, and is a reasonable assumption. It’s also reasonable IMO to require a certificate check to differentiate between the normal case of changing IP address and duplicate EP name errors, i.e. without security you can’t identify duplicate endpoint name errors.

Michael

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 28 Oct 2014 12:34:40 +0000

> Yes, 4.09 should be registered in general as per OMA Lightweight M2M (the
> whole spec really needs an IANA review, as there are plenty of things still to
> be registered).

At the moment, the Registration operation is the only one using the 4.09 Conflict. Question is, if we really need it, since a 4.03 Forbidden would nicely express that the server refuses the registration due to the missing credentials. On the other hand, a 4.09 Conflict would nicely fit with the Create operation when the Instance ID already exists. Yet the spec currently uses a generic 4.00 Bad Request for this...

Ciao
Matthias