Subject: [Mip6] 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

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Sami Vaarala <[email-masked]>
Date: Sun, 13 Mar 2005 12:05:33 +0200

Hi,

 > [...]

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.

 > [...]

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