Re: Confirm decision on identity handling.

[Michael Thomas <mat@cisco.com>]

Eric Rescorla writes:
 > Michael Thomas <mat@cisco.com> writes:
 > > Eric Rescorla writes:
 > >  > Huh? The user asks you to initiate a TCP connection to
 > >  > 1.2.3.4. How else do you propose to ensure that you've
 > >  > done that other than by checking the certificate at
 > >  > SA establishment time?
 > > 
 > > You didn't answer my question.
 > Obviously I didn't understand it, then. Try rephrasing it.
 > 
 > > And I hardly know
 > > where to start on the identity/routing tag
 > > conflation you seem to be making. There isn't a
 > > binding in IPsec between TCP connection -- or any
 > > sort of transport connection -- and the SA
 > > establishment, so your question is a non-sequitur.
 > I'm afraid it's not. One of the major arguments in favor of
 > IPsec is that it allows security-oblivious applications to
 > be secured by enhancing the kernel. The only information
 > that the kernel has about the desired peer endpoint when
 > an application tries to transmit data is the IP address.
 > Therefore it's the only information on which the decision
 > can be made.

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.

 > > 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. 

 > > 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.

	   Mike