NATCracker: NAT Combinations Matter Roberto Roverso 1,2 , Sameh El-Ansary 1,3 , and Seif Haridi 2 1 Peerialism Inc., Sweden, 2 KTH-Royal Institute of Technology, Sweden, 3 Nile University, Egypt {roberto,sameh}@peerialism.com, seif@it.kth.se Abstract—In this paper, we report our experience in working with Network Address Translators (NATs). Traditionally, there were only 4 types of NATs. For each type, the (im)possibility of traversal is well-known. Recently, the NAT community has provided a deeper dissection of NAT behaviors resulting into at least 27 types and documented the (im)possibility of traversal for some types. There are, however, two fundamental issues that were not previously tackled by the community. First, given the more elaborate set of behaviors, it is incorrect to reason about traversing a single NAT, instead combinations must be considered and we have not found any study that comprehensively states, for every possible combination, whether direct connectivity with no relay is feasible. Such a statement is the first outcome of the paper. Second, there is a serious need for some kind of formalism to reason about NATs which is a second outcome of this paper. The results were obtained using our own scheme which is an augmentation of currently-known traversal methods. The scheme is validated by reasoning using our formalism, simulation and implementation in a real P2P network. I. I NTRODUCTION Dealing with Network Address Translators (NATs) is nowa- days an essential need for any P2P application. The techniques used to deal with NAT have been more or less “coined” and there are several widely-used methods[1][2]. Some of them are rather a defacto standard like STUN [3],TURN [4],ICE [5]. In the context of our a P2P live video streaming application PeerTV, we are mainly concerned with media streaming using UDP and therefore the scope of this paper is UDP NAT traversal. Moreover, we are strictly interested in solutions that do not use relay, such as TURN for instance, due to the high bandwidth requirements of video streaming. We have found lots of of previous work on the subject that aims to answer the following question: For every t in the set of NAT types T , which s in the set of traversal strategies S should be used to traverse t? The answer is of the form f : T→S . i.e. the following is an example with a couple of types f : { Simple Hole Punching, Port-Prediction }→{ Full-Cone, Symmetric} [6]. However, the point which we found not gaining enough attention is that the presence of a feasible traversal technique that enables two peers behind NAT to communicate depends on the “combination” of the NAT types and not on the type of each peer separately. Thus, the question should be: “Given 2 peers p a and p b with respective NAT types t(p a ) and t(p b ), which traversal strategy s is needed for p 1 and p 2 to talk? The answer is of the form f : T×T→S ”, i.e we need to analyze traversable combinations rather than traversable types. Most works contain a few examples of combinations for explanation purposes [6][7]. However, we have failed to find any comprehensive analysis that states, for every possible combination of NAT types, whether direct (i.e. with no relay) connectivity is possible and how. The analysis is more topical given that NAT community is switching from the classical set of NAT types T classic = { Full-Cone, Restricted-Cone, Port- Restricted, Symmetric} [3] to a more elaborate set that defines a NAT type by a combination of three different policies, namely, port mapping, port allocation and port filtering [8]. With that, a statement like “two peers behind symmetric NAT can not communicate” becomes imprecise, as we will show that in many cases it is possible given the nuances available in the presently wide spectrum of NAT types. II. RELATED WORK The work in [7] includes a matrix for a number of combina- tions, however mostly drawn from T classic rather than the more elaborate classification in [8]. The work in [6] is probably the closest to ours, one can see our work as a superset of the set of combinations mentioned in that work. III. NAT TYPES AS COMBINATIONS OF POLICIES In this section we try to semi-formally summarize the more elaborate classification of NATs known as “BEHAVE- compliant”[8] and craft the notation that we will use in the rest of the paper. Notation. Let n a and n b be NAT gateways. For i ∈{a, b}, Let P i = {p i ,p ′ i ,p ′′ i ,... } be the set of peers behind n i . An “endpoint” e is a host-port pair e =(h, p), where h(e) is the host of e and p(e) is its port. Let V i = {v i ,v ′ i ,v ′′ i ,... } denote the set of all private endpoints of all peers behind n i and U i = {u i ,u ′ i ,u ′′ i ... } be the set of public endpoints of n i . i.e ∀v ∈ V i ,h(v) ∈ P i and ∀u : U i ,h(u)= n i . When a packet is sent out from a certain private endpoint v i of a peer p i behind a gateway n i , to some public endpoint d, a rule in the NAT table of n i is created. We define the set of NAT table rules R i = {r i ,r ′ i ,r ′′′ i } at n i , the rule records the fact that some public port u i and some private port v i are associated, e.g r a =(v a ↔ u a ). The behavior of a gateway n i is defined by three policies, namely, port mapping, port filtering and port allocation. We use the notation f (n i ),m(n i ),a(n i ) to denote the respective policies of gateway n i .