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

From: ivancic <[email-masked]>
Date: Fri, 11 Mar 2005 16:49:04 -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

_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec