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

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

>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:15:41 +0100

> dtheir active filters, at least if IP-in-UDP does for IPv4 mobile 

Until the day T-Mobile realizes that Doors bubbles try to get
through so T-Mobile will stop the Doors bubbles too, no?

Filters mean that they look at every bit of the packet (from IP version
number up to TCP/UDP headers HTTP data and even at the last bit of the
payload).  So they can filter out whatever they want.

I think the only way one could get through this is to imagine a protocol
with an apparently random bit pattern but following a strict rule known
only by the two nodes (one behind T-Mobile and one outside).  And this
implying secrecy (don't tell this rule to T-Mobile), can not be 
standardized.

Alex
GBU

---

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

Alex
GBU