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

From: Vasilenko Eduard <[email-masked]>
Date: Sat, 18 Jul 2020 07:37:17 +0000

Hi Jordi,
I have clarified a little below. Use this version.
Eduard
From: Vasilenko Eduard
Sent: 17 июля 2020 г. 23:27
To: 'JORDI PALET MARTINEZ' <[email-masked]>
Cc: 'V6 Ops List' <[email-masked]>
Subject: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - some disruptive proposals

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 translation. 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).
CLAT translation would become stateless again. But in general CLAT would be stateful, because decision about destination IPv6 (PLAT or real Internet resource) should be done almost per-flow (for source IPv4 + destination IPv4) that was lucky to create a state in EAMT.

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).
We could reuse now Happy Eyeball (RFC 8305) for double DNS requests with all associated timers, because FQDN request is personal now (just for one App of one Host). Part of HEv2 could be on proxy CPE (on behalf of IPv4 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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 19 Jul 2020 16:18:36 +0200

Hi Eduard,

Tks a lot!

I just sent a tentative text as part of the responses to Philip. See below, anyway.

El 18/7/20 9:37, "Vasilenko Eduard" <[email-masked]> escribió:

Hi Jordi,

Eduard

From: Vasilenko Eduard 

Hi Jordi,

[Jordi] Actually a pleasure to get so many good inputs!

[Jordi] Yep, this seems to be a very good solution, even if it has a few drawbacks, is a good trade-off. 

[Jordi] Not sure if I got it correctly. I don’t think so. If we use the addresses as in a non-optimized CLAT, they are synthetized, so they will naturally follow the PLAT path – this is what we try to avoid. The IPv6 source address after the CLAT is not relevant for the optimization (no impact).

[Jordi] Exactly. We need state because we need to “disconnect” the DNS TTLs form the hosts applications connections.

[Jordi] No need for that. We only optimize IPv4-only hosts. Further, trying to change HE is a “no way”.

[Jordi] I don’t think this is good, because that will mean having a bigger EAMT than actually needed. We need to delete entries as soon as possible. The “stale” status, as suggested by Erik, resolves the issue. Anyway, I still need to think and work more on this text.

Good things:

[Jordi] I don’t see this. It is only possible using IPv6, not IPv4.

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

One visible restriction:

[Jordi] yes to all those points

[Jordi] I’m re-reading anyway, everything and making sure we aren’t missing any issue before sending a new version …

Eduard

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 20 Jul 2020 10:17:17 +0000

Hi Jordi,
[Jordi] Not sure if I got it correctly. I don’t think so. If we use the addresses as in a non-optimized CLAT, they are synthetized, so they will naturally follow the PLAT path – this is what we try to avoid. The IPv6 source address after the CLAT is not relevant for the optimization (no impact).
[Eduard] You are thinking about destination IPv6 – you are dealing with it by DNS request. I have shown to you already in many discussions that I am thinking about source too. Stateful against stateless – it is about it.
I was talking in (2) about “Source address”. Source CLAT IPv6 is a IPv6 that has been given to CPE as a result of DHCP PD (from Carrier’s address space).
Look to the referenced chapters (they are short): IPv4-Embedded IPv6 Address – clause 2 RFC 6052, but RFC 6877 clause 6.3 states that only /64 version should be used

·        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
[Jordi] I don’t see this. It is only possible using IPv6, not IPv4.
[Eduard] It is because you have not understood previous point about source address translations.
We could potentially extend current draft a little and permit inbound connection. If MAC is IPv4 only. No any FQDN request needed. EAM record could be created just on packet arrival from the Internet with proper IPv4-Embedded IPv6 Address (proper IPv4-only should be embedded).
It is not a big security hole anyway, because all subscriber’s IPv6 address are End-to-end accessible anyway (open to public).
If security people would insist (subscriber could be “smart” – could not expect that public IPv4 is visible in IPv6 internet☺) – this feature may be disabled by default, could be manually switched by subscriber is he would like to expose his private IPv4 server to IPv6 public internet.

[Jordi] I don’t think this is good, because that will mean having a bigger EAMT than actually needed. We need to delete entries as soon as possible. The “stale” status, as suggested by Erik, resolves the issue. Anyway, I still need to think and work more on this text.
[Jordi] I don’t think this is good, because that will mean having a bigger EAMT than actually needed. We need to delete entries as soon as possible. The “stale” status, as suggested by Erik, resolves the issue. Anyway, I still need to think and work more on this text.
[Eduard] I have shown to you already in separate comment how big troubles we could create with any times (even 1 week long). Never to say about timers taken from DNS.
OK. Refresh timers by traffic as I have proposed. Make sure that stale is really stale.

[Jordi] No need for that. We only optimize IPv4-only hosts. Further, trying to change HE is a “no way”.
[Eduard] I did not propose to change HEv2. I have proposed to read it carefully and reuse everything possible in this draft. At least timers. If we emulate IPv6 host – let’s be as much consistent to HEv2 as possible.

Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: 19 июля 2020 г. 17:19
To: V6 Ops List <[email-masked]>
Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - some disruptive proposals

Hi Eduard,
Tks a lot!

El 18/7/20 9:37, "Vasilenko Eduard" <[email-masked]<mailto:[email-masked]>> escribió:

Hi Jordi,
I have clarified a little below. Use this version.
Eduard
From: Vasilenko Eduard
Sent: 17 июля 2020 г. 23:27
To: 'JORDI PALET MARTINEZ' <[email-masked]<mailto:[email-masked]>>
Cc: 'V6 Ops List' <[email-masked]<mailto:[email-masked]>>
Subject: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - some disruptive proposals

Hi Jordi,

Good things:

One visible restriction:

Eduard