Not sure, if some DTLS 1.2 history helps. Hope, it doesn't mix up more.
DTLS role exchange was an topic in DTLS 1.2. It was in discussion in LwM2M. > What I meant is that, isolated to a single path, an endpoint (A > or B) should only be a server or a client, not both at the same > time. So a single "ip:port" is not supposed to “initiate”/"run" > multiple isolated servers and clients at the same time. In DTLS 1.2 that causes race conditions and the easiest way out was to abandon the handshake and retry it with a random timeout. At retry it's unlikely, that both peers start the handshake. > 2. A single server serving multiple clients, where the clients share an > address. Not sure, if "address" is just the ip-address or the ip-address and service port. For the first it works in DTLS 1.2 CID, if the clients have different service ports. For the second it may depend on the implementation. My implementations of DTLS 1.2 CID don't support that. > 3. A single endpoint acting as both client and server on the same address. See the DTLS 1.2 role exchange discussion in LwM2M. Even if a "central server" is used, there are corner cases, when such a "DTLS 1.2 role exchange" seems to be the only escape. A NAT will frequently block that, but sometimes it may succeed. (I don't use this approach, but others may do.) best regards Achim Am 06.01.23 um 23:17 schrieb Eric Rescorla:
On Fri, Jan 6, 2023 at 9:59 AM Kristijan Sedlak <[email protected] <mailto:[email protected]>> wrote:On 6 Jan 2023, at 18:39, Eric Rescorla <[email protected] <mailto:[email protected]>> wrote: On Fri, Jan 6, 2023 at 9:28 AM Kristijan Sedlak <[email protected] <mailto:[email protected]>> wrote: > If I understand correctly, the issue here is a difference between DTLS and > "Datagram cTLS". In DTLS, the syntax allows a client to parse handshake > messages from the server and discover that the message is actually a > ClientHello. I don't know that this is a good idea, or actually > implemented anywhere, or even formally "allowed", but it's at least > syntactically possible. Yes. > In Datagram cTLS (as of -07), this is not possible. The parsing of > handshake messages depends on prior knowledge of who is the client and who > is the server. This is because CTLSServerPlaintext and CTLSClientPlaintext > are different structs, but they use the same ContentType. OK, "prior knowledge" explains everything :). I assumed all structures should be parsed as unique objects. RFC9146 and RFC9147 somehow confused me and made me think that by using CIDs it's allowed to reuse sockets A and B and then handle multiple connections through a single path. In that case you would have clients and servers on both sides. Inputs from this thread suggest that CIDs are meant for "NAT rebinding" purpuse only. Hmm, no, I don't think that's quite true. A server can serve multiple clients on the same 4-tuple using the CID. It's just that it will not generally act as a client.For sure, a server can serve multiple clients on the same address :). What I meant is that, isolated to a single path, an endpoint (A or B) should only be a server or a client, not both at the same time. So a single "ip:port" is not supposed to “initiate”/"run" multiple isolated servers and clients at the same time. There are three things going on here, not two. 1. A single server serving multiple clients, where the clients have different addresses. 2. A single server serving multiple clients, where the clients share an address. 3. A single endpoint acting as both client and server on the same address. DTLS allows (1) by default (2) with CID, and not (3). -Ekr-Ekr -Kristijan_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
