Subject: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal

From: William D Ivancic <[email-masked]>
Date: Tue, 04 Nov 2003 11:22:30 -0500

From the basic support document page 7:

"  Once the binding process completes, a bi-directional tunnel is
    established between the Home Agent and the Mobile Router.  The tunnel
    end points are Mobile Router's Care-of Address and the Home Agent's
    address.  If a packet with a source address belonging to the Mobile
    Network Prefix is received from the Mobile Network, the Mobile Router
    reverse-tunnels the packet to the Home Agent through this tunnel.
    This reverse-tunneling is done by using IP-in-IP encapsulation [3].  "

In the requirements document, one of the requirements is to make sure we 
consider NATs.  Although most may consider NATs to only exist in IPv4,  I 
strongly suspect they will occur in IPv6 in order to manage security at a 
single location (rather that to increase the available address space).

Thus, should we consider something like IP-in-UDP encapsulation also.  I 
believe this is the solution for NAT transversal in IPv4.

Note, this is not necessarily just a NAT issue.  I was running  IPv4 mobile 
network code (Cisco Systems IOS version) in T-Mobile's network (GPRS) with 
public address space.  It was working until they implemented a security 
policy that stopped data into the T-Mobile network unless it originated 
from the T-Mobile network.  Thus, they are not NATing, but they are 
administratively filtering.  I believe NAT transversal code will solve 
this, but have not tried it yet.

I was able to obtain information from T-Mobile indicating that the policy 
was put in place to keep excess traffic off of the GPRS network (excess 
traffic was being generated by Internet address searching software and 
worms.  T-Mobile indicated that the GPRS links are considered valuable 
resources that need to be protected.  They were unwilling to change their 
policy.

Will

=======================================
Will Ivancic
NASA Glenn Research Center
21000 Brookpark Road    MS 54-5
Cleveland, Ohio  44135
Phone +1 (216)433-3494
Fax +1 (216) 433-8705
Yahoo Instant Messenger  ID: ivancic
http://roland.grc.nasa.gov/~ivancic

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 06 Nov 2003 23:28:14 +0100

William D Ivancic wrote:
> consider NATs.  Although most may consider NATs to only exist in IPv4,  
> I strongly suspect they will occur in IPv6 in order to manage security 
> at a single location (rather that to increase the available address space).
> 

Even if we don't consider IPv6 NAT's, _most_ (in number of users) 
cellular access systems today are NAT and probably in future too 
(3GPP/UMTS was apparently considering  IPv6 but my first glimpses into 
_some_ UMTS deployment looks not only to be v4 but also behind NAT).  In 
this context, if one wants to connect a NEMO (exclusively Mobile IPv6 no 
Mobile IPv4) to such a wide reach cellular access system, one does need 
a form of NAT traversal.

The optimization that may exist for this problem, maybe, is to consider 
that the  tunnel between MR and HA may be actually the NAT traversal 
tunnel, such as less encapsulation.

> Note, this is not necessarily just a NAT issue.  I was running  IPv4 
> mobile network code (Cisco Systems IOS version) in T-Mobile's network 
> (GPRS) with public address space.  It was working until they implemented 
> a security policy that stopped data into the T-Mobile network unless it 
> originated from the T-Mobile network.  Thus, they are not NATing, but 
> they are administratively filtering.  I believe NAT transversal code 
> will solve this, but have not tried it yet.
> 
> I was able to obtain information from T-Mobile indicating that the 
> policy was put in place to keep excess traffic off of the GPRS network 
> (excess traffic was being generated by Internet address searching 
> software and worms.  T-Mobile indicated that the GPRS links are 
> considered valuable resources that need to be protected.  They were 
> unwilling to change their policy.

Thanks for this description, it is very good to know.

A suggestion for T-Mobile is to consider filtering out bad worms coming 
from outside (and not the legitimate users coming from inside).  The 
problem of filtering out outside worms is as hard as defending from an 
insider trying to traverse, only it looks to them easier to filter the 
insiders.

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 06 Nov 2003 23:28:14 +0100

Alex
GBU