1. 1 MIPv6 CN-Targeted Location Privacy and Optimized Routing draft-weniger-mobopts-mip6-cnlocpriv-01 IETF #68, Prague, March 2007

2. 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. 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. 4 Scenario MN is reachable at public HoA IR –associated with MN‘s identity (e.g., FQDN) and is anchored at HA IR Session can be initiated either by MN or CN –CN initiates session by sending data to HoA IR Communication session requires short packet delays MN wants to hide its location from CN –i.e., must be hidden from CN CN MN HA IR MN addresses HoA IR CoA

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

6. 6 Solution in draft-irtf-mobopts- location-privacy-solutions MN CN HA IR MN addresses HoA IR HoA pseudo CoA 2. revealed RO mode 1. revealed Approach –Disclose location, but hide identity by using pseudo HoA MN-initiated session (case 1) –MN uses RO mode with HoA pseudo 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 HoA IR, it already knows MN‘s identity  Issue: no solution to the problem location privacy compromised

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

8. 8 Changes in new draft version ( based on feedback from last meeting) HA OR must be trusted, since it learns MN‘s location –Either MN verifies trust before or during the bootstrapping or HA OR discovery mechanism only returns trusted home agents Assumptions about deployed HA OR –HA OR is not required to be located in CN‘s domain. A nearby domain is sufficient –(Local) HAs deployed by ASPs could be used as HA OR 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. 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. 10 Thanks! Questions/Comments?

11. 11 Appendix

12. 12 HA OR discovery Specification of discovery mechanism is currently out of scope Some options are 1.MN has list of MSPs (possibly with distances to various prefixes), which can be used by MN to select HA OR 2.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” 3.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. 13 Case 1: MN-initiated session Before sending data to CN, MN discovers HA OR MN bootstraps with HA OR and obtains HoA OR MN uses HA OR in bi-directional tunneling mode and HoA OR for the session with CN –MN keeps registrations with other HAs, such as HA IR MNCN HA OR HA OR discovery MIP bootstrapping (incl. obtaining HoA OR ) BU (HoA OR, CoA) Data packets Decision to optimize route Session starts (sending from HoA OR )

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

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

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