Yes, I'm referring to P2P networks. Hum … let me try to explain. Imagine a group of computers discovering each other through Kademilia or similar. Each endpoint is required to connect to N remote nodes so it can then in theory access all parts of the network. Each endpoint uses a single socket address, communicates over UDP, and can accept connections or can initiate them. A socket can serve multiple virtualized clients thus DTLS CIDs are used. Endpoints go live and then disappear - so you don't really know who's a client and who's a server. In case a connection has already been established by some initiator then you don't need to initiate a new connection when "the algorithm" requires connection establishment.
I hope the above makes sense. K > On 4 Jan 2023, at 17:10, Eric Rescorla <e...@rtfm.com> wrote: > > > > On Wed, Jan 4, 2023 at 6:30 AM Ben Schwartz > <bemasc=40google....@dmarc.ietf.org <mailto:40google....@dmarc.ietf.org>> > wrote: >> On Wed, Jan 4, 2023 at 7:50 AM Kristijan Sedlak <xpeperm...@gmail.com >> <mailto:xpeperm...@gmail.com>> wrote: >>> Hey, >>> >>> The record layer of the cTLS skips the "profile_id" in the >>> CTLSServerPlaintext. I wonder how will an endpoint correctly distinguish >>> between multiple, CID-ext-based CTLSClientPlaintext requests and >>> CTLSServerPlaintext responses when the same socket is used for client and >>> server communication. >> >> It sounds like you are thinking about cases where (1) a single 5-tuple can >> be used for DTLS in both directions, (2) the parties have not already agreed >> who will be the client and who will be the server, and (3) there can be >> multiple handshakes in flight simultaneously. In this case, a party who >> sends a ClientHello might receive a ServerHello, HRR, or a racing >> ClientHello in response. This is not a use case I had thought about. Is >> this considered a supported configuration for DTLS (with Connection IDs)? > > When would this actually happen? In my experience the only situation in which > there is ambiguity about who will be the client and the server are p2p-style > applications and those need ICE for NAT traversal, so you already have a way > of determining who is who. > > -Ekr > > > >> >>> I believe there should be a different content_type for a request and >>> response or just a requirement that the response always has `profile_id=0` >>> or smth. >> >> If we decide this use case is in-scope, I would add a content_type to >> distinguish the roles. I'm interested to hear if people feel this use case >> is in scope. >> >>> I hope I'm not reacting too fast and thus my writing makes sense. >>> >>> K >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org <mailto:TLS@ietf.org> >>> https://www.ietf.org/mailman/listinfo/tls >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org <mailto:TLS@ietf.org> >> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
