Re: addresses and IKEv2

[Charlie_Kaufman@notesdev.ibm.com]

This posting points out the tip of a very large iceberg. I think I understand some of the issues (but I'm not confident); some seem unsolvable; and some raise questions about the design goals of IPsec. Attempts to improve things for some scenarios (e.g. Mobile IP) may make things worse in others (e.g. Address Translation Gateways).

> Each party can get up to 5 addresses:
> - the address used for the transport of phase 1 messages (T1)
> - the address in the phase 1 identity (I1)
> - the address in the party's certificate (C1)
> - the address used for the transport of phase 2 messages (T2)
> - the address in the phase 2 traffic selector (which replaces IKEv1
> phase 2 identity) (I2)
> (I don't consider the optional IKEv2 phase 2 identity payload until
> it has an interesting semantic when it is an address identity).
> 
> A not-really-written-down rule specifies the phase 1 identity must be
> the subject or an alternate subject of the party's certificate (when
> certificates are used but in any case the identity and the authentication
> means must be strongly bound).

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 sh! ould 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.

How is this possible?

One way is by having the identities in certificates in fact be IP addresses rather than names as implied by the quoted text above. Systems may be deployed that way, but it would surprise me. More likely is that the "Policy Database" installed as part of IPsec configuration contains a table matching IP addresses to either public keys or the names that must appear in certificates used in IKE. How that policy database would be populated and maintained is one of the great remaining mysteries of IPsec. For firewall to firewall tunnels, manual configuration works, and I believe that's how people do it today. But for end to end IPsec to become routine, better techniques will need to be deployed and standardized. It's a much harder problem than any already solved in IPsec, so I don't expect progress soon. I certainly don't want to hold IKEv2 hostage to solving it.

In tunnel mode, it's the inner IP addresses that must be authenticated. They are because they must match the traffic selectors and the traffic selectors must match the authenticated names from IKE and in the IPsec Policy Database. In tunnel mode, the outer IP addresses are like those of IKE... it doesn't matter what we do with them so long as we don't open ourselves to denial of service attacks.

In transport mode, it's the outer IP addresses that must be authenticated. This is tricky because they are not cryptographically protected. What should ESP or AH do if they receive a transport mode IP packet with IP addresses that don't match the traffic selectors? I believe the spec says they should throw them away. This will break transport mode SAs if they pass through address translation gateways. I believe the right answer to this is to always use tunnel mode through address translation gateways. Proposals for tunneling through address translation gateways call for use of a special tunnel mode that is encapsulated in UDP.

IKEv2 explicitly supports Address Translation Gateways by *not* authenticating the outer IP addresses in IKE messages. This allows connections to work even though the outer IP addresses appear different to the two ends of the IKE (and presumably also ESP) SAs.

It's not clear what we can or should do to provide better support for ATGs or Mobile IP, but I'm open to suggestions.

--Charlie

This footnote confirms that either (1) this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses, (2) this email message was sent by a virus that appends this footnote, or (3) (most likely) the sender of this message is trying to raise awareness of how foolish it would be to place any confidence in footnotes like this.