uses versions 128 to 255 (8 major and 16 minor). Only by inspecting the first byte, the socket daemon (process) can find out the protocol. The daemon must also FIFO buffer the packets for sending and receiving. At the second level are the processes of M-KE and M-SE, which asynchronous read from the buffer and handle the packets.
3.5 M-KE overview
The Mobile Key Exchange (M-KE) has the following targets:
• Operation in mobile environment with frequent changes of IP.
• Identification and authentication of participants using a variety of algorithms, like digital signature with x509 certificates, shared secret, password etc. The protocol must integrate in the current AAA structures.
• Negotiation of cryptographic parameters for M-SE session, like encryption, authentication, integrity protection etc.
• Delivery of authenticated key material for M-SE session, thus session keys for encryption, authentication and integrity protection.
• Announcement of the mobile parameter of the nodes, like minimal interval supported between the PoA changes.
• Exchange of network and service information. They describe the network or services directly connected to the server and client. Networks connected by hops (not directly connected) are not considered.
• The protocol allows information’s exchange about other known servers offering resources. The nodes can build overlay networks with dynamic topologies in this way.
The M-KE runs over UDP and is fully defined in chapter 4. The Mobile Client initialises the negotiation using the pre-configured Mobile Security Policy (M-SP). The Mobile Server is always the responder and cannot initiate a session.
The M-KE delivers the parameters for M-SE after a successful negotiation. The M-KE session is deleted after the negotiation, thus there is no permanent session, like in IKE (s. A.2.2). One M-KE session results in one M-SE session. If there is a need for more than one M-SE session, then the M-KE must be repeated. A single M-KE for building multiple M-SE sessions makes sense from theoretical perspective, but it has many practical disadvantages, like permanent session, need for keep-a-live mechanisms, out of the state by network failures.
3.5.1 Mobility during the M-KE
In order to define how fast can change the PoA, the term mobility in negotiation must be defined. A negotiation in total mobility cannot be designed principally. There is a circular
UDP msg [ < 128 ] [ > 127 ] Check the First Byte M-SE msg M-KE msg M-SE process M-KE process FIFO FIFO FIFO Buffer Buffer
3.5 M-KE overview 51
dependency if the time between movements is less than the packet transmission time. The IP/port of received packet is already out-of-date, since the sender already has a new one. The nodes can principally communicate only if the host has a constant PoA for at least the round trip delay plus the local processing time. The negotiation cannot be achieved if one of the hosts is moving faster than this interval. This is not a restriction specific to M-KE but one that hold for any other protocol as well. The IP and port can change during the negation but the change must be bigger than sum of round trip time with the processing at host. The requirement can be mathematically expressed as:
client proc send client proc receive send client constPoA t t t t t t + ⋅ ≥ + + ≥ 2 server proc send server proc receive send server constPoA t t t t t t + ⋅ ≥ + + ≥ 2 ,
where clientserver constPoA
t / denotes the time for which the client or server must have constant PoA.
The tsend/receivedenotes the time for sending or receiving a packet. The time for sending and
receiving could be assumed as equal (this is in most of the cases). Potentially, the asymmetric DSL bandwidth can lead to different delays but this is out of scope in this section. The
server client proc
t / is the time for packet processing, thus the time needed to generate an answer of the
received packet. The processing time includes not only the physical processing time dependent on the gateway’s CPU but also the AAA authentication by remote server, thus looking in remote databases etc. It should not be underestimated, since by roaming for example, the authentication is made by remote system and it can take up to a minute. Further more, involving searches in databases leads to processing time of several seconds.
3.5.2 Polling and caching in M-KE
To increase the mobility, the interval with constant PoA must be reduced. The transmission time cannot be influenced because it is a physical property. The only way to reduce the interval with constant PoA is working on the processing time at the MC (Mobile Client) and MS (Mobile Server). The key idea is to split the negotiation in multiple parts, between which the PoA may change. The polling mechanism reduces the requirement on the processing time, thus improves the mobility.
The M-KE exchange consists of multiple request and response messages. Mobile Client sends the request and the Mobile Server sends the response. A pair of request and response is denoted as mobile exchange pair. The M-KE consists of multiple mobile exchange pairs.
The key requirement is that the Mobile Server must send the response message immediately to Mobile Client, thus with out any delay. There two types of possible responses: pending and response data. The pending is send when the server cannot process the request immediately. For example, if the Mobile Server needs to perform DB search taking around a second, then it responds with pending. The pending message contains the time in seconds, when the Mobile Client must repeat the request. If the Mobile Server can answer immediately, then it sends the data to the PoA of the request message. The PoA of the Mobile Client may change between the mobile exchange pairs. The Mobile Server uses always the PoA of the last request message of the Mobile Client.
Every mobile exchange pair can be repeated several times until successful exchange. An example is shown in Figure 3.7. The client sends its authentication credentials, like username and challenge response. The server cannot verify the credential immediately and therefore answers with pending notification to the PoA of the request. The polling interval in the server
3.6 M-SE overview