Mobile IPv6 with IKEv2 and revised IPsec architecture IETF 61

Mobile IPv6 and IPsec RFC 3776 describes how IPsec is used with Mobile IPv6 IPsec architecture has been revised IPsec selectors revised Security policy and association databases more clearly defined IKEv2 developed Simplified The use of EAP defined in the spec Need a new specification to describe Mobile IPv6 operation with IKEv2 and the revised IPsec architecture

A new draft draft-ietf-mip6-ikev2-ipsec-00.txt describe the necessary SPD and SAD configuration and packet formats describe the required processing steps on the MN and the HA describe the use of IKEv2 for key negotiation for Mobile IPv6 A very initial version. Far from complete Missing some sections Will try to get a stable version out soon If the above approach is a bad idea, speak up

Key negotiation Manual IPsec keying MUST be supported Minimal requirement to support interoperability Dynamic Keying through IKEv2 should be supported RFC 3775 has MAY for dynamic key negotiation through IKEv1 Leave it at MAY for IKEv2 too? Make it a SHOULD? Proposal is to leave it as it is RFC 3775 is one that should really say whether dynamic keying SHOULD be supported or MAY be supported This draft will only describe how IKEv2 can be run with Mobile IPv6 ‘K’ bit still required to dynamically update the tunnel end points

SPD configuration New selectors Mobility Header message type ICMPv6 message type Makes it easier to apply policies just to the HoTi or HoT message instead of all reverse tunneled mobility header messages Makes it easier to apply policies just to the Mobile Prefix Discovery messages instead of all ICMPv6 messages SPD configurations described in the draft (not listed here) Please read draft and comment on mailing list

SPD configuration RFC 3776 required per-interface SPDs Not needed anymore Is that true? We still need policy entries that can be applied to payload traffic reverse tunneled through the Home Agent Need to distinguish between payload traffic sent reverse tunneled, payload traffic sent route optimized, payload traffic sent using CoA only Can we do this with just tools provided in RFC2401-bis? Implementation is complex for per-interface SPDs But it is implementation specific

PAD configuration Peer Authorization Database provides a link between a key negotiation protocol and the SPD Indicates the range of identities that a peer may use for negotiating keys HA maintains an entry per mobile node in the Peer Authorization Database Indexed by the identity of the MN Has one of more Home Addresses allocated to the MN HA can check if the MN is authorized for a home address when the MN initiates IKE negotiation or when the MN sends a BU PAD entry also indicates whether the MN needs to be authenticated through a shared key, certificate, etc.. PAD is optional Implementations can use any mechanism to achieve the above

SAD configuration Transport mode SAs for Binding Update and Binding Acknowledgement Integrity protection a must Confidentiality protection optional Tunnel mode SAs for HoTi and HoT messages Integrity and confidentiality protection Transport mode SAs for Mobile Prefix Discovery messages Integrity protection a must Confidentiality protection optional

Use of IKEv2 to negotiate keys MN initiates IKEv2 exchange Authentication of Home Agent through public keys Should the use of a shared key be allowed? (guess, the answer is YES) Identity included in IDi in IKE_AUTH exchange FQDN or RFC 822 identifier After IKE_AUTH exchange, MN and HA initiate CREATE_CHILD_SA exchange TSi set to Home Address of the MN All required security associations for Mobile IPv6 created using CREATE_CHILD_SA exchanges

Use of IKEv2 to negotiate keys Issues At the end of IKE_AUTH exchange an IKE SA and an IPsec SA created Can the IPsec SA created in IKE_AUTH exchange used for protecting the BU/Back? Is it okay to set TSi to Home Address during the IKE_AUTH exchange? What about the IKE SA if TSi is set to HoA in IKE_AUTH exchange? –Is it keyed on CoA or HoA? Can TSi in CREATE_CHILD_SA exchange be different from TSi in IKE_AUTH exchange? Am I making any sense at all?

Use of EAP MN indicates it wants to use EAP Includes the IDi payload, but excludes AUTH payload in the IKE_AUTH exchange Home Agent includes an EAP payload IKE_AUTH exchange done after EAP success Can the key generated during EAP exchange be used for generating the AUTH payload in IKE_AUTH exchange? Issues Takes four round trips instead of two round trip to create the first security association Should work with other EAP and AAA-HA interface proposals being proposed in the WG Must we require the HA to support the mechanism? MUST/MAY?

Home Address configuration MN dynamically configures a HoA during initial IKE negotiation IKE_AUTH exchange Configuration Payload CFG_REQUEST INTERNAL_IP6_ADDRESS INTERNAL_IP6_SUBNET INTERNAL_IP6_DNS Home Agent allocates a HoA for the MN Could use a DHCPv6 backend CFG_REPLY INTERNAL_IP6_ADDRESS INTERNAL_IP6_SUBNET INTERNAL_IP6_DNS INTERNAL_ADDRESS_EXPIRY If Home Agent unable to allocate a HoA, include INTERNAL_ADDRESS_FAILURE in a Notify payload Should the support for this be optional? MUST/MAY?