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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Nov 2003 15:14:27 -0000

Hi William

Note that Doors should work with the T-Mobile IPv4 infrastructure an
dtheir active filters, at least if IP-in-UDP does for IPv4 mobile
tunnels.

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
William D Ivancic
Sent: mardi 4 novembre 2003 17:23
To: [email-masked]
Subject: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT
transversal

   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).

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 7 Nov 2003 08:22:21 -0000

> 
> Pascal Thubert (pthubert) wrote:
> Until the day T-Mobile realizes that Doors bubbles try to get 
> through so T-Mobile will stop the Doors bubbles too, no?
> 

For the record, doors does not have bubbles (that's teredo), but the
equivalent service is obtained naturally from Binding Updates.

My understanding is that the probes that T-Mobile is filtering out are
generally offensive and can be seen as DOS attacks on a low bandwidth
s.a. GPRS. This is about filtering things coming from the outside, just
like a firewall.

If T-Mobile wished to deploy a MIPv6 or Nemo service that uses their
CURRENT IPv4 GPRS structure, I believe that they could do so, even with
these filters active, using doors. The 'bubbles' would not be filtered
because:

- they come from the inside
- T-Mobile does not wish to kill their own service

We have an implementation of doors that has already been successfully
tested with some GPRS deployments. I'd be glad to try more :)

Pascal

---

From: William D Ivancic <[email-masked]>
Date: Sat, 08 Nov 2003 21:34:31 -0500

The document at this URL was generated to explain the packet filtering 
problem to T-Mobile.  Perhaps this helps.

http://roland.grc.nasa.gov/~ivancic/t-mobile/administrative_filtering.pdf

Don't be surprised when others begin implementing such filtering.

Will

---

From: William D Ivancic <[email-masked]>
Date: Sat, 08 Nov 2003 21:34:31 -0500

Will