Re: addresses and IKEv2

[Michael Thomas <mat@cisco.com>]

Charlie_Kaufman@notesdev.ibm.com writes:
 > You're right that the rules aren't really written down. We tried to copy
 > IKEv1 on the theory that people were using it and we didn't understand the
 > issues well enough to have confidence that changes would be improvements.
 > If there are specific changes or clarifications that you think would be
 > useful, please propose them.
 > 
 > There is an implicit (or it might in fact be explicit though I couldn't
 > find it) assumption that all the IKE phase 1, IKE phase 2, ESP, and AH
 > messages associated with an IKE SA will have the same source and
 > destination IP addresses. ESP and AH explicitly state that their SA is
 > identified by the combination of the Destination IP address and SPI, and
 > the only anticipated case for having the source address vary for an SPI is
 > for multi-sender multicast.
 > 
 > The IKEv2 spec doesn't say what an implementation should do if it receives
 > a cryptographically valid message from an unexpected source address. I
 > suppose it should. One possibility is that it could specify that such
 > messages are discarded and possibly logged. A second is that they be
 > treated as though they were cryptographically invalid. A third is that the
 > source address be ignored and the packet treated as though it was received
 > from the expected source address. A fourth is that the source address be
 > remembered and future messages on the SA be sent to that one.
 > 
 > Why would it matter? I claim that in all cases except Transport mode ESP
 > (which is an ESP issue rather than an IKE issue), no invalid messages can
 > be delivered as the result of any of these approaches. The reason it might
 > be desirable to accept messages from changing source addresses is to allow
 > the other end of an SA to change IP addresses mid-conversation without
 > breaking the connection. This argues for the fourth approach. But the
 > fourth approach makes possible a denial of service attack that is
 > unacceptable. An attacker need only intercept and prevent delivery of a
 > single IKE packet and retransmit it with a changed source IP address. The
 > other end will begin misdirecting responses and the IKE SA will eventually
 > time out. If we believe we need to be able to handle the case of a mobile
 > SA, I believe we would have to do it with an authenticated message. This
 > could be added later, but my going in position would be that if either end
 > of an SA changes IP addresses then the SA should be broken and
 > renegotiated. In that case, it doesn't matter which of the first three
 > approaches an implementation takes because it shouldn't happen (and no
 > useful attacks could exploit them).
 > 
 > Where addresses are important is in the ESP and AH connections tunnelled or
 > transported through IPsec SAs. ESP and AH are designed to "transparently"
 > secure applications that use existing networking APIs and may trust data
 > differently based on the IP address from which it originates (e.g. the Unix
 > rtools). For any useful security to be provided, IKE is responsible for
 > assuring that the authenticated identity corresponds to the IP address of
 > SAs.

Charlie,

I don't really see what this enforcement
specifically at the SPI/dst address lookup is
buying. Lookups for incoming unicast ESP/AH don't
actually need anything more than the SPI itself to
fetch the correct context. For ESP in particular,
I don't see what security property is being
enforced by checking the outer tunnel address. If
you don't have the keying material, the hash will
fail and the packet will never be admitted. The
inner address (eg home address) still needs to be
kosher for the traffic filtering. What's the
problem here?

Like Francis I suspect, there's a lot to be gained
for mobility if we separate routing tags from
identity. In particular, it would be very, very
advantageous to be able to create a tunnel where
the outer routing tag is irrelevant so long as the
inner payloads/integrity all check out. The reason
is that for mobility you may be changing your link
layer and L3 routing information quite often;
renegotiation new SA's would be an *extreme*
hardship!

What happens with IKE is another discussion that
I'll bow out of for the time being...

	 Mike