Re: Confirm decision on identity handling.

[Eric Rescorla <ekr@rtfm.com>]

Michael Thomas <mat@cisco.com> writes:
> Eric Rescorla writes:
> I think that what you're confusing here is the
> identity used to establish an SA and the general
> filtering mechanism that IPsec provides. It may
> be perfectly reasonable to have a policy which
> states:
> 
> "For all transport mode connections, the filters
>  should discard any source IP addresses != the IP
>  address used in the IKE session."
>
> Or something like this. Note that this doesn't
> have anything to do with the *IKE* identity, it's
> completely a property of the SA and its filters
> that were derived from the policy which matched
> for the mode and identity. It does, however,
> enforce the property that you desired above,
> especially when combined with the fact that you
> need several round trips which establish that that
> entity is, in fact, reachable at the outgoing
> address.
You must be joking.

What, you've never heard of active attacks? IP spoofing?

Much of the purpose of the exercise is to protect ourselves
from people who can arbitrarily manipulate the IP packet
delivery service.

>  > > IP addresses can be used as identities, but so can
>  > > RFC 822 addresses, etc. And IP addresses have huge
>  > > downsides, especially for mobility, unlike RFC 822
>  > > addresses.
>  > RFC822 addresses have the disadvantage that the kernel
>  > doesn't know anything about them when you're trying to
>  > transmit packets.
> 
> Again, you seem to be conflating the IKE session
> identity and the packet filtering mechanism of
> IPsec. 
It's not that I'm conflating them but rather that they're
bound by the logic of the desired security service. 

>  > > Any desire to use IP addresses as
>  > > identities should be considered harmful.
>  > That's just, like, your opinion, man.
> 
> Well, mine and a lot of other people's I'd say.
That's fine, but you haven't convinced me and it doesn't really
follow from anything you've said.

-Ekr

-- 
[Eric Rescorla                                   ekr@rtfm.com]
                http://www.rtfm.com/