Subject: [BEHAVE] dns64 review

From: Matthijs Mekking <[email-masked]>
Date: Wed, 26 Nov 2008 17:34:56 +0100

Hi,

Upon request, I have looked at the draft-bagnulo-behave-{dns,nat}64. I
have found some nits and some feedback primarly on the DNS64 algorithm
with respect to DNSSEC. Since, I did not follow this from the beginning,
 I might repeat some issues that were raised in the past. If so, I would
be grateful if someone gave me a pointer.

First of all, some general comments/questions about the nat64 document.

- - On page 4, in section 1.2, it is stated that in order to perform IPv6
to IPv4 translation, NAT64 requires state. Is there any analysis of its
scalability?

- - Somewhere round page 8, I was wondering if it is required for DNS64 to
be dual stack. If it does not do IPv4, how would it otherwise contact
the authoritative nameserver in the IPv4-only network?

- - On page 8, in step 2: Shouldn't the ports be chosen by the source
node, in this case H1?

- - Page 9, step 6. The translated packet is sent out the IPv6 interface
  to H2. Shouldn't that be H1?

That was it with respect to NAT64. DNS64 next.
- - Personally, I think putting the DNS64 functionality in the end hosts
is a cleaner solution. You don't need to worry about breaking the DNSSEC
at the end-host, since synthesizing occurs after validation. But since
it requires upgrading all end-hosts in the IPv6-only network, and this
is against the requirements for NAT64, a different solution should be
adapted.

- - I don't understand the situation in section 1.2.3. Are you suggesting
that after receiving a dynamic update, the authoritative name server
should store synthesized AAAA records? Isn't it possible for other IPv6
networks to contact the authoritative DNS64 name server? If so, should
it configure all possible IPv6 prefixes in order to synthesize AAAA
records for different IPv6 networks? This section leaves me filled with
questions.

- - The second option, generating the synthesized AAAA records upon a
query seems a bad idea. This means that in order to allow the recursive
nameserver on the other side to do validation, the authoritative name
server should not only generate synthesized AAAA records, but also
create new signatures for the AAAA RRset and adjust the NSEC bitmap
values. This will increase the load on the authoritative nameserver and
the time window on the resolver. Creating signatures on the fly is
something that should be avoided in the DNS, imho. I prefer this
proposal not to be mentioned at all, instead of tagging it not
recommended but possible.

- - Should synthesized records be cached? RFC 2672 introduced the DNAME
record, including synthesized CNAME records. It defines that the TTL of
the synthesized record MUST be set to 0. However, the RFC is under
revision and the new text tells us to keep the CNAME RR as long as
needed, so it should be equal to the DNAME TTL. This allows non-aware
clients to cache the CNAMEs and thus lightens the load on authoritative
servers. I think a similar approach is possible for synthesized AAAA RRs.

- - We had some discussion on the Jabber during the behave meeting and at
our office, how resolvers should handle synthesized AAAA RRs with
respect to DNSSEC. Synthesizing and DNSSEC can go along, just like with
DNAME/CNAME.

Two problems came to mind with the current solution, in the case the
end-host is transition-oblivious (no DNS64 implemented), but DNSSEC-aware.

1. How does the stub resolver know no *real* AAAA records were available?
2. How can the stub resolver verify the prefix is correct?

The first problem can be solved quite easily. When the response for AAAA
records returned in no error and no data, keep the received DNSSEC data.
This includes one or two NSEC records that proof there was no data at
the QNAME. With this data, the end-host can verify the proof of
synthesis. The answer might look like
	; the synthesized record
	ipv4.example.com IN AAAA ::ffff:1.2.3.4
	; these are needed to determine security status of data
	ipv4.example.com. IN A 1.2.3.4
	ipv4.example.com. IN RRSIG A [valid sig]
	; the following two records are needed for proof of synthesis
	ipv4.example.com. IN NSEC A ; no AAAA bitmap set
	ipv4.example.com. IN RRSIG NSEC [valid sig]

Now the end-host can verify the need for synthesis. The only part that
can be faked now is the prefix. Have not yet figured it out how this can
be securely learned. Maybe the draft-wing-behave-learn-prefix may
facilitate in that. But if you can figure that out, I think you can
continue with NAT64 without the need to update end-hosts and withouth
breaking DNSSEC.

- - In 4.3.2., not only would you need to create signatures for the AAAA
RRset, you would also need to adjust the NSEC data. The end-host must
also have the public key configured of the DNS64 node, in order to
validate the synthetic AAAA RRset. I don't understand why you want to
generate synthesized AAAA RRs when a Dynamic Update is done (when the
DNS64 is located in the IPv6 network).

- - In the case that multiple prefixes are known to the DNS64, which is
discussed in section 4.5, providing all possible synthesized AAAA
records when a DNS64 box is configured with multiple prefixes seems to
be the cleanest solution imho. It reflects the most to how it is done
with real address records.

- - By the way, why were the rules about adding synthetic AAAA records to
the answer section removed when transitioning the draft from version 00
to 01?

Finally the nits. Some of them are linguistic, and my proposed
correction may be only correct within my own judgement. Nevertheless, I
would like to share them.

In the nat64 document:
- - p4, 1. Introduction. It states that no changes are required to the
  IPv6 client nor the IPv6 server. This probably needs to be IPv4
  server.
- - p4, 1.2. Overview. NAT64 mechanism is implemented... -> A NAT64
  mechanism...
- - p12, 2. Terminology. For a detailed understand -> For a detailed
  understanding

In the dns64 document:
- - p5, 1.2. Walkthough -> Walkthrough
- - p11, 2. Terminology. For a detailed understand -> For a detailed
  understanding
- - p13, 4.1. Tagging synthetic RR. "when a semantics of an existent
  protocol is changed" -> "when the semantics of an existent protocol
  has changed"
- - p14. 4.1. Tagging synthetic RR. ENDS0 -> EDNS0
- - p20. 4.5. Supporting multiple ...: sever -> server
- - and: Note that is the NAT64... -> Note that it is the NAT64 that
  failed, ...

Kind regards,

Matthijs Mekking
NLnet Labs
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 01 Dec 2008 09:15:43 +0100

Hi Matthijs,

Thanks for the comments.
I need to look into this.
I will come back on this shortly.

Regards, marcelo

Matthijs Mekking escribió:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFJLXqvIXqNzxRs6egRAvWQAJ9OzkdmJFCu9naSWzn/c3Y6viLBcQCghRsu
> 2wdfhWJZf9U+34M4d9afp2Y=
> =rc7h
> -----END PGP SIGNATURE-----