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

Hi Will,

Just as an FYI - 3GPP2 is starting to work on firewall signaling:
http://www.ietf.org/internet-drafts/draft-bajko-nsis-fw-reqs-00.txt

This is meant so that terminals could selectively open or close firewall
pinholes, so this could potentially help with this issue.

John

> -----Original Message-----
> From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org]On Behalf Of
> ext ivancic
> Sent: 11 March, 2005 21:07
> To: mip4@ietf.org; mip6@ietf.org; nemo; hip@ietf.org
> Subject: [Mip6] NAT traversal and cellular network administrative
> filtering
> 
> 
> 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_S
ervice.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
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6