Re: addresses and IKEv2

[[e-mail]]

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

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.