assignment 2 koustubh arpit
TRANSCRIPT
ANSWER 1
(a)
(b)
Packets- 3, 4, 6, 7, 8
Packet Delay
2 7
3 9
4 8
5 7
6 9
7 8
8 8
(c)
Packets -3, 6
(d)
Minimum delay= 2 units of time.
ANSWER 2
(a)
di = (1- u)di-1 + u(ri - ti)
U=0.1
Packet Estimated delay for packets
2 1.33
3 2.097
4 2.687
5 3.119
6 3.707
7 4.136
8 4.662
(b)
vi = (1- u)vi-1 + u(ri - ti - di)
U=0.1
Packet Estimated deviation of
delay from estimated avg
2 1.23
3 1.7073
4 2.0678
5 2.2492
6 2.5536
7 2.6846
8 2.7539
ANSWER 3
(e)
For the address 2819:00AF:0000:0000:0000:0035:0CB2:B271;
Sr.No Question After Abbreviation
(a) 0000:0000:0F53:6382:AB00:67DB:BB27:7332 ::F53:6382:AB00:67DB:BB27:7332
(b) 0000:0000:0000:0000:0000:0000:004D:ABCD ::4D:ABCD
(c) 0000:0000:0000:AF36:7328:0000:87AA:0398 ::AF36:7328:0:87AA:398
(d) 2819:00AF:0000:0000:0000:0035:0CB2:B271 2819:AF::35:CB2:B271
Name Address After Abbreviation
Link-Local FE80:0000:0000:0000:0000:0035:0CB2:B271
FE80::35:CB2:B271
Unique Local FC00:0000:0000:0000:0000:0035:0CB2:B271 FC00::35:CB2:B271
Node Multicast IPv6
FF02:0000:0000:0000:0000:0001:FFB2:B271 FF02::1:FFB2:B271
ANSWER 4
(a)
Scenarios Message
type
Code ICMPv6 error message
Router drops a packet as the
size is too big
2 0
Router drops a packet
because of a prohibiting
policy.
1 1 communication with destination
administratively prohibited
The IPv6 layer of a host
receives an IP packet for a
non-existing process.
1 4 port unreachable
(b)
Scenarios DHCPv6 messages required for the following
The client wants to obtain two temporary IP addresses ::8080 and ::8090 from the
DHCP server
DHCPv6 message – DHCPREQUEST Message type: Request (3) Transaction-ID: 0x0086a342 Client Identifier option type: 1 option length: 14 DUID type: link-layer address plus time (1) Hardware type: Ethernet (1) Time: 281507745 Link-layer address: 00:16:3e:18:88:fe Server Identifier option type: 2 option length: 14 DUID type: link-layer address plus time (1) Hardware type: Ethernet (1) Time: 281498447 Link-layer address: 00:16:3e:60:6d:5d Option Request option type: 6 option length: 4 Requested Option code: DNS recursive name
server (23) Requested Option code: Domain Search List (24) Elapsed time option type: 8 option length: 2 elapsed-time: 0 ms Identity Association for Non-temporary Address option type: 3 option length: 40 IAID: 1041795326 T1: 3600 T2: 5400 IA Address option type: 5 option length: 24 IPv6 address: 2001:558:ff10:870:f914:a7c1:42d1:faa1 Preferred lifetime: 7200 Valid lifetime: 7500
The server wants to reconfigure all the clients with the IPv6 network prefix
2001:30:42::/48
DHCPv6 message - DHCPFORCERENEW Message type: Reconfigure (10) Transaction-ID: 0x00000000 Client Identifier option type: 1 option length: 14 DUID type: link-layer address plus time (1) Hardware type: IEEE 802 (6) Time: 1414087501 Link-layer address: 00:15:a4:a5:a4:68 Server Identifier option type: 2 option length: 14 DUID type: link-layer address plus time (1) Hardware type: Ethernet (1) Time: 261780576 Link-layer address: 00:03:ba:90:fb:61 Reconfigure Message option type: 19 option length: 1 Reconfigure-type: Renew Authentication option type: 11 option length: 28 Protocol: 3 Algorithm: 1 RDM: 0 Replay Detection Authentication Information
ANSWER 5
(a)
In the context of computer networks, the signal is generally a data packet, and the RTT is also known as the ping
time. An internet user can determine the RTT by using the PING command.
We use PING from the CMD Window.
It gives us the following:-
Type of RTT In Units of milliseconds
Minimum 0
Maximum 8
Average 2
(b)
Using traceroute tool at: http://support.deldsl.net/cgi-bin/trace/chaseroute.pl. Tracing route to 8.8.8.8. [8.8.8.8] Over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms ptr-203-110-87-17.deldsl.net [203.110.87.17] 2 <1 ms <1 ms <1 ms ptr-203-110-80-9.deldsl.net [203.110.80.9] 3 2 ms 2 ms 2 ms 115.113.254.77.static-delhi.vsnl.net.in [115.113.254.77] 4 44 ms 44 ms 43 ms 172.31.17.5 5 43 ms 42 ms 43 ms 121.240.1.46 6 46 ms 46 ms 46 ms 209.85.241.21 7 47 ms 47 ms 46 ms google-public-dns-a.google.com [8.8.8.8] Trace complete.
(c)
Network-Tools Traceroute Results :
Network-Tools Traceroute Results [Clear]:
traceroute to 49.248.160.149 (49.248.160.149), 30 hops max, 40 byte packets 1 vserver155.hostnoc.net (64.120.200.186) 0.073 ms 0.019 ms 0.017 ms 2 ec0-61.agg04.sctn01.hostnoc.net (96.9.184.62) 0.858 ms 0.832 ms 0.809 ms 3 xe1-04.gwy02.sctn01.hostnoc.net (96.9.191.13) 0.777 ms 0.755 ms 0.730 ms 4 TenGE2-1.br02.phl02.pccwbtn.net (63.218.31.41) 5.675 ms 6.643 ms 6.618 ms 5 gblx.ge12-4.br02.ash01.pccwbtn.net (63.218.94.214) 10.583 ms 10.558 ms 11.522 ms 6 te3-2-10G.ar5.DCA3.gblx.net (67.16.139.66) 8.498 ms 8.471 ms 8.446 ms 7 teleglobe-1.ar5.dca3.gblx.net (64.215.195.82) 9.405 ms 8.967 ms 9.956 ms 8 if-3-2.tcore2.NJY-Newark.as6453.net (216.6.87.10) 216.812 ms if-10-2.tcore1.L78-London.as6453.net (216.6.87.105) 204.794 ms 206.757 ms 9 if-6-2.tcore2.MLV-Mumbai.as6453.net (80.231.130.6) 211.728 ms 209.843 ms 208.842 ms 10 if-4-2.tcore1.L78-London.as6453.net (80.231.130.33) 209.934 ms 207.888 ms 180.87.39.98 (180.87.39.98) 231.841 ms 11 if-6-2.tcore2.MLV-Mumbai.as6453.net (80.231.130.6) 216.820 ms * * 12 115.113.164.198.static-mumbai.vsnl.net.in (115.113.164.198) 211.738 ms 180.87.39.98 (180.87.39.98) 216.710 ms 231.669 ms 13 * 202.149.208.108 (202.149.208.108) 209.802 ms 209.841 ms 14 smtp.ttml.co.in (49.248.251.166) 240.824 ms 115.113.164.198.static-mumbai.vsnl.net.in (115.113.164.198) 213.843 ms *
(d)
Name Server:NS1.BITS-PILANI.AC.IN Name Server:NS2.BITS-PILANI.AC.IN
(e) Administrative Contact: Finance Team, APNIC
[email protected] APNIC Pty Ltd 6 Cordelia St, PO Box 3646 Brisbane, QLD 4101 AU +617-3858-3100 fax: +617-3858-3199 (f) For this, we use ‘netstat’ with various extensions. Example:- If we use ‘netstat –sp tcp’, we get response as,
If we use ‘netstat –sp udp’, we get response as,
(g)
All the TCP connections opened to access the website www.google.com
When we use ‘tracert’, we can see that it has only 2 TCP connections
‘Pathping’ command confirms the above point.
ANSWER 6
Part A.
Write appropriate Wireshark capture filters you need to capture the traffic described below.
I. Capture HTTP traffic. Does your filter work in the presence of proxy server too? Why (not)?
If we go for ‘display filter’, then we can just type ‘http’ in the ‘filter expression’ box.
Example:-
However, if we want to go for ‘capture filter’, we can do that only if we know the port number. Since in our
case we know that port number = 8080, so we can capture it. So the capture filter would be “tcp.port ==
8080”
Example:-
Yes, it is working for a proxy server as well. It automatically detects the proxy server through the application
layer.
II. Capture DNS traffic going to the name server 10.1.1.61.
The capture filter for such a case is “udp.port == 53 and ip.dst == 10.1.1.61”
III. Capture all the packets containing TCP connection setup and release segments.
To capture TCP packets, we use “tcp.stream” in the capture filter.
IV. Capture all the UDP packets going from 10.2.1.230 to 10.1.1.26
The capture filter will be “udp.port == 53 and ip.src == 10.2.1.230 and ip.dst == 10.1.1.26”
Part B. Use Wireshark to capture all the traffic coming to the NIC. Write a proper display filter for the following
scenarios.
I. All the RTSP packets.
To display RTSP packets, we have to use “rtsp” in the display filter.
For the capture filter, we cannot directly filter RTSP protocols while capturing. However, if you know the
TCP port used we can filter on that one. Here, the capture filter will be “tcp.port == 8080”
II. All the DHCPv6 packets from the localhost.
We can use “bootp” in the display filter.
If we use “dhcpv6” in the display filter,
III. All the packets containing HTTP requests to host www.bits-pilani.ac.in.
For this, we must know the destination ip address. So if do a dnsquery of the url www.bits-pilani.ac.in,
we can find where the name server is located. Then we can give the display or capture filter as
“http.request and ip.dst == 202.78.175.200”.
Or we can also use the string function of Wireshark expression field.
If we use the expression “http.request.uri contains www.bits-pilani.ac.in”, we can get all http requests
to that particular URL.
Example:-
IV. TCP stream between 10.2.1.230 and 10.1.1.26
We use the expression in the display or capture filter “tcp.stream and ip.src == 10.2.1.230 and ip.dst ==
10.1.1.26”
As an example, we have used source ip as 10.20.1.183.
ANSWER 7
(a) .flickr.com .yahoo.com .scorecardresearch.com s.yimg.com .google.com .youtube.com .google.co.in login.yahoo.com us.yahoo.com
(b) .flickr.com .yahoo.com .scorecardresearch.com s.yimg.com .google.com .youtube.com .google.co.in login.yahoo.com .google.co.in
3rd party cookies are:- r02.ycpi.in.yahoo.net (YahooTrafficServer) r07.ycpi.in.yahoo.net (YahooTrafficServer) ad.yieldmanager.com
(c)
(d)
The logout status of a google account user is indicated in the following way in the cookies: Set-Cookie: SID=EXPIRED; Set-Cookie: HSID=EXPIRED
Set-Cookie: SSID=EXPIRED; Set-Cookie: APISID=EXPIRED Set-Cookie: SAPISID=EXPIRED
Set-Cookie: LSID=EXPIRED
(e)
The main contents of the site comes from the site itself, but the ads come from another server or website. The browser assembles the different information fed from different sources so that all items appear on the same page.
For the browser to assemble the ads correctly, the website directs the browser to collect information from a different site's ad server. The third party website creates a cookie in the browser's folder as a result.
(f) 200 OK www.flickr.com 200 OK us.adserver.yahoo.com 200 OK us.bc.yahoo.com 200 OK geo.yahoo.com 302 Moved Temporarily b.scorecardresearch.com 200 OK login.yahoo.com 200 OK s.yimg.com 302 Found www.flickr.com 302 Moved Temporarily sb.scorecardresearch.com 302 Found open.login.yahoo.com 302 Moved Temporarily www.google.com 302 Moved Temporarily accounts.google.com 200 OK accounts.google.com 200 OK accounts.youtube.com 200 OK accounts.google.co.in 200 OK adjax.flickr.yahoo.com 302 Found cookex.amp.yahoo.com 302 Found ad.yieldmanager.com 200 OK apis.google.com 404 Not Found r07.ycpi.in.yahoo.net 204 No Content us.yahoo.com
ANSWER 8
(a)
We can do so by identifying the number of stack sequences of the identification numbers. If there is a large difference between two identification numbers, then they must have been sent by different hosts. The number of unique hosts will be equal to the number of sequence patterns. (b) If the identification numbers are not sequentially assigned but randomly assigned, then technique won't work because we cannot identify the sequence and hence the number computer behind the NAT which was sending them.
ANSWER 9
The following pages contain solution to answer 9.
NAT Traversal Techniques And
Peer-To-Peer Applications
Koustubh Laha BITS Pilani K.K. Birla Goa Campus
Arpit Gupta BITS Pilani K.K. Birla Goa Campus
Abstract— This paper reviews commonly existing and
Peer-to-Peer widely using NAT transversal techniques.
There is no heal-all technique to make NAT devices fully
inter-operable with P2P applications. On the other hand,
P2P applications could have to make use general purpose
method combined with special efforts to cope with
different NAT environment.
INTRODUCTION
Network Address Translation (NAT) is very useful in Small
Office and Home Office (SOHO) community to build a small
private network by sharing global routable IP addresses. The
main reason of the trouble is NAT mangling IP addresses and
port numbers thus breaking common end-to-end connections.
NAT Traversal Techniques is to let enable end-to-end protocol
and application packets through NAT gateway directly or
indirectly. Before delving deeper into the problem, we must
know the definitions of the terms we are going to deal with.
A. Network Address Translation (NAT)
Network Address Translation is a technique by which endpoint
IP address or IP address with TU port are translated from
private address realm to public address realm and back.
Network Address Translators both in software or hardware,
offer transparent routing to hosts by mapping private and
public address realms based on a conceptual communication
session. The main reason of NAT’s birth is the short-term
solution of IPv4 address depletion.
Figure 1: NAT Scenario.
A communication session between two hosts is identified as
the 4-tuple (local IP, local Port, remote IP, remote Port). The
most common NAT is traditional or outbound NAT which is
an asymmetric mapping between private address realm and
public address realm. Outbound NAT by default only permits
outbound sessions and blocks all incoming packets unless the
session is identified as an existing session initiated from
trusted private network host. Pure translations of addresses are
basic NAT. Both address and ports translations are Network
Address/Port Translation (NAPT). Obviously outbound NAT
conflicts with Peer-to- Peer communication. Bi-directional
NAT or Inbound NAT is to allow sessions initiated from either private or public hosts. A DNS-ALG must be deployed to
facilitate NAT for address and domain names mapping. A
NAT is session based on endpoint identities translation. NAT
device keeps an endpoint session address binding. Once the
first session address binding is created, the subsequent
sessions are associated with the same address binding. A new
address binding is created by starting a brand new session
between local and remote hosts. More complex, private hosts
might reside in multi-level NATs or a overlapped NATs when
two NAT environments merges with private address realm
overlapped.
B. Peer-to-Peer Network
Peer-to-Peer network is different with Client-Server network.
In Peer-to-Peer network peers have equal positions without
classification of client and server and peers are directly
connected by other peers. They act both as client and server
simultaneously.
PROBLEM STATEMENT
In NATed environment, general firewall/NAT role does not
allow incoming connection to private addressed hosts unless
private hosts initiate the connection at first or NAT is
specifically configured. The built-in privacy and security
benefits of NAT are private addressed hosts hiding. On the
other hand, this is a trouble because it is hard to locate and
communicate with the private hosts behind a NAT gateway.
How two private addressed hosts behind NATs could get to
know each other in the very beginning of the Peer-to-Peer
communication?
SOLUTION
The above problem demands NAT device makers, protocol
designers and Peer-to-Peer application vendors to provide
smooth and secure two way direct communication including
unsolicited incoming connection attempts for customers’ hosts
residing in NATed environments. Diverse NAT Traversal
Techniques offer a variety of NAT devices with transparent
traversal abilities to keep the end-to-end connection virtually.
Some of them are NAT gateway optimized and plugged
techniques such as Universal Plug and Play (UPnP),
Application Lever Gateway (ALG). Some of them are fall-
back (make use of Client-Server model) approaches, by which they use a relay server or introducer server on either side of
NAT gateway or both sides, such as STUN and TCP/UDP
hole punching. No single NAT traversal technique is suitable
for all NAT necessary environments since NAT is not
standard, that is, no single Peer-to-Peer application could work
smoothly in all NATed hosts. Some of the techniques have
been described below.
C. Universal Plug and Play (UPnP)
UPnP is architecture and open standard for flexible
connectivity of intelligent both wired and wireless devices. The automatic service discovery, addressing, zero
configuration are suitable for SOHO. UPnP’s specification is
based TCP/IP. Windows Internet Connection Sharing (ICS) is
UPnP enabled. When a new host needs a connection, UPnP
device can automatically configure network addressing,
announce its presence on a network subnet, and permit the
exchange of device and service descriptions. A Windows XP-
based computer application could detect that if it is behind an
UPnP-enabled NAT device. Then the application can learn the
shared, globally-routable IP address, and configure UDP and
TCP port mappings to forward packets from the external ports of the NAT to the internal ports.
D. Simple Traversal UDP Through Network Address
Translators (STUN)
STUN is lightweight protocol to allow the applications in
private address realm to discover the presence of NAT devices
and type of NAT between them and public address realm. The
steps followed by it are:-
1. STUN client asks the STUN server for a temporary
user name and password for subsequence Binding Requests and Binding Responses’ packets integrity
check and authentication.
2. The STUN client sends a Binding Request to STUN
Server which typically resides in public address
realm.
3. The request UDP packet may traverse several NAT
devices to arrive STUN server.
4. The Server could learn the last NAT modified source
address and port.
5. The STUN server then copies the source address and
port into a Binding Response and sends it back to the STUN client.
By comparing itself local address and port in response packet,
STUN client could learn if it is behind a NAT device. By
sending two Binding Requests from the same source address
and port to two different IP addresses, STUN client could
further learn if it is behind a symmetric NAT device.
Figure 2: STUN Scenario
The advantage of STUN is it does not require any changes on
NAT devices. On the other side, STUN is just a short term
solution. It does not work with symmetric NAT which is
commonly used by large corporate users. STUN requires
client application upgraded to support STUN and an additional
STUN server residing in public Internet.
E. Application Level Gateway (ALG)
In the context of computer networking, an application-level
gateway (also known as ALG or application layer gateway)
consists of a security component that augments a firewall or
NAT employed in a computer network.
It allows customized NAT traversal filters to be plugged into
the gateway to support address and port translation for certain
application layer "control/data" protocols such as FTP,
BitTorrent, SIP, RTSP, file transfer in IM applications etc.
In order for these protocols to work through NAT or a firewall, either the application has to know about an
address/port number combination that allows incoming
packets, or the NAT has to monitor the control traffic and
open up port mappings (firewall pinhole) dynamically as
required. Legitimate application data can thus be passed
through the security checks of the firewall or NAT that would
have otherwise restricted the traffic for not meeting its limited
filter criteria.
F. UDP and TCP hole punching
UDP and TCP hold punching is general purpose, robust technique to establish peer-to-peer communication in Peer-to-
Peer network. The main idea of hole-punching is to have a
relaying server which could be reached by clients both or
either behind NAT. Two clients send registration message
containing private IP address, TU port and public IP address,
TU port to relay server. Relay server then introduces two
clients to know each other private and public IP address and
TU port. UDP hold punching works well for clients behind
same NAT, clients behind different NATs and multiple level
NATs. TCP hold-punching requires a single local TCP port to
listen to an incoming TCP connection and to initiate multiple
outgoing TCP connections concurrently.
Figure 3: Hole-Punching with two clients behind different
NAT Scenario
This requires operating system and API support. Hole-
punching does not work with symmetric NAT.
DISADVANTAGES AND SHORTCOMINGS
So far we have seen how we can solve the problem which a
regular NATed network creates. But the above methods also
come with a lot of disadvantages or security constrictions. We
will see them point-by-point.
G. Avoidance of IP address
NAT is not aware of embedded IP address and ports so that
private un-routable address leaks publicly because NAT
would not do proper address mapping. Protocol designers and
application makers should avoid using IP address and TU
ports in payload directly.
H. ALG Complexity
With use of ALG, NAT can allow inbound connections. But
this technique would not work without additional software
upgrade on NAT device. This increases device cost and
decreases the popularity of ALG thus dis-encourage designers
to use ALG to make NAT friendly to Peer-to-Peer
applications.
I. Reuse session address binding
Symmetric NAT does not offer the reuse of session address
binding resulting in TU hole punched not possibly being further used for Peer-to-Peer subsequent communication. It is
suggested to keep a single connection as possible as it could.
NAPT NAT TU timers should be set properly to allow
maximum use of session address binding and to recycle TU
port resource.
J. Peer-to-Peer application automatic and manual
configuration
Peer-to-Peer application is suggested to use hybrid approach:
combine pure Peer-to-Peer with Client-Server network.
Automatically NAT detection and awareness for peer client is
important to diagnose the type of behavior of NAT device,
even multi-level NATs. This technique requires at least one
dedicated response server to give exploratory response
messages to peer clients.
K. Security Concerns
There is always an engineering trade-off between open and security. Client-Server model is less open than Peer-to-Peer
model and it is more secure with NAT and firewall. Currently
NAT traversal techniques are to modify NAT device and
firewall to let Peer-to-Peer application packets going through.
Techniques like hole-punching opens a two way TU port hole
in NAT/Firewall. Naive NAT and Firewall cannot simply
recognize whether reused session binding is secure or not.
NAT breaks the open end-to-end connection. This introduces
more complexity of security implementation.
CONCLUSION
In order to make NAT devices friendly to Peer-to-Peer
applications, many NAT traversal techniques are invented.
Some technique has limitation resulting in less popularly
acceptance and slow deployment. Some technique like hole-
punching is widely deployed and general purpose method. For
SOHO community, due to the limit knowledge about network
and device, management and configuration NAT is pessimistic
for end users. Most Peer to Peer service chooses hole-
punching as a general purpose method to transverse NATs.
Relaying server is a fall-back strategy of using Client-Server
model to solve peer-to-peer network problem. Using hybrid
approach is a make shift and practical way. In the short term, NAT will widely exist and there is no single
technique which could solve diverse NAT traversal problems.
In the long term, IPv6 would offer enough address space to
accommodate any IP based terminals. It is said IPv6 could
offer each grain of sand a unique address on the planet. At that
time, NAT might not be necessary. However those techniques
like hole-punching and UPnP is still very useful on IPv6 era.
REFERENCES
Zhou Hu, NAT Traversal Techniques and Peer-to-Peer Applications, Telecommunications Software and Multimedia Laboratory; Helsinki University of Technology; hzhou@ cc.hut.fi
A New Method for Symmetric NAT Traversal in UDP and TCP
Koustubh Laha
BITS Pilani K.K. Birla Goa Campus
Arpit Gupta
BITS Pilani K.K. Birla Goa Campus
Abstract — This paper proposes a new method for Network
Address Translator (NAT) Traversal in UDP. Existing NAT
traversal methods cannot traverse symmetric NAT boxes. This
method uses a new port prediction method which helps solve the above problem. It is based on new UDP hole punching technique.
II. INTRODUCTION TO PROBLEM STATEMENT
A network address translator (NAT) is a well-known, versatile tool that enables the reuse of IP addresses in the
Internet. However, a fatal problem can occur if an applications
protocol includes an IP address as part of the payload of IP
packets. There have been many proposals to solve this
problem. Existing NAT traversal methods like Universal Plug
and Play (UPnP), Simple traversal of UDP over NATs (STUN)
and Teredo, cannot traverse symmetric NAT boxes.
This paper proposes a new method for NAT traversal, which is
applicable to symmetric NATs as well as other types of NATs.
This new method is based on port prediction. It manipulates
port numbers in order to traverse symmetric NATs
successfully. Several experiments have been conducted to
evaluate the performance of this new method. The results show
that this method can be practically implemented for successful
NAT traversal.
In this review, we describe the various types of NATs. Then
we survey the existing methods of NAT traversal. Later the new method is proposed. We also see the results of the
experiments conducted finally concluding the review.
III. TAXONOMY OF NAT
Full Cone, Restricted Cone, Port Restricted Cone and
Symmetric are the different types of NATs. For better
understanding, we use the following terms:-
1. Addr – node address with prefix i – internal; e –
external; h - host;
2. Port – node port number with prefix i – internal; e –
external; h - host;
A. Full-cone NAT
Once an internal address (iAddr: iPort) is mapped to an
external address (eAddr: ePort), any packets from (iAddr:
iPort) will be sent through (eAddr: ePort). Any external host
can send packets to (iAddr: iPort) by sending packets to
(eAddr: ePort).
B. Address restricted cone NAT
Once an internal address (iAddr: iPort) is mapped to an
external address (eAddr: ePort), any packets from iAddr: iPort
will be sent through (eAddr: ePort).
An external host (hAddr: any) can send packets to (iAddr:
iPort) by sending packets to (eAddr: ePort) only if (iAddr:
iPort) has previously sent a packet to (hAddr: any). "Any"
means the port number doesn't matter.
C. Port-restricted cone NAT
Similar to an address restricted cone NAT, but the restriction
includes port numbers.
Once an internal address (iAddr: iPort) is mapped to an
external address (eAddr: ePort), any packets from iAddr: iPort)
will be sent through (eAddr: ePort). An external host (hAddr:
hPort) can send packets to iAddr: iPort) by sending packets to
(eAddr: ePort) only if (iAddr: iPort) has previously sent a
packet to (hAddr: hPort).
D. Symmetric NAT
Each request from the same internal IP address and port to a
specific destination IP address and port is mapped to a unique
external source IP address and port, if the same internal host
sends a packet even with the same source address and port but
to a different destination, a different mapping is used.
Only an external host that receives a packet from an internal
host can send a packet back.
IV. EXISTING SOLUTIONS TO THE PROBLEM
There have been many proposals on methods to traverse NATs.
This section describes some well-known techniques such as
UPnP, STUN, and Teredo. However, they cannot be applied to
Symmetric NAT.
A. UPnP
In a UPnP architecture ,when a new host needs a connection,
the UPnP device can automatically configure a network
address, announce its presence on the network subnet, and
exchange a description of device and services. NAT traversal
in UPnP is known as the Internet Gateway Device (IGD)
Protocol. However, one of the disadvantages of UPnP is that it
requires that all the devices in the network should support
UPnP.
B. STUN
STUN is a protocol used for communication between a client
and a server. If a peer-to-peer software package includes a
STUN client, it sends a request to a STUN server. The server
then reports back to the STUN client about the global IP
address of the NAT router. One of the drawbacks of STUN is
that it does not work with symmetric NATs. STUN cannot
handle symmetric NATs because the global IP address and port
number translated from the private address and port number of
the client are not fixed.
C. Teredo
Based on IPv6 tunneling technology proposed by Microsoft, a
Teredo client obtains a Teredo IPv6 address from the Teredo
server. It utilizes an IPv6 address with IPv6 tunneling in UDP/IPv4.It communicates with other Teredo clients and other
IPv6 nodes through a Teredo relay. A Teredo server should
have both an IPv4 global address and an IPv6 global address.
A Teredo relay should have an IPv4 global address and an IPv6
global address. It provides routing between the Teredo clients
and nodes on the IPv6 Internet.
V. INTRODUCTION OF A NEW METHOD
In this section we propose a new method for UDP multi-hole
punching. This method establishes a UDP connection between
two end points through NATs. The new method is based on
port prediction and limited TTL values. It controls the port numbers to allow successful traversing of symmetric NATs. It
also works well for the other types of NATs. In addition, the
new method can be extended to NAT traversal in TCP.
The following steps elaborate the process.
F1. The echo client communicates with S1. Then, S1
analyzes the port number mapped by NATa.
F2. S1 conveys the port number to the echo client.
F3. The echo client sends a packet to S2. It includes
information obtained on the port number of NATa
when the echo client communicated with S1. Then, S2
analyzes the port number of NATa and records it.
Furthermore, S2 also records the information obtained
on the port number of NATa when the echo client
communicated with S1 at step F1.
F4. The echo server communicates with S1. Then, S1
analyzes the port number mapped by NATb.
F5. S1 conveys the port number to the echo server.
F6. The echo server sends a packet to S2. The packet
includes the port number information of NATb obtained from the communication of the echo server
with S1 at step F4. Then, S2 analyzes the port number
of NATb and records it. Furthermore, S2 records the
port number information of NATb obtained when the
echo server communicated with S1 at step F4.
F7. Based on the two types of information communicated
in phases I and II, namely the communications of
NATa with S1 and S2, we can predict a suitable port
number for hole-punching. We can also determine the
punching mode. S2 sends the information containing
the predicted port number and the punching mode to
the echo server.
F8. Based on this information, the echo server sends a
large number of packets. These packets have a fixed
destination port and a low TTL value. The echo server binds the port. The packets are then sent to the echo
client.
F9. Using the two kinds of information obtained in phases
I and II, namely, the communications of NATb with
S1 and S2, we can predict a suitable port number for
the hole-punching. S2 sends the information that
contains the predicted port number and the punching
mode to the echo client in a manner similar to that of
step F7.
F10. On the basis of the information obtained in step F9,
the echo client sends many packets to the echo server. These packets have a fixed destination port. The echo
client binds the port. After sending all the packets, the
echo client switches to the receiving mode.
F11. The echo server replies to the echo client. It
establishes a P2P connection between the echo client
and the echo server at this stage.
VI. ADVANTAGES
A. Normal UDP communications
The new method puts small TTL value, 2 or 3, in a packet from
the Echo Server. These packets appear normal UDP
communications if we neglect the extra packets. Thus, UDP packets have less possibility of being discarded because of the
use of security criteria for screening packets at NATs.
B. Precise port number prediction
Most NATs translate port numbers according to one of the
following algorithms: (i) increment, (ii) decrement, (iii) leap,
i.e., skipping alternative port numbers, or random. The
proposed method uses two servers so that we can observe any
type of port translation.
C. Control of port numbers
The new method uses fixed port numbers rather than random
numbers. When the source port numbers are {x, x + 1, x +
2 . . .} and the translated port numbers are {n, n + 1, n + 2 . . .},
it can detect the translation algorithm at a NAT based on the
sequences of the source ports and the translated ports.
D. Use of many port numbers
The new method uses many port numbers. The current
implementation uses 1,000 port numbers. The large number of
ports increases the success rate of hole-punching. When
NAT a translates port numbers by some unknown algorithm
and one of the 1,000 ports matches with the mapping of NATb,
the communication is successfully established.
E. Stateful Packet Inspection (SPI) in TCP
Currently, many NAT products are equipped with Stateful
Packet Inspection (SPI). It is a type of function for filtering of
TCP packets. When SPI is applied, a valid sequence of packets
should follow the 3-way handshake of TCP. The 3- way
handshake is as follows:
1. [SYN] - outgoing
2. [SYN, ACK] - incoming
3. [ACK] - outgoing
The proposed method can be extended to cover TCP NAT
traversal.
VII. EXPERIMENTAL PROCEDURE
The following methods were used as experimental procedures.
A. Classification of Types of NAT using WinSTUN
WinSTUN was used to classify NATs. The following
illustration shows the network configuration for the
experiment.
B. Packet Capturing
In order to study the port translation algorithm, we used packet
capture software. This software monitors the port number information in the packets. The test was conducted for a fixed
source port number of 5323. The packets are sent to the
appropriate destination port, whose number is changed using
the incremental algorithm. The following illustration shows the
network configuration for the experiment.
The packets were captured at a switch, where a mirror function
had been enabled.
C. Use of Skype Software for NAT Traversal
Skype uses three types of communication methods — P2P,
UDP-RELAY, and TCP-RELAY. The communication
methods of Skype were observed using the analysis window of
Skype.
VIII. NEW METHOD IN TCP
The performance of the new method for traversing NATs in
TCP was tested. The extended method is based on UDP hole-
punching. It uses UDP communication to exchange
information over a TCP connection. It then simulates the TCP
3-way handshake sequence and generates a sequence of TCP
segments with proper sequence numbers. The results showed
that the new method can successfully traverse NATs in TCP
for five out of six products. It has one failure because the
specific product has a filtering function on port numbers as well
as SPI. It allows a local port is designated to unique destination
at {IP address, port} only. It is more restrictive than SPI.
CONCLUSION
The new method needs two servers increasing the cost of
infrastructure. But the high success rate can justify the
overhead cost in the proposed method. This new method can
also be used for TCP hole punching, which is more difficult
than UDP hole punching if existing methodologies are
followed.
REFERENCES
[1] Yuan Wei, Daisuke Yamada, Suguru Yoshida and Shigeki Goto, ―A New Method for Symmetric NAT Traversal in UDP and TCP‖ ; Waseda University, 3-4-1 Okubu, Shinjuku-ku, Tokyo, Japan.