[Mip4] NAT traversal and cellular network administrative filtering
ivancic <wivancic@grc.nasa.gov> Fri, 11 March 2005 19:09 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26507 for <mip4-web-archive@ietf.org>; Fri, 11 Mar 2005 14:09:42 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9pZ7-0004SL-OJ for mip4-web-archive@ietf.org; Fri, 11 Mar 2005 14:12:54 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9pU1-0002Fz-UU; Fri, 11 Mar 2005 14:07:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9pTz-0002Am-OO; Fri, 11 Mar 2005 14:07:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26393; Fri, 11 Mar 2005 14:07:34 -0500 (EST)
Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9pX3-0004L6-AU; Fri, 11 Mar 2005 14:10:45 -0500
Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 38952C249; Fri, 11 Mar 2005 14:07:21 -0500 (EST)
Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id j2BJ7KRs005469; Fri, 11 Mar 2005 14:07:20 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j2BJ7KQZ025033; Fri, 11 Mar 2005 14:07:20 -0500 (EST)
Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.n asa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 20498-20; Fri, 11 Mar 2005 14:07:20 -0500 (EST)
Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j2BJ7Hq P024910;Fri, 11 Mar 2005 14:07:17 -0500 (EST)
Received: by webmail.grc.nasa.gov (Postfix, from userid 501)id DC23233800F; Fri, 11 Mar 2005 14:07:17 -0500 (EST)
Received: from grc.nasa.gov (oh-northolmstead1-16-134.clvhoh.adelphia.net [6 8.71.111.134])by webmail.grc.nasa.gov (Postfix) with ESMTPid 4A18D33800D; F ri, 11 Mar 2005 14:07:15 -0500 (EST)
Message-ID: <4231EC62.3050800@grc.nasa.gov>
Date: Fri, 11 Mar 2005 14:07:14 -0500
From: ivancic <wivancic@grc.nasa.gov>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: mip4@ietf.org, mip6@ietf.org, nemo <nemo@ietf.org>, hip@ietf.org
Content-Type: text/plain; charset="windows-1252"; format="flowed"
X-imss-version: 2.19
X-imss-result: Passed
X-imss-approveListMatch: *@*.nasa.gov
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Content-Transfer-Encoding: quoted-printable
Subject: [Mip4] NAT traversal and cellular network administrative filtering
X-BeenThere: mip4@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobility for IPv4 <mip4.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip4@ietf.org>
List-Help: <mailto:mip4-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=subscribe>
Sender: mip4-bounces@ietf.org
Errors-To: mip4-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Content-Transfer-Encoding: quoted-printable
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@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/
- [Mip4] NAT traversal and cellular network adminis… ivancic
- Re: [Mip4] NAT traversal and cellular network adm… Sami Vaarala
- Re: [nemo] Re: [Mip4] NAT traversal and cellular … Alexandru Petrescu
- Re: [nemo] Re: [Mip4] NAT traversal and cellular … Sami Vaarala
- [Mip4] RE: [Mip6] NAT traversal and cellular netw… john.loughney
- Re: [nemo] Re: [Mip4] NAT traversal and cellular … Qiang Zhang/Aber