Subject: Re: [Mip6] Review of the draft-ietf-mip6-ikev2-ipsec-07.txt

From: Francis Dupont <[email-masked]>
Date: Sat, 09 Dec 2006 14:08:11 +0100

In your previous mail you wrote:

   This should probably also talk about MOBIKE, as MOBIKE can offer some
   more building blocks for the MIP6 which will make it easier to use
   IKEv2 when addresses changes. 
   
=> MOBIKE was already mentioned in the mailing list but we tried to
avoid confusion: even if MOBIKE and MIPv6 can provide the same service
in some cases, MIPv6 is strictly more powerful (and if we have done
our job well is not strictly less secure for the common part :-) and,
mor important, MOBIKE and MIPv6 are clearly incompatible.
BTW in MIPv6 the address update is handled by MIPv6 and IKEv2 is notified
only for residual stuff (exactly the IKE SA update, cf the MIGRATE I-D,
draft-sugimoto-mip6-pfkey-migrate-03.txt).

   I do not know exactly what the RFC3775 specifies how to detect whether
   the SA can be moved or not, but if MOBIKE was supported by both ends
   when the IKEv2 SA was created, then SAs can always be updated with
   MOBIKE ADDRESS_UPDATE notify.
   
=> the K flag in BU/BA can detect configuration mismatch: it was first
designed as a way to negociate the SA update capability but IMHO it is
more reliable for problem detection (this avoids to specify how to
recover unexpected values).

   > 7.2.  Security Association negotiation using IKEv2
   ...
   >    When the mobile node uses its home address in the IDi field,
   >    implementations are required to match the source address in the
   >    outermost IP header with the IP address in the IDi field [8].  This
   >    verification step, however, should be configurable [8].  With Mobile
   >    IPv6, this verification step will always fail because the source
   >    address in the IP header is the care-of address and the IP address in
   >    the IDi field is the home address.  Therefore, this verification step
   >    MUST be disabled.
   
   Actually RFC 4306 section 3.1 says:
   
      Information from the beginning of the packet through
      the UDP header is largely ignored except that the IP addresses and
      UDP ports from the headers are reversed and used for return
      packets.
   
=> you know it is not true in the real world, i.e., there is a security
issue to accept random SA establishment from an unknown source (aka
proper authorization) so in IKEv1 many implementors check the IDi against
the peer address in the header...
In IKEv2 we have a good optional protection against fake peer address
(cf what I call the transient pseudo-NAT attack) and the design moved
the IDi role to a secondary one. So you are true in theory but until
all IKev2 implementations will be less paranoid about this point
I am strongly in favor to keep this paragraph.

   I.e the outer IP addresses are not used to verify IDi/IDr fields.
   RFC4718 (IKEv2 Clarifications and Implementation Guidelines) says this
   explicitly in section 7.1:
   
      Furthermore, IKEv2 does not require that the addresses in
      ID_IPV4_ADDR/ID_IPV6_ADDR match the address in the IP header of the
      IKE packets.  However, other specifications may place additional
      requirements regarding this.  For example, [PKI4IPsec] requires that
      implementation must be capable of comparing the addresses in the
      ID_IPV4_ADDR/ID_IPV6_ADDR with the addresses in the IP header of the
      IKE packets, and this comparison must be enabled by default.
   
=> there is the PKI4IPsec document too...

   So it would be enough here to say that you follow IKEv2 way of not
   matching the outer IP addresses with the ID payloads, and not follow
   the pki4ipsec profile about the IKEv1 (pki4ipsec is mostly for IKEv1
   in any case).

=> BTW I disagree about the PKI4IPsec mostly for IKEv1.

   Also PKI4IPsec WG is now thinking whether they should
   say that section 3 of the draft-ietf-pki4ipsec-ikecert-profile-11.txt
   is only used for IKEv1 or for both IKEv1 and IKEv2.
   
=> of course this will clarify things.

   It would be better not to refer the pki4ipsec draft at all in this
   point, as it just adds confusion. 
   
=> I am afraid that without guidelines some people just will be not
confused but will follow the wrong way. Do you believe we should try
to fix this with PKI4IPsec people? BTW we recommend PKI use so it
should be more sound.

I skip the EAP and INTERNAL_ADDRESS_EXPIRY points because I've seen
there are some dedicated messages about them.

Thanks

[email-masked]

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Francis Dupont <[email-masked]>
Date: Sat, 09 Dec 2006 14:56:05 +0100

In your previous mail you wrote:

   > RFC 3775 describes the use of a flag (K) in the binding 
   > update/binding ack messages to signal the capability to 
   > update the IPsec SA when the MIP tunnel end point is updated. 
   > this document does not modify that.
   
   You mean the IKE_SA? I don't see any text in RFC3775 that describes
   updating the IPsec SA - I guess the assumption was that the IPsec SA is
   based on the HoA and it survives movements. However, when ESP is used in
   tunnel mode, this would imply changing the tunnel outer address. Is that
   captured anywhere? 
   
=> in fact both... please look at draft-sugimoto-mip6-pfkey-migrate-03.txt
to understand what can be done (and how).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 09 Dec 2006 15:11:32 +0100

Using MOBIKE would allow MIP6 to work on more implementations as I
   guess MOBIKE will be implemented in most of the future IPsec client
   style implementations. I.e. if MIP6 could be able to use standard
   IPsec + MOBIKE combination, there would be no need for special support
   for MIP6 inside the IPsec stack. 
   
=> there is no special support for MIP6 inside the IPsec stack.
Only the MIGRATE stuff is useful but it is not necessary as SAs
can be re-established... and it can be supported with a small piece
of code (i.e., far smaller (and easier) than NAT traversal for instance).

Regards