On Tue, Apr 20, 2021 at 3:42 PM John Scudder <j...@juniper.net> wrote:
> On Apr 20, 2021, at 5:32 PM, Eric Rescorla <e...@rtfm.com> wrote: > > 3. Section 6: >> >> * There is a strategy for ensuring that the new peer address is able >> to receive and process DTLS records. No such strategy is defined >> in this specification. >> >> This is a little mind-boggling to me. I understand this to mean I can’t >> send >> the new address a DTLS record unless I’ve already ensured it can receive >> and >> process that record, right? This seems almost like a classic Catch-22. I >> feel >> like I must be missing something. > > > This specification *only* allows you to mux, but doesn't allow you to > migrate. > We could probably make this point clearer. > > > Yes, I think so. Various things led me to think this was supposed to be a > feature. For starters, the abstract: > > A CID is an identifier carried in the record layer header that gives > the recipient additional information for selecting the appropriate > security association. In "classical" DTLS, selecting a security > association of an incoming DTLS record is accomplished with the help > of the 5-tuple. If the source IP address and/or source port changes > during the lifetime of an ongoing DTLS session then the receiver will > be unable to locate the correct security context. > > > It’s true the abstract doesn’t promise that I can migrate to the new > address, but I felt led in that direction. But more to the point, §6 itself: > > When a record with a CID is received that has a source address > different than the one currently associated with the DTLS connection, > the receiver MUST NOT replace the address it uses for sending records > to its peer with the source address specified in the received > datagram unless the following three conditions are met: > > > If I understand your reply correctly, the quoted sentence could end “… > unless the following three conditions are met (which will never happen):”. > Since that seems both capricious and pointless, I still think I’m missing > something. Is it that you envision a future specification that does define > a strategy that will fulfill the third condition? > Yes. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
