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

From: ivancic <[email-masked]>
Date: Fri, 11 Mar 2005 14:07:14 -0500

Please excuse the cross-post.

This week I sat in 4 IETF sessions that all where discussing very 
similar, if not the same, problem of NAT traversal. HIP, MIP6 and NEMO 
where generally discussing 6 to 4 tunneling issues and the need to 
address NATs. MIP4 was not concerned with 6 to 4 tunneling, just NAT 
traversal in general.

I have used Cisco’s mobile networking MIP4 code with NAT traversal and 
Cisco’s (draft-thubert-nemo-ipv4-traversal-01 - expired) Doors 6 to 4 
UDP-base tunneling NAT traversal code.

Both work, but here is something to be aware of. About 18 months ago we 
noticed T-Mobile began administratively filtering traffic. The end 
result is that traffic that does not originate from the T-Mobile network 
gets blocked. They appear to be using ports to map the traffic. Thus, 
and IP-in-IP tunnel gets blocked even though the initial traffic came 
from within T-Mobile’s network (no ports to map to for IP-in-IP 
tunnels). UDP tunnels operate over this. That is why we used T-Mobile’s 
links for an mobile-ipv6 demonstration. The Doors implementation could 
handle this.

(See: http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm)

Sprint and Verizon may have recently started administratively filtering 
data – similar result as NATing even though you have unchanged public 
address space. One way to cope with this is UDP-in-IP tunneling, the 
same as with NAT traversal code.

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.

I spoke to T-Mobile when this first started happening (actually found 
the right person). They said that the filtering was put into place to 
eliminate worms probing the networks. The filtering was done no so much 
for security as to protect the valuable RF bandwidth. T-Mobile is GPRS 
and you really get somewhere around 30 kbps in practice. Sprint and 
Verizon are 1xRTT and get around 40 to 60 kbps in practice. Thus, worms 
were starting to effect the usable bandwidth and QoS – or at least that 
was the fear. Thus, I agree with their security implementations as the 
reasoning appears valid.

See this URL for the T-Mobile problem:
http://roland.grc.nasa.gov/~ivancic/t-mobile 
<http://roland.grc.nasa.gov/%7Eivancic/t-mobile>
http://roland.grc.nasa.gov/~ivancic/t-mobile/Letter_Customer_Service.pdf 
<http://roland.grc.nasa.gov/%7Eivancic/t-mobile/Letter_Customer_Service.pdf> 

http://roland.grc.nasa.gov/~ivancic/t-mobile/administrative_filtering.pdf 
<http://roland.grc.nasa.gov/%7Eivancic/t-mobile/administrative_filtering.pdf> 

NATs breaks a lot of things. Security breaks the rest! J

Will Ivancic

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 13 Mar 2005 15:02:40 +0100

[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:
[...]
> 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: Sami Vaarala <[email-masked]>
Date: Sun, 13 Mar 2005 12:05:33 +0200

Hi,

> but “weak” firewall traversal.

This is certainly an unfortunate development :(  Although networks with
such restrictions weren't common at the time, the 'F' (force UDP
tunnelling) flag was added to the MIP4 NAT-T spec specifically to
deal with such restrictions.  (However, I'm quite sure this level of
paranoia isn't enough, but it hasn't bitten us yet :-)

Since the 'F' flag is part of the core NAT-T spec, MIP4 should be OK
as long as mobile nodes expose the standard UDP forcing mechanism.
Indeed, at least a few vendors made UDP tunnelling the default simply
to avoid irritating blackhole situations which you point to.

> for security as to protect the valuable RF bandwidth. T-Mobile is GPRS 

I'm curious - given the scenario where public addresses are used and
IP-IP doesn't work, why does IP-over-UDP work better?

With UDP encapsulation the MN RRQ/RRP process will establish firewall
state, while with IP-IP the state is established only after the first
(reverse tunneled) data packet.  Is this the problem?  I.e. the MN does
not have traffic to send but needs to be reachable from external
addresses (without corresponding IP-IP state)?  Or is it the case that
IP-IP state is not tracked as accurately as UDP state?

Best regards,

-Sami
--
Sami Vaarala
Chief Technology Officer
Stinghorn  (http://www.stinghorn.com)
Secure Virtualized Software

---

From: "Brijesh Kumar" <[email-masked]>
Date: Mon, 14 Mar 2005 10:05:38 -0500

I think people on the list will be interested in the enclosed paper, 
submitted to a conference recently by Jaehoon Jeong, Jungsoo Park and 
Hyoungjun Kim.

This paper appears  similar to the draft presented in the nemo group in the 
last IETF meeting by someone on the same subject ( 
http://www.mobilenetworks.org/nemo/ietf62/nemo-ietf62-agenda.txt ). However, 
unlike the draft presented in IETF, this paper correctly uses the IPV6 
format for the new IPv4 address of the mobile router and dynamically 
updating the information about tunnel endpoint between mobile router and 
home agent.

This paper also proposes the use the router running home agent also become 
IPv6 transition tunnel endpoint for nemo, however,  like the draft submitted 
to IETF, it does not discuss the long tern impact of this approach on over 
all IPv6 transition architecture.

--bk