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

[John Todd]

At 4:22 PM -0500 on 3/17/05, 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.
>
>For various reasons, there are folks who don't like that idea and are
>pushing another.  They want server in the domain to return your address when
>asked.  They propose to use your IP address as the key to who "you" is.
>Just for the moment, ignore the issues of what the protocol is and what its
>security characteristics are.  They say that within their network (think a
>big DSL network), you cannot spoof IP addresses.
>
>I was pretty taken aback by that.  I thought it was pretty easy to spoof.  I
>understand that they have the DSL modems pretty wired down (they won't let
>you spoof an address coming from the DSL modem; they know what IP address it
>should be), but I thought there were other was to spoof.
>
>So that's my question: is IP address good enough, or are they just
>delusional that they can prevent spoofing within the domain.
>
>Brian


While I would like to say that they are delusional, (because of my 
inherent distrust of IP addresses as a measure or indicator of 
_anything_ security-related) I cannot.  It is possible in a large 
network where all of the equipment (or at least all of the edge 
equipment) is controlled by a central administrator.  If the edge 
equipment has the ability to do a crude form of RPF by means of an 
access list, then it may be possible to have each edge device filter 
spoofed IP addresses.  In other words: if I am allocated IP address 
1.2.3.4, then my DSL modem would simply refuse to route any packets 
from the local LAN to the upstream DSLAM unless those packets had an 
origin of 1.2.3.4.  You already note this in your comments, but it's 
worth explaining again.

Note that this ACL method could be used at the DSLAM as well as at 
the DSL modem, thus allowing a broader choice of DSL end devices if 
the provider does not have a method for "locking down" DSL device 
choice at the end user location.

I seem to recall certain DSLAMs having problems with this type of 
line filtering when applied to all interfaces, owing to the lack of 
processing power at the IP stack.  I'm sure this is not a universal 
issue, but does sound like a possible problem for certain DSLAM 
vendor implementations if implemented in the core instead of being 
distributed at the CPE.

In short: I don't see why this wouldn't work in a stub network.  It's 
a hack, but I've implemented it before on small scales with DSL 
equipment and it seemed to work well (though I did not have a 
particularly aggressive environment to test the ACL to it's fullest.

So, this brings up an interesting point: for this implementation, is 
the data contained in the VoIP message irrelevant?  Once a 911 call 
hits the call management system, does the data simply get re-written 
out of a static database, with the IP address as the "key"?  This 
also implies that the user cannot have a "roaming" VoIP device or 
PBX-like (Asterisk) system which acts as a further proxy to external 
SIP clients.  In fact, this almost precludes the use of their VoIP 
termination system by anything other than their equipment since that 
is the only way to ensure that the VoIP device is "local" to the IP 
address which is in turn local to the physical address.

JT