Sandeep Pinnamaneni Vijay Chand Uyyuru Vivek Nemarugommula Topology Hiding Sandeep Pinnamaneni Vijay Chand Uyyuru Vivek Nemarugommula

Agenda Introduction Problem definition Benchmarks and Metrics Requirements Summary Conclusion

What is Topology Hiding? Provides protection by hiding internal IP addressing. Removes sensitive IP addressing and domain names. Source: www.newport-networks.com/downloads/eluff_Interworking.ppt

Network Address Translation NAT is an Internet standard that enables a local-area network (LAN) to use one set of IP addresses for internal traffic and a second set of addresses for external traffic. NAT serves three main purposes: Provides a type of firewall by hiding internal IP addresses Enables a company to use more internal IP addresses. Since they're used internally only, there's no possibility of conflict with IP addresses used by other companies and organizations. Allows a company to combine multiple ISDN connections into a single Internet connection.

Types of NAT NAT has many forms and can work in several ways: Static NAT Dynamic NAT Overloading NAT

Static NAT Mapping an unregistered IP address to a registered IP address on a one-to-one basis. Particularly useful when a device needs to be accessible from outside the network. Source: http://computer.howstuffworks.com/nat1.htm

Dynamic NAT Maps an unregistered IP address to a registered IP address from a group of registered IP addresses. Source: http://computer.howstuffworks.com/nat1.htm

Overloading NAT A form of dynamic NAT that maps multiple unregistered IP addresses to a single registered IP address by using different ports. This is known also as PAT (Port Address Translation), single address NAT or port-level multiplexed NAT. Source: http://computer.howstuffworks.com/nat1.htm

NAT Variations Full Cone NAT Restricted Cone NAT Port Restricted Cone NAT Symmetric NAT

NAT Problem The NAT maintains a 'table' that links private and public addresses and port numbers. It is important to note that these 'bindings' can only be initiated by outgoing traffic. NAT breaks end-to-end semantics. Source: http://www.newport-networks.com/whitepapers/nat-traversal.html

Methods of solving the ‘NAT Problem’ The current proposals for solving NAT traversal are: Simple Traversal of UDP Through Network Address Translation devices (STUN) Traversal Using Relay NAT (TURN) Universal Plug and Play (UPnP) Application Layer Gateway Manual Configuration Tunnel Techniques

Simple Traversal of UDP Through Network Address Translation devices (STUN) Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them.

STUN Source: http://www.newport-networks.com/whitepapers/nat-traversal.html

Operation of STUN The STUN proposal defines a special STUN server in the public address space to inform the STUN-enabled SIP client in the corporate (private) address space of the Public NAT IP address and port being used for that particular session. Having to use STUN-enabled clients, or upgrade existing clients to support STUN, makes this method unpopular. In fact, very few vendors have announced support for STUN enabled clients.

Operation of STUN STUN identifies the public side NAT details by inspecting exploratory STUN messages that arrive at the STUN server. The STUN-enabled client sends an exploratory message to the external STUN server to determine the transmit and receive ports to use. The STUN server examines the incoming message and informs the client which public IP address and ports were used by the NAT. These are then used in the call establishment messages sent to the SIP server. Note that the STUN server does not sit in the signalling or media data flows.

STUN STUN relies on the fact that once the outgoing port has been mapped for the STUN server traffic, any traffic appearing from any part of the network, with any source IP address, will be able to use the mapping in the reverse direction and so reach the receive port on the client. The destination VoIP client address is different from that of the STUN server. This means that the NAT will create a new mapping using a different port for outgoing traffic, which in turn means that the information contained in the call establishment messages is incorrect and the call attempt will fail.

Limitations of STUN STUN does not work with the type most commonly found in corporate networks – the symmetric NAT. This means that they create a mapping based on source IP address and port number as well as the destination IP address and port number. STUN does not address the need to support TCP based SIP devices. As SIP User Agents and Call Agents become more complex, the use of TCP will increase. NATs that do work in this way (i.e. using the same mapped address) are susceptible to port scan attacks and create security concerns.

Traversal Using Relay NAT (TURN) TURN relies on a server that is inserted in the media and signalling path. This TURN server is located either in the customers DMZ or in the Service Provider network. The TURN-enabled SIP client sends an exploratory packet to the TURN server, which responds with the public IP address and port used by the NAT to be used for this session. This information is used in the SIP call establishment messages and for subsequent media streams. The advantage of this approach is that there is no change in the destination address seen by the NAT and, thus, symmetric NAT can be used. TURN has recently been extended to address some serious security issues associated with TURN, which may have held back its acceptance.

Traversal Using Relay NAT (TURN)

Universal Plug and Play UPnP is a technology that is predominantly targeted at home-office users and domestic residential installations etc. One of the driving forces behind UPnP is Microsoft Corporation. The UPnP architecture is designed to address a number of general issues – not just VoIP – and is designed to allow the ready configuration of small networks by typically un-skilled people. UPnP allows client applications to discover and configure network components, including NATs and Firewalls, which are equipped with UPnP software.

Application Layer Gateway (ALG) This technique relies on the installation of a new, enhanced Firewall/NAT – called an Application Layer Gateway – that ‘understands’ the signalling messages and their relationship with the resulting media flows. The ALG processes the signalling and media streams so it can modify the signalling to reflect the public IP addresses and ports being used by the signalling and media traffic.

Application Layer Gateway (ALG)

Manual Configuration In this method, the client is manually configured with details of the public IP addresses and ports that the NAT will use for signalling and media. The NAT is also manually configured with static mappings (or ‘bindings’) for each client. This method requires that the client must have a fixed IP address and fixed ports for receiving signalling and media.

Manual Configuration

Tunnel Techniques This method achieves Firewall/NAT traversal by tunnelling both media and signalling through the existing Firewall/NAT installations to a public address space server. This method requires a new server within the private network and another in the public network. These devices create a tunnel between them that carries all the SIP traffic through a reconfigured Firewall. The external server modifies the signalling to reflect its outbound port details, thus allowing the VoIP system to both make outgoing calls and accept incoming calls. The tunnel through the existing infrastructure is not usually encrypted.

Tunnel Techniques

NAT Benchmarks The NAT benchmark creates a series of packets during initialization with various source addresses, destination addresses, and random packet sizes. Each packet is then wrapped with IP header information. Status information is included and the packets are assembled into a list for processing. Finally, the NAT rules are added to the table. The benchmark then begins processing and rewriting the IP addresses and port numbers of packets based on the pre-defined NAT rules. Each rewritten packet will have a modified source IP address and source port chosen from the available ports of each IP address available to the router. In this way, the NAT benchmark simulates an important part of network processing for many router designs, performing many of the functions of a commercial NAT implementation.

NAT Benchmarks The Network Address Translation benchmark simulates work done by a router when one address group must be translated to another address group. This code is also based on NetBSD. The instruction mix for the NAT benchmark is similar to that of the IP Reassembly benchmark, except with a few multiply and divide instructions (included in the pie chart as part of “Other”). As in the IP Reassembly benchmark, the combination of its Power Architecture instruction set and its 1 Mbyte L2 cache help the 750GX achieve a high score. The 750GX scores 3767 iterations per second on the NAT benchmark.

NAT Benchmarks

EEMBC develops networking benchmark The NAT benchmark focuses on the handling of egress packets. When a packet arrives, initial processing ascertains what action, if any, needs to be undertaken. The NetBSD NAT benchmark implementation uses a 128-entry hash table to hold information about current connections. By using the source address, destination address, protocol, and ports (if applicable) of the packet, the system computes an offset into the hash table. If this entry in the hash table relates to the current packet, the packet belongs to a connection that is already established and the packet processing is undertaken as dictated by the NAT table entry. If the packet doesn't belong to a current connection, the list of NAT rules are searched to ascertain if a rule exists for the packet handling. If a rule exists for this "connection" (rules are specified during an initialization phase before the benchmark is started), the system creates an entry in the hash table for this connection to accelerate future handling of packets for this connection. If the packet is determined to correspond to a NAT entry, the source address of the packet is altered as stipulated by the pertinent rule. The IP header checksum is then fixed to reflect this modification. Additionally, if the packet is a TCP packet, the TCP checksum is also updated to reflect the modification in source address. The translated packet is then sent onward.

Study of NAT Behavior Characterization and Measurement of TCP Traversal through NATs and Firewalls. -By Saikat Guha and Paul Francis Link: http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat/

Market Share of NAT Brands

TCP NAT Traversal Approaches

TCP NAT Traversal Approaches

TCP NAT-Traversal Success Rates

Address Shortage Causes More NAT Deployment Extrapolating the number of DNS registered addresses shows total exhaustion in 2009.

Introduction Overview Problem Definition Traversal Of Mobile Ip Introduction Overview Problem Definition

Introduction If node moves from one link to another without changing its IP address, it will be unable to receive packets at the new link If a node changes its IP address when it moves, it will have to terminate and restart any ongoing communications each time it moves Mobile IP solves these problems in secure, robust, and medium-independent manner whose scaling properties make it applicable throughout the entire Internet

Requirements Main reference document : Request for Comments (RFC-3344) in 2002. A mobile node must be able to communicate with other nodes after changing its link-layer point of attachment to the Internet, yet without changing its IP address. A mobile node must be able to communicate with other nodes that do not implement these mobility functions

Overview Mobile IP introduces the following new functional entities: Mobile Node: A host or router that changes its point of attachment from one network or sub network to another. Home Agent: A router on a mobile node's home network which tunnels datagrams for delivery to the mobile node when it is away from home, and maintains current location information for the mobile node. Foreign Agent: A router on a mobile node's visited network which provides routing services to the mobile node while registered. The foreign agent detunnels and delivers datagrams to the mobile node that were tunneled by the mobile node's home agent.

Mobile IP

Problems with IP addreses TCP Association CN (corresponding node) 128.59.16.149 135.180.32.4 80 1733 128.59.16.149 135.180.54.7 128.59.16.149 1733 80 moves MN MN (mobile node) 135.180.32.4 135.180.32.4 128.59.16.149 1733 80

NAT Traversal Of Mobile IP (Problem Definition) A basic assumption that Mobile IP makes is that mobile nodes and foreign agents are uniquely identifiable by a globally routable IP address. This assumption breaks down when a mobile node attempts to communicate from behind NAT. Mobile IP relies on sending traffic from the home network to the mobile node or foreign agent through IP-in-IP tunnelling. IP nodes which communicate from behind a NAT are reachable only through the NAT's public address(es).

Problem Illustrated

Problem Definition(continued) IP-in-IP tunnelling does not generally contain enough information to permit unique translation from the common public address(es) to the particular care-of address of a mobile node or foreign agent which resides behind the NAT; in particular there are no TCP/UDP port numbers available for a NAT to work with. For this reason, IP-in-IP tunnels cannot in general pass through a NAT, and Mobile IP will not work across a NAT.

Problem Illustrated

Conclusion What is needed is an alternative data tunnelling mechanism for Mobile IP which will provide the means needed for NAT devices to do unique mappings so that address translation will work, and a registration mechanism which will permit such an alternative tunnelling mechanism to be set up when appropriate. This solution is defined in RFC-3519. (Details in Seminar-2)

IPSec IPsec (IP security) is a standard for securing Internet Protocol (IP) communications by encrypting and/or authenticating all IP packets. IPsec provides security at the Network layer. IPsec is a set of cryptographic protocols for (1) securing packet flows and (2) key exchange

IPSec NAT Transparency The IPSec NAT Transparency feature introduces support for IP Security (IPSec) traffic to travel through Network Address Translation (NAT) or Point Address Translation (PAT) points in the network by addressing many known incompatabilites between NAT and IPSec. The IPSec NAT Transparency feature introduces support for IPSec traffic to travel through NAT or PAT points in the network by encapsulating IPSec packets in a User Datagram Protocol (UDP) wrapper, which allows the packets to travel across NAT devices

Extensions IKE Phase 1 Negotiation: NAT Detection IKE Phase 2 Negotiation: NAT Traversal Decision UDP Encapsulation of IPSec Packets for NAT Traversal (Discussed in detail in seminar-2)

References http://www.ietf.org/rfc/rfc2356.txt http://www.faqs.org/rfcs/rfc3519.html http://www.ipunplugged.com/pdf/NAPTTraversalWithMobileIP.pdf http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t1/mobileip.htm#3932 http://www.cp.eng.chula.ac.th/~intanago/Classes/2004_2/AdvComNet/Mobile%20IP.pdf http://www.faqs.org/rfcs/rfc2411.html http://en.wikipedia.org/wiki/IPSEC http://www.unixwiz.net/techtips/iguide-ipsec.html http://www.netcraftsmen.net/welcher/seminars/intro-ipsec.pdf http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t13/ftipsnat.htm http://www.phptr.com/articles/article.asp?p=330804&rl=1