> OK. Well, I believe that CID *can* handle this. Do you think otherwise?
As I wrote in the second mail: "Sorry, too fast and unprecise." Reading the other messages in this thread, I assume, that it mainly refers to handshakes at the same time. But I missed in my first e-mail to be clear at that. Under the precondition, that the handshake are executed at the same time, I belief DTLS 1.2 CID *can not* handle this. For the handshake messages of epoch 0 no cid-records are used, therefore parallel handshakes requires distinguished endpoints. best regards Achim Am 07.01.23 um 18:52 schrieb Eric Rescorla:
On Fri, Jan 6, 2023 at 11:43 PM Achim Kraus <[email protected] <mailto:[email protected]>> wrote: > 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. You don't need CID for demultiplexing in this case. For the second it may depend on the implementation. My implementations of DTLS 1.2 CID don't support that. OK. Well, I believe that CID *can* handle this. Do you think otherwise? > 3. A single endpoint acting as both client and server on the same address. See the DTLS 1.2 role exchange discussion in LwM2M. I don't follow LwM2M, but DTLS-SRTP already handles this case. See: https://www.rfc-editor.org/rfc/rfc5763#section-5 <https://www.rfc-editor.org/rfc/rfc5763#section-5> If you're aware of cases where this design does not correctly handle the situation, please surface them... -Ekr 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]> > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > >> On 6 Jan 2023, at 18:39, Eric Rescorla <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> >> >> >> On Fri, Jan 6, 2023 at 9:28 AM Kristijan Sedlak >> <[email protected] <mailto:[email protected]> <mailto:[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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
