HASH(4) = prf(SKEYID_b, M-ID | N1 | CERT1)
HASH(5) = prf(SKEYID_b, M-ID | N1_b | N2 | CERT2)
HASH(6) = prf(SKEYID_b, M-ID | N1_b | N2_b | SA1 | KD1 | KREQ)
HASH(7) = prf(SKEYID_b, M-ID | N1_b | N2_b | SA2 | KD2)
    

Figure 6: Hashes used in Step 4

Hash computation is similar to that explained in step 2. In step 4 hashes are computed by applying a pseudorandom function to the key SKEYID_b, along with the message id concatenated with the message contents following the hash. Also, nonces from a message exchange are included in the hash computation of the subsequent exchanges in order to ensure that both parties have the nonces just exchanged. This helps in data origin authentication. Hence N1_b and N2_b refer to N1 and N2 in exchanges (4) and (5) respectively. Hashes are very essential to ensure message integrity and to confirm that the messages have not been modified (possibly by an intruder) during transit.

All information received by the LKS of a GM from the GCKS as well as from neighboring LKSes is written to stable storage persistent across reboots. This can be effectively used to avoid flooding the GCKS with requests on a router reboot. This is one of the advantages of the proposed design over GDOI [RFC6407], where, when routers reboot they come back up with no information and the GCKS is flooded with requests. The routing protocol is notified by the KMP about the new SA being available in the key table for it to protect its control traffic.

The routing protocol security mechanism would store the incoming and outgoing SA information, and the adjacency information into the relevant databases.

As we can see, confidentiality and authentication has been ensured for all steps by means of secret keys and certificates.

In the following section, we shall see the small variations required in the basic protocol design proposed above, in order to handle the various categories of keying groups.

5.2.5. Variations for handling other Keying Groups

We have seen the different granularities possible for a keying group, that is, the different key scopes, in Section 2. We have also seen that the design proposed in Section 5.2 is able to handle the keying group where there is a separate key per sending router. This has been achieved by each router generating its own key, which would be the same for all its interfaces. Hence each router has a different SA for outgoing traffic and multiple SAs for incoming traffic, one corresponding to each neighbor. It is to be noted here that the key generation being done locally could have a small possibility of two routers ending up with the same key when they generate it randomly. However, if a good random number generator is used for key generation, the probability of ending up with the same key is drastically reduced. This extremely small possibility can be ignored since the method more importantly has the advantages that it reduces the load on the GCKS. Also the GCKS does not have the need to be aware of the individual keys of each router. This could be considered as a case of tradeoff.

In this section, we shall see how the remaining cases of keying groups can be handled. They can actually be handled by minor variations to the basic design. In essence, these variations can be implemented by the GM interpreting the key scope information given to it by the GCKS in step 2, and thereby knowing whether to expect keys from the GCKS or to derive them itself. This also makes the GM aware of the path to be followed. As we shall see, in a majority of cases it is step 4 that gets slightly altered.

Same key for the entire AD -

Let us take the most coarsely grained case, namely, a keying group per AD. Since all routers have to share the same key (TEK), the centralized GCKS is the one that should generate it. Every GM gets the TEK and other SA parameters directly from the GCKS in step 2. The TEK information received from the GCKS can be stored as both the outgoing as well as the incoming key since all GMs share the same key. Therefore, step 4 can be eliminated. However, step 3, which involves GMs authenticating neighboring GMs is necessary before the GMs can start exchanging control packets. In essence, this variation of key scope can be implemented by the GM interpreting the key scope information given to it from the GCKS in step 2, and thereby knowing that it should expect the TEK from the GCKS (TEK is also received in the same step).

Key per link -

This is another flavor of keying groups wherein there exists a TEK per link, that is, a key is shared by all routers sharing a link. This can be handled in a manner similar to the single key per router case described as far as steps 1, 2 and 3 are concerned. However, there is a slight variation required in step 4. Previously, the LKS of each GM generated a single key to be used on all interfaces of the GM. However in this case, an LKS needs to generate as many TEKs as the number of its interfaces by interacting with the neighbors on the respective links. This is done by GMs on a link interacting to derive a TEK and other SA parameters through any of the mutual key agreement protocols. Some examples of protocols that could be used for this purpose are MRKMP [I-D.hartman-karp-mrkmp], group Diffie-Hellman, and the STS protocol. Since MRKMP specifies how keys can be generated and distributed on a LAN by electing a GCKS, it can be used for TEK generation for the case where the key scope is per link. The TEK and the other SA parameters generated are stored by all LKSes sharing the link as the outgoing and incoming parameters on that particular link. This procedure is repeated by all GMs for all their links in turn.

Key per sending router per interface -

The only difference here when compared to the separate key per router case is that in that case, each GM generates a single TEK to be used on all of its interfaces, whereas, here each GM generates a different TEK for each of its interfaces. In step 4, it gives each neighbor the TEK that it plans to use on the connecting link between them.

Key per peer -

This is the last category of keying groups. This refers to unicast communication where peer routers exchange control packets. Here the SA parameters corresponding to the traffic key TEK and the TEK itself can be generated using a unicast key management protocol such as IKE or even KMPRP. However, an important point to note here is that adjacency management is necessary even for this case since routers should exchange keys only with legitimate neighbors. This can be achieved only by having a central authority that is aware of all valid adjacencies. Our design handles this. Steps 1, 2 and 3 of the design are sufficient. The key derived in step 3, namely, SKEYID_b serves as the TEK.

We have mentioned that the SA parameters along with the TEK are either delivered to the GMs by the GCKS (for the single key per AD case) or generated by the GMs themselves, possibly through interactions with other GMs (for the other keying groups, depending on the particular category). A parameter that could have a slightly different behavior is the SPI. This is also one of the parameters of an SA. However the range of SPIs to be used in an AD could be decided by the administrator. Whatever be the category of keying group, it could so happen that the administrator chooses to have the same SPI for all GMs. In this case, the GCKS could deliver the SPI to the GMs along with the policy for the remaining parameters of the SA. It could also be that the administrator wants each GM to use a different SPI for its outgoing traffic. In this case, the GCKS should not be overloaded with the task of generating a different SPI for each GM. GMs should generate the SPI themselves, possibly with communication with other GMs. If that happens, even for the single key per AD category of keying groups, the SPI is generated by the GMs, although the TEK may be obtained from the GCKS (since the TEK is to be the same for all GMs for this category of key scope). In other words, the key scope may be different from the scope of the SPI used in the AD. Our design is flexible enough to handle this since the SA policy handed down by the GCKS to the GMs would indicate to the GM the exact steps to be followed.

In all cases of keying groups, the LKS stores SA information to persistent storage to be used across reboots. Keys are stored into the key table [I-D.ietf-karp-crypto-key-table] and the KMP informs the same to the routing protocol, which would start using the keys to secure its control traffic. This is the step 5 mentioned in the explanation of the concept of hierarchical design in Section 5.1.3.

6. Other Aspects of the Key Management Problem

In this section, we address some of the other important aspects of the key management problem. Firstly we show how this automated system allows key updates to be done as frequently as desired. Soon after that, we show how various good-to-have features have been incorporated in the proposed design. Some of these features are scalability, incremental deployment ability, effective handling of router reboots and smooth key rollover. Addition of these features would help in achieving the requirements stated in Section 3.

6.1. Key Updates

Keys used by the routing protocols to secure their traffic need to be updated at regular intervals. They may have to be updated at other non-specific times as well depending on the requirement. There are a couple of reasons why key updates are required:

• As a good practice in order to protect against passive intruders who could have obtained access to the keys and could be eavesdropping the traffic.
• Whenever a new member comes up on a link, in order to ensure PBS. This means that the new member should not be able to get access to keys currently being used on the link since that could mean that the member can comprehend old messages exchanged on the link when it was not part of it.
• Whenever a member leaves, in order to ensure PFS. This means that going forward, even if the old member manages to get hold of messages exchanged among the remaining members on the same link, it should not be able to comprehend them.

One of the important points to be noted here is that PFS and PBS can be achieved very easily and in a straight forward way for unicast communication. Unicast communication involves a pair of routers that share keys for securing their traffic. Every pair of routers derives its own set of keys and those keys are known only to that particular pair of routers. Hence a change in any one of the members of the pair of routers would mean that the old keys are no longer valid and new keys are derived for communication. This automatically takes care of PFS and PBS. When a router, say R1, is uninstalled, the keys used by the other routers for pairwise (unicast) communication with R1 are no longer used. This ensures PFS. When a new router, say R2, is installed, all routers engaging in a unicast communication with it derive new pairwise keys with it. This ensures PBS.

For multicast communication, key updates are essential on a router uninstallation or an installation to ensure PFS and PBS respectively. This is because in multicast communication, multiple routers share the same key and a key remains valid even if one of the routers involved in the communication is changed. To achieve PFS and PBS, keys have to be updated so that the leaving or entering routers do not have access to information they are not entitled to.

We now have to determine what are the keys that need to be updated. For regular updates, it is quite obvious that the traffic keys of all the routers would have to be changed. The other case to consider is when the routers in an AD change, either due to an installation or an uninstallation. It is interesting to note that when the same traffic key is used for the entire AD, that key should be changed, leading to the effect of changing the keys for all the routers. However, for all other key scopes, only the keys corresponding to the neighbors of the leaving/ entering router need to be changed. This is because as far as control traffic is concerned, routers have knowledge of the keys of their neighbors only. Of course the adjacencies and hence the neighbors, may be defined differently for the various routing protocols.

One of the major problems with the manual method of key management is that keys cannot be updated as frequently as desired. This is due to the lack of authorized people to carry out the task. This issue can be easily overcome by an automated key management system. Let us see how these two cases of regular rekey and a rekey on a router installation/ uninstallation can be handled by the automated key management system we propose.

6.2. Regular Key Updates

In this section, we discuss how our design for automated key management aids key updates at regular intervals. The interval at which key updates are to be done is determined from the policies handed down by the Policy Server entity described in Section 4.2. These policies are handed down by the Policy Server to the GCKS in the form of a policy token, which in turn is handed down by the GCKS to the GMs in Step 2 of the protocol as explained in Section 5.2. We now need to see how key updates for all variations of keying groups can be addressed. As we shall see, when all routers in the AD share the same traffic key, the centralized GCKS is the generator of the new key, whereas in all other cases, the GMs generate the new keys appropriately. This is in fact similar to the process of initial key generation described in Section 5.2.

6.2.1. Same key for the entire AD

First, let us take the case of having a single key for the entire AD. Here, when a rekey is required, the GCKS generates the new traffic key and unicasts it to each individual GM. This ensures that all GMs share the same new TEK after the rekey. As an alternative to transferring the new TEK through unicast communication, the GCKS and all GMs in the AD could share a key called a 'TEK Encryption Key'. This key could be used by the GCKS for encrypting the new TEK derived, and multicasting to all GMs. The advantage of this approach over the unicast method is that it eliminates the need to have multiple key update messages sent out by the GCKS, one corresponding to each GM. This in turn reduces the network traffic. However, the downside to the multicast approach is the overhead of maintaining a group key (and appropriately updating it) just for the rekey purposes. This is a case of tradeoff.

6.2.2. Key per link

In this category of keying group, routers sharing a link also share the traffic key for that link. Here when a TEK update is required, GMs on a link execute one of the key agreement protocols such as MRKMP, group Diffie-Hellman or the STS protocol to derive a new TEK. This is similar to the manner in which they interact to derive the initial TEK for the link. The interval after which the TEK should be changed is of course determined from the policy token.

6.2.3. Key per sending router

In this case, every router has a different TEK that it uses for securing its control traffic. When a rekey is required, each GM generates a new TEK individually and then communicates the same to all its neighbors. The neighbors update the incoming TEK information corresponding to that router in their databases.

6.2.4. Key per sending router per interface

This case is very similar to the previous one. The only difference is that here, each GM generates as many new TEKs as the number of its interfaces, one per interface. The GM then communicates to each of its neighbors the TEK it plans to use on the interface corresponding to that particular neighbor.

6.2.5. Key per peer

This is the unicast case. Keys can be updated just by every pair of routers executing a unicast key management protocol such as IKE.

In all the above cases, the LKS updates the key store as well as its persistent storage with the updated key information. The KMP notifies the routing protocol of a change in the keys used to secure the control traffic.

6.3. Router Installation/ Uninstallation

Along with the regular key updates, keys need to be updated even when an existing router is uninstalled or a new router is installed. These are for PFS and PBS purposes respectively as already explained in Section 6.1. There are a couple of differences between key updates in these cases when compared with the regular key updates.

• Regular traffic key updates require that the traffic keys corresponding to all routers in the AD be updated. However, key updates on a router removal or addition require only the keys corresponding to the neighbors of the leaving or entering router to be changed. This is because routers have knowledge of the keys corresponding to their neighbors only as far as control traffic is concerned. But if it so happens that the same traffic key is being used for all routers in the AD, then a change in the key automatically implies that the key gets changed for all the routers.
• Regular key updates are done at intervals determined from the policy token given by the Policy Server. However, key updates on a router removal or addition are done based on instructions given by the GCKS in such a situation. This is because routers in the AD (other than the GCKS) would not be aware of the fact that a particular router is either installed or uninstalled.

Apart from these differences, the process of key updates during a router change is very similar to the regular key updates. We shall now discuss briefly how key updates on a router change can be handled for each of the categories of keying groups.

6.3.1. Same key for the entire AD

For this category of key scope, the same traffic key is shared by all routers in the AD. When a router is removed or a new router is installed, the GCKS derives a new TEK and unicasts it to each of the routers in the AD.

As an alternative to transferring the new key through unicast method, the GCKS and all GMs could share a key called the 'TEK Encryption Key'. If this option is followed, first of all, the TEK Encryption Key would have to be changed on a router change. Then for the case of router installation, the GCKS multicasts the new TEK Encryption Key, encrypted in the old key to all existing routers. It then unicasts the new TEK Encryption Key to the newly installed router. After this, the GCKS derives a new TEK and multicasts it to all the routers after encrypting it in the new TEK Encryption Key. This can be decoded by the new router as well since it now possesses the latest TEK Encryption Key. For the case of router uninstallation, the GCKS changes the TEK Encryption Key and unicasts it to all the remaining routers. The new TEK Encryption Key cannot be multicast in this case since the old router would also be able to decrypt it. Changing of the TEK would be the same as for router installation. The new TEK is sent in a multicast message to all routers encrypted in the new TEK Encryption Key.

When compared with the unicast method of key updates, this multicast method has the advantage of low bandwidth consumption. However the disadvantage of the multicast method is that an extra key, the TEK Encryption Key, now needs to be maintained and updated accurately. So the exact method chosen depends on the administrator.

6.3.2. Key per link

For this case, on a router installation or an uninstallation, the GCKS informs the neighbors of that router. These routers interact with each other (and with the new router if it is a case of router installation) and derive a new traffic key for that particular link where the neighbor change has occurred. Any of the mutual key agreement protocols such as MRKMP, group Diffie-Hellman or the STS protocol can be used.

6.3.3. Key per sending router

Here again the GCKS appropriately informs the neighbors of the affected router. Each such neighbor runs a randomized key generation algorithm to derive a new traffic key and communicates the key to its neighbors. This is very similar to the case of regular key updates.

6.3.4. Key per sending router per interface

This category of keying group can also be handled in an easy manner. The GCKS informs the neighbors of the affected router. Each such router derives a new traffic key for that interface on which the neighbor change has occurred. The router then communicates the new key to its new set of neighbors on that particular interface.

6.3.5. Key per peer

As already explained, key updates on a router change are not valid for unicast communication. This is because in unicast communication, a key is shared by only two routers. A router addition or a removal results in a change in a particular pair (or pairs) of routers. Hence new keys are anyway derived to be shared by the new pair. Thus this can be considered as an automatic update of keys without any explicit processing.

6.4. Router Reboots

Router reboots form a very important case to be considered in any design pertaining to networks. Especially in a centralized architecture, care should be taken to prevent the central entity from being stormed with requests when multiple routers happen to reboot almost simultaneously. In our architecture, it is the persistent storage of the distributed LKS that plays a major role on a router reboot. As already seen the LKS of each GM writes to persistent storage some configuration and policy information such as the key scope, adjacencies, SAs, the traffic keys corresponding to itself and its neighbors, certificate received from the GCKS, and the policy token. Hence on a GM reboot, the LKS retrieves information from the persistent storage. This is an extremely important feature since it avoids the GCKS being flooded with requests for information when multiple routers in the AD happen to reboot.

However, information retrieval from the persistent storage may not always be sufficient. Occasionally a rekey could have happened when a router was down. This could have been either a regular rekey or a rekey due to a router installation or removal. These cases should be dealt with in an appropriate manner so as to ensure that the rebooted router gets the latest SA and adjacency information.

In order to handle these cases, a router needs to query its neighbors on a reboot. This is done as soon as the router has rebooted and read the relevant information from its persistent store. The neighbors communicate their traffic key and SA information to the rebooted router. Depending on this information as well as the key scope information retrieved from the persistent storage, the rebooted router can handle a rekey appropriately. This interaction with the neighbors for the different cases of key scopes is explained below:

Same key for the entire AD -

To handle this case, a router gets the TEK related information initially from one of its neighbors. It compares this key with the key corresponding to that neighbor (which is the same as its own key since the same key is shared by all routers in the AD) as retrieved from the persistent storage. If the two keys match, then it is evident that no rekey has happened on the neighbor. Since the key scope is such that the same key is used for the entire AD, it can be concluded that there has been no rekey in the AD. Hence the rebooted router need not do anything else. If the keys are in mismatch, the rebooted router concludes that a rekey has happened in the AD, either due to a regular key update or due to a key update based on a router change. In either case, the router changes its outgoing traffic key to be the same as the new one got from its neighbor. This helps maintain consistency of all traffic keys across the AD.

Key per link -

For this case, the rebooted router queries its neighbors in turn, one neighbor on each of its links. Again it compares the traffic key received from its neighbor with the corresponding information retrieved from its persistent store. If the two keys match, it means that there has been no rekey on that link. If the keys are in mismatch, it means that a rekey has happened on the link. The rebooted router then changes its own outgoing traffic key on that link to be the same as the new key got from the neighbor. In either case, the router proceeds with querying its neighbors on its remaining links. This is different from the previous case where a single key was used by all routers in the AD. This is because in the key per link case, determining whether a rekey has happened on a particular link does not help determine the status on other links. Hence at least one neighbor on each link has to be queried.

Key per sending router -

For this case, the rebooted router starts by querying one neighbor on each of its interfaces. If the traffic keys of all the queried neighbors are the same as the corresponding keys retrieved from the persistent storage of the rebooted router, there is nothing to be done. If there is at least one neighbor whose key has changed, the rebooted router changes its own key and communicates it to its neighbors. The rebooted router can stop querying its neighbors at this point. An interesting observation here is that a neighbor's key could have changed either due to a regular rekey or due to an installation/ uninstallation of its neighboring router. This neighboring router may or may not be a common neighbor to the rebooted router. Since the exact situation cannot be determined, the rebooted router just goes ahead with its key change once it sees that the key of its neighbor has changed. This should be fine since an extra key update is not harmful.

Key per sending router per interface -

This case is similar to the key per link case. The rebooted router queries one neighbor per interface and compares the traffic key information received with the corresponding information from the persistent key store. If the keys match, there has been neither a regular update nor a router change on that interface. If the keys do not match, it means that there has been a key update either as part of a regular rekey or due to a neighbor change on that interface. Hence the rebooted router derives a new traffic key for that interface and communicates the same to its neighbors on that interface. The router then proceeds with querying its neighbors on the remaining interfaces to determine whether the keys used on its remaining interfaces are required to be changed or not.

Key per peer -

This category of keying group represents unicast communication. Here when a router comes back up after a reboot, it queries its counterpart for the traffic keys corresponding to this pair of routers. Since for unicast communication, a pair of routers together derives traffic keys, new keys for this pair would not be available as yet even though a regular rekey interval may have passed when the router was down. Therefore the two routers could engage in a unicast key management protocol such as IKE to derive new traffic keys or could decide to proceed with using the old keys itself till the next rekey interval has passed.

The method described above helps ensure that in a majority of cases, rekeys that could have happened when a router was down are handled. There are a couple of cases to be considered as yet.

Firstly, the rebooted router should verify whether the adjacencies as retrieved from its persistent storage are accurate still. They could now be stale due to the fact that a router could have been installed/ uninstalled when it was rebooting.

Secondly, in the discussion above regarding the ways in which reboots can be handled for the different categories of keying groups, we have mentioned that a router queries only one neighbor in some cases and one neighbor per link or interface in other cases. A situation could arise wherein the queried neighbor itself had gone through a reboot resulting in its own key being stale. This in turn would mean that the querying router cannot rely on the information got from this single neighbor.

One way in which both of these issues could be addressed is for the rebooted router to query the GCKS to get the updated information. However we do not want the GCKS to be flooded with requests from the various routers in the AD. Hence there are two layers of protection designed as follows:

• As already explained, the rebooted router retrieves information from its persistent store. It then queries its neighbors and appropriately changes its keys or realises that a key update is not required.
• Once this is done, in order to query the GCKS, the rebooted router chooses a random time interval so as to avoid clashes with other routers querying the GCKS.

Due to the randomness introduced, chances of the GCKS being flooded with requests are reduced. The GCKS when queried, could give the router information corresponding to its new adjacencies, probably the time of change of its adjacencies and any other relevant rekey information. This enables the rebooted router to know whether its traffic keys are stale or not.

Another fine point here is that very rarely the rekey process could be in progress when the router comes up. This is a corner case and is being left for future work.

6.5. Scalability

Any system that has widespread deployment should be designed keeping the scalability feature in mind. If scalability is overlooked during the design phase, the system would fail on high loads when actually deployed.

We have designed the automated key management system so as to make it scalable. We have already mentioned that we are limiting the scope of our problem to key and adjacency management within an AD. Even within an AD since the number of routers is not fixed, the system should be able to handle a variable/ large number of routers. The proposed protocol involves a set of GCKS-GM interactions and a set of GM-GM interactions. The GM-GM communication is only among neighboring GMs and hence scalability is not an issue for that. Even for the GCKS-GM communication in the normal case, there should not be any issue since all GMs are not installed or turned on at the same time. However, a situation to be considered is when the GMs reboot. It could so happen that due to a power outage, all GMs in the AD go down and come back up at approximately the same time. It is extremely important to ensure that the GCKS is not stormed with requests at this point.

Our proposal handles this case in a couple of ways. Firstly we have seen that the LKS of each GM maintains a stable storage. All important pieces of information, such as the ones got from the GCKS and from the neighboring GMs are written to this storage, which is persistent across reboots. Hence a GM after a reboot, reads information directly from its persistent storage thereby preventing the GCKS from being flooded with requests. Secondly after retrieving information from the local storage, when the GMs need to query the GCKS itself, they do so by starting a timer and querying at a random time interval. This plays a major role in preventing the GCKS from being overloaded thereby leading to scalability.

Another factor that enables partial distribution of functionality thereby enhancing scalability is the presence of the Standby GCKS. If a situation arises such that the active GCKS fails (which could be due to an overload), the Standby GCKS would immediately take over the functionality of the active one. This eliminates a single point of failure and hence allows the system to withstand higher loads, or more number of GMs in the AD.

6.6. Option to Turn Off Adjacency Management

We have already discussed why it is important for an automated key management system to manage adjacencies well. In fact, this is because routing protocol updates are usually exchanged with neighbors, which in turn leads to the requirement that communicating routers should be legitimate neighbors. It is a good practice to have adjacency management turned on in a network so that for any router, only its legitimate neighbors and all of its legitimate neighbors get to know the keys it uses for securing its control traffic.

However, sometimes an administrator may decide to turn off adjacency checks because his network of routers is probably too small and the extra overhead is not required. This would mean that any router is then allowed to query for and receive the traffic keys of any other router in the network even though the routers may not be neighbors. If adjacency management is turned off, even routing protocols would respond to all control packets without performing adjacency checks. This definitely reduces security in the network.

If the key scope is such that the same traffic key is used throughout the AD, not much harm is caused if a router gives its key information to any other router in the AD since all routers share the same key. Of course mutual authentication of the routers should happen in order to know if the routers are valid members of the AD. However, an administrator could use the key per sender model, for example, and turn off adjacency management. The administrator then relies on the physical adjacency to ensure that a router far away from another router does not query it for keys.

6.7. Incremental Deployment

Whenever a new system is to be deployed in the real world, the ease with which that can be done is of utmost importance. Network operators may not be ready to switch over to a new system if it is not easy to deploy it. Also, operators using a certain setup, when switching over to a new one would usually want to deploy the new system on an incremental basis. This would help them detect problems in the new system, if any, and then decide whether to completely move to the new model or not. We have designed our automated key management system keeping this requirement in mind. The model we have proposed can be deployed on a per interface basis. This means that initially GMs could be manually configured with the TEKs for some of their interfaces, and made to run the key management protocol to derive TEKs corresponding to the other interfaces. This is for the case of separate key per interface of each router. The other cases of keying groups can be handled in a similar manner. Secondly, the new system can be used to provide TEKs for one routing protocol at a time. This again makes the transition from the manual method of configuration to the automated method smooth.

6.8. Smooth Key Rollover

Whenever the TEK is changed, smooth key rollover should be ensured so that no packets are dropped during the process of key transitions. In order to achieve this, while transitioning from the old key to the new one, for a short duration routers have to accept messages secured using either key. This allows for the time delay involved in the new keys being received by all routers participating in that particular communication. After a certain time period as determined by a timer, the old key information could be cleared. For smooth key rollover in multicast communication, these points have been explained in more detail in [RFC5374]. For unicast communication, either this method could be followed or the two participating routers could exchange new keys and acknowledge the receipt of the keys just before beginning to use them.

6.9. Eliminating Single Point of Failure

The proposed design for key management describes the use of a centralized GCKS as the controller and co-ordinator for the entire AD. In any centralized system, there is a possibility of having a single point of failure. In such a system, if the central entity goes down, it could so happen that the entire system stops functioning due to loss of important data. This can be avoided by having a backup entity to take over when the primary controller goes down. This is precisely what is proposed in our design in Section 4.2. We propose maintaining a Standby GCKS, which is always kept in sync with the primary GCKS. This can be done by correctly syncing all data from the active to the standby at regular intervals. The appropriate interval could be determined by the policies handed down by the Policy Server to the GCKS. Whenever the active goes down, the standby can immediately take over its responsibility thereby preventing any interruption in the functioning of the system. This introduces a certain degree of distribution of functionality and hence can successfully eliminate a single point of failure.

7. An Alternate Mechanism for Transporting the Messages

It is possible that TCP-AO could provide a suitable vehicle for the necessary message exchanges. This will be explored in detail in the next revision of this document.

8. Detailed Packet Formats

TBD

9. IANA Considerations

This document has no actions for IANA.

10. Acknowledgements

11. Change History (RFC Editor: Delete Before Publishing)

[NOTE TO RFC EDITOR: this section for use during I-D stage only. Please remove before publishing as RFC.]

atwood-karp-akam-rp-03

• changed focus to be on policy for key and adjacency management, instead of on the key and adjacency management itself
• Proposed that TCP-AO might serve as a suitable vehicle for the exchanges

atwood-karp-akam-rp-02

• Inserted ASCII art for figures and hashes
• Resolved internal cross-references
• Resolved external citations

atwood-karp-akam-rp-01

• copied in the rest of the relevant material from Revathi's thesis
• added overview material on protocol operations

atwood-karp-akam-rp-00 (original submission, based on Revathi's thesis)

• copied in some sections of the thesis that are relevant to the specification.

12. Needs Work in Next Draft (RFC Editor: Delete Before Publishing)

[NOTE TO RFC EDITOR: this section for use during I-D stage only. Please remove before publishing as RFC.]

List of stuff that still needs work

• Determine if TCP-AO is a viable platform for this work
• Create the section on packet formats

13. References

13.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

13.2. Informative References

[atwo2009:AKM]	Atwood, J.W., "Automated Key Management for Router Updates", October 2009.
[I-D.ietf-karp-ops-model]	Hartman, S. and D. Zhang, "Operations Model for Router Keying", Internet-Draft draft-ietf-karp-ops-model-05, February 2013.
[I-D.ietf-karp-threats-reqs]	Lebovitz, G., Bhatia, M. and B. Weis, "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", Internet-Draft draft-ietf-karp-threats-reqs-07, December 2012.
[I-D.hartman-karp-mrkmp]	Hartman, S., Zhang, D. and G. Lebovitz, "Multicast Router Key Management Protocol (MaRK)", Internet-Draft draft-hartman-karp-mrkmp-05, September 2012.
[I-D.mahesh-karp-rkmp]	Jethanandani, M., Weis, B., Patel, K., Zhang, D., Hartman, S., Chunduri, U., Tian, A. and J. Touch, "Negotiation for Keying Pairwise Routing Protocols in IKEv2", Internet-Draft draft-mahesh-karp-rkmp-04, February 2013.
[I-D.tran-karp-mrmp]	Tran, P. and B. Weis, "The Use of G-IKEv2 for Multicast Router Key Management", Internet-Draft draft-tran-karp-mrmp-02, October 2012.
[I-D.ietf-karp-crypto-key-table]	Housley, R., Polk, T., Hartman, S. and D. Zhang, "Database of Long-Lived Symmetric Cryptographic Keys", Internet-Draft draft-ietf-karp-crypto-key-table-07, March 2013.
[RFC2409]	Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC6407]	Weis, B., Rowles, S. and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, October 2011.
[RFC6518]	Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012.
[RFC3740]	Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC5796]	Atwood, W., Islam, S. and M. Siami, "Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010.
[RFC4535]	Harney, H., Meth, U., Colegrove, A. and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC5374]	Weis, B., Gross, G. and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008.
[RFC5996]	Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.

Authors' Addresses