IDKE N ODE S PECIFICATION

Figure 25: SDL Example 

Many extensions have been made to improve the capability of SDL. The FIFO  concept for queuing as an example, is interrupted when the state cannot handle the  next signal as input. In this case, the inapplicable signal can either be dropped or  stored separately and be executed at some later date. Other conceptions can extend  the SDL by, for instance, adding timers or object orientation concepts. As these  extensions are irrelevant for the evaluation carried out in this thesis they are not  described further. Any reader requiring more detail can refer to [ITU99]. 

5.3 IDKE Node Specification

The IDKE  protocol  involves  two ARs: one  as sender and  another as  receiver. 

However, an IDKE‐aware AR might adopt both roles consecutively when there is a  traversing MN and thus, a former receiver becomes a future sender. It is an actuality  that each IDKE‐aware AR must be able to act both parts. However, most of the  challenges that ARs face are in situations where several requests occur in parallel. 

The following scenarios are considered possible: 

1. An AR receives a request from an “nAR” before having retrieved the key. In  this case, an nAR is considered as a “pAR” in any further protocol run. This  scenario occurs whenever an MN moves faster than the completion of a  protocol run and is thus referred to as fast moving.  

2. An MN returns to the previous AR before completing the protocol run; this is  called fast toggling. 

3. An MN double‐requests the key at the same time as an AR. Although this  could be a double request, the MN might also have been connected to a third  AR and has as a result returned to its previous domain. This is referred to as  fast cycling. 

As examples in all three scenarios, one might imagine three ARs (AR1, AR2, AR3)  where the MN is initially attached to the AR1 and performs a sequence of handovers. 

These handovers are assumed to take place in such a fast manner that the first one is  still pending at the time the last one has been initiated. Taking the viewpoint of AR2,  example sequences for all three scenarios are: “AR1, AR2, AR3” as sequence for a fast  moving MN; “AR1, AR2, AR1” for a toggling MN as well as “AR1, AR2, AR3, AR1  AR2” for a cycling MN. Given the assumption that messages contain timestamps, the  current session‐key holder upon receiving several requests is always able to judge  which request is the most recent one. Accordingly, the AR exclusively accepts the  most recent one and cancels all others. 

A difficult situation occurs whenever an AR receives a request without having the  corresponding session‐key. In this case, the AR is not even capable of judging as to  whether the request is valid or not. It is even more challenging when an AR is  waiting  for  a  key,  but  instead  receives  a  further  request.  The  AR  has  three  possibilities to deal with this situation: 

• Drop the new request  

• Queue the request  

• Forward the request to the AR from which it is itself expecting to obtain the  key. 

The first possibility is inadequate since it would end in a key forwarding chain and  would involve a second request by the MN. The second possibility is impracticable  for two reasons: 

• The queuing of potentially invalid requests from malicious senders would  make the ARs vulnerable against DoS‐attacks [Gop01]. 

• Treating all requests in the order of their arrival would lower the performance. 

The cycling scenario would specifically involve a cycling session‐key transfer  and would thus involve an additional delay. 

Therefore, the forwarding of requests is the only possibility that corresponds with  the requirements of the IDKE protocol. The design decision is accordingly made to  realize  the  request‐forwarding  function  as  an  optional  part  of  the  IDKE‐AR  extension. 

5.3.1 IDKE AR Specification

Chapter 3 introduces and specifies all messages relating to the IDKE protocol. The  major part of the protocol involves two ARs where the key is transferred between  them. The pAR acts as the sender while the nAR performs the part of the receiver. 

According to the role an AR adopts, it performs dedicated actions within the protocol  run. The tasks of the nAR are:  

• to forward the MN‐token, 

• to establish a key for tunneling between the ARs (also called SA), 

• to request the MN’s session‐key and  

• to send an acknowledgment to the MN. 

The pAR’s tasks are: 

• to check the MN’s token in order to guarantee the MN’s identity and the  freshness of the request,  

• to respond to the tunnel key establishment (SA request) and  

• to forward the session‐key. 

The capability for request‐forwarding and a mechanism for cancelling key transfers  have to be established at each AR in addition to providing the functions for both the  pAR and the nAR. 

An  example  scenario  involving  request‐forwarding  is  given  in  Figure  26.  The  scenario shows an MN fast moving among an AR‐chain from AR1 to AR4. Initially,  the MN was attached to AR1 and sequentially has sent handover requests to AR2,  AR3 and AR4. Figure 26 shows that the key has been successfully transferred from  AR1 to AR2. The tunnel establishment between AR2 and AR3 is in progress when a  key‐request from AR4 reaches AR3. As AR3 is unable to judge whether the request is  valid or not, it forwards the request (also called token) to AR2. AR2 is in possession  of the session‐key and is thus able to interpret the received token as a valid request. 

Thus, AR2 has two tasks: Firstly, to cancel the tunnel establishment between AR2  and AR3; and secondly, to start the tunnel establishment procedure with AR4. The  session‐key can then be directly transferred from AR2 to AR4. 

movement

AR1 AR2 AR3 AR4

KSMS

Handover Requests

HR1 HR2 HR3

Key Request AR3: Reqest forwarded

KSMS

AR2: Tunnel est. canceled

Figure 26: Example ‐ Fast Moving MN 

5.3.2 IDKE AR Extension

The fundamental concept of the extended AR specification is to initially consider  both roles of sender and receiver as separate state machines. The next step is to  combine them into a single state machine by first connecting the end states of one  state machine with the initial state of the other. Secondly, for all states all possible  incoming messages have to be checked in order to verify if they create a shortcut or  not. The result is an extended IDKE‐AR that is able to handle all potential IDKE  messages as the sender and the receiver. It forwards request messages from other  ARs and interrupts protocol runs by sending cancel messages. It is also able to  accept cancel messages from other ARs. Figure 27 illustrates a schema of an  extended IDKE‐AR. 

The block in the centre represents an IDKE‐AR consisting of two parts: The part of  the receiver and that of the sender. Initially, the AR is in the state which is referred to  as idle. In this state, the AR has neither key nor SA. The idle state belongs to the  receiving part of the AR. Once the MN sends an HO‐Request, the AR starts the key  obtaining procedure with the pAR according to the request made by the MN. After  the key transfer has been performed successfully, the AR switches its state to KEY established. If the AR receives a token before it has obtained the key, it will  forward the request to its pAR. When the token has already been forwarded, the AR  sends a cancel message to the token forwarder. The AR likewise continues the  communication and key obtaining procedure in case the token is invalid. The pAR  either proves the correctness of the token and forwards a cancel message or it  forwards the token in the same way and answers with a cancel message. This  message resets the AR to the idle state. 

The retrieving of the key enables the AR to enter the state of KEY established. 

This is the initial state of the sender. An acknowledgement is sent to the MN when  the AR enters the state KEY established. The AR in this state is thus able to  decide if a received token is valid and fresh. It should be mentioned here that until it  receives the session‐key, the AR is unable to make such a judgment. The AR now  takes on the role of the “pAR” and waits for a valid key request. When such a request  is received, it starts the SA‐establishment and the key‐transfer procedure with the  nAR‐ID  contained  in  the  message.  One  should  note  that  the  nAR‐ID  is  not  necessarily the sender of the request message since the sender could have simply  forwarded the request message. In such a case, the AR sends a cancel message to  the sender in order to interrupt the transfer.  previous AR it sent a ho request for requesting a handover. 

SENDER PART

CANCEL to cAR SA / KEY to nAR

RECEIVER PART

HO REQUEST HO REQUEST

SA / KEY TOKEN (self) TOKEN (nAR via cAR)

MN Forward TOKEN to pAR

IDKE AR

Figure 27: IDKE aware AR Overview