Re: [core] CoAP observation in NATed environment using DTLS

[Simon Bernard <[e-mail]>]

You're right both issue is not directly linked to observation.

1)About using host option, How does it works for DTLS session without 
authentication? I still prefer just adding the constraint "same DTLS 
identity or same session is there is no DTLS authentication" and let 
more flexibility to application on top of CoAP to handle this 
information. Each part of the stack have its own responsibility:
- DTLS provides authentication + encryption.
- CoAP ensure that request/response exchange are done for the same 
Identity. (when there is no authentication we just warranty exchange is 
done in the same session, this is the best we can do)
- Application layer authorize request based on this identity.

2) it's seems we head for a consensus about connectionID 
(draft-fossati-tls-iot-optimizations-00). The privacy concern could be 
handle by hash chain but would not be mandatory.
(https://mailarchive.ietf.org/arch/msg/core/a_cZN9nTkHoeETLXhBJAQWfYlp4)


Le 04/11/2016 à 09:20, Lauri Piikivi a écrit :
> Hi,
>
> I have battled with these issue a while. I think there are 2 very separate issues: COAP identity and DTLS connection ID, neither of which is only an observation issue
>
> = COAP identity =
>> 1) Define a long term identifier for CoAP instead of limited CoAP interaction to the same DTLS connection. At CoAP level users would like to know from which or to which they send data.
> With the strong focus on security, COAP starts with  the DTLS certificate or raw public key  information
> “9.1.3.3.  X.509 Certificates
> The discovery process used in the system
>     would build up the mapping between IP addresses of the given devices
>     and the subject for each device.”
>
> COAP is based on URLs. And the URL must have a host part. Host can be IP address (with problems when IP changes) or a DNS name (that needs to be mapped and maintained in DNS registry) or some other long term identifier like certificate subject name.
> “   6.1.  coap URI Scheme
>     If host is a registered name, then that name is considered an indirect identifier
>     and the endpoint might use a name resolution service, such as DNS, to
>     find the address of that host.  The host MUST NOT be empty”
>
> So there is mechanisms to define a long lasting name or identifier for the host and the resources it publishes.
>
> I would suggest for the observation problem that the responses have the URI-Host option with the long lasting identifier of the device? The spec needs changing so that the DTLS session can change. If the DTLS session changes, but is accepted on DTLS layer, the application layer gets the new information that it maps using  it’s own mechanism of URI-host. Additional checking can be done that the host id matches the certificate subject for example. Newest IP and port is then known
>
> Having the URI-host in responses supports the nosec mode, which is still mandatory in 7252.
>
> This is a minor issue for the draft https://tools.ietf.org/html/draft-ietf-core-resource-directory-09. For registry (publishing COAP URLs) there might be need to define more structure to the host part, is it a DNS resolvable name or is a mapping that is understood in the registry itself? How is a client of the registry to know? Should there be a service that maps the non-DNS identity to IP?
>
> = (D)TLS Connection ID =
>> 2) Be able to use DTLS with dynamic IP address (e.g. NAT) without the need to redo full handshake or resume handshake.
> This is not tied to observation, any long lasting session where there is very little data sent will fail due to NAT in the path. I think the problem is most in DTLS, since there the NAT's ip/port mapping timeout is more aggressive and the devices usually communicate only  seldomly. It is almost guaranteed that the DTLS connection will not stay alive in NAT.  RFC5382 for TCP talks of 2-hours, and RFC4787 for UDP NAT behaviour talks of 4-minutes
>
> So to map the sent DTLS records at receiver, even if a NAT mapping changes along the way, the record would need the connection ID so that the servers find the correct DTLS context for the record. Now the spec says the context is found with ip/port information.
>
> I understand the privacy concerns for IoP (internet of people), but could there be something easy for IoT — if privacy is not an issue? Mechanism that allows t meet both concerns.
>
> BR
> - Lauri
>
>
>
>> On 03 Nov 2016, at 20:03, Simon Bernard <[e-mail]> wrote:
>>
>> Hi list,
>>
>> I have attended meeting of the T2T RG in Ludwigsburg, there is a discussion around CoAP observation in NATed environment using DTLS (1.2).
>>
>> I would like to share my thought here about that:
>>
>>     The problem :
>> Currently the CoAP spec say :
>> "All notifications resulting from a GET request with an Observe Option MUST be returned within the same epoch of the same connection as the request."
>> Currently, in TLS, a connection is identified by its IP/Port address.
>> So when your IP address changed because of the NAT expiration, you must create a new TLS connection and so create a new CoAP observation relation.
>>
>>     Behind this practical problem, I understand there is 2 separated issue :
>> 1) Define a long term identifier for CoAP instead of limited CoAP interaction to the same DTLS connection. At CoAP level users would like to know from which or to which they send data.
>> 2) Be able to use DTLS with dynamic IP address (e.g. NAT) without the need to redo full handshake or resume handshake.
>>
>>     Possible Solutions ?
>> 1) Using the DTLS identity (PSK identity for PSK, public key for RPK, CN for certificate, ...) and only if there is no authentication the DTLS Session as constraint for CoAP exchange. (we remove the same epoch/same connection constraint)
>> 2) Using the "connectionId" extension proposed in the draft-fossati-tls-iot-optimizations-00.
>>
>> Does it make sense  ?
>>
>> Simon
>>
>> _______________________________________________
>> 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.