Subject: [Mip4] 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

-- 
Mip4 mailing list: [email-masked]
    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/

---

From: "Qiang Zhang/Aber" <[email-masked]>
Date: Fri, 18 Mar 2005 16:27:00 -0500

Sami,I am not T-mobile :)It is becoming a trend when providers look for data revenues, service selectionmechanisms are being deployed to distinguish/charge the byte usages and perform authorizations. The Idea to block IP-IP is not the right way to combat worms :) a deep inspection is.I am curious which service plan iVincic was referring to and whether T-mobile blocks all IP-IP in all different data plansQiangAlexandru,

It may be the case that operator forbids IP-IP because IP-IP has the
potential to deny the effectiveness of all other firewall filtering
rules that may be in place (rules acting on IP, not IP-in-IP - acting on
IP-in-IP requires more processing time which may be detrimental to
performance).
Not only processing time, but depending on the firewall architecture
it may be easy, hard, or impossible to peer into IP-IP (or IP-IP-IP,
IP-over-PPP-over-L2TP etc).In this sense, IP-IP may "escape" the normal
policy mechanism.

On the other hand you need a remote IP-IP endpoint for decapsulation,
and if you have that, you may escape the normal policy anyway by using
any of the dozen available tunneling tools out there.

At the same time, operator may allow certain UDP tunneling to pass
through because that operator may have agreements with Content Providers
that are placed outside that operator's network.  "Content" may be video
streaming over UDP.  So operator assumes that UDP mms port 1755
(Microsoft Multimedia Streaming) should pass through, and keeps it open.
Just a potential explanation, and it's pure speculation, and it may be
far from the actual motivation of T-Mobile filtering rules.
Right.  It may well be that operator X (in general) may want to block
IP-IP but is accidentally letting IP-over-UDP pass because of lacking
support in firewalls to prevent it.  Bypassing that policy using forced
UDP encapsulation is not necessarily very nice (from the operator's
viewpoint), but we lack the common tools to let the operator make this
policy decision.

However, in this case it seemed to me that the effects on normal MIP4
were a side-effect of a response to a perceived threat, not a deliberate
policy to block MIP4.

Best,

-Sami

--
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/