[v6ops] Re: Fwd: New Version Notification for draft-link-v6ops-claton-03.txt

[Jen Linkova <[e-mail]>]

Hi George,

Sorry for the delayed response, catching up with emails post-vacation..

On Sat, May 25, 2024 at 9:15 AM George Michaelson <[e-mail]> wrote:
> In practice what does "disabling CLAT" look like. Is it different to a classic DHCP renegotiate with address change? Or a v6 privacy address change?

I'm not sure how much should be specified in this doc, and how much
should be left to implementations to decide.
How about we update the text to say that the node should remove the
clat IPv4 address and the corresponding default route?

> What happens to active bound associations through the CLAT basically. "Stop" can be sudden or graceful but graceful incurs timer and tail cost.

The main reason to disable CLAT immediately upon obtaining native IPv4
connectivity is to mitigate an attack.
Practically it means that if the node has CLAT running and then IPv4
appears, there is a pretty good chance that existing CLAT flows are
affected by either MitM or DoS. Therefore it would make sense to tear
them down anyway and let them re-establish over native IPv4.
Would you like this to be explicitly clarified in the text?

> "While disabling CLAT is impactful for all applications and traffic flows already utilizing CLAT, it is recommended not only from performance perspective, but also from security point of view."
>
> I think a little more is needed. Active TCP connections will fail in flight. Quic and other address agile session models will be robust but other applications and protocols may not be. Cached rtt and other structural state will no longer apply and path selection through the upstream which shards on the 5 tuple will change.

So would you like to elaborate on details of the impact? I'm just not
sure how much value it would add to the draft but happy to add more
text there.

> On Sat, 25 May 2024, 2:13 am Jen Linkova, <[e-mail]> wrote:
>>
>> Hello,
>>
>> Here is the updated version of the CLAT recommendations draft.
>> The key changes:
>> - some sections are reordered to improve readability
>> - the draft now recommends disabling CLAT as soon as IPv4 connectivity
>> becomes available (not doing so would have not just performance
>> implications but security ones as well)
>> - a (simplified) diagram is added to illustrate the logic of enabling
>> and disabling CLAT.
>>
>> Comments are appreciated.
>>
>>
>>
>> ---------- Forwarded message ---------
>> From: <[e-mail]>
>> Date: Sat, May 25, 2024 at 1:54 AM
>> Subject: New Version Notification for draft-link-v6ops-claton-03.txt
>> To: Jen Linkova <[e-mail]>, Tommy Jensen <[e-mail]>
>>
>>
>> A new version of Internet-Draft draft-link-v6ops-claton-03.txt has been
>> successfully submitted by Jen Linkova and posted to the
>> IETF repository.
>>
>> Name:     draft-link-v6ops-claton
>> Revision: 03
>> Title:    464 Customer-side Translator (CLAT): Node Recommendations
>> Date:     2024-05-24
>> Group:    Individual Submission
>> Pages:    14
>> URL:      https://www.ietf.org/archive/id/draft-link-v6ops-claton-03.txt
>> Status:   https://datatracker.ietf.org/doc/draft-link-v6ops-claton/
>> HTML:     https://www.ietf.org/archive/id/draft-link-v6ops-claton-03.html
>> HTMLized: https://datatracker.ietf.org/doc/html/draft-link-v6ops-claton
>> Diff:     https://author-tools.ietf.org/iddiff?url2=draft-link-v6ops-claton-03
>>
>> Abstract:
>>
>>    464XLAT ([RFC6877]) defines an architecture for providing IPv4
>>    connectivity across an IPv6-only network.  The solution contains two
>>    key elements: provider-side translator (PLAT) and customer-side
>>    translator (CLAT).  This document provides recommendations on when a
>>    node shall enable or disable CLAT.
>>
>>
>>
>> The IETF Secretariat
>>
>>
>>
>>
>> --
>> Cheers, Jen Linkova
>>
>> _______________________________________________
>> v6ops mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]



-- 
Cheers, Jen Linkova