Subject: [core] CoAP Endpoint Identification

From: Oliver Kleine <[email-masked]>
Date: Wed, 17 Sep 2014 11:03:42 +0200

Hello,

this is my first message to the core list and I hope that it is the
correct list. However, this is to promote resp. start a discussion on my
draft that I updated recently:

https://datatracker.ietf.org/doc/draft-kleine-core-coap-endpoint-id/

The basic idea is that it enables message exchanges, e.g. running
observations, to keep going despite changing IP addresses at any
involved endpoint. This is a likely event to happen e.g. when running a
CoAP Server on smartphones that provide there sensor data as observable
Webservices. The smartphones IP address frequently changes due to
network changes (WiFi, mobile Internet).

For me, in my particular project, this is a serious issue which is is
not covered by any existing standard or popular draft. However, there is
another (new) draft from Kepeng Li that deals with a similar problem but
provides another solution:

https://datatracker.ietf.org/doc/draft-li-core-coap-node-id-option/

The main difference between the approaches is that I propose to make the
endpoints to assign IDs to their communication partner and by this means
keep the responsibility for the uniqueness of IDs at the respective
endpoints. On the contrary, if I got that right, Kepengs draft proposes
some kind of self-assignment of IDs.

What do you think?

Thank you and best regards,
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
    [email-masked]

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

---

From: Likepeng <[email-masked]>
Date: Wed, 17 Sep 2014 10:34:35 +0000

> For me, in my particular project, this is a serious issue which is not covered
> by any existing standard or popular draft.

Agree that it is an important topic for us to consider. 

I also want to mention that there is another draft related to this topic:
http://datatracker.ietf.org/doc/draft-hong-core-coap-endpoint-unit-id/

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: core [mailto:[email-masked]] 代表 Oliver Kleine
> 发送时间: 2014年9月17日 17:04
> 收件人: [email-masked]
> 主题: [core] CoAP Endpoint Identification
> 
> Hello,
> 
> this is my first message to the core list and I hope that it is the correct list.
> However, this is to promote resp. start a discussion on my draft that I updated
> recently:
> 
> The basic idea is that it enables message exchanges, e.g. running observations,
> to keep going despite changing IP addresses at any involved endpoint. This is a
> likely event to happen e.g. when running a CoAP Server on smartphones that
> provide there sensor data as observable Webservices. The smartphones IP
> address frequently changes due to network changes (WiFi, mobile Internet).
> 
> For me, in my particular project, this is a serious issue which is is not covered
> by any existing standard or popular draft. However, there is another (new)
> draft from Kepeng Li that deals with a similar problem but provides another
> solution:
> 
> keep the responsibility for the uniqueness of IDs at the respective endpoints.
> On the contrary, if I got that right, Kepengs draft proposes some kind of
> self-assignment of IDs.
> 
> What do you think?
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 17 Sep 2014 13:43:33 +0200

Hi Oliver,

I am not sure I understand the problem statement properly.

You write:

----

   Due to the mobile nature of some devices. e.g. smartphones, they are
   often assigned new IP addresses because of a network change.  Thus,
   the IP address of a CoAP server might change during an ongoing
   conversation.  This draft proposes a method to assign each
   communication partner with an identifier (endpoint ID) which replaces
   the IP address as (partial) key to relate requests and responses.

-----

First, I would assume that CoAP is mostly used with DTLS and hence the
problem of IP address changes would occur at the DTLS layer rather than
in the layer above.

Second, I wonder why a smart phone would use CoAP rather than HTTP.
Smart phones are not really IoT devices. If CoAP is used to talk to a
IoT device in your home then the IP address change will most likely
affect also the IoT device and you have to go through a couple of
procedures to get started again.

Third, if the IP address changes then what is the problem with just
initiating a new message exchange with CoAP (using the new IP address)
since CoAP runs over UDP and is therefore connectionless.

Ciao
Hannes

PS: These comments are also applicable to
draft-li-core-coap-node-id-option-01.

On 09/17/2014 11:03 AM, Oliver Kleine wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Zach Shelby <[email-masked]>
Date: Wed, 17 Sep 2014 13:08:27 +0000

Oliver,

You should also check out the unique Endpoint Name identifier defined in the Resource Directory specification. This was designed to help solve the problem you are talking about here, and is further tied into e.g. the certificate used with DTLS. The Lightweight M2M standard uses this mechanism to provide a stable identifier for endpoints which have dynamic IP addresses (or even change protocol).

http://tools.ietf.org/html/draft-ietf-core-resource-directory

Zach

On Sep 17, 2014, at 2:43 PM, Hannes Tschofenig <[email-masked]> wrote:

> <signature.asc>_______________________________________________
> core mailing list
> [email-masked]

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: Oliver Kleine <[email-masked]>
Date: Wed, 17 Sep 2014 15:30:21 +0200

Hi Hannes,

thank you for your comments and sorry for the very long response but
apparently some things need to be clarified.

> problem of IP address changes would occur at the DTLS layer rather than

I don't get the problem with DTLS. I didn't look into DTLS in detail but
I think, any endpoint may initiate a new key exchange whenever
necessary. So, I think the pure message transport between the endpoints
is problem-free (be it encrypted or not).

However, despite potential issues on the DTLS layer the problem is for
sure existing on the CoAP layer as the remote endpoints IP address is
one part of the key to relate incoming ACKs to yet unconfirmed CONs
(together with the message ID) and to relate incoming responses to open
requests (together with the token).

> procedures to get started again.

Why wouldn't you consider a smartphone an IoT device? Please correct me
if I'm wrong but to the best of my knowledge there is not even a proper
definition of the term "IoT". So I consider an IoT device any device (be
it resource constraint or not) which provides data to represent an
arbitrary (physical) thing in an Internet compatible manner, e.g. a
Webservice as virtual alter-ego of that physical thing.

Assuming one wants to integrate a street (the physical thing) with the
Internet of Things one could do so by providing a Webservice that
provides static information (like the streets name, length, number of
lanes, surface, ...) and non-static information (like current traffic
density) which is based on actual sensor readings. For the traffic
density one could count the number of GPS sensors (which are attached to
smartphones) being present on that street. To me this makes a smartphone
an IoT device.

The reason for using CoAP instead of HTTP is that it better fits my
needs, particularly in combination with the observe extension. I use the
smartphone as server platform and not as a client. Besides possible
bandwidth constraints a main issue is the usage of NAT in the mobile
Internet and also in WiFi networks. This makes scalable anytime-access
from the Internet to the smartphone, i.e. the CoAP or HTTP server,
impossible.

So, the idea is that the server (on the smartphone) registers its
services at a proxy which has a public IP address. That proxy
immediately starts the observation of the newly registered services and
provides one mirror-service for each of the registered original
services. By this means the data is globally available and the
scalability issue is moved to a non-constrained environment. To the best
of my knowledge that couldn't be realized with HTTP but works with raw
CoAP and the observe extension. The only remaining issue is the IP
address change.

> since CoAP runs over UDP and is therefore connectionless.

For the client this likely causes information loss. Assume, the server
IP changes after sending an update notification. After that the status
of the observed status changes which causes a new update notification
which is sent from the new IP address. As the IP address is a partial
key to relate update notifications with requests (together with the
token) the client is not able to handle the new update notification and
sends an RST which makes the server to wrongly assume that the client is
no longer interested in the data. Only after ~24 hours the client
realizes that there were no update notifications (see page 15 of the
observe draft v14) and may restart the observation. In the meantime all
update notifications are lost.

For the server this causes memory consumption overhead. Assume the
client IP changes while there is an ongoing observation. If the client
re-registers as an observer the server assumes a second observation
instead of a replacement. So, the server keeps the useless observation
relationship with the outdated client IP running and thus, wastes memory
and bandwidth to send update notifications to the old IP address.

I recently presented a poster on the conference "iThings 2014" which
summarizes both, the problem(s) and the proposed solution. The poster is
available for download here:

http://media.itm.uni-luebeck.de/people/kleine/ietf/poster_kleine_coap_endpoint_id.pdf

Thank you again and best regards,
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: Michael Richardson <[email-masked]>
Date: Wed, 17 Sep 2014 14:52:06 -0400

{Thank you for your very well written intro email; I wish that all
people who write drafts could learn from your example.  Your summary
of the conflict was ideal}

Oliver Kleine <[email-masked]> wrote:
    Hannes> Second, I wonder why a smart phone would use CoAP rather than
    Hannes> HTTP.

I think the better simple answer is that the smartphone may well be the
non-constrained device in the system, and the other devices may well
be constrained enough to need CoAP, but further, the smartphone example
is perhaps just one example, and any system which has significant amount
of mobility between autonomous systems (e.g. between networks, not within
networks) might need this.

    > needs, particularly in combination with the observe extension. I use

I think that this is the correct simple answer.
You want observe; it an IPv6 end-to-end world, you can get it directly,
but otherwise, you have to go through a proxy.

    > scalability issue is moved to a non-constrained environment. To the
    > best of my knowledge that couldn't be realized with HTTP but works with
    > raw CoAP and the observe extension. The only remaining issue is the IP
    > address change.

It seems to me that that this exactly duplicates STUN.
    http://tools.ietf.org/html/rfc5389
I suggest that you want to instead run CoAP over STUN.
That has implications for *all* parties involved, but so does your proposal.

Since you seem to be adding something to CoAP in order to deal with
instability caused by IPv4,  that it would be better to find a way to get
stable IPv6 to the device involved, and then the expense of the IPv4 NAPT
is born by the device that has the problem, rather than all end points.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Likepeng <[email-masked]>
Date: Thu, 18 Sep 2014 09:52:41 +0000

Hi Zach,

> You should also check out the unique Endpoint Name identifier defined in the Resource Directory specification.

If I understand correctly, in "resource directory" draft, unique Endpoint Name identifier is generated by endpoint, and sent to Resource Directory Server using URI parameters during registration.

That means, every time when the endpoint IP address changes, the endpoint needs to update its registration to RD Server, even there is no other change for the resources. And clients need to check with RD Server to know the IP address / ID mapping.

In my opinion, this is quite inefficient. If we use option , ID can be sent directly from server to client, or from client to server, without the involvement of RD Server.

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: core [mailto:[email-masked]] 代表 Zach Shelby
> 发送时间: 2014年9月17日 21:08
> 收件人: Hannes Tschofenig
> 抄送: [email-masked]
> 主题: Re: [core] CoAP Endpoint Identification
> 
> Oliver,
> 
> You should also check out the unique Endpoint Name identifier defined in the
> Resource Directory specification. This was designed to help solve the problem
> you are talking about here, and is further tied into e.g. the certificate used with
> DTLS. The Lightweight M2M standard uses this mechanism to provide a stable
> identifier for endpoints which have dynamic IP addresses (or even change
> protocol).
> 
> > problem of IP address changes would occur at the DTLS layer rather
> > than in the layer above.
> >
> >> correct list. However, this is to promote resp. start a discussion on
> >> my draft that I updated recently:
> >>
> >> involved endpoint. This is a likely event to happen e.g. when running
> >> a CoAP Server on smartphones that provide there sensor data as
> >> observable Webservices. The smartphones IP address frequently changes
> >> due to network changes (WiFi, mobile Internet).
> >>
> >> not covered by any existing standard or popular draft. However, there
> >> is another (new) draft from Kepeng Li that deals with a similar
> >> problem but provides another solution:
> >>
> >> The main difference between the approaches is that I propose to make
> >> the endpoints to assign IDs to their communication partner and by
> >> this means keep the responsibility for the uniqueness of IDs at the
> >> respective endpoints. On the contrary, if I got that right, Kepengs
> >> draft proposes some kind of self-assignment of IDs.
> >>
> >> What do you think?
> >>
> -- 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: Likepeng <[email-masked]>
Date: Thu, 18 Sep 2014 09:55:36 +0000

Hi Oliver,

> keep the responsibility for the uniqueness of IDs at the respective endpoints.

One potential issue with this approach is, one client may talk with many servers, 
and one server may talk with many clients.

How to guarantee uniqueness?

Also, some endpoints already have unique ID, we can reuse that.

Kind Regards
Kepeng

---

From: Oliver Kleine <[email-masked]>
Date: Thu, 18 Sep 2014 12:15:13 +0200

Hi Michael,

first of all thank you for you comments!

> That has implications for *all* parties involved, but so does your proposal.

My proposal does only affect the CoAP endpoints and has no implications
on intermediate devices like e.g. a NAT router and I would actually
prefer to keep it that way. I think, that there is no problem on the
underneath layers like IP or UDP. The transport of the CoAP message from
one endpoint to the other just works. The problem occurs on the CoAP
layer and in particular in terms of relating incoming responses resp.
update notifications with requests. This is due to using the endpoints
socket addresses (IP and port) as partial key for the request/response
relation. Thus, I consider this an application layer problem which
should be solved on the application layer, i.e. in CoAP.

> is born by the device that has the problem, rather than all end points.

Again, I don't consider this a problem on the IP layer. I think, NAT was
designed to deal with the unexpected huge amount of devices on the one
hand and the limited number of IPv4 addresses on the other hand. In
particular to enable unique addressing and by this means message
transport from one endpoint to the other without any need to care about
the application layer. With IPv6 we probably don't need NAT anymore, but
who knows? Anyway, the fact of potentially changing IP addresses will be
present also with IPv6, maybe even more present than with IPv4 as IPv6
addresses may change from time to time not only due to network changes
but also within the same network e.g. for privacy reasons.

However, the message transport between endpoints is not the problem that
I tried to deal with. Despite potential IP address changes on any of the
involved endpoints the raw message exchange works with e.g. IP and UDP
as is.

The problem is the interpretation of the CoAP message
(request/response/update notification relation). Actually, I just
propose to optionally avoid the cross-layer dependency between CoAP and
IP layer, i.e. to replace the IP address with another unique identifier
which is fixed for the duration of a single communication, i.e. a
"request/response" pair or a "request/update notifications" tuple.

Best regards,
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: Oliver Kleine <[email-masked]>
Date: Thu, 18 Sep 2014 13:21:55 +0200

Hi Kepeng,

> How to guarantee uniqueness?

as a matter of fact, there is no need for global uniqueness of such IDs.
Let me take your examples from the clients perspective:

1. Assume one client that talks to many servers. Within the respective
requests the client sets the EID1 option to different values for each of
this servers. The servers set the EID2 option with each response/update
notification and by this means enable the client to relate request and
response/update notifications.

2. Assume many clients talking to one server. Coincidentally all those
client set the EID1 option in there requests to the same value. Thats no
problem, as the server sets the EID2 option to that value in all the
responses. Thus, all clients are (independently) able to relate the
incoming response/update notifications with the respective request.

Generally speaking, the uniqueness of assigned IDs is crucial only
within the set of parallel communications of a certain endpoint. It is
e.g. not important that a particular server is assigned different IDs
from different clients (see examples above). But it is important that
one client does not assign the same ID to different servers which is
easy to realize. That's what I ment by "keep the responsibility for the
uniqueness of IDs at the respective endpoints" in my previous mail.

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: Oliver Kleine <[email-masked]>
Date: Thu, 18 Sep 2014 15:44:50 +0200

Hi,

Am 18.09.2014 um 11:52 schrieb Likepeng:

>> You should also check out the unique Endpoint Name identifier
>> defined in the Resource Directory specification.
> 
> If I understand correctly, in "resource directory" draft, unique
> Endpoint Name identifier is generated by endpoint, and sent to
> Resource Directory Server using URI parameters during registration.

that was also my understanding.

> That means, every time when the endpoint IP address changes, the
> endpoint needs to update its registration to RD Server, even there is
> no other change for the resources. And clients need to check with RD
> Server to know the IP address / ID mapping.
> 
> In my opinion, this is quite inefficient. If we use option , ID can
> be sent directly from server to client, or from client to server,
> without the involvement of RD Server.

Now that I've read the RD and Lightweight M2M specifications I'm
positive to some degree that it is possible to somehow solve the
original issue with those techniques. But I agree with Kepeng, that this
is quite a lot of overhead for just the ability to e.g. keep
observations running despite IP address changes at the endpoints. And as
I said in a previous message I think, that the core issue is the
cross-layer dependency from CoAP to the underlying network and transport
layers in terms of identification (e.g. IP address and port number as
partial keys to relate requests and responses).

So, the proposal is to solve the issue where it occurs which is within
CoAP. Assuming we have one CoAP client and one CoAP server (over UDP/IP)
and one (or even both) of them change their IPs from time to time for
any reason (such as moving to another network or for privacy reasons).
Then, in my opinion, some sort of identifier which is independent from
other layers is very useful. And that's basically the core of the draft(s).

Would you agree on that?

Best,
Oliver

> 
>> -----邮件原件----- 发件人: core [mailto:[email-masked]] 代表 Zach
>> Shelby 发送时间: 2014年9月17日 21:08 收件人: Hannes Tschofenig 抄送:
>> [email-masked] 主题: Re: [core] CoAP Endpoint Identification
>> 
>> Oliver,
>> 
>> You should also check out the unique Endpoint Name identifier
>> defined in the Resource Directory specification. This was designed
>> to help solve the problem you are talking about here, and is
>> further tied into e.g. the certificate used with DTLS. The
>> Lightweight M2M standard uses this mechanism to provide a stable 
>> identifier for endpoints which have dynamic IP addresses (or even
>> change protocol).
>> 
>>> Due to the mobile nature of some devices. e.g. smartphones, they
>>> are often assigned new IP addresses because of a network change.
>>> Thus, the IP address of a CoAP server might change during an
>>> ongoing conversation.  This draft proposes a method to assign
>>> each communication partner with an identifier (endpoint ID) which
>>> replaces the IP address as (partial) key to relate requests and
>>> responses.
>>> 
>>> -----
>>> 
>>> First, I would assume that CoAP is mostly used with DTLS and
>>> hence the problem of IP address changes would occur at the DTLS
>>> layer rather than in the layer above.
>>> 
>>> Second, I wonder why a smart phone would use CoAP rather than
>>> HTTP. Smart phones are not really IoT devices. If CoAP is used to
>>> talk to a IoT device in your home then the IP address change will
>>> most likely affect also the IoT device and you have to go through
>>> a couple of procedures to get started again.
>>> 
>>> Third, if the IP address changes then what is the problem with
>>> just initiating a new message exchange with CoAP (using the new
>>> IP address) since CoAP runs over UDP and is therefore
>>> connectionless.
>>> 
>>> Ciao Hannes
>>> 
>>>> this is my first message to the core list and I hope that it is
>>>> the correct list. However, this is to promote resp. start a
>>>> discussion on my draft that I updated recently:
>>>> 
>>>> observations, to keep going despite changing IP addresses at
>>>> any involved endpoint. This is a likely event to happen e.g.
>>>> when running a CoAP Server on smartphones that provide there
>>>> sensor data as observable Webservices. The smartphones IP
>>>> For me, in my particular project, this is a serious issue which
>>>> is is not covered by any existing standard or popular draft.
>>>> However, there is another (new) draft from Kepeng Li that deals
>>>> with a similar problem but provides another solution:
>>>> 
>>>> the endpoints to assign IDs to their communication partner and
>>>> by this means keep the responsibility for the uniqueness of IDs
>>>> at the respective endpoints. On the contrary, if I got that
>>>> right, Kepengs draft proposes some kind of self-assignment of
>>>> IDs.
>>>> 
>>>> What do you think?
>>>> 
>>>> Thank you and best regards, Oliver
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________ core mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/core
>>>> 
>>> core mailing list [email-masked] 
>> 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
>> 
>> _______________________________________________ core mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/core
> _______________________________________________ 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

---

From: Likepeng <[email-masked]>
Date: Fri, 19 Sep 2014 03:26:49 +0000

> So, the proposal is to solve the issue where it occurs which is within CoAP.
> Assuming we have one CoAP client and one CoAP server (over UDP/IP) and
> one (or even both) of them change their IPs from time to time for any reason
> (such as moving to another network or for privacy reasons).
> Then, in my opinion, some sort of identifier which is independent from other
> layers is very useful. And that's basically the core of the draft(s).
> 
> Would you agree on that?

Agree.

Kind Regards
Kepeng

> 发送时间: 2014年9月18日 21:45
> > In my opinion, this is quite inefficient. If we use option , ID can be
> > sent directly from server to client, or from client to server, without
> > the involvement of RD Server.
> 
> Now that I've read the RD and Lightweight M2M specifications I'm positive to
> some degree that it is possible to somehow solve the original issue with those
> techniques. But I agree with Kepeng, that this is quite a lot of overhead for just
> the ability to e.g. keep observations running despite IP address changes at the
> endpoints. And as I said in a previous message I think, that the core issue is the
> layers in terms of identification (e.g. IP address and port number as partial keys
> to relate requests and responses).
> 
> So, the proposal is to solve the issue where it occurs which is within CoAP.
> Assuming we have one CoAP client and one CoAP server (over UDP/IP) and
> one (or even both) of them change their IPs from time to time for any reason
> (such as moving to another network or for privacy reasons).
> Then, in my opinion, some sort of identifier which is independent from other
> layers is very useful. And that's basically the core of the draft(s).
> 
> Would you agree on that?
> 
> Best,
> Oliver
> 
> >
> >> You should also check out the unique Endpoint Name identifier defined
> >> in the Resource Directory specification. This was designed to help
> >> solve the problem you are talking about here, and is further tied
> >> into e.g. the certificate used with DTLS. The Lightweight M2M
> >> standard uses this mechanism to provide a stable identifier for
> >> endpoints which have dynamic IP addresses (or even change protocol).
> >>
> >>> often assigned new IP addresses because of a network change.
> >>> Thus, the IP address of a CoAP server might change during an ongoing
> >>> communication partner with an identifier (endpoint ID) which
> >>> First, I would assume that CoAP is mostly used with DTLS and hence
> >>> the problem of IP address changes would occur at the DTLS layer
> >>> rather than in the layer above.
> >>>
> >>> Smart phones are not really IoT devices. If CoAP is used to talk to
> >>> a IoT device in your home then the IP address change will most
> >>> likely affect also the IoT device and you have to go through a
> >>> couple of procedures to get started again.
> >>>
> >>> initiating a new message exchange with CoAP (using the new IP
> >>> address) since CoAP runs over UDP and is therefore connectionless.
> >>>
> >>> Ciao Hannes
> >>>
> >>>> correct list. However, this is to promote resp. start a discussion
> >>>> on my draft that I updated recently:
> >>>>
> >>>> involved endpoint. This is a likely event to happen e.g.
> >>>> when running a CoAP Server on smartphones that provide there sensor
> >>>> data as observable Webservices. The smartphones IP address
> >>>> frequently changes due to network changes (WiFi, mobile Internet).
> >>>>
> >>>> For me, in my particular project, this is a serious issue which is
> >>>> is not covered by any existing standard or popular draft.
> list
> >> Zach Shelby Director of Technical Marketing ARM Internet of Things BU
> >> www.arm.com US: +1 (408) 203-9434 Finland: +358 407796297 Skype:
> >> disclose the contents to any other person, use it for any purpose, or
> >> store or copy the information in any medium.  Thank you.
> >>

---

From: Likepeng <[email-masked]>
Date: Fri, 19 Sep 2014 07:25:23 +0000

> this servers.

One possible issue is, one server will get several assigned IDs from different clients and it has to maintain the mappings between different IDs with different clients.

It adds overhead for the constrained servers.

In Toronto, we also discussed two other use cases to use endpoint ID: 
1) Alternative transport: for example, a client can send SMS with endpoint ID to a server, the server uses UDP transport to talk with the client. Endpoint ID can be used to correlate MSISDN number with IP address for the client.
2) Authentication and authorization: for example, in the Authorization Server, the authorization rule can be defined with Endpoint ID, instead of IP address, since IP address is not stable.

Does this EID1/EID2 solution fit into these two use cases?

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Oliver Kleine [mailto:[email-masked]]
> 发送时间: 2014年9月18日 19:22
> 收件人: Likepeng; [email-masked]
> endpoints.

---

From: Oliver Kleine <[email-masked]>
Date: Fri, 19 Sep 2014 10:53:42 +0200

Hi Kepeng,

>> 1. Assume one client that talks to many servers. Within the
>> respective requests the client sets the EID1 option to different
>> values for each of this servers.
> 
> One possible issue is, one server will get several assigned IDs from
> different clients and it has to maintain the mappings between
> different IDs with different clients.
> 

thats true but the server has to maintain the IP/messageID and IP/token
pairs anyway. Depending on the implementation the additional EIDs lead
to another pair (IP/EIDs) to be maintained. Maybe there is a more
efficient way. However, the overhead is rather limited. Even if we
restrict ourselves to a maximum EID length of 1 byte, this leads to the
ability of up to 256 parallel communications. With a maximum length of
two bytes it even is 65793 which I would consider more than enough for
resource constrained servers.

>  1) Alternative transport: for example, a client can send SMS with
> endpoint ID to a server, the server uses UDP transport to talk with
> the client. Endpoint ID can be used to correlate MSISDN number with
> IP address for the client.

> 2) Authentication and authorization: for
> example, in the Authorization Server, the authorization rule can be
> defined with Endpoint ID, instead of IP address, since IP address is
> not stable.

> Does this EID1/EID2 solution fit into these two use cases?

1) Yes. If we consider the MSISDN equivalent to an IP address but just
for another kind of transport that should be no problem. Instead of the
EID/IP mapping you would use an EID/MSISDN. But do you think, this is
useful for MSISDNs? In my understanding, they are strictly attached to a
SIM card and no subject to change.

2) That is something to be discussed. Currently, the EIDs are valid for
the duration of a single conversation. By conversation I mean the set of
a request and all follow-up messages caused by that initial request.
This is to enable the endpoints to assign their communication partners
with the shortest possible EID that is currently not in use and thus
save memory and bandwidth.

Best,
Oliver

> 
>> -----邮件原件----- 发件人: Oliver Kleine
>> [mailto:[email-masked]] 发送时间: 2014年9月18日 19:22 收件人:
>> Likepeng; [email-masked] 主题: Re: [core] CoAP Endpoint
>> Identification
>> 
>> Hi Kepeng,
>> 
>>>> The main difference between the approaches is that I propose to
>>>> make the endpoints to assign IDs to their communication partner
>>>> and by this means keep the responsibility for the uniqueness of
>>>> IDs at the respective
>> endpoints.
>>> 
>>> One potential issue with this approach is, one client may talk
>>> with many
>> servers,
>> as a matter of fact, there is no need for global uniqueness of such
>> IDs. Let me take your examples from the clients perspective:
>> 
>> 1. Assume one client that talks to many servers. Within the
>> respective requests the client sets the EID1 option to different
>> values for each of this servers. The servers set the EID2 option
>> with each response/update notification and by this means enable the
>> client to relate request and response/update notifications.
>> 
>> 2. Assume many clients talking to one server. Coincidentally all
>> those client set the EID1 option in there requests to the same
>> value. Thats no problem, as the server sets the EID2 option to that
>> value in all the responses. Thus, all clients are (independently)
>> able to relate the incoming response/update notifications with the
>> respective request.
>> 
>> within the set of parallel communications of a certain endpoint. It
>> is e.g. not important that a particular server is assigned
>> different IDs from different clients (see examples above). But it
>> is important that one client does not assign the same ID to
>> different servers which is easy to realize. That's what I ment by
>> "keep the responsibility for the uniqueness of IDs at the
>> respective endpoints" in my previous mail.
>> 
>> 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 

-- 

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: Likepeng <[email-masked]>
Date: Sat, 20 Sep 2014 09:24:52 +0000

Hi Oliver,

> Depending on the implementation the additional EIDs lead
> to another pair (IP/EIDs) to be maintained.

Since in Resource Directory draft, it already proposes to have self-generated Endpoint ID, it is better to reuse it, but just transfer it in options.

> Currently, the EIDs are valid for the duration of a single conversation.

For Authorization Rules, it is better to use long-lived IDs. Self-generated ID is a good candidate.

Kind Regards
Kepeng

---

From: Oliver Kleine <[email-masked]>
Date: Wed, 24 Sep 2014 14:41:27 +0200

Hi all,

from the previous discussion I took that unique endpoint identification
is somehow an issue. However, the proposed ways of unique ID assignment
differ on several aspects:

1. Assignment: self-assignment vs. remote-assignment
2. Level of uniqueness: global vs. resource-directory wide
3. Lifetime: as long as possible vs. duration of single message-exchange
(bound to token lifetime)
4. Purpose: directory service vs. relating responses with requests

Would you consider this something to be discussed in the next IETF
meeting? I would be able to join that meeting and I'm really interested
in the evolution of upcoming standards and what aspects make a new draft
a promising RFC candidate.

Am 20.09.2014 um 11:24 schrieb Likepeng:
> Hi Oliver,
> 
>> Depending on the implementation the additional EIDs lead to another
>> pair (IP/EIDs) to be maintained.
> 
> Since in Resource Directory draft, it already proposes to have
> self-generated Endpoint ID, it is better to reuse it, but just
> transfer it in options.
> 
> Kind Regards Kepeng

-- 

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: Likepeng <[email-masked]>
Date: Thu, 25 Sep 2014 00:20:12 +0000

> Would you consider this something to be discussed in the next IETF meeting?

This topic (Endpoint ID) was on the agenda of last IETF F2F meeting. 

But we ran out of time in the meeting, and this agenda item was postponed.

I would assume it will be on the agenda for the next F2F meeting.

>I would be able to join that meeting.

That is great. But you need to get confirmation about agenda arrangement from the chairs, to plan your travel.

Kind Regards
Kepeng

> 发送时间: 2014年9月24日 20:41
> from the previous discussion I took that unique endpoint identification is
> somehow an issue. However, the proposed ways of unique ID assignment
> 1. Assignment: self-assignment vs. remote-assignment 2. Level of uniqueness:
> global vs. resource-directory wide 3. Lifetime: as long as possible vs. duration
> of single message-exchange (bound to token lifetime) 4. Purpose: directory
> service vs. relating responses with requests
> 
> Would you consider this something to be discussed in the next IETF meeting? I
> would be able to join that meeting and I'm really interested in the evolution of
> upcoming standards and what aspects make a new draft a promising RFC
> candidate.
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Sep 2014 08:38:08 +0200

> That is great. But you need to get confirmation about agenda arrangement from the chairs, to plan your travel.

Well, clearly there is interest in this approach.
We haven’t done agenda planning yet for Hawaii, but I would expect this is one of the items that we will have to fit in.
Luckily, this came up before the session request deadline, so we can ask for more time in Hawaii than we had in Toronto.

Putting the subject on the agenda is not enough, though.  We need to get some progress on the list, too.
So, please don’t stop discussing this after this message...

<hat off>
The problem I had with the initial drafts was that there were some solutions proposed without a good understanding of the problem.
For the solutions, it was not clearly discussed what the processing model was (when does an initiator send the option, how does a recipient react, etc.), and how the solution is meant to impact base CoAP (in particular the response matching algorithm).
There were some proposals mentioning the word “authentication” without really explaining how the solution would fit into a security model.
</hat off>

Please remember that the Internet-draft cutoff is 2014-10-27.  So we have about a month left to run this discussion and come up with more complete (and possibly merged) drafts that are worth discussing f2f in Hawaii.

Grüße, Carsten

---

From: Likepeng <[email-masked]>
Date: Thu, 25 Sep 2014 08:19:57 +0000

> The problem I had with the initial drafts was that there were some solutions
> proposed without a good understanding of the problem.

Here is one of the problems I want to resolve:
http://www.ietf.org/mail-archive/web/core/current/msg05144.html

In short, how to correlate a multicast observation request with the multiple notification responses from different nodes, in case of IP address change?

> For the solutions, it was not clearly discussed what the processing model was
> (when does an initiator send the option, how does a recipient react, etc.), and
> how the solution is meant to impact base CoAP (in particular the response
> matching algorithm).

For my proposal, when CoAP Server receives an observation request, it should include its Endpoint ID in the first notification, and include it when IP address changes. For CoAP Client side, when it receives a notification message from a unknown IP address, it can use received Endpoint ID to match its previous observation request. The solution adds one more step for the response matching processing but does not break backward compatibility for the base CoAP.

Thanks for bringing this up. This is currently missing in my draft. Will add it.

> There were some proposals mentioning the word "authentication" without
> really explaining how the solution would fit into a security model.

Endpoint ID can be used as "Description" parameter in the authorization request as mentioned in this draft. 
http://datatracker.ietf.org/doc/draft-gerdes-ace-dcaf-authorize/

      D: Description.  A descriptive label of the initiator of the
      authorization request.  This label MAY be a fully qualified domain
      name, an IP address, or any other character literal that is used
      by the Authorization Server to decide whether or not access is
      granted to the requesting entity.

For this parameter, IP address is not stable, domain name may not be available. Endpoint ID is a good candidate.

One open issue is, should we include it in the payload or as an option? This certainly needs some discussions.

In DICE, recently there are also some discussion about role based authorization vs identity based authentication.
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00379.html

Kind Regards
Kepeng

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 25 Sep 2014 10:34:26 +0200

Kepeng,

Likepeng <[email-masked]> writes:

> Endpoint ID can be used as "Description" parameter in the
> authorization request as mentioned in this draft.
> For this parameter, IP address is not stable, domain name may not be
> available. Endpoint ID is a good candidate.

This was indeed our general mindset.

Gruesse
Olaf

---

From: "weigengyu" <[email-masked]>
Date: Sun, 28 Sep 2014 13:12:15 +0800

Hi,

When Node ID (NID) or Endpoint ID (EID) is defined and every CoAP Endpoint 
has a unique ID that is never changed.

CoAP can just use the token to match request and response when IP address is 
stable.
With a pair  NIDs and the token the relationship between the requester and 
the responsor can be uniquely identified at any time.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Olaf Bergmann
Sent: Thursday, September 25, 2014 4:34 PM
To: Likepeng
Cc: [email-masked]
Subject: Re: [core] CoAP Endpoint Identification

Kepeng,

Gruesse
Olaf

---

From: Oliver Kleine <[email-masked]>
Date: Mon, 29 Sep 2014 11:06:01 +0200

Hi,

Am 28.09.2014 um 07:12 schrieb weigengyu:

> When Node ID (NID) or Endpoint ID (EID) is defined and every CoAP
> Endpoint has a unique ID that is never changed.

the term "never changed" is not exactly true for EIDs. Let me explain
that. I wanted the EIDs to be independent from any layers or other
components but the CoAP layer on just both endpoints. Every other layer
has its identifiers with a certain lifetime, e.g. MAC addresses on the
network layer, IP addresses on the Internet layer and ports on the
transport layer. All of them are necessary to transfer data from one
source process to the other (maybe remote) destination process.

The EID approach follows that well established tradition by defining an
independent new identifier for the specific purpose of relating requests
to responses and update notifications just for the necessary lifetime.

In CoAP the mutually assigned EIDs are valid for the duration of one
conversation. A conversation is considered the the set of all messages
between two endpoints that share the same token instance, e.g. a single
request/response pair or one request and an unbound set of update
notifications.

Best,
Oliver

> -----原始邮件----- From: Olaf Bergmann

-- 

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