Subject: Re: [v6ops] Working Group Last Call draft-ietf-v6ops-464xlat-optimization

From: Erik Kline <[email-masked]>
Date: Wed, 15 Jul 2020 14:22:01 -0700

On Mon, Apr 27, 2020 at 10:05 AM Ron Bonica
<rbonica=[email-masked]> wrote:
>
>  Folks,
>
> This message initiates a WG Last Call on draft-ietf-v6ops-464xlat-optimization.
>
>  Please submit comments by May 11, 2020.
>
>                                    Fred and Ron

(July 15th < May 11th, yes?  Apologies for the lateness of the review.)

doc{draft-ietf-v6ops-464xlat-optimization-02}

I find this draft to be problematic in several ways.  I'm not sure if/how it
can be fixed, frankly.  But perhaps I've misunderstood several things...

[1] As has been noted by others, the EAMT maintenance laid out in 5.2.3 and
5.2.6 is attackable by someone who can cause IPv4-only hosts to lookup a name
in their control.  This name would have some victim IPv4 address for an
A record and some other IPv6 address for an AAAA that the attacker controls.

I disagree with the assessment in the Security Considerations section on this
point.  This is very different.  Ordinarily, translation entries are created
by observation of traffic.  Here, the translation entries are partially
pre-made by DNS results.  And this is where all the trouble starts, IMHO.

[2] What about STUN/TURN and custom implementations of similar functionality
done via encrypted means (e.g., QUIC)?  If I do:

   bash$ for i in stun turn; do host $i.l.google.com; done
   stun.l.google.com has address 172.253.117.127
   stun.l.google.com has IPv6 address 2607:f8b0:400e:c0a::7f
   turn.l.google.com has address 173.194.196.127
   turn.l.google.com has IPv6 address 2607:f8b0:4001:c03::7f

An IPv4-only host would be unable to learn its public IPv4 address information
if this "optimization" were employed because the IPv4 STUN/TURN service would
be utterly unreachable.

I don't think we can just "exempt" STUN/TURN traffic because there might be
custom, cryptographically protected ways to effect much of the same thing,
and these services could be run on non-standard ports.

I don't think we can even craft some exemption for just optimizing
"CDN/cache traffic" because then there are restrictions being imposed on what
the CDN devices can do (they already do much more that just serve static
cached content).

[3] Isn't the possibility of an EAMT entry collision (5.2.10 a) really bad?
Different apps can use different DNS services to resolve hostnames. But even
if a client used the CE's DNS, a service provider can have two hostnames with
the same IPv4 address but two different IPv6 addresses.  This is supported
today, but with this "optimization" wouldn't the EAMT mapping collisions break
this use case?

Given the above, I'm sure how this can be fixed.  5.2.1 can work, if a CDN
pod is located within the ISP's network and the CDN operator is amenable to
the operational work and to the restriction on the kinds of services that can
be provided.  But I think the rest of the stuff...is just going to
break things.  :-/