IETF #68, Prague, March 2007

1. MIPv6 CN-Targeted Location Privacy and Optimized Routingdraft-weniger-mobopts-mip6-cnlocpriv-01<kilian.weniger@eu.panasonic.com> IETF #68, Prague, March 2007

2. Outline • Scope of this draft • Scenario and problem definition • Solution in draft-irtf-mobopts-location-privacy-solutions • Proposed solution • Changes in new draft version • Conclusion

3. Scope of this draft • “CN-targeted location privacy” = Preventing disclosure of the MN‘s topological location to a Correspondent Node (CN) • CN can be off-path attacker initiating a session just to find out MN‘s location • Problem of disclosing location to eavesdroppers is out of scope

4. MN is reachable at public HoAIR associated with MN‘s identity (e.g., FQDN) and is anchored at HAIR Session can be initiated either by MN or CN CN initiates session by sending data to HoAIR Communication session requires short packet delays MN wants to hide its location from CN i.e., <identity, location> must be hidden from CN Scenario HAIR CN MN • MN addresses • HoAIR • CoA

5. location privacy compromised Problem definition • A MIPv6 MN has the choice. It can either • hide location from CN (by using rev. tunneling) or • get short packet delays (by using RO mode) • How to achieve both simultaneously? HAIR 1. HoAIR revealed reverse tunneling CN MN RO mode 2. <HoAIR, CoA> revealed • MN addresses • HoAIR • CoA

6. 1. <HoApseudo, CoA> revealed RO mode location privacy compromised Solution in draft-irtf-mobopts-location-privacy-solutions • Approach • Disclose location, but hide identity by using pseudo HoA • MN-initiated session (case 1) • MN uses RO mode with HoApseudo as HoA Issue: location privacy compromised if CN figures out MN‘s identity during session • CN-initiated session (case 2) • Since CN initiated session using HoAIR, it already knows MN‘s identity Issue: no solution to the problem HAIR CN MN 2. <HoAIR, CoA> revealed • MN addresses • HoAIR • HoApseudo • CoA

7. Proposed solution • Approach • Hide location, disclose identity by bootstrapping with HA close to CN • MN-initiated session (case 1) • MN uses reverse tunneling mode with HoAOR as HoA location privacy ensured • CN-initiated session (case 2) • MN uses RO mode with HoAIR as HoA and HoAOR as CoA • CoT/i,BU,data is tunneled over HAOR location privacy ensured HAIR 1. HoAOR revealed HAOR CN reverse tunneling MN (+RO mode) 2. <HoAIR, HoAOR> revealed • MN addresses • HoAIR • HoAOR • CoA

8. Changes in new draft version (based on feedback from last meeting) • HAOR must be trusted, since it learns MN‘s location • Either MN verifies trust before or during the bootstrapping or HAOR discovery mechanism only returns trusted home agents • Assumptions about deployed HAOR • HAOR is not required to be located in CN‘s domain. A nearby domain is sufficient • (Local) HAs deployed by ASPs could be used as HAOR • Assumptions about roaming relationships • This draft assumes that MN‘s MSA has roaming relationships with multiple MSPs offering HA services from various locations • This is also required for widespread use of local HA service (MSP=ASP) as specified, e.g., in draft-ietf-mip6-bootstrapping-integrated-dhc

9. Conclusion • draft-irtf-mobopts-location-privacy-solutions-04 lists solutions for MIPv6 location privacy problems, but support for scenarios where MN needs both location hiding from CN and optimized routing is missing • Bootstrapping with a HA close to CN is an option to achieve that with existing MIPv6 tools and without changes to HA, CN or MIPv6 protocol msgs

10. Thanks! Questions/Comments?

11. Appendix

12. HAOR discovery • Specification of discovery mechanism is currently out of scope • Some options are • MN has list of MSPs (possibly with distances to various prefixes), which can be used by MN to select HAOR • Anycast-based or DNS-based HA address discovery (according to draft-ietf-mip6-bootstrapping-split) • MN contructs anycast address based on CN‘s prefix • MN include CN’s prefix or FQDN in QNAME, e.g., “_mip6._ipv6.CNdomain” or “CNdomain.nearbyHA.MNdomain” • DHCP-based HA address discovery (according to draft-ietf-mip6-bootstrapping-integrated-dhc, draft-ietf-mip6-hiopt) • MN puts CN‘s realm as target network in Home Network Identifier Option

13. Case 1: MN-initiated session • Before sending data to CN, MN discovers HAOR • MN bootstraps with HAOR and obtains HoAOR • MN uses HAOR in bi-directional tunneling mode and HoAOR for the session with CN • MN keeps registrations with other HAs, such as HAIR HAOR MN CN HAOR discovery Decision to optimize route MIP bootstrapping (incl. obtaining HoAOR) BU (HoAOR, CoA) Data packets Session starts(sending from HoAOR)

14. MN HAIR HAOR CN Data packets Session starts(sending to HoAIR) HAOR discovery Decision to optimize route MIP bootstrapping (incl. obtaining HoAOR) BU (HoAOR, CoA) HoTi/HoT CoTi/CoT BU (HoAIR, HoAOR) Data packets Case 2: CN-initiated session • Data is sent to/from MN‘s public HoAIR • MN discovers HAOR and bootstrap with it • MN performs return routability over reverse tunnel to HAOR and registers HoAOR as CoA at CN

15. Headers in case 2 (CN-initiated sessions) • Data packets and BU sent by MN to CN IPv6 header (source = care-of address, destination = HAOR) ESP header in tunnel mode IPv6 header (source = HoAOR, destination = correspondent node) Destination Options header Home Address option (HoAIR) Any protocol • CoTi sent by MN to CN IPv6 header (source = care-of address, destination = HAOR) ESP header in tunnel mode IPv6 header (source = HoAOR, destination = correspondent node) Any protocol

16. location privacy compromised Possible solution with local HA • Approach • Disclose location and identity, but hide fact that HoAlocal contains location information • Case 1: MN-initiated session • MN bootstraps with local HAlocal and uses reverse tunneling mode  Issue: location privacy is compromised if CN knows identiy associated with HAlocal and knows that HoAlocal is anchored at local HA • Case 2: CN-initiated session • To be reachable, MN publishes <HoAlocal, identity>  Issue: location privacy is compromised if CN knows that HoAlocal is anchored at local HA HAIR 1. HoAlocal revealed HAlocal / IR reverse tunneling CN MN 2. <HoAlocal, identity> revealed • MN addresses • HoAlocal • CoA