Subject: [v6ops] <draft-ietf-v6ops-464xlat-optimization-00.txt> - pre-(shepherd-writeup) review

From: Jen Linkova <[email-masked]>
Date: Fri, 10 Jul 2020 13:58:04 +1000

OK, I"ve read the document and before I finish the write up I'd like
to discuss a number of comments I have.
My apologies for not raising them during the WGLC - I was not paying
attention, got busy with work...

0) I might need coffee but I found the Abstract a bit confusing so if
I may suggest some text..

""IP/ICMP Translation Algorithm (SIIT) can be used to provide access
for IPv4-only devices or applications to IPv4-only or dual-stack
destinations over IPv6-only infrastructure. In that case the traffic
flows are translated twice: first from IPv4 to IPv6 (at the ingress
point to then IPv6-only network) and then from IPv6 back to IPv4 at
the egress point.  If the destination is IPv6-enabled that second
translation might not be required. This document describes some
optimization to 464XLAT and MAP-T deployments to avoid translating IP6
flows back to IPv4 if the destination is reachable over IPv6. The
proposed solution would significantly reduce the NAT64 utilisation in
the operator's network"

1) Introduction section
The draft says: "allow IPv4-only devices or applications to connect
with IPv4 services in Internet, by means of a
   stateless NAT46 SIIT (IP/ICMP Translation Algorithm) as described
by  [RFC7915]."

Do you think it would help saying  "with IPv4 services in Internet
over IPv6-only infrastructure"?  Otherwise it sounds confusing - why
do we need anything at all to help IPv4-only clients to talk to
IPv6-only services?

2) ""This allows to translate the IPv6-only flow back to IPv4, in
order to forward it to Internet."

I'm not sure we can call a flow 'IPv6-only'. Flows are usually IPv6 or
IPv4...I think the terms 'IPv6-only' and 'IPv4-only flows' are used
extensively in the draft.

3) "In both cases (NAT46 and NAT64), the translation of the packet
   headers is done using the IP/ICMP translation algorithm defined in
   [RFC7915] and algorithmically translating the IPv4 addresses to IPv6
   addresses following [RFC6052]."

IMHO this text would be more readable if we split it in two sentences:
" In both cases (NAT46 and NAT64), the translation of the packet
   headers is done using the IP/ICMP translation algorithm defined in
   [RFC7915] . Translation between IPv4 and IPv6 addresses is done as
per RFC6052]."

4) Section 3 is called "Possible Optimisation". However it comes
before the Section 4 (problem statement) and the text seems to be more
about the problem.
Also, the first 3 paragraphs of Section 4 (until "until "As shown in
the Figure 4" text) seem to repeat Section 3. Shall those two sections
be merged?
Or am I missing anything and they are actually talking about different things?

5) "In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally) in charge
of the synthesis of AAAA records from the A records, so they can use
   a NAT64, without the need of doing a double-translation by means of
   the NAT46/CLAT." - who are "they"?  This is the first sentence of
the section so not sure who you are referring to.

6) Fig 1: Shouldn't it be 'Dual-Stack LAN', not 'LAN's Dual-Stack'?

7) ""As it can be observed in the preceding picture, the situation is the
   same, regardless of in case of a wired network with a CE Router or a
   cellular network where a UE is connecting other devices (which may be
   IPv4-only or have IPv4-only apps), by means of a tethering
   functionality."

IMHO it's a bit hard to parse...Maybe smth like:
"Examples of a topology shown on the picture above includes:
- a residential ISP IPv6-only access network with a dual-stack LAN
behind a CPE performing NAT46 (CLAT);
- IPv6-only mobile ISP network when a UE performs CLAT for IPv4-only
applications running on that UE or for traffic originated by other
devices connected to the UE via tethering."

8) Section 5.1. Approach 1: DNS/Routing-based Solution
"5.1. Approach 1: DNS/Routing-based Solution
"Because the WKP is non-routable, this solution will only be possible
   if the CDN/cache is in the same ASN as the provider network, or
   somehow interconnected without routing thru" Internet."

Maybe it's worth explicitly mentioning that this approach would
require that the path to the destination is NOT traversing NAT64
devices. Otherwise the simple configuration of such devices 'translate
everything with the destination address in the WKP' would become much
more complex.

9) Section 5.2.3
""In normal conditions the TTL for both A and AAAA records, of a given
FQDN, should be the same,"

I'm not sure it's the case actually and we can expect that to happen
'normally'. Do you have any references proving that point?

10) Section 5.2.7. Behavior in case of multiple A/AAAA RRs
Sorry but I have difficulties understanding those two sentences. What
'existing procedures'  the resolver must be using?
IMHO this section would be much easier to understand if there is an
example: the given FQDN has 15 A RRs and 5 AAAA RRs. What EAMT entries
would be created?
As most CDNs would have multiple entries, this is a key point of the proposal.

11) Section 5.2.8. Behavior in presence/absence of DNS64
"Furthermore,  because as indicated in Section 5.2.2, the EAMT entry
is not created
   when the service is IPv6-enabled."

Is it correct? The section 5.2.2 seems to be talking about detecting
IPv6 enabled services and using their AAAAs for creating EAMT entries.

12)  (related to 11) The draft seems to assume that the CPE/UA knows
the NAT64 prefix somehow. As it's an operational document I believe it
would be beneficial to provide some guidance on how exactly the device
should discover the prefix. Obviously, the operator could use RFC8781
(PREF64 RA option) or PCE. Or the device and use RFC7050. However if
the device uses RFC7050 then the Section 5.2.8 shall discuss this.

13) IMHO sections 5.2.9.  Behavior when using literal addresses or non
IPv6-compliant APIs and 5.2.12. Behavior in case of Foreign DNS should
be follow each other or  sections 5.2.9. might have a reference to
5.2.12.

14) Section 5.2.11 Behavior in presence of Happy Eyeballs
IMHO, this section should make it explicit and very very clear: as
soon as an EAMT entry is created for an IPv4 address, Happy Eyeballs
fallback to that IPv4 address becomes impossible. In case of
connectivity issues with the IPv6 address used in that EAMT entry, the
client would not be able to reach the destination.
I feel like the draft does not discuss the impact enough.  It's not
about delay, it's about IPv6 becoming the only protocol to reach
IPv6-enabled destinations for both dual-stack and IPv4-only hosts.
Maybe it's a good thing in 2020 ;)

15) Later in that section the draft says:
" So even if Happy Eyeballs is present, the fallback to IPv4-only
typically, will be slower than native IPv6 itself, because
   the added delay in the NAT46+NAT64 translations, when not using this
   optimization."

I think it should be saying "IPv4 would be slower", not "fallback to
IPv4".  So maybe smth like " 'IPv4 is expected to be slower than
native IPv6 due to delays added by NAT46+NAT64. This optimization
reduced that delay by eliminating the need of the second translation
(NAT64)"?

16) The draft does not discuss the troubleshooting implication. For
example if I'm running 'traceroute 8.8.8.8 from my IPv4-only host and
there is an EAMT entry for 8.8.8.8.
IMHO this draft needs to discuss this and potential impact on tech
support procedures.

17) Another thing which seems to be missing is some guidelines on
controlling this feature. I'd suggest adding some text about that.
IMHO, the router vendors SHOULD (I'd vote for MUST even) have that
optimization disabled by default. The routers MUST have a knob to turn
it off if it's enabled.

18) Acknowledgements Section
Pls remove "....and TBD".

-- 
SY, Jen Linkova aka Furry

---

From: Jen Linkova <[email-masked]>
Date: Fri, 10 Jul 2020 17:04:26 +1000

Oh I forgot to add one more thing:
- The Security Considerations section states that "This document does
not have any new specific security considerations,
   besides the ones already known for DNS64.".
I'm not sure it's the case. The proposed approach drastically
amplifies DNS poisoning impact.
If the attacker manages to spoof the DNS response the CPE would create
an EAMT entry which would affect *all* traffic to that destination,
even for devices/applications behind that CPE which might be using
DNSSEC. This could create DoS attack vector and force CDN operators to
turn off IPv6 for their caches.
I believe that should be discussed in more detail.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 10 Jul 2020 09:17:54 +0200

Hi Jen,

Still Reading thru all your points.

On this specific one, if the attacker spoof the DNS response, it will be able to create an invalid EAMT entry, so the client behind the NAT using that destination will not reach what it wanted to reach. This is not different if it happens without an EAMT.

Having the same result as a regular DNS spoofing, should I mention it in the security considerations? May be indicating that it is the same kind of attack as a DNS spoofing without the EAMT entry, so it is not a new security risk.

I will try to respond to the other later on in the morning, and if needed update the last version with the relevant clarifications.

Regards,
Jordi
@jordipalet

El 10/7/20 9:04, "Jen Linkova" <[email-masked]> escribió:

**********************************************
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: Jen Linkova <[email-masked]>
Date: Fri, 10 Jul 2020 17:53:20 +1000

> On this specific one, if the attacker spoof the DNS response, it will be able to create an invalid EAMT entry, so the client behind the NAT using that destination will not reach what it wanted to r…

I believe it's different. The difference here is that invalid EAMT
entry would affect *all* devices behind the CPE.
Let's consider an example:
- I have a CPE which has that optimization enabled. I have 5 devices
at home, all of them are smart and using DNSSEC even.
- Now one of them sent a A query for www.example.com.
- The CPE sent an AAAA which got spoofed. The invalid EAMT entry is created.
- Now none of the devices could reach www.example.com, despite the
fact that 4 of them maybe using DNSSEC and/or 3rd party DNS servers.

This is actually related to my point about 'when/how this feature gets
enabled'.  It's not just must be explicitly enabled by an operator, it
MUST be disabled if the roiter does not have IPv6 connectivity on the
uplink (and the question is 'how to define that').
> Having the same result as a regular DNS spoofing, should I mention it in the security considerations? May be indicating that it is the same kind of attack as a DNS spoofing without the EAMT entry,…

The impact is much higher as it would affect all devices, incl.ones
which might not be even using that CPE as a resolver.
Shall this feature only be used if the CPE is capable of DNSSEC?
We must be really careful here as what you are proposing basically
nullifies Happy Eyeballs and might force content providers to go back
to IPv4.

> I will try to respond to the other later on in the morning, and if needed update the last version with the relevant clarifications.

Thank you!

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 10 Jul 2020 13:29:35 +0200

Hi Jen,

El 10/7/20 9:53, "Jen Linkova" <[email-masked]> escribió:

[Jordi] If instead of the spoofing the AAAA, it is spoofed the A or even the AAAA (without this optimization), the result is the same. In my opinion it all depends on how and "where" the attack occurs, because the DNS cache may be poisoned in the CPE or the hosts, etc. As said, I've no problem to mention it, but I think is not clear if it is worst or not, it very much depends on how and where the attach is performed.

[Jordi] This nullifies the full purpose of the optimization. The idea is that the optimization is performed as easy and automatically as possible if the WAN is IPv6-only. I will say in the other way around. If, in an extreme situation, an operator has any "big" trouble with this optimization, they will use TR-069 or whatever to disable it by default. Clearly the optimization will be only enabled by the CPE if it is using 464XLAT because it has IPv6-only WAN. I'm happy to add a sentence or even a section to clarify that, but for me an optimization for 464XLAT only works if 464XLAT is working, not otherwise!

[Jordi] I don't see the relevance of DNSSEC in the CPE here. What I'm missing? I understand that if validation of DNSSEC is present and the RR have been spoofed then the CPE *already* will discard them, because it just discovered that the DNSSEC validation is failing. Right?

[Jordi] In my experience, in an IPv6-only environment Happy Eyeballs doesn't "solve" most of the cases. Let's see:
1) If the IPv6-only link or part of the IPv6-only network is broken inside the operator, IPv4 will not work as well. So, HE will only add delay in detecting the problem (the Resolution Delay).
2) If the IPv6 connectivity is broken outside the operator network, in most of the cases, IPv4 may be broken as well.
3) I agree that there may be cases where the IPv6 connectivity is broken outside the operator network and IPv4 is working, and a very typical example was when a www owner sets an AAAA record, not having IPv6 connectivity. This happen less and less often.

**** However as explained in section 5.2.11, happy eyeballs it is only available in dual-stack hosts.

A dual-stack hosts, normally, will not create the EAMT entry, neither use it (if it was created already by an IPv4-only host accessing the same FQDN).

There may be an extreme case, where an IPv4-only hosts creates the EAMT entry, and then a dual-stack host, talking to the same destination, using HE, because suddenly the IPv6 connectivity fails, falls back to IPv4. In this case, the dual-stack host will be using the optimization. It may be in the case 1 or 2 above. HE with or without optimization is not resolving the problem.

If we are in case 3 above, then is not a good thing that IPv4 is failing considering that we are in an IPv6-only operator?
It is acceptable that dual-stack networks/services don't realize that IPv6 is not working?
If there are IPv6-only hosts (example a NAT64+DNS64 instead of 464XLAT, in the same operator or others), they will not reach the destination, because HE will not help them, right?
So, is this an acceptable trade-off?

    Thank you!

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 11 Jul 2020 14:31:57 +0200

Hi Jen,

Tks a lot, very useful inputs!

Responding now to this ... sorry bit busy today with another document ;-) and as a consequence, a new version (-02) being published in a while ...

El 10/7/20 5:58, "Jen Linkova" <[email-masked]> escribió:

[Jordi] Yep, tks, I'm happy to use this alternative text (slightly changed):

   IP/ICMP Translation Algorithm (SIIT) can be used to provide access
   for IPv4-only devices or applications to IPv4-only or dual-stack
   destinations over IPv6-only infrastructure.  In that case, the
   traffic flows are translated twice: first from IPv4 to IPv6
   (stateless NAT46 at the ingress point to the IPv6-only
   infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at
   the egress point).  When the destination is IPv6-enabled, the second
   translation might be avoided.  This document describes a possible
   optimization to 464XLAT and MAP-T to avoid translating IPv6 flows
   back to IPv4 if the destination is reachable over IPv6.  The proposed
   solution would significantly reduce the NAT64 utilization in the
   operator's network.

    1) Introduction section

[Jordi] Yep, tks!

[Jordi] Yep, tks! Reviewed across all the doc.

[Jordi] I'm sure I've read/used this text in other documents and got no complains, but I'm happy to change it.

[Jordi] This was a single longer section before, including the intro (which explains also some of your other inputs later on), but a previous review from the WG suggested to split it. I think it makes sense to keep the actual distribution of the text, as it follows a natural reading flow, even if the problem statement comes "later". May be an alternative is to rename section 4 as "problem statement summary" ?

[Jordi] Caused by the split of the section ... resolved now.

[Jordi] I think it was originally just LAN's or just Dual-Stack and when adding the other wording ... changed.

[Jordi] Yep, reworded.

[Jordi] Is there "having more specific routing prefixes", anyway, I've added test to remark it.

    9) Section 5.2.3

[Jordi] I don't have in mind a reference. Tried to find it now, and no luck, but I'm sure is the correct way. If you have different TTLs for A and AAAA records strange things will happen to IPv4-only or IPv6-only or dual-stack users. Anyway, even if I'm wrong, the text we have doesn't get impacted, because for the optimization the important one is the AAAA record, as already indicated in the actual text.

[Jordi] Existing procedures are either using the first RR, or shuffling among them (RFC1794). Whatever is done must be transparent to the CDNs. In fact, CDNs and caches usually (just done some random test to verify it) do the round robin. What it is clear, and this what I'm trying to say, is that whatever is doing the CE,  should not be "modified" with the optimization, because the CDN is making sure that the response is good never mind it is any of the A records or any of the AAAA records. I will try to reword the text to make it clearer.

[Jordi] The "not" is a typo. Some wrong copy and paste. Anyway, I think I will reword the full paragraphs to  make it clearer and actually shorter.

[Jordi] I was having in mind using RFC8585, but actually never put it, because the other references (464XLAT, NAT64, etc., already have it). However now I think it is a good point having a reference to RFC8781, and all the other choices.

[Jordi]  Ok. Moved 5.2.12 after 5.2.9.

[Jordi] I've pointed to this in the other email ... So, I think we agree on the possible tradeoff. I will see how I can improve the text to made it clearer.

[Jordi] Yep. All the happy eyeballs section re-worded and made more explicit. Note that depending on "where" the IPv6 failure is happening, IPv6 to a destination could be failing and IPv4 still working ... see the new text.

[Jordi] This is already considered, either via a CLI, GUI or both, you can configure static "invalid" entries:
   6.  Valid/Invalid: When set to 1, means that this EAMT entry MUST NOT
       be used and consequently no optimization performed.  It may be
       used also for an explicit configuration (GUI, CLI, provisioning
       system, etc.) to disallow optimization for explicitly configured
       IPv4 addresses.

   7.  Auto/Static: When set to 1, means that this EAMT entry has been
       manually/statically configured, for example by means of an
       explicit configuration (GUI, CLI, provisioning system, etc.), so
       it doesn't expire with TTL.

Anyway, I will add a specific section to remark it.

[Jordi] In my previous email already discussed about this. I've added this text:
   Note that this optimization MUST NOT be
   enabled when the WAN link is IPv4-only or dual-stack.  In other
   words, only can be enabled if the WAN link is IPv6-only and
   consequently, the NAT46/CLAT is enabled in the CE

[Jordi] I usually keep it open for last minute contributors, and the RFC editor close it (and they order them alphabetically, etc.). Done now.

---

From: Erik Nygren <[email-masked]>
Date: Wed, 15 Jul 2020 01:53:16 -0400

> attention, got busy with work...

Prodded by Jen's response here I also re-read
draft-ietf-v6ops-464xlat-optimization-02.
(My apologies also for not raising these during WGLC -- similar excuses to
Jen...  ;-)

While this continues to close corner-cases, I'm still concerned
that there is significant possibility for breakage in a way that
will result in content that is now dual-stacked getting switched
to be IPv4-only.

It would be good to add some examples as to why
some of the invalidation logic needs to actually work
(and the risk of corner cases where it doesn't).
To that end, it may make sense to also have some more
use of normative rfc2119 language for clearly spelling out behaviors
where there are sharp edges.

Some example cases of breakage or significant risk of breakage:
* A site is IPv4-only (breaks for or denies all IPv6 users) but shares an A
record with a dual-stack site.  If this isn't detected properly, it will
break users who get sent over IPv6 to the IPv4-only site.
* some CDNs use TLS SNI for demuxing IPv4 traffic but the IPv6 address for
demuxing IPv6 traffic (both to determine which cert to serve).  This means
that the IPv4:IPv6 associations are one to many and using the wrong one
will result in cert errors.
* Some CDNs may use cluster A for IPv4 and cluster B for IPv6 for one
customer/tenant, but then cluster A for IPv4 and cluster C for a different
customer/tenant.  An stale or invalid association will result in going to
the wrong cluster which may not be able to serve the request properly.

While the recent revisions help some, there are still a bunch of cases
where things could still break.  I fear that when they do break it's
not something that content providers or CDNs or their customers will
debug and the result will be for content to get switched back
to IPv4-only (which is not what we want happening, but will
appear to "fix" issues here).

I think there may also be some significant security issues not called out
that are independent of the DNS spoofing issue.

Another area not discussed is clients caching DNS lookups well past
their TTL.  This is fairly common in some clients (eg, some Java versions)
which could result in entries getting expired from the EAMT but then used
with a new association that should be invalid but wasn't detected as such
as the first client is caching well past the expiry.

Some other specific concerns on parts of the doc:

> 5.2.1 Detection of IPv4-only hosts or applications
> It needs to be remarked that, if the detection of the IPv4-only
> device or application is done incorrectly (either not detecting it
> or by a false detection), no harm is caused.

I'm not sure that "no harm is caused" is always the case.
There may be harm due to cases such as a client no longer
able to fall back to the IPv4 address it would have used
in a Happy Eyeballs setup.  (ie, connectivity is discussed extensively
here, but application-level breakage due to some of the issues
mentioned above may not be possible to recover from).

=========

> 5.2.1  Detection of IPv4-only hosts or applications

Will Android doing synchronous A/AAAA lookups break this
detection?  and does this impact other things like STBs built on
Android?  Android does one of the A or AAAA lookups, waits for it
to return, then does the other.  From the perspective of the CPE resolver,
could look like an IPv4-only host and just always introduce the 50ms delay?

Some more details may be needed here on the timing heuristics needed
to detect various scenarios like this.

=====

> 5.2.3
> 4. TTL
>    "In normal conditions the TTL for both A
>       and AAAA records, of a given FQDN, should be the same, so this
>       ensures a proper behavior if there is any DNS mismatch."

Actually if the resolver is a forwarding resolver talking
to the ISP's recursive resolver then it is likely the TTLs
returned will have degraded some and will be different.
For example, if a CDN is using a 60s TTL then it is likely
that the A RRset could have 12s remaining while the AAAA RRset
has 48s remaining.

Using the minimum of the two TTLs is likely better than assuming they will
match.

It may make sense to keep track of EAMT records somewhat past their
TTL to handle clients caching things longer as well as race conditions.
For example, add a "stale" state which can convert to "invalid" but won't
get used for new connections and which entries stay in for some amount
of time past expiry.

Nit: Is this really an "expiry time" rather than a "TTL"?
While mentioned later, it would be good to emphasize
that invalidating or expiring EAMT entries MUST NOT
break existing connections.  (ie, that the 5.2.4 behavior
is absolutely required.)  Implementations getting this wrong
would be really bad in-terms of breaking dual-stack content
while IPv4-only content would keep working (ie, due to
the lack of associations).   Hurting reliability for dualstack
content relative to IPv4-only content would be bad.

Also not covered here is clients caching A/IPv4 lookups for extended time.
For example, the  EAMT entry may have expired but client may have A record
cached and then another mismatching EAMT entry might get created for a
different FQDN.
=======

> 5.2.6.
> "The existing EAMT entry for 192.0.2.1 is set as invalid".

Clarify that:
* 5. Existing connections to 192.0.2.1 remapped to 2001:db8::a:b:c:d
  MUST NOT be broken.

=======

> 5.2.7.  Behavior in case of multiple A/AAAA RRs

Agreed with Jen's earlier comment that this needs more clarification.
Example algorithm:

* For each A record on the A RRset, create an EAMT entry with a randomly
  selected record from the AAAA RRset.

* Resolver should ideally randomly permute the A RRset prior to
  returning to the client

==========

> 5.2.10 Behavior in case of Foreign DNS

How will the mismatches that should trigger invalidations
get detected in this case?

* Breakage due to as mismatches won't be detected and result in
invalidations
 if one device or app is doing lookups via this resolver but another is not.
  Constraining the EAMT entry to the IPv4 client IP could at least bound
  the damage to a single device, but not if some apps on it use different
  resolver schemes.

* I believe Google ships Chromecast to hardcode DNS lookups to 8.8.8.8
  in addition to also sometimes using the local resolver.  Some other STBs
and mobile apps
  do the same.  This has significant potential for mismatches to not get
  detected and not get invalidated.

================

> 5.2.13.  Troubleshooting Implications

How do corner-cases around collisions where EAMT entries
don't get proprerly invalidated get debugged by the ISP
(and content provider!)?

This is opaque to the CDN and could result in lots of escalations from
end-users and customers.  The net result will be for content to get
switched to IPv4-only if that "fixes" the problem which might impact
users world-wide.  (Neither the CDN or their customer has any
visibility into what is going on here other than that some end users
may be reporting not being able to view dual-stacked content.)

============
General for 5.2.x:

* Should this doc use more normative language in places where warranted?
  (There are a bunch of MUST NOT sharp edges.)
  Especially in 5.2.4.

* Clarify that EAMT table updates MUST be made before A record
  is returned to the client (especially invalidations!).  Otherwise there
  is a potential race condition.

* What happens if the FQDNs mismatch but the A and AAAA RRsets are
identical?
This is going to be very common as many CDNs use lots of names
 with a smaller number of IPv4 addresses.
  What if the A and AAAA RRsets overlap but aren't identical?
  (Perhaps the EAMT entry MUST be marked invalid if the FQDNs mismatch
  and the EAMT entry does not have both its A *and* AAAA values
  in the returned RRsets.  ie, all EAMT entries must be valid
  within the mismatching FQDN.)
  (May still be corner cases here I'm forgetting?)

* We have a recommended maximum cap/threshold on the TTL?
  (even if it's something like 8 hours...)  Otherwise bad entries
  might stick around too long.

==========

Additional security considerations:

(The first of these is minor --- the others seem like they make this too
dangerous to deploy.
It may be worth having a Security AD do some focused review in this
context.)

* Filling EAMT table with very long TTL records.  (ie, triggering a client
to
  do DNS lookups that create lots of long-lived associations)

* There is an serious risk exposure to hijacking traffic by inserting bogus
binding
  (ie, return target's A record and malicious actor's AAAA record).
  In most cases these records should get marked as Invalid,
  but the corner cases here are fragile (eg, with foreign DNS or
  clients caching past the TTL mixed in here.
  An example attack here is that a client has an A record
  for "www.example.com" pointing to 192.0.2.1 cached past
  its TTL so the EAMT record is gone.  An attacker convinces
  another user in the same home network to do a DNS lookup
  that has an A record of 192.0.2.1 (which the attacker doesn't own)
  but a AAAA record for 2001:db8:eeee::eeee (which is attacker-controlled).
  Even if 192.0.2.1 is IPv4-only, if the EAMT entry has expired or never
  existed then the attacker can redirect all traffic to it to an IPv6
address
  of their choice.  No DNS spoofing is needed here at all, just making
  a "claim" that the A/AAAA are associated (which has no authentication).
  This is potentially worse as I'd hypothesize that IPv4-only STB
  clients are much less likely to use HTTPS/TLS.

* This previous risk is particularly problematic for hijacking traffic from
  users/devices/clients using Foreign DNS since they won't create
  EAMT entries but will be exposed to clients getting tricked into creating
them.
  (This cCould be especially problematic for users using DoH for privacy
  on one device, but then another device in their home allows
  them to be hjijacked.  At some point Firefox preferred IPv4 in some
  cases when using DoH so this may be a real exposure
  / vulnerability risk.)

Sorry again for not sending these earlier --- I think a bunch of these
concerns were raised in my previous feedback and while this version
has made significant improvements, I'm still very concerned that it will
be very risky from an operational fragility and security perspective.

     Erik

---

From: Jen Linkova <[email-masked]>
Date: Wed, 15 Jul 2020 19:23:01 +1000

On Fri, Jul 10, 2020 at 9:29 PM JORDI PALET MARTINEZ
<[email-masked]> wrote:
> [Jordi] If instead of the spoofing the AAAA, it is spoofed the A or even the AAAA (without this optimization), the result is the same. In my opinion it all depends on how and "where" the attack occurs, because the DNS cache may be poisoned in the CPE or the hosts, etc.

Sorry I should have clarified. The difference is that spoofing *one*
DNS response would affect *all* devices behind the CPE *even* if those
device are not using that CPE as a resolver and use DNS over [smth]
and/or DNSSEC. My laptop might build a secure tunnel to the DNS server
it's using and validate response using DNSSEC.
But it does not help because my TV asked for an A RR and the
corresponding AAAA was spoofed on the CPE, so now all devices in my
house can not reach that IPv4 address.

> [Jordi] This nullifies the full purpose of the optimization. The idea is that the optimization is performed as easy and automatically as possible if the WAN is IPv6-only. I will say in the other way around. If, in an extreme situation, an operator has any "big" trouble with this optimization, they will use TR-069 or whatever to disable it by default.

Why can they not use TR-069 or whatever to enable it? Operators might
not have CDNs in their network, they might have enough capacity  etc -
so they might not need the optimisation at all.

>Clearly the optimization will be only enabled by the CPE if it is using 464XLAT because it has IPv6-only WAN. I'm happy to add a sentence or even a section to clarify that, but for me an optimization for 464XLAT only works if 464XLAT is working, not otherwise!

I do like the update to Section 5.2, thanks for that! However IMHO the
current version does not imply that the optimization is enabled only
if 464X:AT is enabled.
What if the device was not able to get an IPv4 address on the uplink
initially but eventually DHCPv4 succeeded?
Not sure there is any clear guidance for that.
That's why I was thinking that letting the operator make a decision if
they need this feature and enable it would make sense - those who
really need would know that they shall buy routers supporting this and
enable it. Those who do not care would not be negatively impacted.

---

From: Erik Nygren <[email-masked]>
Date: Wed, 15 Jul 2020 14:17:02 -0400

On Wed, Jul 15, 2020 at 5:23 AM Jen Linkova <[email-masked]> wrote:

> > [Jordi] If instead of the spoofing the AAAA, it is spoofed the A or even
> the AAAA (without this optimization), the result is the same. In my opinion
> it all depends on how and "where" the attack occurs, because the DNS cache
> may be poisoned in the CPE or the hosts, etc.
>
>

It's also not just a matter of spoofing.  All it takes is for one device
to get tricked into doing an A/AAAA looking for a legitimate name
(eg, URL embedded in an advertisement or even email) and
if the attacker controls the name being looked up they can
put in a redirection for an IPv4 address of their choice (which
could belong to someone else) to an IPv6 address of their choice
(which could belong to the attacker).  As this is a legit name,
it could be happily DNSSEC signed as well.  The problem is that
an attacker can return an A record for IP space they don't own.

The collision invalidation may help in some cases, but it won't help
for cases where other clients in the local network are using DoH
or are caching and using A records well past their DNS TTL (common
in some cases like older Java).
This is a fairly serious new attack vector that is very easy to exploit
(much more so than DNS spoofing).
If we see deployment of this, we should expect to see people attacking
it this way to bad effect.

    Erik