This problem in mobility and security protocols allows making profiling of physical movements, which is a major privacy thread.
The scenario is shown in Figure 2.6 regarding Mobile IP and IPSec. An attacker taps (intercepts) all packets going to Home Agent (HA) or to IPSec Gateway regardless of the IP of the mobile host. This means it must be in front of the IPSec Gateway (HA) in the best case.
In IPSec, there is data confidentiality but not for the Session ID. The headers of ESP [14] and AH [12] contain the Security Parameter Index (SPI), see A.2.2. The SPI value is unique for the gateway and constant during the IPSec session. The SPI is used to identify the Security Association (SA) for inbound processing at the peer. The SPI value stays constant for a long time and its change can be tracked during the Rekeying in IKE as the NAPT devices does, see A.2.2.10.6 and A.2.1.11. The attacker can match the SPI to all the temporary IPs. The Home Address or User ID is unknown. The attacker has a SPI and all physical locations in the time, thus a profile. As mentioned earlier, the user ID to SPI can be matched using heuristic observation.
In the Mobile IPv4 [4] protocol, the registration message is authenticated but is not confidential. The Home Address of the Mobile Node is sent in clear as part of the registration request. The attacker can easily match the Care-of-Address (temporary IP address) to the Home Address. The attacker can find out where the mobile node is located and how it is moving.
The Mobile IPv6 [6] uses IPSec for protection of the Binding Update which makes the protocols vulnerable in the same way.
The tracking of the mobile session is serious deficit of IPSec and Mobile IP, which are the major protocols for mobility and security. All current solutions, see 2.10, have this issue and it is considered by the author as very serious problem.
2.7 Requirements for secure IP mobility
The high-end requirements defined in 2.1 are described here in technical terms. The common criteria are divided into three groups:
General requirements:
• The mobility must not involve special features by the intermediate devices, such as router, switches etc. The requested functionality must be implemented at the mobile hosts and at the gateway only. The solution must be possible in the heterogeneous Internet, where the devices are under the control of different ISPs.
• The solution must be compatible to the current Internet with NAPT router and multi-homed hosts (see 2.4 and 2.5). The solution should not require a translation of payload by the NAPT routers (see A.2.1).v
Internet Internet Mobile IP or IPSec Moving Mobile Host Home Agent IPSec Gateway Moving Attacker
2.7 Requirements for secure IP mobility 16
• The solution must be supportable in IPv4 and IPv6.
• The solution should integrate in the current network structures, such as AAA (Authentication Authorisation and Accounting) servers, firewalls routers. Without this integration, a practical implementation becomes almost impossible.
• The Internet hosts must not support any features in order to communicate to mobile host. The mobility features must be supported at mobile host and its mobile gateway (Mobile IP terminology Mobile Node and Home Agent). Requirements on mobility:
• The solution must deliver IP mobility, thus keeping the same IP address while changing the access networks (see 2.8). IP mobility allows the transparent use of all IP based protocols, without any need for specific changes in previously developed applications.
• Mobility must be independent from the link layer. Changing the different types of access networks, such as from UMTS on WiFi, must not interrupt the connection insofar as IP connectivity is available.
• The mobile host is unaware of its PoA, thus its Internet IP and port. The only way of detaching the PoA is executing proactively an update procedure in some intervals. The procedure updates also the current PoA at the participants.
• The bandwidth must be used efficiently. The signalling packets should be proportional to the network changes and host movements. When the host moves rarely the signalling must be low, and vice versa.
Security requirements:
• The mobile signalling and application data must be: authenticated, encrypted, replay and integrity protected.
• The session must not be traceable to IP address. Header information, such as session ID’s, can be static during the session. This allows an attacker to map certain sessions to PoA. The IP addresses are physically allocated and the attacker can trace the physical movements of the mobile host in this way. This must be avoided in M-VPN.
• The principle of Perfect Forword Secrecy must be implemented, see A.2.2.6.3. The compromising of a single private key must not lead to the compromising of other keys.
• The solution must deliver security between the Mobile Host and the Gateway. The intermediated devices are not considered trustful. Solutions, like hop-by-hop protection implemented in SIPS [2], do not deliver the required security. In the hop-by-hop solutions, the connection is only protected between the clients and proxies. The data in the proxies is unprotected, thus in clear text.
The requirements in terms of security and mobility are delivered from a practical experience. They do not try artificially to tie the circle of possible solutions, in order to develop research work. Currently, there is a big gap between the theoretically developed protocols and the real implementation requirements as shown in 2.10. The primary target is to