Subject: Re: [core] Implications of IP address / port changes for CoAP & Co

From: Oliver Kleine <[email-masked]>
Date: Wed, 5 Oct 2016 22:10:03 +0200

Hi Hannes,

if I got you right this is exactly the problem I was talking about at
IETF 91 almost two years ago. Back then, I briefly presented an
extension draft with a rather simple approach to solve that issue.

If you don't mind, please have a look at [1]. Are you talking about the
same thing?

Best regards,
Oliver

[1] https://tools.ietf.org/html/draft-kleine-core-coap-endpoint-id-01

Am 31.08.2016 um 12:36 schrieb Hannes Tschofenig:
> Hi all,
> 
> in the OMA device management group we have been discussing the
> implications of IP address and/or port number changes of devices
> (particularly with devices that sleep for an extended period of time).
> 
> The challenge from a protocol point of view is to use an identifier that
> does not depend on the IP address and port. Of course, when a IP packet
> has to be sent to a specific node then IP address and port information
> has to be used from somewhere but my expectation is that at least the
> protocol machinery shouldn't break when an IP address changes (or there
> should be a story for how to recover).
> 
> In CoAP the 'endpoint' appears to be an important identifier. In an
> attempt to define what an endpoint is the CoAP specification is a bit
> confusing:
> 
> Section 1.2 says:
> 
> "
>    Endpoint
>       An entity participating in the CoAP protocol.  Colloquially, an
>       endpoint lives on a "Node", although "Host" would be more
>       consistent with Internet standards usage, and is further
>       identified by transport-layer multiplexing information that can
>       include a UDP port number and a security association
>       (Section 4.1).
> "   
> 
> Section 4.1 of RFC 7252 says:
>     
> "
>    A CoAP endpoint is the source or destination of a CoAP message.  The
>    specific definition of an endpoint depends on the transport being
>    used for CoAP.  For the transports defined in this specification, the
>    endpoint is identified depending on the security mode used (see
>    Section 9): With no security, the endpoint is solely identified by an
>    IP address and a UDP port number.  With other security modes, the
>    endpoint is identified as defined by the security mode.
> "
> 
> The two definitions do not appear to be in sync, particularly when using
> DTLS to secure CoAP since the DTLS record layer adds nothing with
> respect to additional multiplexing. I also did not find text that
> describes what the different endpoint definition is when DTLS is used.
> 
> In any case, when DTLS is used an IP address / port change at the client
> will prevent the CoAP server from finding the right security context and
> a new (hopefully abbreviated) handshake has to be run.
> 
> Luckily the implications of an IP address/port change are quite minimal
> for CoAP itself since the only impact (as far as I can tell) is with
> regards to the use of request/response exchange, as described in Section
> 5.3.2 "Request/Response Matching Rules". The likelihood that a client
> changes IP address in the middle of a request/response interaction are
> IMHO minimal.
> 
> The story is more interesting when we look at extensions to CoAP, like
> CoAP Observe. Section 4.1 of https://tools.ietf.org/html/rfc7641 says:
> 
> "
>    The entry in the list of observers is keyed by the client endpoint
>    and the token specified by the client in the request.  If an entry
>    with a matching endpoint/token pair is already present in the list
>    (which, for example, happens when the client wishes to reinforce its
>    interest in a resource), the server MUST NOT add a new entry but MUST
>    replace or update the existing one.
> "
> 
> With Observe a token is used for demultiplexing (in addition to the
> endpoint info). I assume that the spec uses the same definition of
> endpoint as in CoAP.
> 
> While the spec does not say what is actually being updated or replaced
> one can assume that a client sending a request with a new IP address and
> port (which corresponds to the endpoint definition in CoAP) gets at
> least that information updated.
> 
> The spec is IMHO unclear what should happen in case of an IP
> address/port change. I suspect that an implementation would send a new
> register message and the server would update state. Of course, when the
> IP address / port of the client is not in sync with what is being stored
> at the server then the notifications sent by the server will not reach
> the client.
> 
> The story for RD appears to be different again. First, there appears to
> be a different definition of endpoint being used (which I prefer more).
> For multiplexing it does not use IP address & port information. Of
> course, RD will still have to maintain this information but at least one
> can be sure that packets are not dropped after the IP address and/or
> port at the client change.
> 
> Section 11.1 of draft-ietf-core-resource-directory-08 says:
> 
> "
>    An Endpoint is determined to be unique by an RD by the Endpoint
>    identifier parameter included during Registration, and any associated
>    TLS or DTLS security bindings.  An Endpoint MUST NOT be identified by
>    its protocol, port or IP address as these may change over the
>    lifetime of an Endpoint.
> "
> 
> It appears that the way how state is indexed is different throughout the
> specifications developed in the CORE working group and I am curious
> whether someone else has been looking at the implications of IP address
> and/or port changes on the protocol operation. I would certainly
> appreciate your thoughts on this topic.
> 
> Ciao
> Hannes
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 

Dr.-Ing. Oliver Kleine

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

    Ratzeburger Allee 160
    23538 Lübeck

    Tel +49 451 3101-6406 (NEU)
    Fax +49 451 3101-6404 (NEU)
    [email-masked]

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

---

From: Dave Thaler <[email-masked]>
Date: Wed, 5 Oct 2016 22:22:41 +0000

It is important that every device have a unique UUID that is endpoint-address-agnostic
and protocol-agnostic.  Other ecosystems of devices , including WSD, UPnP, OCF (which uses COAP),
AllJoyn, etc., all have a way of passing the same device UUID in various protocols. 

If CoRE wants to move it down into the COAP protocol itself that would be fine (some other
ecosystems do so), but it's important that it be a UUID, and that it be protocol-agnostic and not
COAP-specific.

Besides address/port changes, the other use case is that when the same device is discovered
via multiple paths or protocols, the UI can know to only show it once to the user and hide the
multiple paths/protocols from the end user.   This is often called "deduplication" in the cross-protocol
discovery process.

Dave

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Oliver Kleine
Sent: Wednesday, October 5, 2016 1:10 PM
To: [email-masked]
Subject: Re: [core] Implications of IP address / port changes for CoAP & Co

Hi Hannes,

if I got you right this is exactly the problem I was talking about at IETF 91 almost two years ago. Back then, I briefly presented an extension draft with a rather simple approach to solve that issue.

If you don't mind, please have a look at [1]. Are you talking about the same thing?

Best regards,
Oliver

Am 31.08.2016 um 12:36 schrieb Hannes Tschofenig:
> The challenge from a protocol point of view is to use an identifier 
> that does not depend on the IP address and port. Of course, when a IP 
> packet has to be sent to a specific node then IP address and port 
> information has to be used from somewhere but my expectation is that 
> at least the protocol machinery shouldn't break when an IP address 
> changes (or there should be a story for how to recover).
> 
> The two definitions do not appear to be in sync, particularly when 
> using DTLS to secure CoAP since the DTLS record layer adds nothing 
> with respect to additional multiplexing. I also did not find text that 
> In any case, when DTLS is used an IP address / port change at the 
> client will prevent the CoAP server from finding the right security 
> context and a new (hopefully abbreviated) handshake has to be run.
> 
> Luckily the implications of an IP address/port change are quite 
> minimal for CoAP itself since the only impact (as far as I can tell) 
> is with regards to the use of request/response exchange, as described 
> in Section
> one can assume that a client sending a request with a new IP address 
> and port (which corresponds to the endpoint definition in CoAP) gets 
> at least that information updated.
> 
> register message and the server would update state. Of course, when 
> the IP address / port of the client is not in sync with what is being 
> stored at the server then the notifications sent by the server will 
> not reach the client.
> 
> The story for RD appears to be different again. First, there appears 
> to be a different definition of endpoint being used (which I prefer more).
> course, RD will still have to maintain this information but at least 
> one can be sure that packets are not dropped after the IP address 
> and/or port at the client change.
> 
> It appears that the way how state is indexed is different throughout 
> the specifications developed in the CORE working group and I am 
> curious whether someone else has been looking at the implications of 
> IP address and/or port changes on the protocol operation. I would 
> certainly appreciate your thoughts on this topic.
> 
> Ciao
> Hannes
> 

-- 

Dr.-Ing. Oliver Kleine

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

    Ratzeburger Allee 160
    23538 Lübeck

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 5 Oct 2016 23:28:41 +0100

Hi Dave,

On 05/10/16 23:22, Dave Thaler wrote:
> It is important that every device have a unique UUID that is
> endpoint-address-agnostic and protocol-agnostic.

Considering the privacy implications I'm not at all sure I'd
accept that argument. In fact I'd argue we ought encourage
that devices not have globally unique long-term identifiers at
all unless there is a real need for those, and unless we
understand how to control their (ab)use.

Cheers,
S.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 06 Oct 2016 00:47:38 +0200

The magic word seems to be "directed identity".

It seems best to keep long-term identifiers confined to usage within a
long-term security association.

We don't have good mechanisms to manage those.

An example for what we could use is a mechanism that allows a CoAP node
to say to another node "here is my new transport address.  I'm not
telling you right away who I am, but if as I believe we are sharing a
security association, here is some information that allows *only you* to
find out which", e.g. in order to resume a DTLS connection.
(draft-barrett-mobile-dtls doesn't cut it here.)

We will discuss this specific issue next at T2TRG in Ludwigsburg,
2016-10-27.  Submissions to this meeting would be very welcome.

Grüße, Carsten

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 5 Oct 2016 23:54:15 +0100

> (draft-barrett-mobile-dtls doesn't cut it here.)

Discussing such semantics and how to make them practical seems
like a fine thing to me. While solving the problem for CoAP is
a good thing, I'd hope that solutions (if they exist) could be
generalised too. (Esp. since the discussion will be in an RG and
not the core WG.)

> 2016-10-27.  Submissions to this meeting would be very welcome.

Submission: please solve the above, if you can:-)

Sorry I can't make that. If t2trg meet in Seoul and there's a
report out on the topic, I'd go though.

Cheers,
S.

---

From: Dave Thaler <[email-masked]>
Date: Wed, 5 Oct 2016 23:00:55 +0000

For privacy, it is also important that the UUID not be disclosed to untrusted parties, but that it be disclosed only to trusted parties.
Privacy does not dictate that there shouldn't be one, it just dictates who not to let see it.

(This is a significant piece of the issue that led to my redirects draft.)

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, October 5, 2016 3:29 PM
To: Dave Thaler <[email-masked]>; Oliver Kleine <[email-masked]>; [email-masked]
Subject: Re: [core] Implications of IP address / port changes for CoAP & Co

Hi Dave,

Cheers,
S.

---

From: Peter Saint-Andre - Filament <[email-masked]>
Date: Wed, 5 Oct 2016 17:03:50 -0600

> understand how to control their (ab)use.

By "identifier" do we necessarily mean "network identifier"? It seems to 
me that it is useful to have a unique long-term identifier for every 
device, based on its public key. Whether you can obtain a network 
connection to that device based on such information is another story.

Peter

-- 
Peter Saint-Andre
https://filament.com/

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 6 Oct 2016 00:07:26 +0100

On 06/10/16 00:00, Dave Thaler wrote:
> For privacy, it is also important that the UUID not be disclosed to
> untrusted parties, but that it be disclosed only to trusted parties. 

Well, again I'm not sure I agree. (I do agree that we don't "dictate"
though:-)

I would argue that we ought not assume the existence of any long
term stable identifier when we don't need one.

That implies justifying each one.

And I'd further argue that each re-use of such ought also be similarly
justified.

The "disclose to trusted parties" thing is just too easy to end up
meaning "wave arms and hope all's well (knowing it won't be)"

S

PS: Note that I am not claiming that there is IETF consensus for
the above (but it'd be nice:-), it's just what I happen to think.

> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Wednesday, October 5, 2016
> 3:29 PM To: Dave Thaler <[email-masked]>; Oliver Kleine
> <[email-masked]>; [email-masked] Subject: Re: [core]
> Implications of IP address / port changes for CoAP & Co
> 
> 
> Hi Dave,
> 
> Considering the privacy implications I'm not at all sure I'd accept
> that argument. In fact I'd argue we ought encourage that devices not
> have globally unique long-term identifiers at all unless there is a
> real need for those, and unless we understand how to control their
> (ab)use.
> 
> Cheers, S.
> 
>

---

From: Mohit Sethi <[email-masked]>
Date: Wed, 5 Oct 2016 19:10:42 -0400

What is trusted today, may not be trusted tomorrow (servers get 
compromised all the time). But once revealed, there is no way of going 
back.

Thanks
/--Mohit

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 6 Oct 2016 00:11:26 +0100

Hi Peter,

> connection to that device based on such information is another story.

It is undoubtedly useful to have long term stable identifiers of
various kinds. I'd include key IDs and public keys as such.

Turns out that it's also fairly universally privacy unfriendly
as people will abuse such identifiers for good and bad reasons.

So I think we need to get much better at analysing when such
things are really needed and in what scope. My bet is that a lot
of the time a locally or probabilistically unique more transient
identifier would be just fine.

But yeah, I can't prove that. OTOH there is a hint in the term
"IMSI catcher" isn't there?

Cheers,
S.

---

From: Peter Saint-Andre - Filament <[email-masked]>
Date: Wed, 5 Oct 2016 17:30:01 -0600

> as people will abuse such identifiers for good and bad reasons.

I'd be curious to learn more about the attack surface here. But I 
realize this is probably not a CORE WG topic; is there a better venue?

Peter

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 6 Oct 2016 00:33:37 +0100

> realize this is probably not a CORE WG topic; is there a better venue?

Two IETF list options I guess:

- perpass list if for a general discussion of privacy unfriendliness
of identifiers in protocols and we can see where it goes from there

- saag list if for a more IETF-process oriented discussion of how to
handle (new) identifiers in IETF protocols (I suggest this because
we're in the process of revising RFC3552 (the guidelines on what to
put in security considerations) so guidance on this topic would be
relevant to suggest as part of that

Feel free to kick off a thread on either

Cheers,
S.

---

From: Peter Saint-Andre - Filament <[email-masked]>
Date: Wed, 5 Oct 2016 17:37:43 -0600

> Feel free to kick off a thread on either

The perpass list sounds best. See you there! ;-)

Peter

-- 
Peter Saint-Andre
https://filament.com/

---

From: Peter Saint-Andre - Filament <[email-masked]>
Date: Wed, 5 Oct 2016 17:59:02 -0600

> The perpass list sounds best. See you there! ;-)

Posted:

https://mailarchive.ietf.org/arch/msg/perpass/i3djUQopTtC35LEHSDOpAtY22Jg

Peter

-- 
Peter Saint-Andre
https://filament.com/