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 <mailto:contact@simonbernard.eu>
> *Sent:* Friday, June 09, 2017 6:35 PM
> *To:* Carsten Bormann <mailto:cabo@tzi.org> ; Kraus Achim (INST/ECS4) 
> <mailto:Achim.Kraus@bosch-si.com>
> *Cc:* core@ietf.org <mailto: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