Sort of. Client uses one HOTP value from the sequence at a time, until it sees fit — for example, until it's on the same network attachment.
When attachment changes (and its transport identifiers with it), before sending a new packet, it picks the next HOTP and sticks it in the record. When Server sees this, it switches CID accordingly. From: Martin Thomson <martin.thom...@gmail.com<mailto:martin.thom...@gmail.com>> Date: Tuesday, 15 November 2016 10:12 To: "Fossati, Thomas (Nokia - GB)" <thomas.foss...@nokia.com<mailto:thomas.foss...@nokia.com>> Cc: Nikos Mavrogiannopoulos <n...@redhat.com<mailto:n...@redhat.com>>, "tls@ietf.org<mailto:tls@ietf.org>" <tls@ietf.org<mailto:tls@ietf.org>>, Hannes Tschofenig <hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>> Subject: Re: [ALU] Re: [TLS] extending the un-authenticated DTLS header Okay, so you are saying that every packet has the same number? On 15 Nov 2016 6:30 PM, "Fossati, Thomas (Nokia - GB)" <thomas.foss...@nokia.com<mailto:thomas.foss...@nokia.com>> wrote: On 15/11/2016 09:20, "TLS on behalf of Martin Thomson" <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org> on behalf of martin.thom...@gmail.com<mailto:martin.thom...@gmail.com>> wrote: >This means that you can guarantee privacy, but it forces >the server to do an exhaustive search of all of its active connections >(that is, O(N)) when it gets a 5-tuple mismatch. I don't think I follow. You'd use CID as primary key to index your security contexts. So, regardless your 5-tuple matches or not you'd do your O(1) lookup in the CID table and find the associated security context.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
