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:core-bounces@ietf.org] Im Auftrag von Hannes Tschofenig
Gesendet: Mittwoch, 31. August 2016 12:37
An: core@ietf.org WG <core@ietf.org>
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
core@ietf.org
https://www.ietf.org/mailman/listinfo/core