response is 50 seconds. The MC waits for 50 second and resends the authentication packet for the second time. The PoA in the retransmitted M-KE packet can be different that the first one, thus between the exchanges pairs the PoA can change. The server is still not ready with the authentication and authorisation and again answers with pending notification. The polling interval is 20 seconds. The client repeats the request in 20 sec from different PoA. The server has finished the authentication meanwhile and answers immediately with successful
The server must implement caching to fulfil the polling mechanism. It must be able to keep client information in the memory, so it can be replied immediately. This is mostly relevant for the authentication and the authorisation, where the AAA server may be in multiple hops distance. The AAA answer can take many seconds. The current Radius servers do not use validity period, thus the answer is valid only at the time point of the response. In M-KE, validity of the AAA answer must be set. It is called caching period. The caching period must be at least the polling interval plus the clientserver
constPoA
t / . Otherwise, the AAA response
will expire between the pollings. The challenge and the response values must be cached when working with passwords. Caching password means that the same challenge must be involved, because the password can be verified only through the challenge value.
3.6 M-SE overview
The M-SE is an application protocol over UDP fully defined in chapter 5. The M-SE parameters can be classified in three groups: security parameters, mobility parameter and data parameters. The security parameters are keys, algorithms for the protection etc. The mobility parameters consider the mobility properties of the Mobile Nodes, like the minimum PoA change interval supported by the Mobile Server. They give common estimation of the node performance and the network quality. The data parameters are traffic selectors defining which packet must be protected by the M-SE session. The traffic selectors are pre-defined at the Mobile Nodes. They are announced during M-KE and the biggest common denominator is set. The selector defines the transport layer parameters such as protocol and ports.
The M-SE achieves confidentiality through encryption, authentication and integrity through HMAC [32], reply protection. The protocols deploys anti tracing mechanism by using pseudo random values in the header (see 3.7). The M-SE delivers transparent transport layers to the server. Transparent means that it is not manipulated or intercepted between the end-hosts. The network layer (IP) is constant, but not transparent, thus IP’s are replaced between the ends.
Figure 3.7: M-KE polling example Mobile Client
Mobile Server M-KE, authentication
Pending, polling in 50 sec
M-KE, authentication (2) Pending, polling in 20 sec
M-KE, authentication (3) MK-KE, auth. successful 50 sec
20 sec
PoA Change of Mobile Client (movement)
3.6 M-SE overview 53
The protocol operates in tunnel and native mode (see 3.3). The tunnels, like L2TP and GRE can be built between a Tunnel Node (TN) and Mobile Node (MN). In native mode, the communication between single applications is achieved. The layers in tunnel and native modes are shown in Figure 3.8.
The tunnel is built on top of the M-SE layer. The Tunnel Nodes (TNs) administrate Home IP parameters, which are unknown to the Mobile Nodes (MNs). The TNs can authenticate and authorize additionally to M-SE. This is common to the L2TP (PPP) implementations. The authentication and authorization duties can be distributed between the TN and MN according 6.1. The Figure 3.8 a) presents the integration with the two main tunnel types, i.e. L2TP and GRE. The use of tunnel requires more resources, but it is more flexible. It is recommended over the native mode.
M-SE in native mode protects the communication between two predefined application hosts. The Mobile Node and the application host can be the same or different physical node. The applications can use TCP or UDP for establishing the connection. The layers are shown in Figure 3.8 b). This form of protection must not be confused with TLS/SSL, where the security protocol delivers application layer and operates at the transport layer. The applications must be written to support SSL/TLS. The M-SE native mode delivers transparent transport layers, so every application based on UDP or TCP can be used without any adoption. It can be compared to transport mode of IPSec. This mode can be used to secure a connection in an efficient way to dedicated server, like FTP, HTTP. The advantage of native mode is the simplicity of implementation. Because of its simplicity, the usage is very restrictive. It cannot be used with any protocols transporting IP addresses in their payloads. The M-SE does not take care of proper translation of the payloads. Bundled sessions are also not supported. M-VPN concentrates on tunnel mode and native mode is a minor feature.
The M-SE contains a procedure for updating the PoA parameter described in 3.11. The procedure is implemented with notification messages (see 5.8.1). It is build of request and reply message. The messages are encapsulated in the M-SE protocols and therefore protected. The outbound processing of M-SE is different from the classical protocols, like IPSec. The main problem is how to match the packets to the M-SE session. The IP addresses of the Mobile Nodes cannot be used since they are dynamic. For this reason, a new concept of Mappers is introduced. A Mapper is a constant IP address assigned to an M-SE session and used for transport between the Tunnel Node and Mobile Node. The working principle is explained in the following 3.6.1. The inbound processing is similar to IPSec, where the packet is matched using unique session ID.
3.6.1 Mappers
The Mobile Node and Tunnel Node can be deployed at different physical hosts, as already described in 3.3.2. For the communication between physical hosts, IP addresses are
Figure 3.8: M-SE mode of operation Data UDP M-SEP L2TP IP GRE a) Tunnel mode Data UDP M-SEP TCP/UDP IP b) Native mode TCP/UDP IP User data Tunnel Transport User data Transport
3.7 Anti-tracing mechanism in M-SE