Re: [core] DTLS and Epochs

Hi all,

In DTLS there is a formal to calculate a cookie: 
      Cookie = HMAC(Secret, Client-IP, Client-Parameters)
Cookie is related to the Client-IP address and used during DTLS handshakes. 

If the IP address is changed just during handshanke stage, the handshake will not continue.  
Then it must start a new DTLS shandshake with the new IP address.

If the IP address is changed during DTLS record delivery after a successfule handshake, 
the DTLS record carried in a new IP address would be treated to belong to a different DTLS association. 
In a receiving side with an unchanged IP address, the DTLS record would be regarded as an invalide one to be discarded according to RFC6347. 

So, for CoAP Observe if the IP address is changed, a new DTLS association must be establishied. 

Regards,

Gengyu WEI
Network Technology Center
School of Computer 
Beijing University of Posts and Telecommunications

From: Simon Bernard 
Sent: Friday, June 09, 2017 6:35 PM
To: Carsten Bormann ; Kraus Achim (INST/ECS4) 
Cc: core@ietf.org 
Subject: Re: [core] DTLS and Epochs

Hi,

  We faced this issue when we tried to make observe work behind NAT in a LWM2M context.

  My understanding is  "same epoch" means implicitly "same DTLS connection too" which is a real issue in dynamic IP address environment (as DTLS connection is identified by IP address). "same epoch" means "no TLS renegociation".

  IMHO, "same epoch/connection" should be replaced by "same identity" (PSK identity for PSK, public key for RPK, CN for certificate) for authenticated peer or "same session" for non-authenticated. In case you want to allow TLS renegotiation you should add "same cipher" too. But TLS renegotiation seems to be not advisable for DTLS 1.2 : https://tools.ietf.org/html/rfc7925#section-17 and removed to DTLS 1.3 last time I looked at it.

  I initially think about that for observe request, but maybe it can be generalized to all request/response correlation.

  Here some discussion about this idea :
     - https://www.ietf.org/mail-archive/web/core/current/msg08019.html
     - https://www.ietf.org/mail-archive/web/core/current/msg08004.html

Simon

Le 08/06/2017 à 11:08, Carsten Bormann a écrit :

On Jun 8, 2017, at 10:17, Kraus Achim (INST/ECS4) mailto:Achim.Kraus@bosch-si.com wrote:
It's still unclear to me, if this should be considered to be the "same epoch" in the meaning of RFC7252.   

I pointed to that last summer (https://www.ietf.org/mail-archive/web/core/current/msg07816.html) but I could get clarification on that.
I think that we can agree that the current definition is
— not fully clear
— unrealistic in certain implementation environments (so it may not actually be implemented)
— unnecessarily restrictive.

Now the next question is what definition would
— make sense from an implementers’ point of view
— not be unnecessarily restrictive
— retain the desirable security properties of the current restrictive definition
- be clear
- maybe also make sense for DTLS 1.3 (which isn’t fully baked yet).

(And then we have to figure out the process for fixing it — that is not too hard once we know the extent of the change that needs to me made.  E.g., an RFC updating RFC 7252.)

Grüße, Carsten

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

--------------------------------------------------------------------------------
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core