Hi all, in most of the existing 2G/2.5G mobile PS-core (Packet Switch) networks have Gi segment (interface between GGSN & IP Router/firewall). Due to the IP address constraint, operator usually do NAT on the Gi firewall to NAT the private IP to public IP in the past. Looking at the traffic pattern and user access behaviour, does it make sense to have firewall between the GGSN & Public Internet if the public IP addresses are sufficient to cater for mobile subscribers? Especially with 3G/UMTS/HSPA or even LTE in the future.
Please share your thought and thanks in advance 
Regards,
Steven Lee
The only reason I see to have a FW on Gi would be to have a stateful device to stop scanning from the Internet towards the mobile devices (I don't know how much SYNs you see on a /16 nowadays, it used to be quite a lot). I know mobile operators who have been operating with public IPs to all customers without FW for a lot of years. Todays GGSN and other devices should handle it, even though they didn't do it well 5+ years back.
No, IMHO. Most broadband operators don't insert firewalls inline in front of their subscribers, and wireless broadband is no different.
The infrastructure itself must be protected via iACLs, the various vendor-specific control-plane protection mechanisms, and so forth, but inserting additional state in the middle of everything doesn't buy anything, and introduces additional constraints and concerns.
I would think that, however you are providing IP addresses, any ingress point
to a GSM core network ought to be carefully policed on security grounds.
Especially if you have IMS or SIP-based services or intend to deploy them.
There's a lot of legacy (and not-so-legacy) gear out there with weak IP stacks; beyond that, the relevant BCPs like iACLs should be deployed to protect the GGSN, et. al.
Sure. But stateful firewalls aren't required to protect that infrastructure, stateless ACLs in hardware will work quite well.
Hello Steven,
There seems to be an underlying assumption to your question
- that a firewall exists for Gi traffic only because of the NAT
requirement. This is not necessarily a safe assumption to make. The NAT
functionality may be needed to conserve IP space but does not take away from
the importance of protecting the network infrastructure from both the
outside world as well as from the mobiles themselves.
There are caveats to putting firewalls in the Gi path that you have to
consider - such as session count limits and how they play with lots of
small-sized packets. (as you may know, not all mobile applications are
well-behaved).
Miguel
On shared media like radio access, every unwanted packet means less
performance you will get out of the network. This can be done by NAT,
stateful filtering with public IPs or stateless filtering with public
IPs; the advantage of doing NAT is making it easier for the end-point
software to know that (two ways: noticing your local IP address is
from RFC1918 space, or connecting to a server that tells your IP in
order to compare it to the local address).
As such, GPRS, EDGE, EVDO, HSPA, LTE and Mobile WiMAX services have
good reasons to use NAT, and most do.
Rubens
Roland Dobbins wrote:
Please share your thought and thanks in advance 
No, IMHO. Most broadband operators don't insert firewalls inline in front of their subscribers, and wireless broadband is no different.
Some operators put firewalls to NAT their subscribers into smaller IP address pools (I have put some for a particular one).
The infrastructure itself must be protected via iACLs, the various vendor-specific control-plane protection mechanisms, and so forth, but inserting additional state in the middle of everything doesn't buy anything, and introduces additional constraints and concerns.
Yes.
Speaking of unwanted traffic, I was quite surprised how much unwanted traffic I see on my RFC 1918 space thats given out by one of the Canadian telcos-- i.e. this is behind the giant natting firewalls....
Blocking all inbound traffic and logging to pflog (pcap format)
Its full of cruft like this
0[i7]# tcpdump -nr /var/log/pflog | head -2
reading from file /var/log/pflog, link-type PFLOG (OpenBSD pflog file)
16:01:09.899554 IP 10.141.184.158.2167 > 10.141.81.113.445: Flags [S], seq 2743613661, win 53760, options [mss 1360,nop,wscale 3,nop,nop,TS[|tcp]>
16:01:10.439516 IP 10.141.184.158.2167 > 10.141.81.113.445: Flags [S], seq 2743613661, win 53760, options [mss 1360,nop,wscale 3,nop,nop,TS[|tcp]>
Looking at the pflogs for the last 3 days of just port 445 and 135 scans traffic as well as the odd ping packet
1[i7]# cat pflo* | tcpdump -nr - -w /tmp/scan.pcap port 445 or port 135 or icmp
reading from file -, link-type PFLOG (OpenBSD pflog file)
tcpdump: pcap_loop: bogus savefile header
1[i7]# tcpstat -r /tmp/scan.pcap -a
Bytes/sec = 0.4 B
Bytes/minute = 26.2 B
Bytes/hour = 1.5 KB
Bytes/day = 36.8 KB
Bytes/month = 1.1 MB
0[i7]#
Hmmm... considering some plans start at 1MB per month....
---Mike