Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#43 closed defect (wontfix)

Questions on Security Discussion in REQ Draft

Reported by: kempf@… Owned by: kempf@…
Priority: minor Milestone:
Component: nohost-req Severity:
Keywords: REQ draft Cc: netlmm@…

Description (last modified by kempf@…)

Pete McCann?:

Section 2.3:

The owner of the correspondent or mobile node might not even be aware of the problem if an attacker has installed spyware or some other kind of exploit and the malware is relaying the change in local address to the attacker. Host-based localized mobility management solutions in which the correspondent only sees a regional address but the host still maintains a local address are unsatisfactory because they still have a potential for malware on the mobile node itself to reveal a change in the local address.

This seems like security through obscurity. If there is malware on the host and if the host has any means of determining its own location (i.e., GPS hardware) then its location may be compromised. Malware on the mobile host introduces a whole host of security issues that just cannot be addressed by a netlmm protocol.

Change History (2)

comment:1 Changed 13 years ago by kempf@…

  • Description modified (diff)
  • Resolution set to wontfix
  • Status changed from new to closed

"Security by obscurity" typically means that the information, entity, item, etc. one is trying to secure is known and that the security solution is to simply hide knowledge of that information from possible attackers by some noncryptographic mechanism. In this case, what is being proposed is that the mobile terminal doesn't have knowledge of the information, the information being fine-grained topological information that can be mapped to geography, so it is not being obscured.

Parenthetically, it is possible to use cryptographic means to achieve location privacy, but the design is not pretty. It requires changes in all the routers in the local routing domain. Suprisingly, the performance impact is not all that large and would be quite amiable to hardware acceleration, but the mechanism is so intrusive that it is probably not generally acceptable. See Trostle, J., bin Tariq, M., Kempf, J., and Jain, R., "Cryptographically Protected Prefixes for Location Privacy in IPv6," PET04, May, 2004, for more details.

comment:2 Changed 12 years ago by anonymous

  • Milestone milestone2 deleted

Milestone milestone2 deleted

Note: See TracTickets for help on using tickets.