[VOIPSEC] Spoof of IP address within a (large) domain

Wed Mar 23 16:10:16 CST 2005

These systems really are all still layer 2 determination of location.  They
really do trace circuit IDs, or MAC addresses or something else at layer 2.
The discussion is how does the device whose location is determined at layer
2 find out what it is.  For this they want to use a higher layer protocol,
using the IP address to correlate the location to the device.  The reason to
do that is so that you can have many layer 2 specific tracing methods, with
only one query method.

You wouldn't do this over a VPN tunnel. You do it at the outside, first
level access, before you establish the tunnel.

We're still stuck with the issue that if the IP address (or the server) can
reasonably be spoofed, then address forgery is reasonably possible.

GPS is a wonderful solution except:
1. To get the accuracy you need, you need "Assisted" GPS.  While this is
becoming more common and easier, it's not deployed everywhere.

2. It's still too power hungry to leave on all the time.  That means you
have a "first fix" delay that is long (10 seconds is not uncommon).  That's
a Loooong time to wait to get an emergency call through, but we can't route
the call until we know where you are

3. It doesn't work indoors.

The latter is the biggest problem for now.  There are repeater mechanisms,
but they aren't cheap to deploy in large office buildings.  Works better in
a single family, wooden construction situation.

Brian

> -----Original Message-----
> From: Robert Moskowitz [mailto:rgm at icsalabs.com]
> Sent: Wednesday, March 23, 2005 2:45 PM
> To: Jeffrey Skelton; Brian Rosen; VoipSec
> Subject: Re: [VOIPSEC] Spoof of IP address within a (large) domain
> 
> At 01:53 PM 3/23/2005, Jeffrey Skelton wrote:
> >These arguments about various "rogue" (or righteous) edge extensions
> would
> >seem to apply equally to IP address as a reliable key for location lookup
> or
> >location information pushed from a DHCP server.
> 
> Exactly.  There can be no trust in device location from a third
> party.  Only the device can 'speak for itself'.
> 
> I could go on with other ways the device is not where the visible IP
> address seems to be.  All perfectly legit (like my use of SSH tunneling
> when I am on the road).
> 
> >Don't methods claim that something other than the actual edge node knows
> >what the physical location of that edge node is?
> 
> A tunneling protocol and an application proxy has the knowledge of the IP
> address of the its endpoint.  Hopefully we are dealing with only one hop,
> but we are not (consider remote tunnel then an application proxy).
> 
> There is no standard way to make that information available.
> 
> Anyone that really wants to know where a device is should look at the work
> being done in IEEE 802.11p.  They are addressing this the 'right way'.  It
> is all about vehicle safety for them.  One of their goals in anonymity,
> thus 'you don't know who I am, or probably care, but I am at GPS .... and
> doing ..... (160' (your car figures out that is 8 cars) ahead of you,
> moving at 80mph, and slamming on my brakes for maximum deceleration).  Law
> inforcement does NOT want to know which car did this.  The safety value
> outweighs any law enforcement value.  But we also have to kick a car out
> of
> the system that has been determined to 'lie'.
> 
> 
> 
> 
> 
> >On 3/22/05 3:12 PM, "Robert Moskowitz" <rgm at icsalabs.com> wrote:
> >
> > > At 04:22 PM 3/17/2005, Brian Rosen wrote:
> > >> Now it's my turn to "ask the experts".
> > >>
> > >>
> > >>
> > >> I have someone proposing a solution to a large problem of "where are
> > you?";
> > >> that is, finding your own location.
> > >>
> > >> It's for 9-1-1, and we have one mechanism, DHCP, that we are pretty
> happy
> > >> with; you can spoof within your subnet, but that's about it, and
> location
> > >> doesn't vary much within the subnet.
> > >
> > > I've read through all the comments here and see that a couple of items
> have
> > > not been covered that using IP addresses as a physical locator is a
> total
> > > waste of time.  Well not total yet, but getting there.
> > >
> > > First as two subnets.
> > >
> > > With developments in bridging equipment over the past 5 years or so,
> many
> > > places are running flat networks.  My colleague in 802.1 from
> Enterasys
> > > said that they have one university running flat with 100,000 devices.
> You
> > > know the IP address is somewhere, but no more than that.  MAC address
> is a
> > > better indicator.
> > >
> > > But more likely than that are technologies like MobileIP.
> > >
> > > I could be running my home agent on my DSL line and be anywhere in the
> > > world, thanks to IPnIP (protocol 9, as I recall).  I could be running
> the
> > > call over an ESP tunnel with the same results.  The IP address does
> not
> > > locate the device within the Internet.
> > >
> > > Of course HIP does this the right way.  The IP address stays where it
> > > belongs and the system stack moves around the internet.  But then HIP
> is
> > > only beginnig to get attention eventhough I wrote the first paper on
> it in
> > > Jan '99...
> > >
> > > The one example of a Asterisk server is another way that IP address
> seen is
> > > not the IP address of the device.
> > >
> > > Finally, how does the DSL provider really know which house that call
> came
> > > from?  What if the homeowner is providing wireless services via an
> 802.11
> > > network to the neighbors?  (or the neighbor just lunching off an open
> > > network...).
> > >
> > > You want reliable locator, put digital certs from the vendor and GPS
> > > hardware to deliver authenticated location information.  Look at what
> > > 802.11p is facing for authenticating car locations (and they are
> tackling
> > > anonymity).
> > >
> > >
> > >
> > >
> > >
> > > Robert Moskowitz
> > > Senior Technical Director
> > > ICSA Labs, a division of Cybertrust, Inc.
> > > W:      248-968-9809
> > > F:      248-968-2824
> > > E:      rgm at icsalabs.com
> > >
> > > There's no limit to what can be accomplished
> > > if it doesn't matter who gets the credit
> > >
> > >
> > >
> > > _______________________________________________
> > > Voipsec mailing list
> > > Voipsec at voipsa.org
> > > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 
> Robert Moskowitz
> Senior Technical Director
> ICSA Labs, a division of Cybertrust, Inc.
> W:      248-968-9809
> F:      248-968-2824
> E:      rgm at icsalabs.com
> 
> There's no limit to what can be accomplished
> if it doesn't matter who gets the credit
> 
> 
> 