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

From: [email-masked]
Date: Mon, 14 Mar 2005 08:28:40 +0200

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: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext ivancic
> Sent: 11 March, 2005 21:07
> To: [email-masked]; [email-masked]; nemo; [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 14 Mar 2005 18:20:08 +0100

Actually the first trial we ever did was with orange... and a timeport
from Motorola :) Then we switch to SFR for some reasons. But that was
more then 2 years ago. I'm not sure which agreement that was :( 

Pascal

| -----Original Message-----
| From: Alexandru Petrescu [mailto:[email-masked]]
| Sent: Monday, March 14, 2005 12:24 PM
| To: Pascal Thubert (pthubert)
| Cc: nemo; ivancic
| Subject: Re: [nemo] NAT traversal and cellular network administrative
| filtering
| 
| Pascal Thubert (pthubert) wrote:
| > In the last 2 years, we have been experimenting with our Doors
| > solution on 3 continents over all forms of links, and whatever the
| > theory is about all things that could be weird in NAT boxes, the
| > practice was that we went through everything we tried...
| 
| Well, this is an optimistic message and I will gladly share this
optimism.
| 
| In our experience here, we had many difficulties "going through" when
| connecting to the operator Orange, with GPRS.  This operator is
present
| in many countries in Europe and we tested in three of them, same
| results.  So I was curious whether you have any particular experience
| with Doors with this particular operator and with a normal
| (non-business) GPRS subscription.
| 
| Thanks,
| 
| Alex