Mobile IPv6 with IKEv2 and revised IPsec architecture

1
Mobile IPv6 with IKEv2 and revised IPsec
architecture

• IETF 61
• vijay.devarapalli_at_nokia.com

2
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

3
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

4
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

5
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

6
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

7
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

8
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

9
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

10
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?

11
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?

12
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