1 IPsec-based MIP6 Security Qualcomm 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 MNHA1AAAHA2 Failure Recovery (HA2 allocated) Binding Update (Protected with IPsec) AAA (Get IPsec SA) AAA (IPsec SA) Binding Acknowledgement (Protected with IPsec) Option 1 (Manual IPsec Keying)

4 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 Failure Recovery Operation MIP6 Session Initialization Handoff Operation First Time Power-up Operation MNHA1HA3 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) 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) AAA (IPsec SA) Binding Acknowledgement (Protected with IPsec) 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 Failure Recovery Operation MIP6 Session Initialization Handoff Operation First Time Power-up Operation MNHA1HA3 Binding Update (Protected with IPsec) AAA (Get IPsec SA for MN-HA1) AAA (IPsec SA for MN-HA1) Binding Acknowledgement (Protected with IPsec) Handoff Binding Update (Protected with IPsec) Binding Acknowledgement (Protected with IPsec) IKEv2 and IPsec SAs Setup IKE & IPsec SAs Stored in NV memory Failure Recovery (HA2 allocated) Binding Update (Protected with IPsec) AAA (Get IPsec SA for MN-HA2) AAA (IPsec SA for MN-HA2) Binding Acknowledgement (Protected with IPsec) 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 SAs Stored 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