Subject: RE: [nemo] NAT traversal and cellular network administrative filtering

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 14 Mar 2005 11:23:10 +0100

You might want to consider: 
http://mobilenetworks.org/nemo/ietf56/slides/ietf56-nemo-ipv4traversal.p
pt

In particular, satellite systems require IPv4 traversal, and we found
NAT traversal to be useful in several cases as well. For instance, we
found cases where the customer had his NEMO HA within his IPv4 private
network, the NAT being operated by the service provider. We also found
some cellular provider doing NAT as well.

In the last 2 years, we have been experimenting with our Doors solution
on 3 continents over all forms of links, and whatever the theory is
about all things that could be weird in NAT boxes, the practice was that
we went through everything we tried...

Pascal

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] On Behalf
Of
| Alexandru Petrescu
| Sent: Sunday, March 13, 2005 3:03 PM
| To: ivancic
| Cc: nemo
| Subject: Re: [nemo] NAT traversal and cellular network administrative
| filtering
| 
| [I'm posting this here because I've followed the v6/v4 discussions
here,
|   but I assume that any mip6 through v4 traversal would probably be
done
|   better on the mip6 list]
| 
| I generally very much agree with the aspects of this email raising
| awareness of the fact that NAT traversal is not easy to do, especially
| because "NAT" is something very loosely defined and the actual boxes
| linking a closed system (such as telecom provider, or enterprise net)
to
| the Internet are very often doing much more than just network-address
| translation: address translation, port translation, filtering,
proxying
| and, above all this - periodic changes due to hardware upgrades, new
| software deployment, new security policies, etc.
| 
| ivancic wrote:
| [...]
| > NOTE: Depending on the implementation, you may have to force UDP
| > tunneling, because the address is not changing (CoA and actual
| > address). Thus, there is no easy way to auto-sense that you are
| > getting administratively filtered. I suspect this will break a lot
of
| >  implementations for NAT traversal - as this really isn't NAT
| > traversal, but "weak" firewall traversal.
| 
| This is a point that deserves attention I believe.  Indeed, I think
this
| is not simply "NAT traversal" but more like "firewall traversal"
| (whether that's weak or not - I don't know).  And of course there is
no
| way to auto-sense you're filtered - any method of "auto-sensing" is
| doomed to fail when being itself filtered out.
| 
| I wanted to say also that most telecom operators would allow an HTTP
tcp
| connection out through port 80 (after login to their network), through
| some sort of local http proxy.  This outbound http connection is
| probably the most common denominator of what's let through the various
| firewalls of various operators.  Second best option may be email.
| 
| That said, relying on this channel (http or smtp) one could design a
| protocol to cooperatively and non-intrusively "sense" through the
| firewall (co: MH and HA) dynamically identify which are the open
ports,
| which protocols can pass through, etc.  After this sensing one could
set
| up the respective UDP tunnel.
| 
| But, this may risk being interpreted as "port scanning" or
| similar, which on the firewall end may some day be interpreted as a
| "rogue" activity, at which point new filters may be put in place by
the
| firewall administrator.
| 
| I do not know to which extent having an RFC about firewall traversal
for
| mobility will stop any firewall administrator from filtering
| whatever is currently considered "rogue" - that RFC's traffic in
| occurence. (because if it were enough to release an RFC, then it would
| have been sufficient to release an RFC saying "NAT is no good", people
| would remove NATs because RFC says so, and thus there would be no need
| of NAT traversal at all.)
| 
| Finally, on the other hand, at the NEMO meeting it was said that if
| there's a particular scenario that needs this (NEMOv6 v4 traversal)
then
| the effort of issuing a WG item document may be worth the effort.
| 
| So, do we have a more detailed idea about this scenario?  What are the
| network providers considered?  Do we address only the v6-thtough-v4
| aspects (BU with v4 CoA) or do we address the NAT traversal as well?
| 
| Just some thoughts...
| 
| Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 14 Mar 2005 12:24:16 +0100

Pascal Thubert (pthubert) wrote:
> In the last 2 years, we have been experimenting with our Doors
> solution on 3 continents over all forms of links, and whatever the
> theory is about all things that could be weird in NAT boxes, the
> practice was that we went through everything we tried...

Well, this is an optimistic message and I will gladly share this optimism.

In our experience here, we had many difficulties "going through" when
connecting to the operator Orange, with GPRS.  This operator is present
in many countries in Europe and we tested in three of them, same
results.  So I was curious whether you have any particular experience
with Doors with this particular operator and with a normal
(non-business) GPRS subscription.

Thanks,

Alex