Sorry, too fast and unprecise.
Corrections:
At retry it's unlikely, that both peers start the handshake at the same
time.
> > 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. For the second it may depend on the
> implementation. My implementations of DTLS 1.2 CID don't support that.
That refers to a handshake at the same time. For handshakes at different
times or later traffic that's supported.
best regards
Achim
Am 07.01.23 um 08:43 schrieb Achim Kraus:
Not sure, if some DTLS 1.2 history helps. Hope, it doesn't mix up more.
DTLS role exchange was an topic in DTLS 1.2.
It was in discussion in LwM2M.
> 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.
In DTLS 1.2 that causes race conditions and the easiest way out was
to abandon the handshake and retry it with a random timeout. At retry
it's unlikely, that both peers start the handshake.
> 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. For the second it may depend on the
implementation. My implementations of DTLS 1.2 CID don't support that.
> 3. A single endpoint acting as both client and server on the same
address.
See the DTLS 1.2 role exchange discussion in LwM2M.
Even if a "central server" is used, there are corner cases, when
such a "DTLS 1.2 role exchange" seems to be the only escape. A
NAT will frequently block that, but sometimes it may succeed.
(I don't use this approach, but others may do.)
best regards
Achim
Am 06.01.23 um 23:17 schrieb Eric Rescorla:
On Fri, Jan 6, 2023 at 9:59 AM Kristijan Sedlak <xpeperm...@gmail.com
<mailto:xpeperm...@gmail.com>> wrote:
On 6 Jan 2023, at 18:39, Eric Rescorla <e...@rtfm.com
<mailto:e...@rtfm.com>> wrote:
On Fri, Jan 6, 2023 at 9:28 AM Kristijan Sedlak
<xpeperm...@gmail.com <mailto:xpeperm...@gmail.com>> 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
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
