----- Original Message -----
> Hi all,
>
> I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document
> and you can find the result at https://github.com/tlswg/tls13-spec/pull/512
>
> I have worked on a prototype implementation of DTLS 1.3 and if someone
> else has something working by the time of the Hackathon in Berlin please
> let me know.
May I recommend a more radical approach for DTLS? My experience with servers
handling DTLS traffic from various clients is that the clients change IPs (while
roaming) and incoming ports (due to firewall state timeout), making impossible
for the server to map the encrypted incoming packets from unknown IP/port
combinations
to any particular handler (i.e., handling process/thread or logical handler).
That
is because an independently received DTLS record packet has no session
identifying
information.
For that I'd like to propose the DTLS record format to include at least a
3-byte identifier which will allow servers to recognize streams coming from
unknown
sources. That would be similar to the SPI field in the ESP packets. That is,
a format similar to:
struct {
ContentType type;
ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */
uint24 id;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
where id is sent by the server to the client either via an extension, or
by simply assuming that the client will copy and keep the ID seen at the
server packets (it doesn't really matter that this ID is unprotected as
it doesn't contribute nor affect the security in any way).
regards,
Nikos
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
