Subject: [mobile-ip] concluding issues 194 & 195

From: Jari Arkko <[email-masked]>
Date: Mon, 13 Jan 2003 18:22:13 +0200

Hi,

My intention is to close these issues. Below I will summarize the
discussion and propose a way forward:

- IKE uses care-of addresses in communications to everyone,
   or just with the home agent?

   Proposal: Just with the home agent.

   Justification: The chicken-and-egg problem does not exist elsewhere.
   This will also put less restrictions on IKE modes.

   Text:

    o  Where dynamic keying is used, the key management protocol MUST use
       the care-of address as the source address in the protocol
       exchanges towards the mobile node's home agent.

- Which IKE authentication methods and modes to mandate, if any?

   Proposal: We should document any technical problems resulting
   from the combination of IKE and MIPv6. We should avoid additional
   specification.

   Justification: The technical problems need to be described, and
   we need to have normative language to show how to deal with them.

   Text:

    o  If preshared secrets are used in main mode, IKE needs to determine
       the shared secret to use from the IP address of the peer.  With
       Mobile IPv6, however, this may be a care-of address and does not
       indicate which mobile node attempts to contact the home agent.
       Therefore, if preshared secret authentication is used in IKE
       between the mobile node and the home agent, aggressive mode MUST
       be used. Note also that care needs to be taken with phase 1
       identity selection. Where the ID_IPV6_ADDR Identity Payloads is
       used, mapping of identities to keys is not possible.

- How to deal with movements and IKE?

   Proposal 1: We will require a rekeying mechanism, with an optional
   API-based smoother movement which is negotiated through a new bit
   in the Binding Update header.

   Proposal 2: Where rekeying is necessary, we will not require the
   deletion of the old IKE security associations. This will not be
   possible, as we can not send a Delete message from the new location
   unless the peer supports SPI-based lookups; and if it does we
   don't need to delete anything.

   Justification: As discussed on the list, not all implementations
   may have an API capability.

   Justitication for carrying the bit in the BUs: First of all,
   this capability relates to the ability of the MIPv6 module to
   control the IKE module, so IKE may not know if an API it has
   is actually being controlled by someone else. Secondly, if we
   put the bit in the MIPv6 specification this will be process-wise
   easier than trying to do it in the IPsec WG.

   Text

     Binding Update:

                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |          Sequence #           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |A|H|S|L|M|      Reserved       |           Lifetime            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Mobility options                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Key Management Mobility Capability (K)

	If this bit is reset, the protocol used for establishing the
	IPsec security associations between the mobile node and the
	home agent does not survive movements. It may then have to be
	rerun. (Note that the IPsec security associations themselves
	are expected to survive movements.)

     Binding Acknowledgement:

                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |    Status     |K|  Reserved   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Sequence #          |           Lifetime            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Mobility options                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Key Management Mobility Capability (K)

	If this bit is reset, the protocol used by the home agent for
	establishing the IPsec security associations between the
	mobile node and the home agent does not survive movements. It
	may then have to be rerun. (Note that the IPsec security
	associations themselves are expected to survive movements.)

     (Behaviour rules will be posted later)

- SHOULD vs. MAY for IKE?

   I'll send a separate note on this.

- Refer to IKE in the specification or leave it open which
   key management protocol to use?

   Proposal: Provide a specific reference to IKE, but given that
   this is not behind a MUST, other key management protocols can
   also be used.

   Justification 1: Even draft 19 talks specifically of IKE.

   Justification 2: There are non-trivial interactions with e.g.
   using care-of addresses vs. some IKE modes. I believe we do
   need to document these, and this is impossible at a too general
   level. Also, interoperability is enhanced if different
   implementations support the same key management protocol.

   Text:

    o  Automatic key management with IKE [4] MAY be supported.

    o  If preshared secrets are used in main mode, IKE needs to determine
    ...

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 13 Jan 2003 12:18:35 -0800

>    in the Binding Update header.

you might want to mention somewhere that if manual keying is
used, the K bit is always set to 1. it is ofcourse obvious.

Vijay