On Wed, Jan 4, 2023 at 8:34 AM Kristijan Sedlak <xpeperm...@gmail.com> wrote:
> 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. > In my experience this is not actually how these systems work. The reason is that those devices are usually end-user devices and are often behind NATs, so they need to use some protocol like ICE to do NAT traversal. Those protocols are able to establish who is who as part of the process. This is how WebRTC works, for instance. -Ekr > 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> wrote: > >> On Wed, Jan 4, 2023 at 7:50 AM Kristijan Sedlak <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 >>> https://www.ietf.org/mailman/listinfo/tls >>> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
