Mobile IPv6 with IKEv2 and revised IPsec architecture

IETF 61

vijay.devarapalli@nokia.com

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?