Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion

[Lencse Gábor <[e-mail]>]

Dear Jordi,

I would not say that anything is missing, but perhaps including some of 
our results about DNS64 would strengthen your draft. More specifically, 
I would suggest the following ones.

You wrote in Section 2:

    [...] So, the recursive name server actually
    lie to the client device, however in most of the cases, the client
    will not notice it, because generally they don't perform validation
    themselves as instead rely on their recursive name servers.


    If the client device performs DNSSEC validation on the AAAA record,
    it will fail as it is a synthesized record.


Here you may want to add something like:

The best possible scenario from DNSSEC point of view is when the client 
requests the DNS64 server to perform the DNSSEC validation (by setting 
the DO bit to 1 and the CD bit to 0). In this case, the DNS64 server 
validates the data thus tampering may only happen inside the DNS64 
server (which is considered as a trusted part, thus its likelihood is 
low) or between the DNS64 server and the client; all other parts of the 
system (including transmission and caching) are protected by DNSSEC. [1]


And just one nit. You wrote in at the end of Section 2:

    [...] Previous data seems to indicate, that
    the figures of DNSSEC broken by using DNS64 will be around 1.7%
    (information 2 years old).


It would be worth mentioning the source of this information. I think it 
is [2]. (We have taken the same information from there.)


IMHO, the 100%-1.7%=98.3% of the domains with no DNSSEC also deserve 
some discussion. We have performed the threat analysis of a system, 
which uses DNS64 [1]. From the many identified threats, cache poisoning 
is perhaps the most important one. It was a hot issue about 10 years ago 
[3]. Fortunately, the major DNS servers implemented the countermeasures 
against cache poisoning recommended by RFC 5452. We have also confirmed 
it regarding BIND, PowerDNS and Unbound [1].


I think the readers of the future RFC would benefit from benchmarking 
results of different NAT64 implementations. We are planning to compare 
the performances of the following ones:
- OpenBSD PF
- TAYGA+iptables
- Jool
- Ecdysis
We are going to start their stateless tests according to the dual DUT 
setup of RFC 8219 using an RFC 2544 compliant tester in June.
We are also planning to benchmark them  according to the single DUT 
setup of RFC 8219, but we need to wait for implementation of the Tester. 
(Unfortunately, I have no guarantee, when it will be ready, as it is 
done by one of my PhD students.)

What is the planned time frame of your draft?


I hope that our DNS64 server benchmarking results of BIND, PowerDNS and 
Unbound published in [4] may also be useful. (Perhaps the main 
performance numbers, the different scale up behaviors and the 
performance problem of BIND would be worth mentioning.)

And the references are:

[1] G. Lencse and Y. Kadobayashi, "Methodology for the identification of 
potential security issues of different IPv6 transition technologies: 
Threat analysis of DNS64 and stateful NAT64", /Computers & Security/ 
(Elsevier), vol. 77, no. 1, pp. 397-411, September 1, 2018, DOI: 
10.1016/j.cose.2018.04.012

[2] J. Linkova, "Let’s talk about IPv6 DNS64 & DNSSEC", APNIC Blog 
(2016). https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/

[3] CERT, “Multiple DNS implementations vulnerable to cache poisoning”, 
Vulnerability Note VU#800113 [Online].
Available: http://www.kb.cert.org/vuls/id/800113

[4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: 
Theory and Practice", /Computer Communications/ (Elsevier), in press, 
DOI: 10.1016/j.comcom.2018.05.005


So, what do you think of them?


And I would be happy to receive some feedback from various operators, 
whether they can use our results. Or perhaps what else should we 
measure, examine, analyze concerning the IPv6 transition technologies?

Best regards,

Gábor


5/27/2018 8:04 PM keltezéssel, JORDI PALET MARTINEZ írta:
>
> Hi Lencse,
>
> Thanks a lot for your inputs.
>
> I’ve read all your papers. Nice job.
>
> Do you feel I’m missing anything in the document?
>
> I’m planning a revised version of this document in 2-3 days, so it 
> will be nice if the WG can provide any additional inputs.
>
>
> Regards,
>
> Jordi
>
> *De: *v6ops <[e-mail]> en nombre de Lencse Gábor 
> <[e-mail]>
> *Fecha: *miércoles, 23 de mayo de 2018, 22:04
> *Para: *<[e-mail]>
> *Asunto: *Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion
>
> Dear Fred and Jordi,
>
> I have read the draft and I think it is useful.
>
> If I my put my two cents in, I would like to point out that we have 
> come to a very similar conclusion in Section 4.9 (titled "DNS and 
> DNSSEC") of our paper below to the one presented in Section 2 of the 
> draft.
>
> G. Lencse and Y. Kadobayashi, "Methodology for the identification of 
> potential security issues of different IPv6 transition technologies: 
> Threat analysis of DNS64 and stateful NAT64", /Computers & Security/ 
> (Elsevier), vol. 77, no. 1, pp. 397-411, September 1, 2018, DOI: 
> 10.1016/j.cose.2018.04.012
> Free access link valid until June 30: 
> https://authors.elsevier.com/a/1X1K5c43ukegl
> Revised version is available freely (as green open access) from my 
> list of publications: http://www.hit.bme.hu/~lencse/publications/ 
> <http://www.hit.bme.hu/%7Elencse/publications/>
>
> Perhaps ISPs can use our benchmarking results when selecting DNS64 or 
> NAT64 implementations.
>
> As for DNS64, we have up to date performance information, which may be 
> somewhat surprising concerning the performance problems of BIND. If 
> you are interested, please check our results concerning the DNS64 
> performance of BIND, PowerDNS and Unbound:
>
> G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: 
> Theory and Practice", /Computer Communications/ (Elsevier), to be 
> published
>
> Revised version is available freely (as green open access) from my 
> list of publications: http://www.hit.bme.hu/~lencse/publications/ 
> <http://www.hit.bme.hu/%7Elencse/publications/>
>
> As for stateful NAT64, we have only very old measurement results 
> showing that OpenBSD PF outperformed TAYGA+iptables, which was not 
> surprising at all, but those measurements were not RFC 8219 compliant, 
> as RFC 8219 did not exist yet.
>
> Best regards,
>
> Gábor
>
> On 5/14/2018 4:07 AM, Fred Baker wrote:
>
>     Consideringhttps://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-00
>     <https://tools.ietf..org/html/draft-palet-v6ops-nat64-deployment-00>, discussed at IETF 101 using the slides athttps://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-nat64-deployment-guidelines-in-operator-and-enterprise-networks-00. I'd like to invite discussion on the list. What thoughts do folks have on this draft?
>
>
>
>
>     _______________________________________________
>
>     v6ops mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>
> _______________________________________________ v6ops mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> 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.
>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops