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

[Lauri Piikivi <[e-mail]>]

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) <[e-mail]> wrote:
>
> Hi Kai,
>
> On 06/09/2016 08:23, "core on behalf of Hudalla Kai (INST/ESY1)"
> <[e-mail] on behalf of [e-mail]> wrote:
>>> 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 ...
>
> Yep.
>
>> 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 "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
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>

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.