On Fri, Jan 6, 2023 at 11:43 PM Achim Kraus <[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 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]>> 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
