Subject: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - some disruptive proposals

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 17 Jul 2020 20:25:28 +0000

Hi Jordi,
Sorry to overload you again.
Erik and Jen were right: draft does introduce new attack vectors. Because hosts are “sharing security fate” – they have proved it in many examples. Let’s disjoin hosts back.

1.     I propose to stop this guess-work who is IPv4-only and who is not. DNS query timeout synchronization between Happy Eyeball of particular host implementation and CLAT-NG (CLAT Next Generation) – is a very reliable path to disaster. What if somebody would change this timeout in next software release? What if timeout are very different on current hosts? (I am sure about Android and iOS difference)
I propose just to look to ND and ARP caches: if particular MAC has only binding to IPv4 and the same MAC does not have binding to IPv6, then it is our “optimization case”.

2.     NAPT44 does generate many issues that has been discussed on this mailing list.
I propose to return to stateless nature of CLAT. Let’s create separate EAMT table per every IPv4-only host (that has been discovered as eligible on the previous step of cache comparison).
Then translate it as today for CLAT (IPv4-Embedded IPv6 Address – clause 2 RFC 6052, but RFC 6877 clause 6.3 states that only /64 version should be used).
We could reuse exactly the same IPv6 address that we are using now for traffic to PLAT and prepare it by exactly the same rules.
IPv4 source would be visible (inside IPv6 source), but tracking would be difficult because would be millions of such 192.168.1.x. I do not believe that any randomization is needed (could be added if somebody would insist).
Technically, it could be one EAMT, just it should have source IPv4 as the key field. EAM table does not need IPv4 prefix (of LAN subnet).

3.     The way how we would search for proper destination IPv6 – we could keep as it is in the current version of the draft (query by proxy DNS, just it would be personal query for every host).

4.     If DNS (together with EAM record) would expire, but host would not pay attention to DNS TTL (application does not want to interrupt user session – that is proper behavior), then host could initiate new EAM record that could be resolved to different IPv6. It is not good idea to solve this problem by timers.
I propose to use EAM records forever (do not pay attention to DNS TTL timer), EAM record should be deleted only if (1) host would ask again for the same FQDN, or (2) ARP entry would be deleted – then all EAM entries related to this host should be deleted (in the case of static ARP it means –  (2) would never happen).
We would replicate host behavior: if he would ask – we would refresh, if he does violate protocol – we would do the same (for him). We should be transparent for him.

Good things:

·       It should resolve NAT-traversal issues, because IPv4:IPv6=1:1. Any global IPv6 could connect to this Private IPv4 (it would see it as IPv4-Embedded IPv6 Address). If IPv6 persistent (recommended for FBB), then subscriber could organize Web server on this private IPv4, it would be available for the whole Internet

·       No possibility for one IPv4 host to hijack connection of other IPv4 host (including the situation when one host pointed to foreign DNS – his FQDN request would be just not visible – EAM record for him would not be created)

·       If any strange configuration on server side (TLS SNI demux against IPv6 address demux, IPv4 only server share A record with DualStack server, clever CDN clusters configuration - many presented by Erik) – then client would behave like single dual stack client. If such client would not be served properly – then Server owner would have a big trouble anyway, because many other DualStack client world-wide

·       If DNS would resolve to AAAA, but no IP connectivity – then again: other DualStack clients would have the big trouble

·       Particular EAMT record could stick to only 1 destination IPv6 address, despite DNS Load Balancing, but it would be exactly the same if host would ask by itself, our CLAT-NG is transparent and personal

·       If user would modify DNS on CPE – it is fine – we would try to get AAAA from DNS server preferred by him. No AAAA answer -> no EAM record -> traffic would go to PLAT -> no problem

·       DNS poisoning would affect only 1 host – exactly the same situation as without any optimization

·       I do not see any problem with DNSSEC too – it could additionally check DNS answers

Currently discussed in the draft (and not fixed):

·       Only IPv6 backbone is down or link degraded (IPv4 is fine),- but we push traffic to IPv6 only☹

One visible restriction:

·       If subscriber would have big routed network inside, then ARP entry would not be visible on CPE. Next hop router would be Dual Stack. In such case: EAMT entry would not be created – traffic would go to PLAT

I have looked carefully to all comments of Jen, Erik, and Philip again. I have not found any holes left. Primarily, because in this proposal we are mimicking hosts individually – we are just “fully transparent in both directions”.

Eduard