[Mip4] NAT traversal and cellular network administrative filtering

[ivancic <wivancic at grc.nasa.gov>]

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


--
Mip4 mailing list: Mip4 at ietf.org
   Web interface: https://www1.ietf.org/mailman/listinfo/mip4
    Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/