These types of distributed systems generally have unique node IDs that would allow tie-breaking, assigning the server and client role consistently for each pair. Would that be sufficient, or is there a need for either end to be able to initiate the connection?
On Wed, Jan 4, 2023 at 11: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. 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 > > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
