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

From: "Kraus Achim (INST/ESY1)" <[email-masked]>
Date: Thu, 1 Sep 2016 09:12:34 +0000

Hi Hannes,

thank you! 
I appreciate your writing, because it sum up the critical topics using CoAP and DTLS in an IPv4 environment.

The current "work around" for DTLS may be to always emit a "DTLS session resume", if the last sent
message was some time ago, unfortunately the "some time" is rather small an just a couple of seconds.

The observe seems for me only be usable, if we expect frequently notifies (also just a couple of seconds).
Any other usage of observe (say for notifies just for a couple of minutes or longer), seems for me raising
issues. Even, if we use the DTLS resume approach above, the "epoch" seems to be just the same "number",
but in fact, this is more the result, that epoch 1 is the first after a successful handshake then really the same
(so RFC7252 9.1.2 . "The DTLS session MUST be the same, and the epoch MUST be the same." smells to
be faked. Some statement from encryption experts may be required).    

Mit freundlichen Grüßen / Best regards

Achim Kraus

Bosch Software Innovations GmbH
Communications (INST/ESY1)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com 

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn

-----Ursprüngliche Nachricht-----
Von: core [mailto:[email-masked]] Im Auftrag von Hannes Tschofenig
Gesendet: Mittwoch, 31. August 2016 12:37
An: [email-masked] WG <[email-masked]>
Betreff: [core] Implications of IP address / port changes for CoAP & Co

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

---

From: "Hudalla Kai (INST/ESY1)" <[email-masked]>
Date: Tue, 6 Sep 2016 07:23:19 +0000

Hannes,

thanks for spawning this thread. As one of the committers for the
Californium CoAP stack I can tell you that we are currently struggling
quite a lot with the "ambiguity" of the CoAP spec when it comes to
definition and "identifying characteristics" of Endpoints and its
implications on request/response matching.

I have made some comments below...

Regards,
Kai

On Mi, 2016-08-31 at 12:36 +0200, Hannes Tschofenig wrote:
> 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).
> 
I don't think that the CoAP protocol "breaks" when a peer's IP address
(or port) changes. The problem is more that the way CoAP's strict
request/response matching rules currently prevent some of the more
interesting use cases (observing resources) to be implemented with
constrained devices connected to IPv4 networks via NATed firewalls
(which is basically EVERY device connected via a mobile network
carrier).

> 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
> 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 particular, the definition is referring to missing information.
Section 9 simply doesn't contain any information regarding the
identifying characteristics (at the CoAP layer) of an endpoint when
using any of the non-NoSec security modes. Or at least it is unclear
whether the device's "identity" established by means of authenticating
it e.g. based on a PSK or a certificate is also meant to be used as the
endpoint identity at the CoAP protocol level. IMHO that is not the case
and that is also why we are always just using the IP address and port
number as the identifying characteristics of an endpoint.

> 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.
> 
The client could indeed use an abbreviated handshake, i.e. resume the
DTLS session, if it were aware of the fact that its IP address or port
had changed during its last sleep cycle. However, for that the client
would probably need to use something like STUN first ...

> 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.
> 
I agree, that chance is minimal. The more prevalent problem is that
with constrained devices like small sensor nodes which sleep most of
the time, the probability that they wake up and use a new IP address
(or a new port) for outbound UDP packets is close to 1.

> 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:
> 
> "
> 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 more interesting problem is how we deal with a changed IP
address/port on the CoAP server side, i.e. when a client has started to
observe a resource on the server and now expects notifications coming
in from that server. When the server's (the constrained device's) IP
address or port changes, it sends out notifications (CoAP responses)
with a different source endpoint than what the client expects.

The CoAP specs states in section 9.1.2:

"The following rules are added for matching a response to a request:
The DTLS session MUST be the same, and the epoch MUST be the same.

This means the response to a DTLS secured request MUST always be DTLS
secured using the same security session and epoch.  Any attempt to
supply a NoSec response to a DTLS request simply does not match the
request and therefore MUST be rejected (unless it does match an
unrelated NoSec request)."

my understanding of this paragraph is that any notification received
from a server after its IP address or port has changed must be
discarded/rejected by the client. However, this is based on the
assumption that the "identifying characteristics" of an endpoint (using
DTLS) are still the IP address and port, hence "rules are _ADDED_ for
matching a response to a request".

Maybe the authors of the CoAP spec could provide some insight whether
this is indeed what they wanted to imply or whether they simply forgot
to add some more information regarding the "identifying
characteristics" of an endpoint when using one of the non-NoSec
security modes with DTLS.

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

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Tue, 6 Sep 2016 08:55:02 +0000

Hi Kai,

>would probably need to use something like STUN first ...

Yep.

>security modes with DTLS.

The "Transport Agnostic SAs" proposal in the following draft might
probably help:

https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00#section-
4

Cheers, t

---

From: Lauri Piikivi <[email-masked]>
Date: Tue, 6 Sep 2016 09:28:21 +0000

Hi alls,

When the IP / port changes, the DTLS will fail as it can not map the received message to a session. DTLS says (https://tools.ietf.org/html/rfc6347#page-8)
"Note that unlike IPsec, DTLS records do not contain any association
   identifiers.  Applications must arrange to multiplex between
   associations.  With UDP, this is presumably done with the host/port
   number.”
I assume that a DTLS alert is sent back.

Often the load balancers will already fail similarly, they direct the message to wrong server in the server pool based on the ip / port.

BR,
- Lauri

> On 06 Sep 2016, at 11:55, Fossati, Thomas (Nokia - GB) <[email-masked]> wrote:
>
> Hi Kai,
>

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.