1 IPsec-based MIP6 Security Qualcomm Inc. Starent Inc. Notice: Contributors grant free, irrevocable license to 3GPP2 and its Organization Partners to incorporate

1

IPsec-based MIP6 SecurityQualcomm Inc.

Starent Inc.

Notice: Contributors grant free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner’s name any Organizational Partner’s standards publication even though it may include portions of the contribution; and at the Organization Partner’s sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner’s standards publication. Contributors are also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution.This document has been prepared by the contributors to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on the contributors. The contributors specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of the contributors other than provided in the copyright statement above.

2

Goals

Protect MIP6 signaling Integrity protect BU/BA Optional encryption for route optimization

support Minimize messages exchanged

3

Failure Recovery Operation

MIP6 Session Initialization

Handoff Operation

IPsec SA

Binding Update (Protected with IPsec)

AAA (Get IPsec SA)

AAA (IPsec SA)Binding Acknowledgement

(Protected with IPsec)

Handoff Binding Update (Protected with IPsec)

Binding Acknowledgement(Protected with IPsec)

IPsec SA

MN HA1 AAAHA2

Failure Recovery(HA2 allocated)


AAA (Get IPsec SA)



Option 1 (Manual IPsec Keying)

4

Option 1 (Manual IPsec Keying) Set up manual keying parameters at the MN and AAA server

Keys, SPI, Algorithms need to be configured

When MN sends the first BU, HA retrieves the IPsec SA from the AAA server

BU/BA protected with IPsec Subsequent BUs (after the first one) don’t need any AAA interaction

This option needs zero key management related messaging

The IPsec SA is not unique to the {MN,HA} pair If the HAs are well trusted and belong to the same operator, this may

be okay. But, it could be an issue if HA is dynamically assigned in a visited operator.

This option requires additional configuration (IPsec SA) at the MN and AAA server

5



Handoff Operation

First Time Power-up Operation

MN HA1 HA3


AAA (Get IPsec SA)





IKEv2 and IPsec SAs Setup IKE & IPsec SAs Stored in non-volatile memory

Failure Recovery(HA2 allocated) Binding Update

(Protected with IPsec)AAA (Get IPsec SA)



MN-AAA Key

HA2

IKE & IPsec SAs Stored in non-volatile memory

Option 2 (Optimized IKEv2-based Operation for Dynamic IPsec Keying)

AAA

MN-AAA Key

AAA (IKE & IPsec SAs for MN)

AAA (Ack)

6

Option 2 (Optimized IKEv2-based Operation for Dynamic IPsec Keying)

Set up both IKE and IPsec SA with HA3 at the time of first power-up operation The IKE and IPsec SAs can be set up via IKEv2/EAP. This is done when the MN

powers up for the very first time and can be refreshed at an appropriate time (e.g., once per day).

The IKE and IPsec SAs are then uploaded to the AAA server by HA3 using the HA-AAA interface.

Both IKE and IPsec SAs to be stored in non-volatile memory of MN and AAA, avoiding the need to run IKEv2 again (e.g., at failure recovery time)

Only MN-AAA key to be configured at the AAA server and MN.

If MS wants to initiate a MIP6 session and obtains a dynamic HA (e.g., HA1), MN can use the same IPsec SA (established during power-up with HA3) to protect BU sent to HA1.

No need for full IKEv2/EAP exchange between MN and HA1, because HA1 fetches the IPsec SA from the AAA. Subsequent BUs (after the first one) don’t need this AAA interaction.

The IPsec SA is not unique to the {MN,HA} pair. If the HAs are well trusted and belong to the same operator, this may be okay

This is optimal for home domain operation (i.e., when the HA is in the home domain)

The handoff and failure recovery operation are similar to Option 1 The failure/recovery case shown is a system failure that causes the MN to bootstrap again upon

recovery, e.g., from HA1 to HA2. Again, No need for full IKEv2/EAP exchange between MN and HA2, because HA2 fetches the

IPsec SA from the AAA. Failure/recovery of HAs also can be handled by hot standby methods

7



Handoff Operation

First Time Power-up Operation

MN HA1 HA3


AAA (Get IPsec SA for MN-HA1)

AAA (IPsec SA for MN-HA1)Binding Acknowledgement




IKEv2 and IPsec SAs Setup

IKE & IPsec SAsStored in NV memory

Failure Recovery(HA2 allocated)


AAA (Get IPsec SA for MN-HA2)

AAA (IPsec SA for MN-HA2)Binding Acknowledgement


MN-AAA Key

HA2

Option 2a (Optimized IKEv2-based Operation for HA in Visited Domain)

AAA

MN-AAA Key

AAA (IKE & IPsec SAs for MN-HA3)

AAA (Ack)

IKE_SA_INIT Request (IPsec SA for MN-HA1)

IKE_SA_INIT Response (IPsec SA for MN-HA1)

IKE_SA_INIT Request (IPsec SA for MN-HA2)

IKE_SA_INIT Response (IPsec SA for MN-HA2)

AAA (IPsec SA for MN-HA1)

AAA (Ack)

AAA (IPsec SA for MN-HA2)

AAA (Ack)

IKE & IPsec SAsStored in NV memory

8

Option 2a (Optimized IKEv2-based Operation for HA in Visited Domain) Set up both IKE and IPsec SA with HA3 (in MN’s home domain) at the time of

first power-up operation (same as option 2)

If MN wants to initiate a MIP6 session and obtains a dynamic HA (e.g., HA1) in the visited domain,

MN establishes an IPsec SA with HA3 that uploads the IPsec SA to the home AAA server. This requires only a single roundtrip of create child SA exchange.

MN uses this IPsec SA to protect BU sent to HA1. No need for full IKEv2/EAP exchange between MN and HA1, because HA1

fetches the IPsec SA from the home AAA. Subsequent BUs (after the first one) don’t need this AAA interaction.

The IPsec SA is unique to the {MN,HA} pair Optimal when a visited domain allocates HA to the MN

The failure/recovery case shown is a system failure that causes the MN to bootstrap again upon recovery, e.g., from HA1 to HA2.

If a different HA is assigned upon failure recovery, MN establishes a new IPsec SA with HA3 that uploads the IPsec SA to the home AAA server. This requires only a single roundtrip of create child SA exchange.

Again, No need for full IKEv2/EAP exchange between MN and HA2, because HA2 fetches the IPsec SA from the AAA.

Failure/recovery of HAs also can be handled by hot standby methods

9

Additional Points

The IP address of the HA that bootstraps IKE SA and IPsec SA can be given to the MN via DHCPv6

3GPP2 vendor specific AAA attributes can be defined to distribute IPsec SA

Attributes needed for the security-bootstrapping HA (in home domain) to upload the SAs to the home AAA server

Attributes needed for the dynamically-assigned HA (in visited or home domain) to fetch the SAs from the home AAA server

This proposal can co-exist with the regular MIP6 security mechanism of always performing IKEv2 with the assigned HA. But, how MN knows which mechanism to use (e.g., in roaming scenarios) needs further study.

10

Conclusion & Recommendation

Conclusion: Option 2 provides all the features with the maximum flexibility Avoids any additional configuration Zero re-keying messages needed for home domain operation Two messages (single roundtrip) needed for visited domain

operation Two messages (single roundtrip) needed for failure/recovery

operation

Recommendation: Use option 2 when HA is in the home network and option 2a when HA is in the visited network

Documents

1 IPsec-based MIP6 Security Qualcomm Inc. Starent Inc. Notice: Contributors grant free, irrevocable license to 3GPP2 and its Organization Partners to incorporate