addresses and IKEv2

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

The IKEv2 specs are far more clean than old IKE RFCs about
addresses of the two "parties" but there are still some
"to be clarify" points or even choices.
I've used my I-D about IPsec/IKEv1 and Mobile IPv6
(draft-dupont-ipsec-mipv6-00.txt) as a reference (BTW I am still
looking for some help for a new version of it).

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).
So if I1 and C1 exist then I1 == C1.

There are many good reasons to never provide I1 and C1 (the "road warrior"
case, NATs, mobility, etc). So T1 should be the address found in
message headers and should not be verified. I don't disagree with this
choice but it opens a transient fake-NAT attack vulnerability (see PS2).

If only T1 exists in phase 1 then there are two interesting cases,
T1 != T2 and T1 != I2.
The case where the two phases don't get the same address in message headers
is already implicitly taken into account by the IKE-SA SPI notion:
 - IKE-SA SPIs are (likely in IKEv1, always in IKEv2) unique
 - IKE-SA SPIs permit more than one SA between two parties
 - IKE-SA SPIs permit a party to change its address because they,
   by definition, index the SAs.
Section 2.11 "Address and Port Agility" should be more explicit about
this kind of usage of SPIs.
Note the statement "IKE implicitly sets up ESP, AH, and IPcomp
associations for the same IP addresses it runs over" must in this
case interpret "IP address it runs over" as (actual) T2, not (old) T1.
In general, the address of the party is found in the last message
protected by the IKE-SA.

The last case is when the TS doesn't match the transport address:
 - for a tunnel mode SA establishment, this is only a consequence
   of the existence of two headers (T2 goes in the outer one, I2
   in the inner one).
 - for a transport mode this is an explicit address overwriting
   which must be acceptable according to the policy but there is
   at least a situation where this is needed (see PS3) so I'll strongly
   object if T2 != I2 becomes forbidden for transport mode.

Regards

Francis.Dupont@enst-bretagne.fr

PS1: SUMMARY:
 - explain somewhere the identity payload role.
 - explain the advantages (and drawbacks) to use names (i.e. not addresses)
   as identities (in the general meaning). Perhaps we need some SHOULD/MAY
   for the different types of identity payloads.
 - explain the role of SPIs of IKE-SA.
 - don't throw away the transport/tunnel mode issue in phase 2.

PS2: transient pseudo-NAT attack:
This is an attack using IKE between SGs, not an attack against IKE itself.
The idea is simple: the attacker goes between the two SGs when they are
doing an IKE exchange and changes the source address of messages
(only one with IKEv2 phase 2) to the address of its victim.
If this is not caught by some ingress filtering (RFC 2827) the whole
traffic to the spoofed SG will be redirected to the victim.
This attack is generic against any protocol which can redirect traffic
(mobile IP for instance) and has provision for NAT traversal.
Unfortunately to make the protocol more efficient (two message phase 2
for instance) only makes the attack easier by reducing the time the
attacker must be on the path (where it can already do the pseudo-NAT
attack by redirecting everything to its victim. Here IKE adds the
"transient" feature and the SG (or in mobility the home agent) the mass
effect).
I don't know any defense compatible with NAT traversal (for instance
to protect the party address).

PS3: address overwriting in transport mode:
 When an IPv6 mobile node (MN) is in visit (i.e. not at home) and
sends its first binding update (BU) to its home agent (HA)
(aka the home registration), it must protect it using a SA,
for instance a transport mode ESP SA with the home address (H@)
(note this solution has a lower case "must" in the mobile IPv6 I-D).
 Until the BU is processed, the MN cannot use its home address:
only the care-of address (Co@) is available. So the MN must use
the Co@ as the source address of IKE messages without a home address
destination option (H@O), because the packets to the MN must be
addressed to its Co@ until the home registration is done (after
the HA will intercept all packets to the MN H@ and tunnel them
to the MN using the Co@, so the issue is only for this particular case).
 So the obvious solution is to overwrite the SA address by the proper TS
(it works as in IKEv1 but is easier to explain/implement) *and* to
encode in the policy the authorization to do that (the HA is supposed
to know its MNs so this is a classical key/cert & address binding
problem, local DNSSEC on the home network reverse zone works well
for instance).