Re: [core] DTLS and Epochs

Hi, 

> The issue :  this time this is not the peer with the dynamic IP address which must initiate the relation. 

As the IP address change at any side will invoke to establish a new DTLS association, 
the CoAP Observe entity should handle One Observation over different DTLS associations.
In current Observe standard context, One Observation is implied to be delivered only over one-unchanged DTLS.

> Another issue :  NAT timeout is sometime around 60s so for some use case we need to re-established observe relation each time we receive a notification ? 
> This is not the spirit of the observe feature.

When the IP address is changed, it is Inevitable to establish a new DTLS association, the CoAP Observer entity have to handle this change to keep the observe relations,
something as mentioned the connection ID proposed by Fossati draft-fossati-tls-iot-optimizations-00.

Making the spirit of the observe feature available, the CoAP client and CoAP server needs to have some abilities: 
1. to handle to establish a new DTLS association when IP address is changed;
2. to keep and understand an Observe relationship by some Identities;
3. to deliver the same Observation (Notifications) over different DTLS associations. 

Regards,

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

From: Simon Bernard 
Sent: Saturday, June 10, 2017 1:22 AM
To: weigengyu ; Carsten Bormann ; Kraus Achim (INST/ECS4) 
Cc: core@ietf.org 
Subject: Re: [core] DTLS and Epochs

This is the point. We agree that a new DTLS association must be established. It's ok as generally this is the peer which has a dynamic IP which will initiate this handshake. This is not optimal but this is ok (some solution is explored to optimize that like the connection ID proposed by Fossati draft-fossati-tls-iot-optimizations-00)

Let's suppose a peer with dynamic IP address is observed and send notification. When its IP address changes a new observe relation should also be established to respect the same epoch/same connection constraint. If we don't, observe notifications should be dropped. The issue :  this time this is not the peer with the dynamic IP address which must initiate the relation. Another issue :  NAT timeout is sometime around 60s so for some use case we need to re-established observe relation each time we receive a notification ? This is not the spirit of the observe feature.

Le 09/06/2017 à 18:23, weigengyu a écrit :

  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