Improving the performance and security of the TOTD DNS64 implementation

DNS64 and NAT64 IPv6 transition mechanisms are expected to play an important role in the near future to solve the problem that some of the new clients will not be able to get public IPv4 addresses and thus having only IPv6 addresses they still should be able to reach servers that have only IPv4 addresses. In our earlier experiments, the TOTD DNS64 implementation showed significantly better average performance than BIND, however TOTD was not stable, therefore now it was carefully tested to find the reason for its experienced strange behavior. Besides the detailed description of the testing method, the bug and the correction, a security vulnerability is disclosed and a patch is provided. The performance and the stability of the modified versions of TOTD are analyzed and compared to that of the original TOTD and BIND.Facultad de Informátic

Methodology for DNS Cache Poisoning Vulnerability Analysis of DNS64 Implementations

The trustworthy operation of the DNS service is a very important precondition for a secure Internet. As we point it out, DNS cache poisoning could be even more dangerous if it is performed against DNS64 servers. Based on RCF 5452, we give an introduction to the three main components of DNS cache poisoning vulnerability, namely Transaction ID prediction, source port number prediction, and birthday paradox based attack, which is possible if a DNS or DNS64 server sends out multiple equivalent queries (with identical QNAME, QTYPE, and QCLASS fields) concurrently. We design and implement a methodology and a testbed, which can be used for the systematic testing of DNS or DNS64 implementations, whether they are susceptible to these three vulnerabilities. We perform the tests with the following DNS64 implementations: BIND, PowerDNS, Unbound, TOTD (two versions) and mtd64-ng. As for the testbed, we use three virtual Linux machines executed by a Windows 7 host. As for tools, we use VMware Workstation 12 Player for virtualization, Wireshark and tshark for monitoring, dns64perf for Transaction ID and source port predictability tests, and our currently developed "birthday-test" program for concurrently sent multiple equivalent queries testing. Our methodology can be used for DNS cache poisoning vulnerablility analysis of further DNS or DNS64 implementations. A testbed with the same structure may be used for security vulnerablility analysis of DNS or DNS64 servers and also NAT64 gateways concerning further threats

Analysis of security impact of making mShield an IPv4 to IPv6 converter box

info:eu-repo/semantics/acceptedVersio

NAT64/DNS64 in the Networks with DNSSEC

Zvyšuj?c? se pod?l resolverů a aplikac? použ?vaj?c? DNS-over-HTTPSvede k vyš?mu pod?lu klientů použ?vaj?c?ch DNS resolvery třet?chstran. Kvůli tomu ovšem selhává nejpouž?vanějš? NAT64 detekčn?metoda RFC7050[1], což vede u klientů použ?vaj?c?ch přechodovémechanismy NAT64/DNS64 nebo 464XLAT k neschopnosti tytopřechodové mechanismy správně detekovat, a t?m k nedostupnostiobsahu dostupného pouze po IPv4. C?lem této práce je navrhnoutnovou detekčn? metodu postavenou na DNS, která bude pracovati s resolvery třet?ch stran, a bude schopná využ?t zabezpečen? DNSdat pomoc? technologie DNSSEC. Práce popisuje aktuálně standardizovanémetody, protokoly na kterých závis?, jejich omezen?a interakce s ostatn?mi metodami. Navrhovaná metoda použ?vá SRVzáznamy k přenosu informace o použitém NAT64 prefixu v globáln?mDNS stromu. Protože navržená metoda použ?vá již standardizovanéprotokoly a typy záznamů, je snadno nasaditelná bez nutnostimodifikovat jak DNS server, tak s?t'ovou infrastrukturu. Protožemetoda použ?vá k distribuci informace o použitém prefixu globáln?DNS strom, umožňuje to metodě použ?t k zabezpečen? technologiiDNSSEC. To této metodě dává lepš? bezpečnostn? vlastnosti nežjaké vykazuj? předchoz? metody. Tato práce vytvář? standardizačn?bázi pro standardizaci v rámci IETF.The rising number of DNS-over-HTTPS capable resolvers and applicationsresults in the higher use of third-party DNS resolvers byclients. Because of that, the currently most deployed method of theNAT64 prefix detection, the RFC7050[1], fails to detect the NAT64prefix. As a result, clients using either NAT64/DNS64 or 464XLATtransition mechanisms fail to detect the NAT64 prefix properly,making the IPv4-only resources inaccessible. The aim of this thesisis to develop a new DNS-based detection method that would workwith foreign DNS and utilize added security by the DNS securityextension, the DNSSEC. The thesis describes current methods ofthe NAT64 prefix detection, their underlying protocols, and theirlimitations in their coexistence with other network protocols. Thedeveloped method uses the SRV record type to transmit the NAT64prefix in the global DNS tree. Because the proposed method usesalready existing protocols and record types, the method is easilydeployable without any modification of the server or the transportinfrastructure. Due to the global DNS tree usage, the developedmethod can utilize the security provided by the DNSSEC and thereforeshows better security characteristics than previous methods.This thesis forms the basis for standardization effort in the IETF.

Migration to a New Internet Protocol in Operator Network

This thesis explains the differences between IPv4 and IPv6. Another important part of the thesis is to review the current readiness of IPv6 for worldwide production use. The status (in terms of readiness, adaptability, compatibility and co-existence) of IPv6 in TeliaSonera is discussed in more detail. The most important reason for migrating to IPv6 is the address exhaustion of IPv4. This may not be a big problem in the developed countries but in developing countries the growth of Internet is fast and lots of more addresses are needed. The need for addresses is not only from computers but from many devices connected to the Internet. Attempts to slow down the exhaustion of free addresses have been made but current solutions are not enough. IPv6 will solve the problem by using much longer addresses. It will also add security features and simplify headers to speed up routing. TeliaSonera has started to roll out IPv6 services. At the beginning the corporate customers will receive IPv6 connectivity and consumers will follow later. TeliaSonera International Carrier is already serving its customers with IPv6. It seems that IPv6 is ready, standards have been ready for years and support in devices and software is prevalent. To achieve and keep up the global connectivity, IPv6 is a must and should not be avoided

An analysis of the risk exposure of adopting IPV6 in enterprise networks

The IPv6 increased address pool presents changes in resource impact to the Enterprise that, if not adequately addressed, can change risks that are locally significant in IPv4 to risks that can impact the Enterprise in its entirety. The expected conclusion is that the IPv6 environment will impose significant changes in the Enterprise environment - which may negatively impact organisational security if the IPv6 nuances are not adequately addressed. This thesis reviews the risks related to the operation of enterprise networks with the introduction of IPv6. The global trends are discussed to provide insight and background to the IPv6 research space. Analysing the current state of readiness in enterprise networks, quantifies the value of developing this thesis. The base controls that should be deployed in enterprise networks to prevent the abuse of IPv6 through tunnelling and the protection of the enterprise access layer are discussed. A series of case studies are presented which identify and analyse the impact of certain changes in the IPv6 protocol on the enterprise networks. The case studies also identify mitigation techniques to reduce risk