Regulating ISPs

Well, I have been harping on about location data for emergency services for our VoIP services and fun and games with OFCOM.

What was interesting yesterday was learning more about where this is going over the next few years.

From a technical point of view, a VoIP provider cannot normally locate a customer as all they really have is the IP address details of the far end. The internet acts as a long extension cable connecting the end user to the VoIP provider. Expecting the VoIP provider to locate the caller is not practical.

So the plan is pretty simple - VoIP provider gives details of IP/session to the emergency services and they ask the ISP for details of the location, in real time. The ISP is technically in a much better position to provide location data.

There are a whole load of technical issues with this, and lots of edge cases (don't even mention TOR, or NAT64). However, for a lot of cases, even dynamic allocation with DSL, it is technically possible for an ISP to identify the endpoint for an IP in real time. After all they have to route packets in real time, so that makes sense.

The problem really is that this is a technical committee trying to find a technical solution. They do not have the remit of trying to work out how the hell this happens in practice from a legal point of view, or the policy implications. This sort of division of considerations is not uncommon, but it could mean some interesting times ahead for ISPs, especially small ISPs.

One of the big issues is that this is complicated for an ISP to do. A lot of ISPs, especially small ISPs, buy in the various kit to make it all happen and it all works well together as you would expect. But this sort of location lookup needs more than just BGP and RADIUS. It needs integration with ordering systems and billing systems, and much more. These are often home made or even manual systems in small ISPs and simply not set up for real time queries. The variation from ISP to ISP makes an off the shelf solution difficult. Oh, and the final catch is the 99.999% reliability requirement which is probably something that no ISP can really guarantee.

So, this really will only happen if there is regulation requiring it to happen - given how well OFCOM worded GC4, I can see that being a nightmare. As an ISP I don't like any new regulation, and it is clearly unfair on the ISP if they have to do the work for someone else's VoIP service. After all, the ISP is just passing packets. Why are they tied up with onerous voice regulation just because someone else is sending voice packets over their network, any more than they are tied up with banking regulations because on-line banking goes over their network. Though yes, like us, many ISPs also do VoIP, that is not always the case. At the moment ISPs can choose not to get involved in all this 999/112 hardship by not doing VoIP, but that seems likely to change.

Of course, one of the other issues is that, assuming it is regulated for and enforced, all ISPs will have a handy real-time IP to location lookup service. It is, of course, only for emergency services. But can you image that government departments will not want to get their hands on something so useful? How long before the copyright industry lobby for access (after all, the ISPs are already doing it at that point, so no extra cost)? Before you know it we will have councils using the interface to track kids playing truant from school.

And then, of course, what of ISPs that sell the service. It is bad enough geo-location services guessing you might want to meet girls in low earth orbit but what if they actually had your full address based on your IP? I am sure the DPA would have something to say, but some contracts already seem to allow crazy data sharing like this. Commercialy it may be the only way for the ISP to recover some of the money spent making such a system.

The only light at the end of the tunnel is that there is an idea for the next stage - where smarter VoIP devices find where they are (GPS for example). This could involve protocols for devices to ask their DHCP server or upstream servers for their own location, which is easier to do and clearly has less privacy issues. The device then sends the information with the call and that gets passed through to emergency services. I'd like to see us moving to that type of solution and not implementing a huge can of worms by imposing all sorts of new requirements on ISPs... We'll have to see what happens.

Interesting times ahead.


  1. Hypothetical situation:
    I am a customer of GenericISP. I am supplied with a single /32 at my company headquarters.

    I have several offices, all of which connect to the HQ using a VPN of some description.

    Handsets at my offices all register to my PBX at HQ which then fires calls out through one or more telcos.

    I make a 999 call. The number presented is correct for the office from which I am calling. However the geographic data associated with the IP address of the call is completely inaccurate space there is no way for my ISP to know the geographic location of the caller.

    How can this be right?

    Oh for some common sense.

  2. I know I know - that is one of the many many "edge cases" which are more common that they would like I am sure, and which lead to all sort of questions about companies providing location services and how that could possibly be regulated.

    The idea the handset could find its location, perhaps by data from the company's correctly configured DHCP servers at each site, etc, and send that, is much more sensible in the long run.

  3. What I'd like to see is the statistics on how often location information is required, so how often the caller is unable to give their location to the operator during the call - i.e. actually how important is this issue (while obviously any situation where someone may be in danger is not good, and we should try to avoid it, there's a difference between doing what's practical and realistic, and spending huge amounts of money to solve an issue that's not really a big problem).

  4. OK. Nice easy way of solving this.

    DHCP option 123 would seem to be the answer. Then all we'd need is handset/softphone devices to honour this and http://tools.ietf.org/html/draft-ietf-sip-location-conveyance-13

    Simple. Well, simple in theory anyway.

  5. Surely their proposal would only work if the VOIP provider was the ISP and the device was directly connected to their network?

    The device could be on 1 ISP, the PBX could be on another ISP and the VOIP could be provided by yet another provider.

    How do you trace the device in realtime then :-/

  6. I presume the proposal is that the ISP has the burden of running the trace for a 3rd party.. which seems a little unfair.

    That's if you can define 'the isp' - as you say, it could reach a PBX and go anywhere.

  7. Alex:
    I think this is one of those situations where a decision using statistics is a Bad Thing!
    If location information is needed once a month in the whole country, then "they" could say it's not worth doing. But if you're the person who makes the call that goes "Help! I think I've severed an artery - there's a lot of blood coming out... " then you would be very unhappy if the reason you died was that they had no way to find you because the statistics said it wasn't necessary!
    (I believe the statistical term for something like this is a Poisson distribution - something that is terribly unlikely, but does actually happen. If I remember my Stats A-level correctly, the standard example is the chance of being kicked to death by a donkey in 4 Russian Army Corps. :-)
    Cheers, Howard

  8. Statistics can be useful - the problem is that you are dealing with very small probabilities, but large consequences and large costs. The slightest change in the numbers can have massive impact.

    You have to accept you can never manage perfection, and that some people will die because shit happens. Ignoring that fact would mean not allowing people to have kids in the first place as they are going to die.

    So you effectively have to find a way to draw a line somehow, and statistics are not that bad a way to do it. What is the risk? What is the cost of tackling that scenario? What is the cost of not tackling that scenario? Is it worth it?

    In some cases the costs of trying to get a more perfect system can mean people are worse off. E.g. what if one was to insist that all VoIP calls much have automatic 10m accurate location data? That would mean lots of VoIP systems would have to be shut down as they cannot comply. Sure, in the long run it means all VOIP handsets are made with GPS receivers in them, but people will not afford them. People will die because they are no longer able to call 999 because the phones are not available because of the onerous or costly requirements if someone does provide a service.

    So ultimately it does come down to cost and statistics.

  9. Even a system with GPS receivers wouldn't comply with the 10m example - you have failed to consider phones in locations such as basements where GPS signal is not decodeable, and the possibility of deliberate (criminal) GPS jamming.

    Fundamentally, there is a rock/hard place issue here; traditionally, location requirements were manageable because the telco had the knowledge anyway. Mobile networks can see which cell sectors could see your phone, and use power levels to estimate an approximate distance, to get a reasonable-sized location for you. Fixed-line networks know where they installed the line; practically, extending lines over any length involves their co-operation anyway, so they know where the phone is.

    VoIP telcos only know two things about your address:

    1. Any location data sent by the phone.
    2. The IP address from which the call originated.

    It's trivial for the end user to change either of these; £15/month gets you a VPS in the USA through which the call could be routed, while the location data sent by the phone is easy for the user to tamper with (e.g. misconfigure the phone).

    Arguably, the system needs modernising to let you, as the telco, present what you know to the emergency services (location set in your systems, location sent by the phone, if any - Nicholas has pointed out the appropriate Internet Draft, and IP addresses from which the SIP signalling and RTP originate), and let the emergency services sort it out - at least in this situation, they're aware that the "address" being presented is unreliable information.

  10. I agree - and interestingly it seems the longer term plans are indeed to get data from the phone and pass it on.

    What concerns me is if OFCOM feel it necessary or appropriate to impose regulations on ISPs for this interim solution as published in NICC ND 1638 (Ip to location lookup). If they do, it will only have a short term use before better ways to solve it, but will have long term impact on costs for ISPs and privacy issues.

  11. Reading NICC ND 1638, I see a dangerous misapprehension; namely that only big enterprises will ever combine dynamic addressing and VPNs.

    Practically, even small organisations are quite likely to have enough capacity on an FTTx line to have all calls come via their VPN into the local call server (where you can record calls, for example), then back out to their VoIP provider. If a homeworker in a panic then picks up their work-provided VoIP handset to call 112 for an incident, there is no guarantee that the VoIP handset is even in the same country as the employer, let alone same county (imagine a Bracknell ISP with an employee in Scotland who interacts via VPN with the head office PBX system).

    Does Ofcom really expect that everyone with a VPN concentrator is going to be involved in their LIS setup? Or are they praying that businesses won't do that? If the latter, I think they are completely misunderstanding the rules change VoIP brings in.

  12. That's whats good about VPN, you can access your files anywhere.
    US VPN


Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

TOTSCO moving goal posts, again!

One of the big issues I had in initial coding was the use of correlationID on messages. The test cases showed it being used the same on a se...