Re: Identifiers

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 24-mrt-04, at 21:54, Fleischman, Eric wrote:

> Also, if it were possible today to know that the source IP address 
> were a
> genuine IP address, then that would strengthen a deployment's security 
> posture.

So what's a genuine IP address? As opposed to a cheap knockoff?  :-)

> That is, today we can't know if many attacks are using spoofed 
> addresses or not. However, if we could know that the source address 
> was not valid, then we could identify that packet as being an attack 
> and discard/ignore it (e.g., during a (D)DoS attack).

These days people rarely take the trouble to fake the source address in 
DoS attacks. The real problem here is that sources get to send traffic 
without any means for the recipient to shut them up. So what we need is 
a way to determine whether the recipient is prepared to receive certain 
traffic. I came up with a way to do just that a while ago but I haven't 
written it down as a draft yet. The quick version:

The idea is that a service provider does proxy IPsec AH verification on 
behalf of the recipient. The key used for computing the AH header is a 
hash of the SPI, the source and destination addresses and a secret that 
is known to the service provider and the recipient, but not the sender. 
The sender only gets to know the key that is particular to the 
negotiated SPI, but the service provider only has to maintain a 
relatively small list of recently invalidated SPIs and the shared 
secret and can check the packets coming in from all senders. The 
recipient hands out SPIs/keys to senders and invalidates SPIs when 
senders do stuff they're not supposed to do and then doesn't give them 
a new one.

> Our security posture would be further improved if we could know
> that the claimed sender did indeed send that packet (i.e., 
> non-repudiation; i.e., knowing whether a genuine address was being 
> spoofed or not).

Sounds like a job for IPsec.

> I would have thought that we would be using IPSec (whether AH or ESP) 
> for
> situations requiring authentication at the network layer. Is there a 
> reason
> why we aren't use IPSec but rather need an alternative network layer 
> provision?

We don't want to have AH or ESP headers in all packets because of the 
overhead. This is something like 24 bytes per packet minimum, making 
the overhead of our multihoming scheme + IPv6 more than double that of 
IPv4 (multihomed or otherwise). There are also deployment issues: how 
many people are talking IPsec to strangers today?