On Mon, Jul 04, 2016 at 03:54:19PM -0400, Nikos Mavrogiannopoulos wrote: > ----- 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.
I think in DTLS 1.2, that was meant to be handled at lower layer (of course, often there isn't such layer even when needed). > 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: One can't change the headers in ClientHello/ServerHello and expect to remain backwards compatible. And how would that identifier be assigned? 0 in ClientHello, then copy whatever the server sends? -Ilari _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
