Implementing Trust-to-Trust with Customer Edge Switching Raimo A. Kantola, Member, IEEE, Department of Communications and Networking Aalto University Helsinki, Finland [email protected] for the duration of a session. Abstract — A Network Address Translator allows hosts in a The UNSAF architecture requires a STUN client in the private address space to communicate with servers in the pub- hosts and STUN servers to be deployed in the global net- lic Internet. There is no accepted solution for an arbitrary host work but it leaves the NATs themselves as they are. UNSAF from the public IP network to initiate communication with a uses IP addresses for identification. It clutters applications host in a private address space although attempts have been made to create one. This paper proposes the replace NATs with code that has nothing to do with the task of the with a more comprehensive concept we call Customer Edge application. It scales poorly particularly for mobile hosts. It Switching (CES). Customer edge switching assumes connection does not help in deploying servers in private address space state on the trust boundary between the user and the core net- and thus hampers the user innovation potential. works. The connection state is managed by implicit signaling. An application on a user device such as a mobile termi- The state gives means for the private network operator to ap- nal that wants to be reachable needs to maintain a NAT ply elaborate access control to packet flows arriving from the Internet to the private network. CES is a way of moving from mapping by a keep-alive mechanism that wakes the device the end-to-end principle to the trust-to-trust principle advo- at regular intervals and keeps the NAT state alive. If the cated by Dave Clark. NAT applies the most typical policy of address and port dependent filtering, each application on the device needs to Keywords — Network Address Translator, NAT traversal, send its own keep-alives. For being able to use a single trust, user identity. mapping in the NAT, UNSAF proposes to deploy a network based TURN server for relaying all traffic to and from the host leading to high cost. I. INTRODUCTION Examples of applications that users may want to activate For a long time, the Internet community could not make on their mobiles are voice over IP clients, www-servers and up its mind on the issue of end-to-end or accepting the use mobile peer to peer applications. If even one such applica- of middle boxes such as NATs. The latter were adopted by tion is activated, it drains the mobile’s battery quickly. An the industry because they met a need of extending the IP example how the keep-alive process has been optimized is address space by private addressing and hiding customer by implementing SIP registrations on a preprocessor rather networks from the Internet. IETF took a long time to recog- than the main processor on a Nokia mobile phone. When nize NATs and started to explore how to traverse NATs first used this helped to increase battery lifetime from a few only after peer-to-peer applications had started making fun hours to less than 24h. of doing so. Compare this to the location update process for circuit Now, after the first failed attempt by IETF, there is a switched telephony on mobiles. For CS telephony the mo- new description of NAT behavior and the IETF has gone on bile usually stays reachable for several days without the to create recommendations on how to actually traverse need of recharging the battery. The difference in battery NATs [1]. The result is the Unilateral Self Address Fixing lifetime can be explained by the difference in complexity. It architecture (UNSAF). The architecture consists of the is not feasible to burn on a small piece of silicon all the STUN protocol for spying what the NAT is doing between keep-alive functions required by all applications for packet the user’s device and the global Internet and solution docu- switched services in mobile devices. Due to simplicity and ments such as Interactive Connectivity Establishment (ICE) uniformity of the CS architecture, reachability of the mobile and SIP Outbound that describe how to make use of STUN at all times is efficiently implemented by the location update in particular kinds of applications. The architecture assumes and paging process and their synchronization with the sleep- that applications will want to exchange information about wake-up cycle of the mobile. In case of circuit switched the IP addresses and ports NATs have assigned for the user mobile services, reachability is a low level function upon which an application like telephony can rely. In case of packet access to mobiles, reachability is a matter for each work and thus protect it from attacks. We believe that it is as application. important to address this need as it is to traverse the NAT. The purpose of this paper is to propose an architecture that makes hosts in private address space reachable globally. III. REQUIREMENTS The architecture does not require any keep-alive signaling Let us set the requirement that a host having a private nor registrations from a host. This is optimal for a mobile address can send messages to hosts that also are in their own host that sleeps most of the time for battery saving while private address spaces. Examples where this can apply are wishing to stay reachable and while there is no useful appli- hosts with private IPv4 addresses and hosts with 802.1 cation activity. MAC addresses that also are not globally unique. Moreover, The rest of the paper is organized as follows. Section II the solution should assume that the hosts are mobile and discusses related work. Section III sets the requirements. To may roam foreign networks. Let us formulate this idea of set the stage for the solution, Section IV discusses the dif- communication using private addresses into a clear princi- ference between routing and switching. The solution is de- ple. The principle is that a private network shall not publish scribed in Section V. The issues of deployment are ad- any routing addresses to the public domain and equally, the dressed in Section VI, Section VII compares our proposal public domain shall not publish its addresses to private with an IETF endorsed protocol and finally Section VIII networks. The purpose for the restrictions is enhancing trust. concludes. We illustrate this in Figure 1. Each domain in Figure 1 has an independent address II. RELATED WORK space and is protected by a trust boundary against inbound NAT traversal has been studied by other researchers. traffic. Most recently Miyazaki [2, 3] has explored some new solu- The solution shall not require any keep-alive signaling tions. We summarize the proposed solutions in Table 1. from a host. It makes user devices reachable by default due to network capabilities. It is preferable that all those net- TABLE 1: NAT TRAVERSAL INITIATED BY A GLOBAL NODE work capabilities reside in regular network nodes rather than Changes required in in any add-on servers. Naturally, the host needs to keep Solution GN PN NAT Other some level of attachment to the network using a layer 2 STUN No Yes No STUN Server protocol. The minimum is that the host can be found using AVES No No Yes Waypoint Server paging like in the case of incoming CS telephone calls. Syn- DNS chronizing the network attach –process with the sleep-wake- NAT-f Yes No Yes DDNS up cycle of the mobile will be a responsibility of the lower P2P/UDP Yes Yes No Master Server layer design. Extended No Yes Yes RSA-IP Server It is desirable that the solution does not introduce any RSIP DDNS new protocols for global reachability. It should rather re-use DPRP No Yes Yes existing protocols possibly with new data types. The solu- NATS No Yes Yes NTS Server tion may define new functions. It is undesirable that the GN – Global Node/host, PN – Node in a Private Network, NAT – solution requires changes in hosts because there are too Network Address Translator many of them. A perfect solution is such that if a stake- holder invests into it, it can immediately benefit irrespective Many solutions take the attitude that hosts must adapt to of what the other stakeholders are doing. work with NATs possibly with the help from some servers. On an incoming packet from the global network not A typical solution introduces switching state in a server and belonging to an existing session or flow, the private network some explicit signaling for maintaining that state. Switching shall have reasonable means of making the decision takes place on the IP layer. Several of the solutions suffer from additional configuration information that needs to be maintained. Originator Public Service domain Target IETF is working on the Locator/ID Separation Protocol trust boundaries [10] for the purpose of tackling the scaling issues in the current Internet. We will compare our solution to LISP in Figure 1: Communication across trust boundaries Section VII. All the research papers that we have been able to find whether the packet is legitimate or not. The private network concentrate on the technical problem of traversing a NAT should be offered a range of tools for helping to make that box. We argue that this misses an important point. A private decision. Collectively, these tools can be called packet ac- network administrator has a legitimate need to hide its net- cess control (PAC). We assume that the core network can be based on IPv4, created the mapping entry, it modifies the packet and sets an IPv6 or 802.1 and its variants such as 802.1ah.