On Wed, Oct 18, 2017 at 9:39 AM, Simon Bernard <cont...@simonbernard.eu>
wrote:
> This makes me think about if this is feasible/desirable to use connection
> id to do load balancing.
>
> I think about use cases where you have a cluster of server behind only one
> IP address. Often traffic will be load balanced by IP.
> But with UDP and Nat environment, the IP can change.
>
> Thx to CID, if client is redirected to the same server in the cluster,
> even if its IP has changed it will be able to communicate without new
> handshake.
> But if its IP has changed there is little chance than load balancer will
> balance it on the same server and so new handshake is needed. (unless
> server share their connection state)
>
The usual procedure is for the server and load balancer to coordinate on
the CID algorithm.
A trivial version would be for the server to generate the connection ID as
<server-id> || <random>.
-Ekr
>
> Any thought about that ?
>
>
>
> Le 17/10/2017 à 23:35, Martin Thomson a écrit :
>
>> On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia -
>> GB/Cambridge, UK) <thomas.foss...@nokia.com> wrote:
>>
>>> The following case (NAT box reboot) is problematic:
>>>
>>> 1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on
>>> host B (B.1);
>>> 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1;
>>> 3. The NAT box reboots (all previous 5-tuple mappings are lost);
>>> 4. B.1 receives a record from A.1 (whose 5-tuple has changed in the
>>> meanwhile);
>>>
>>> How is B.1 supposed to correctly interpret the bytes starting at offset
>>> +11? (For what it knows, it could be CID from A.1 or the length field
>>> from A.2.)
>>>
>> I don't think that this is a problem.
>>
>> connection = five_tuples.lookup(packet.five_tuple)
>> if (!connection) {
>> connection = connection_ids.lookup(packet[c
>> onnection_id_offset:connection_id_offset+connection_id_length])
>> }
>> if (!connection) {
>> // is this a ClientHello? otherwise drop it
>> }
>>
>> Of course this doesn't help you with A.2, but that's why this draft
>> exists.
>>
>> If the server can insist on connection IDs from all clients (in the
>> far future perhaps, or for an entirely new protocol), then the code is
>> more simply:
>>
>> connection = connection_ids.lookup(packet[connection_id_offset:connection
>> _id_offset+connection_id_length])
>> if (!connection) {
>> // is this a ClientHello? otherwise drop it
>> }
>>
>> I might be missing something fundamental here, but isn't the length
>>> encoded in the CID field on the wire?
>>>
>> Not by my understanding. There isn't any need (the intent is to have
>> the CID only consumable by the entity that created it, and any others
>> that it collaborates with, like a load balancer).
>>
>> _______________________________________________
>> 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
