Full Disclosure mailing list archives

RE: GPRS/IP-session from Nokia/Symbian mobilephonestays up


From: jamie fisher <contact_jamie_fisher () yahoo co uk>
Date: Mon, 13 Dec 2004 21:25:02 +0000 (GMT)

Dude,
 
What you see is a "feature" of the GPRS system and really up to the operators to control.
 
It works like this:
 
In a simplified form: in GPRS the mobile phone authenticates to the mobile network via SGSN which gets its response 
from the HLR/VLR.  The SGSN then sets up the PDP context between the MS (mobile) and the SGSN - the GGSN is informed of 
the context which allows it to request an IP for the mobile.  Once this is complete, traffic in the form of PDUs can 
then traverse the network from the MS to the GGSN.  TCP/IP traffic is then encapuslated within the PDUs.
 
In the standard case traffic flow can be initiated by the MS or by the GGSN depending on the traffic direction.  In the 
standards, traffic can flow from MS to MS via the GGSN or from the MS to GGSN or from the GGSN to the MS.  It is up to 
the operator to filter the traffic.  Originally it was envisaged that people would want to send packets from MS to MS, 
from the Internet to the MS and from the MS to the Internet.  It is up to the operator to control that as they see fit. 
 For MS to MS traffic flow the PDUs must traverse through the GGSN as the MSs may be using different SGSNs.  (Normally 
in different geographic locations)
 
From memory the PDP context can have a no-activity timeout or the network can initiate "call tear-down" from the MS 
(by hanging up) or by the GGSN.  It is up to the operator as to if then enable the timeout and what duration is set.
 
If there is traffic on the PDP context then the context will stay up - think of it like PPP on demand dialing.
 
The operators DHCP server leases out an address; users can not 'steal' a DHCP lease - as there are limits on how many 
IPs a MS can get.  The limits are both hardware/software and set by the operator.
 

Second point, IPv6 is becomming available on vendor equipment as time goes by.  It is in the standards - see 3GPP - but 
because of legacy equipment operators are slow to take it up hence the lack of IPv6 implementation on mobile networks.  
When you have 10,000s of MS out there that do not support IPv6 you really cannot "turn it on" over night.

"Juliao Duartenn (Oblog-Direccao)" <juliao.duartenn () oblog pt> wrote:
As stated by the original poster, costs are definitely not the only issue here.

One of the main abuse forms for this is depleting the entire provider GPRS IP range. Even though IPv6 is now almost 10 
years old, mobile carriers still chose to implement IP over GPRS using IPv4.

This, of course, leaves them open to address depletion.

And now, will they change?

JuliĆ£o

Howdy,

I think this is part of the reason why some carriers, such 
as T-Mobile,
use RFC1918 addresses instead of publically routable IPs.

Not here in the Netherlands :-)

inetnum: 194.229.200.0 - 194.229.207.255
netname: T-MOBILE-NL
descr: t-mobile.nl
country: NL
admin-c: RM1746-RIPE
tech-c: RM1746-RIPE
status: ASSIGNED PA
mnt-by: NLNET-MNT
changed: bartk () NL uu net 20030801
source: RIPE

I get an IP-address out of this range on my phone.

--
Marco



They do allow
you to specifically request real addresses if you need it 
for something
like IPSec too. Of course, this is kind of a moot point 
when they have
unlimited data plans in the US.

William Reading

Marco Davids (Prive) wrote:

Hi,

For what it is worth:

When my Nokia 6600 (Symbian V7.0s) mobile phone was 
connected to the
Internet and an imap-server for some tests the other day, 
I decided to
run a ping to the phone's IP-address (in fact I did an 
nmap -O to the
phone first, but that didn't work).

After the mail was retrieved I closed the 
email-application on the phone.
Normally the GPRS-session is terminated in such a case. 
But not this time,
while the pings went on. This time I had to force the 
session to go down,
which is an option on the phone, luckily. I just never 
used it before :-)

Later on I tried an SSH-session with the Mocha Telnet 
application from my
phone. Same behaviour. After I closed the SSH-application 
and as the
pings went on the (expensive) GPRS-session did not terminate as it
normally does when there is no incoming icmp traffic. When 
I finished
the external pings to the phone, the GPRS-session closed by itself.

I tried again, this time with a larger packet-size, but 
that did not work.

Then I tried a flood-ping and that did work. The 
GPRS-session stayed up
and the GRPS-counters increased dramatically! By this time 
my little
experiments where getting rather pricey for me.

Conclusion: Even after the last application that uses IP 
on the phone is
closed, the GPRS-session stays up as long as there is incoming
(icmp)traffic. I am not sure what to think of this, but this seems
rather undesirable to me. Do other phones also 'suffer' form this
behaviour?

This 'feature' can be abused. One could easily be lead to 
believe that the
GPRS-session is over, while in reality it is not.

I did a quick ping-scan on the IP-range that my phone was in and
discovered 355 active, 'pingable', IP-addresses out of 
2048. I figured it
be better not to start flood-pinging all of them them, but 
I couldn't help
thinking what would happen if some punk did: many phone's 
online would
probably stay online, depending on the number of phone 
models that show
the same behaviour. That would not only generate costs to 
their owners,
but would probaly also exhaust available IP-addresses for new
connections, resulting in some kind of DoS to the GPRS IP-service.

Greetings,

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

                
---------------------------------
Win a castle  for NYE with your mates and Yahoo! Messenger 
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Current thread: