Re: [v6ops] draft-hunek-v6ops-nat64-srv

[Ted Lemon <[e-mail]>]

Quick review of the document:

There is a quick fix provided by the [RFC8880] that the Well-Known name
> should be treated differently - resolved by autoconfigured resolver on a
> specific outbound interface only.  However, this would mean that the
> application/system stub resolver has to keep track of the source of
> configured DNS resolvers, which may be an unrealistic expectation.


It is generally the case that a resolver such as DoH that attempts to look
up special-use domains such as "ipv4only.arpa," "home.arpa," etc will fail
and provide a bad user experience. The point being, resolvers already have
to solve this problem—it's not specific to IPv4only.arpa.

Another design property of the [RFC7050] is its incompatibility with the
> DNSSEC.  In order for [RFC7050] to work, the DNSSEC has to be turned off,
> and even the detection phase of this method could not use it to verify the
> provided information.  As the network operator does not own the 'arpa.'
> domain, it cannot properly sign the AAAA record for the Well-Known Name.
> Because of it, the first step of the NAT64 prefix detection is always
> insecure.


This is certainly true. Not clear why it's a problem, but it's true. E.g.,
we don't do DNSSEC to validate IP routes. NAT64 is essentially IP routing
technology. Why do we need more security for NAT64 than for plain old IP?

It is fair to say that these methods are viable solutions for system-level
> NAT64 prefix detection - implementations of a system DNS stub resolver or
> CLAT daemon. These methods are not so easy to implement for user-space
> applications and daemons that are not so tightly integrated into an
> operating system.


When does it even make sense for an Application to do NAT64? Why is this
being handled by an application? Can you cite a use case for this?

After section 3, we skip straight to implementation without actually
describing the problem that needs to be solved or why it needs to be
solved. This should have been the first thing this document did. The
proposed solution is not actually secure: the PTR delegation is not likely
to exist in many cases, so the "application" will have to have a fall-back
mechanism, and that won't be secure. Also, if the network is numbered from
RFC1918 or ULA, there can't be a secure delegation of the PTR zone.

Also, the document clearly excludes the application doing DNSSEC
validation, so isn't the application trusting the resolver anyway?

In addition, we never see a motivation for why we want this complex
solution, with multiple possible NAT64 services that the client has to pick
and choose from. We don't make the client pick and choose from different
"network route services" if it's not doing NAT64. Why is this wanted if it
_is_ doing NAT64?

Bottom line: I have no idea what problem this document is trying to solve,
and if there is such a problem, it's not clear to me that the document
solves it, not even that it can be solved for the domain in which the
document purports to be solving it.

On Sun, Jun 12, 2022 at 11:01 AM Fred Baker <[e-mail]>
wrote:

> With this email, let me invite commentary on draft-hunek-v6ops-nat64-srv.
> Please read the draft and raise any issues you might have with it.
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>