Extension for Interaction between Mobile IPv6 and IPsec/IKE

1. PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE Shinta Sugimoto Francis Dupont draft-sugimoto-mip6-pfkey-migrate-00 62nd IETF – Minneapolis Mobile IPv6 WG meeting

2. Topics • Background • Do we need any interaction between Mobile IPv6 and IPsec/IKE? • Extension to PF_KEY framework – MIGRATE • Concepts • Message Format • Message sequence • Limitation • Conclusion 62nd IETF – Minneapolis Mobile IPv6 WG meeting

3. Background • Mobile IPv6 uses IPsec to protect messages exchanged between MN and HA as specified in RFC 3775, RFC 3776: • Home Registration signals (BU/BA) • Return Routability messages (HoTI/HoT) • MIPv6 specific ICMPv6 messages (MPS/MPA) • Payload packets • SA pairs are necessary to be established between the MN and HA in static or dynamic manner • Tunnel mode SAs are necessary to be updated whenever the MN performs movement 62nd IETF – Minneapolis Mobile IPv6 WG meeting

4. INBOUND: • sel: src=HoA_MN1, dst=any, proto=MH • apply SA2 (ESP tunnel) • OUTBOUND: • sel: src=any, dst=HoA_MN1, proto=MH • apply SA1 (ESP tunnel) 1 3 2 IPsec tunnel • INBOUND: • sel: src=any, dst=HoA_MN1, proto=MH • apply SA1 (ESP tunnel) • OUTBOUND: • sel: src=HoA_MN1, dst=any, proto=MH • apply SA2 (ESP tunnel) 4 HA2 HA1 Internet IP-in-IP tunnel IP-in-IP tunnel MN2 MN1 62nd IETF – Minneapolis Mobile IPv6 WG meeting

5. Necessary Interactions between Mobile IPv6 and IPsec/IKE • Update endpoint address of tunnel mode SA • Mobile IPv6 component may not have full access to SADB • Update endpoint address stored in SPD entry which is associated with tunnel mode SA • IKE should be able to continuously perform key negotiation and re-keying • IKE daemon should update endpoint address of the IKE connection (aka K-bit) to keep its alive while the MN changes its CoA 62nd IETF – Minneapolis Mobile IPv6 WG meeting

6. Requirements • Modifications to the existing software (Mobile IPv6 and IPsec/IKE stack) should be kept minimum • The mechanism should not be platform dependent 62nd IETF – Minneapolis Mobile IPv6 WG meeting

7. Extension to PF_KEY framework – PF_KEY MIGRATE • Introduce a new PF_KEY message named MIGRATE which is to be issued by Mobile IPv6 components to inform movement • PF_KEY MIGRATE requests system and user application to update SADB and SPD: • Tunnel mode SA entry • SPD entry which is associated with the tunnel mode SA • Additionally, the message can also be used to handle K-bit 62nd IETF – Minneapolis Mobile IPv6 WG meeting

8. Example: MN updating outbound SP entry for MN to protect MH messages 3ffe:501:ffff:100:1:2:3:4/128 (HoA) ::/128 135 (MH) 1 (outbound) 3ffe:501:ffff:500:1:2:3:4/128 (Old-CoA) 3ffe:501:ffff:100::1/128 (HA address) 50 (ESP) 3ffe:501:ffff:400:1:2:3:4/128 (New-CoA) 3ffe:501:ffff:100::1/128 (HA address) 50 (ESP) PF_KEY MIGRATE – message format • Selector Information: • Source address • Destination address • Upper layer protocol (i.e. MH) • Direction (inbound/outbound) • Old SA Information: • Old tunnel source address • Old tunnel destination address • Protocol (ESP/AH) • New SA Information: • New tunnel source address • New tunnel destination address • Protocol (ESP/AH) 62nd IETF – Minneapolis Mobile IPv6 WG meeting

9. PF_KEY MIGRATE Mobile IPv6 IPsec Mobile IPv6 daemon IKE daemon ISAKMP SA Userland Kernel PF_KEY Socket Mobile IPv6 core SPD SAD 62nd IETF – Minneapolis Mobile IPv6 WG meeting

10. Initial Home Registration MIGRATE MIGRATE HoA=>CoA1 HoA=>CoA1 Home Re-registration Home Registration MIGRATE MIGRATE CoA1=>CoA2 CoA1=>CoA2 Home De-Registration MIGRATE MIGRATE CoA2=>HoA CoA2=>HoA Message Sequence of PF_KEY MIGRATE MN HA 62nd IETF – Minneapolis Mobile IPv6 WG meeting

11. Limitations/Concerns • There is an ambiguity in the way to specify target SADB entry: • Current scheme to specify target SADB entry based on src/dst address pair does not seem to be the best solution • Delivery of PF_KEY MIGRATE message cannot be guaranteed: • When a message is lost, there will be an inconsistency between Mobile IPv6 and IPsec database • Some parts of the PF_KEY MIGRATE are implementation dependent: • There is no standard way to make an access to SPD 62nd IETF – Minneapolis Mobile IPv6 WG meeting

12. Implementation Status • BSD • MIPv6: A prototype implemented on KAME/SHISA on FreeBSD • IKE: Enhancements made to IKEv1 daemon (racoon) • Linux • MIPv6: A prototype implemented on MIPL 2.0 on Linux-2.6 • IKE: Enhancements made to IKEv1 daemon (racoon) which was originally ported from BSD 62nd IETF – Minneapolis Mobile IPv6 WG meeting

13. Conclusion • There should be a minimum interface between Mobile IPv6 and IPsec/IKE to fully take advantage of security features • Newly defined PF_KEY MIGRATE message makes it possible for Mobile IPv6 and IPsec/IKE to interact each other • By receiving PF_KEY MIGRAGE message, system and user application will become able to make necessary update of SADB/SPD • Proposed mechanism has been implemented on both Linux and BSD platform • Further improvements are needed to overcome some limitations 62nd IETF – Minneapolis Mobile IPv6 WG meeting

14. Thank you ! & Questions ? 62nd IETF – Minneapolis Mobile IPv6 WG meeting