Subject: Re: [BEHAVE] dns64 review

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 12 Feb 2009 17:23:24 +0100

Hi Matthijs,

thank you very much for your thorough review.
some replies below...

Matthijs Mekking escribió:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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?
>   

I understand that this would have the same scalability properties than a 
IPv4 NAT, which also holds state per flow.
Do you see the scalability issues being worse in nat64 than in normal 
IPv4 nat?

> - - 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?
>
>   
I understand that the protocol used for transport and the type of RR 
obtained are orthogonal. I mean, a resolver can retrieve AAAA RR over 
IPv4 and retrieve A RR over IPv6, right?
We haven't mentioned anything about the version used for the transport 
of the  RR information cause we ddin't see any special issue with 
this.... do you have some concrete issue that you think needs to be 
mentioned and addressed?

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

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

>
>
>
> 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.
>   
agree

> - - 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? 
upon the reception of a dynamic update, the authoritaive server will 
create a A RR, right?
At the same time, the authoritive server could create an AAAA RR and 
publish it along the new A RR, would that make sense?
(the IPv6 address would be the IPv6 represenation of the IPv4 address 
contained in the A RR)

> Isn't it possible for other IPv6
> networks to contact the authoritative DNS64 name server?
I don't understnad this question, could you expand?

>  If so, should
> it configure all possible IPv6 prefixes in order to synthesize AAAA
> records for different IPv6 networks?

but the prefix used is the prefix being used to represent IPv4 addresses 
in the IPv6 address space.
There is still an open disucssion whether this will be a single well 
knwon prefix or will be a prefix out fo the site's address space, but in 
any case, the site must have a prefix used for this i.e. representing v4 
addresses in v6 land.
It may be possible that more than one prefix is used for this (i.e. if 
we want to assign different prefixes to different NAT64 boxes)
In that case, multiple AAAA RR should be published, one pre prefix. Not 
clear to me how common would this be, but as i said we should wrap up 
the prefix disucssion before figuring out what prefix to include here

>  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.
>   
i agree with that, but some other people express their interest on this.
I may leave this for one more version, to gather more feedback

> - - 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.
>
>   

I have changed to the TTL of the original A RR, would that make sense to 
you?

> - - 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.
>   

right
the new versio of the draft includes two ways of handling DNSSEC, the 
old one and the new one DNAME/CNAME style.
It is open for disucssion which way to go,

please read the next versio fo the draft ad speak your mind on which one 
you preffer
> 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.
right
we could include some text about this, once it is clear which option for 
supporting dnssec we will adopt
>  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.
>
>   
right learning the prefix is critical for dnssec.
one very easy option would be to use a well known prefix that can be 
hardcoded in the implementations. That would do the trick
If not, we need to do some way to learn the prefix, i agree
> - - 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. 

right
> The end-host must
> also have the public key configured of the DNS64 node, in order to
> validate the synthetic AAAA RRset. 
i am not sure what you mean here...
what public key?

> 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).
>
>   
I personally agree with you
People have claimed that there are arguments for doing it this way. For 
instance, what happens if the host is a dual stack host and it will 
create the AAAA RR using Dyn DNS as well?. In this case, if the dual 
stack host creates the A RR first, the automatic creation of the AAAA RR 
would collide with the future real AAAA RR created by the host itself.
If we create the synthetic AAAA RR upon the reception fo the query, we 
are sure that we synthesize only if there are not real AAAA RR.
Again, this could be solved in other ways (i.e. deleting the synthetic 
AAAA RR when a real AAAA RR is created, but this is one of the arguments 
presented by the people defending this option)

> - - 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.
>
>   

right
the problem with that, as pointed by Dan lately is that if the host uses 
different prefixes, will end up using different nat64 boxes and hence 
will use different public IPv4 address in the eyes of an external host, 
which seems not the best behaviour.

> - - 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?
>
>
>   

mmm, not sure what you mean, could you be more specific about the text 
you are referring to?

I deleted all the stuff related to the ENDS0 option cause doesn't seem 
the best option so far.... not sure if this is what you are referring to

>
>
>
> 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.
>   

done
> 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
> -----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-----
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>