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

["Juliao Duartenn (Oblog-Direccao)" <juliao.duartenn () oblog pt>]

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