Hi,
Here are the scenarios we would be interested to see covered by this CID
extension.
1. Clients in unstable IP environment (like NAT)
2. stateless middlebox (like load balancer) with mixed CID and no CID
connections.
3. stateless packet introspection (wireshark), with mixed CID and no CID
connections.
Linkability is not an issue for us, we have almost the same kind of
linkability than with fixed IP.
Point 1. seems already supported.
Points 2. and 3. seems not ok for now because its not so easy to know if
a record contains a CID or not.
To know if a record contains a CID, the proposed solution in this thread
are:
- using content type (not sure to see how?)
- using version (not available in DTLS 1.3? impact on current
implementation?)
- add a MAC for CID (bandwidth cost?)
I don’t know which one could be the best, but I have one question: how
to know the CID length for stateless middlebox or packet introspector ?
Simon
Le 03/11/2017 à 11:12, Matt Caswell a écrit :
On 03/11/17 09:28, Martin Thomson wrote:
On Fri, Nov 3, 2017 at 8:15 PM, Matt Caswell <m...@openssl.org> wrote:
It was my understanding that it is precisely this sort of problem that
this draft was attempting to address. Explicit marking would solve this.
Yes, and the connection ID is that marking. The contention - I think
- is what to do when there is a mix of marked connections and
unmarked.
Right - where you have a mix of packets with connection ID and no
connection ID you don't know whether to look for one or not. IMO this
draft won't really be addressing the issues unless it includes a
mechanism for determining that.
Matt
_______________________________________________
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
