< draft-ietf-karp-ops-model-08.txt   draft-ietf-karp-ops-model-09.txt >
Network Working Group S. Hartman Network Working Group S. Hartman
Internet-Draft Painless Security Internet-Draft Painless Security
Intended status: Informational D. Zhang Intended status: Informational D. Zhang
Expires: March 3, 2014 Huawei Expires: April 14, 2014 Huawei
August 30, 2013 October 11, 2013
Operations Model for Router Keying Operations Model for Router Keying
draft-ietf-karp-ops-model-08.txt draft-ietf-karp-ops-model-09.txt
Abstract Abstract
Developing an operational and management model for routing protocol The IETF is engaged in an effort to analyze security of routing
security that works with all the routing protocols will be critical protocol authentication according to design guidelines discussed in
to the success of routing protocol security efforts. This document RFC 6518. Developing an operational and management model for routing
discusses issues and begins to consider development of these models. protocol security that works with all the routing protocols will be
critical to the deployability of these efforts. This document gives
recommendations to operators and implementors regarding management
and operation of router authentication. These recommendations will
also assist protocol designers in understanding management issues
they will face.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 3, 2014. This Internet-Draft will expire on April 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 3, line 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The KARP working group is designing improvements to the cryptographic The Keying and Authentication of Routing Protocols (KARP) working
authentication of IETF routing protocols. These improvements include group is designing improvements to the cryptographic authentication
improvements to how integrity functions are handled within each of IETF routing protocols. These improvements include improvements
protocol as well as designing an automated key management solution. to how integrity functions are handled within each protocol as well
as designing an automated key management solution.
This document discusses issues to consider when thinking about the This document discusses issues to consider when thinking about the
operational and management model for KARP. Each implementation will operational and management model for KARP. Each implementation will
take its own approach to management; this is one area for vendor take its own approach to management; this is one area for vendor
differentiation. However, it is desirable to have a common baseline differentiation. However, it is desirable to have a common baseline
for the management objects allowing administrators, security for the management objects allowing administrators, security
architects and protocol designers to understand what management architects and protocol designers to understand what management
capabilities they can depend on in heterogeneous environments. capabilities they can depend on in heterogeneous environments.
Similarly, designing and deploying the protocol will be easier with Similarly, designing and deploying the protocol will be easier with
thought paid to a common operational model. This will also help with thought paid to a common operational model. This will also help with
the design of NetConf schemas or MIBs later. the design of NetConf schemas or MIBs later. This document provides
recommendations to help establish such a baseline.
This document also gives recommendations for how management and This document also gives recommendations for how management and
operational issues can be approached as protocols are revised and as operational issues can be approached as protocols are revised and as
support is added for the key table [I-D.ietf-karp-crypto-key-table] support is added for the key table [I-D.ietf-karp-crypto-key-table].
Routing security faces interesting challenges not present with some Routing security faces interesting challenges not present with some
other security domains. routers need to function in order to other security domains. routers need to function in order to
establish network connectivity. As a result, centralized services establish network connectivity. As a result, centralized services
cannot typically be used for authentication or other security tasks; cannot typically be used for authentication or other security tasks;
see Section 4.4. In addition, routers' roles affect how new routers see Section 4.4. In addition, routers' roles affect how new routers
are installed and how problems are handleded; see Section 6. are installed and how problems are handleded; see Section 6.
2. Requirements notation 2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Breakdown of KARP configuration 3. Breakdown of KARP configuration
Routing authentication configuration includes configuration of key
material used to authenticate routers as well as parameters needed to
use these keys. Configuration also includes information necessary to
use an automated key management protocol to configure router keying.
The key table [I-D.ietf-karp-crypto-key-table] describes
configuration needed for manual keying. Configuration of automated
key management is a work in progress.
There are multiple ways of structuring configuration information. There are multiple ways of structuring configuration information.
One factor to consider is the scope of the configuration information. One factor to consider is the scope of the configuration information.
Several protocols are peer-to-peer routing protocols where a Several protocols are peer-to-peer routing protocols where a
different key could potentially be used for each neighbor. Other different key could potentially be used for each neighbor. Other
protocols require the same group key to be used for all nodes in an protocols require the same group key to be used for all nodes in an
administrative domain or routing area. In other cases, the same administrative domain or routing area. In other cases, the same
group key needs to be used for all routers on an interface, but group key needs to be used for all routers on an interface, but
different group keys can be used for each interface. different group keys can be used for each interface.
Within situations where a per-interface, per-area or per-peer key can Within situations where a per-interface, per-area or per-peer key can
be used for manually configured long-term keys, that flexibility may be used for manually configured long-term keys, that flexibility may
not be desirable from an operational standpoint. For example not be desirable from an operational standpoint. For example
consider OSPF [RFC2328]. Each OSPF link needs to use the same consider OSPF [RFC2328]. Each router on an OSPF link needs to use
authentication configuration, including the set of keys used for the same authentication configuration, including the set of keys used
reception and the set of keys used for transmission, but may use for reception and the set of keys used for transmission, but may use
different keys for different links. The most general management different keys for different links. The most general management
model would be to configure keys per link. However for deployments model would be to configure keys per link. However for deployments
where the area uses the same key it would be strongly desirable to where the area uses the same key it would be strongly desirable to
configure the key as a property of the area. If the keys are configure the key as a property of the area. If the keys are
configured per-link, they can get out of sync. In order to support configured per-link, they can get out of sync. In order to support
generality of configuration and common operational situations, it generality of configuration and common operational situations, it
would be desirable to have some sort of inheritance where default would be desirable to have some sort of inheritance where default
configurations are made per-area unless overridden per-interface. configurations are made per-area unless overridden per-interface.
As described in [I-D.ietf-karp-crypto-key-table], the cryptographic As described in [I-D.ietf-karp-crypto-key-table], the cryptographic
skipping to change at page 5, line 47 skipping to change at page 6, line 6
could define a Peer specification indicating the key had a link scope could define a Peer specification indicating the key had a link scope
and also a Peer specification for scoping a key to a specific area. and also a Peer specification for scoping a key to a specific area.
For link-scoped keys it is generally best to define a single Peer For link-scoped keys it is generally best to define a single Peer
specification indicating the key has a link scope and to use specification indicating the key has a link scope and to use
interface restrictions to restrict the key to the appropriate link. interface restrictions to restrict the key to the appropriate link.
Operational Requirements: implementations of this model MUST support Operational Requirements: implementations of this model MUST support
configuration of keys at the most general scope for the underlying configuration of keys at the most general scope for the underlying
protocol; protocols supporting per-peer keys MUST permit protocol; protocols supporting per-peer keys MUST permit
configuration of per-peer keys, protocols supporting per-interface configuration of per-peer keys, protocols supporting per-interface
keys MUST support configuration of per-interface keys, and so on. keys MUST support configuration of per-interface keys, and so on for
Implementations MUST NOT permit configuration of an inappropriate key any additional scopes. Implementations MUST NOT permit configuration
scope. For example, configuration of separate keys per interface of an inappropriate key scope. For example, configuration of
MUST NOT be supported for a protocol requiring per-area keys. This separate keys per interface would be inappropriate to support for a
restriction can be enforced by rules specified by each routing protocol requiring per-area keys. This restriction can be enforced
protocol for validating key table entries. As such these by rules specified by each routing protocol for validating key table
implementation requirements are best addressed by care being taken in entries. As such these implementation requirements are best
how routing protocols specify the use of the key tables. addressed by care being taken in how routing protocols specify the
use of the key tables.
3.1. Integrity of the Key Table 3.1. Integrity of the Key Table
The routing key table [I-D.ietf-karp-crypto-key-table] provides a The routing key table [I-D.ietf-karp-crypto-key-table] provides a
very general mechanism to abstract the storage of keys for routing very general mechanism to abstract the storage of keys for routing
protocols. To avoid misconfiguration and simplify problem protocols. To avoid misconfiguration and simplify problem
determination, the router MUST verify the internal consistency of determination, the router MUST verify the internal consistency of
entries added to the table. Routing protocols describe how their entries added to the table. Routing protocols describe how their
protocol interacts with the key table including what validation MUST protocol interacts with the key table including what validation MUST
be performed. At a minimum, the router MUST verify: be performed. At a minimum, the router MUST verify:
skipping to change at page 6, line 34 skipping to change at page 6, line 43
o The peer specification is consistent with the protocol. o The peer specification is consistent with the protocol.
Other checks are possible. For example the router could verify that Other checks are possible. For example the router could verify that
if a key is associated with a peer, that peer is a configured peer if a key is associated with a peer, that peer is a configured peer
for the specified protocol. However, this may be undesirable. It for the specified protocol. However, this may be undesirable. It
may be desirable to load a key table when some peers have not yet may be desirable to load a key table when some peers have not yet
been configured. Also, it may be desirable to share portions of a been configured. Also, it may be desirable to share portions of a
key table across devices even when their current configuration does key table across devices even when their current configuration does
not require an adjacency with a particular peer in the interest of not require an adjacency with a particular peer in the interest of
uniform configuration or preparing for fail-over. uniform configuration or preparing for fail-over. For these reasons,
these additional checks are generally undesirable.
3.2. Management of Key Table 3.2. Management of Key Table
Several management operations will be quite common. For service Several management operations will be quite common. For service
provider deployments the configuration management system can simply provider deployments the configuration management system can simply
update the key table. However, for smaller deployments, efficient update the key table. However, for smaller deployments, efficient
management operations that do not require a configuration management management operations that do not require a configuration management
system are important. system are important. In these environments configuration interfaces
(such as web interfaces and command-line interfaces) provided
directly by the router will be important to easy management of the
router.
As part of adding a new key it is typically desirable to set an As part of adding a new key it is typically desirable to set an
expiration time for an old key. The management interface SHOULD expiration time for an old key. The management interface SHOULD
provide a mechanism to easily update the expiration time for a provide a mechanism to easily update the expiration time for a
current key used with a given peer or interface. Also when adding a current key used with a given peer or interface. Also when adding a
key it is desirable to push the key out to nodes that will need it, key it is desirable to push the key out to nodes that will need it,
allowing use for receiving packets then later enabling transmit. allowing use for receiving packets then later enabling transmit.
This can be accomplished automatically by providing a delay between This can be accomplished automatically by providing a delay between
when a key becomes valid for reception and transmission. However, when a key becomes valid for reception and transmission. However,
some environments may not be able to predict when all the necessary some environments may not be able to predict when all the necessary
changes will be made. In these cases having a mechanism to enable a changes will be made. In these cases having a mechanism to enable a
key for sending is desirable. Management interfaces SHOULD provide key for sending is desirable. Management interfaces SHOULD provide
an easy mechanism to update the direction of an existing key or to an easy mechanism to update the direction of an existing key or to
enable a disabled key. enable a disabled key.
Implementations SHOULD permit a configuration in which if no Implementations SHOULD permit a configuration in which if no
unexpired key is available, existing security associations continue unexpired key is available, existing security associations continue
using the expired key with which they were established. using the expired key with which they were established.
Implementations MUST support a configuration in which security Implementations MUST support a configuration in which security
associations fail if no un-expired key is available for them. See associations fail if no un-expired key is available for them. See
Section 6.2 for a discussion of security faults including those Section 6.2 for a discussion of reporting and managing security
related to key expiration. faults including those related to key expiration.
3.3. Interactions with Automated Key Management 3.3. Interactions with Automated Key Management
Consideration is required for how an automated key management Consideration is required for how an automated key management
protocol will assign key IDs for group keys. All members of the protocol will assign key IDs for group keys. All members of the
group may need to use the same key ID. This requires careful group may need to use the same key ID. This requires careful
coordination of global key IDs. Interactions with the peer key ID coordination of global key IDs. Interactions with the peer key ID
field may make this easier; this requires additional study. field may make this easier; this requires additional study.
Automated key management protocols also assign keys for single peers. Automated key management protocols also assign keys for single peers.
If the key ID is global and needs to be coordinated between the If the key ID is global and needs to be coordinated between the
receiver and transmitter, then there is complexity in key management receiver and transmitter, then there is complexity in key management
protocols. protocols that can be avoided if key IDs are not global.
3.4. Virtual Routing and Forwarding Instances (VRFs) 3.4. Virtual Routing and Forwarding Instances (VRFs)
Many core and enterprise routers support multiple routing instances. Many core and enterprise routers support multiple routing instances.
For example a router serving multiple VPNs is likely to have a For example a router serving multiple VPNs is likely to have a
forwarding/routing instance for each of these VPNs. Each VRF will forwarding/routing instance for each of these VPNs. Each VRF will
require its own routing key table. require its own routing key table.
4. Credentials and Authorization 4. Credentials and Authorization
skipping to change at page 9, line 47 skipping to change at page 9, line 47
threat model: inside attacks are not in scope. threat model: inside attacks are not in scope.
Preshared keys used with key derivation function similarly to manual Preshared keys used with key derivation function similarly to manual
preshared keys. However to form the actual traffic keys, session or preshared keys. However to form the actual traffic keys, session or
peer specific information is combined with the key. From an peer specific information is combined with the key. From an
authorization standpoint, the derivation key works the same as a authorization standpoint, the derivation key works the same as a
manual key. An additional routing protocol step or transport step manual key. An additional routing protocol step or transport step
forms the key that is actually used. forms the key that is actually used.
Preshared keys that are used via automatic key management have not Preshared keys that are used via automatic key management have not
been specified for KARP. Their naming and authorization may differ yet been specified for KARP although ongoing work suggests they will
from existing uses of preshared keys in routing protocols. In be needed. Their naming and authorization may differ from existing
particular, such keys may end up being known only by two peers. uses of preshared keys in routing protocols. In particular, such
Alternatively they may also be known by a group of peers. keys may end up being known only by two peers. Alternatively they
Authorization could potentially be based on peer identity, although may also be known by a group of peers. Authorization could
it is likely that knowing the right key will be sufficient. There potentially be based on peer identity, although it is likely that
does not appear to be a compelling reason to decouple the knowing the right key will be sufficient. There does not appear to
authorization of a key for some purpose from authorization of peers be a compelling reason to decouple the authorization of a key for
holding that key to perform the authorized function. some purpose from authorization of peers holding that key to perform
the authorized function.
4.1.1. Sharing Keys and Zones of Trust 4.1.1. Sharing Keys and Zones of Trust
Care needs to be taken when symmetric keys are used for multiple Care needs to be taken when symmetric keys are used for multiple
purposes. Consider the implications of using the same preshared key purposes. Consider the implications of using the same preshared key
for two interfaces: it becomes impossible to cryptographically for two interfaces: it becomes impossible to cryptographically
distinguish a router on one interface from a router on another distinguish a router on one interface from a router on another
interface. So, a router that is trusted to participate in a routing interface. So, a router that is trusted to participate in a routing
protocol on one interface becomes implicitly trusted for the other protocol on one interface becomes implicitly trusted for the other
interfaces that share the key. For many cases, such as link-state interfaces that share the key. For many cases, such as link-state
skipping to change at page 12, line 47 skipping to change at page 12, line 47
infrastructureless mode of public-key operation described in the infrastructureless mode of public-key operation described in the
previous section can work well together. One router could identify previous section can work well together. One router could identify
its peers based on names and use certificate validation. Another its peers based on names and use certificate validation. Another
router could use hashes of certificates. This could be very useful router could use hashes of certificates. This could be very useful
for border routers between two organizations. Smaller organizations for border routers between two organizations. Smaller organizations
could use public keys and larger organizations could use PKI. could use public keys and larger organizations could use PKI.
4.4. The role of Central Servers 4.4. The role of Central Servers
An area to explore is the role of central servers like RADIUS or An area to explore is the role of central servers like RADIUS or
directories. As discussed in the design-guide, a system where keys directories. Routers need to securely operate in order to provide
are pushed by a central management system is undesirable as an end network routing services. Routers cannot generally contact a central
result for KARP. However central servers may play a role in server while establishing routing because the router might not have a
authorization and key rollover. For example a node could send a hash functioning route to the central service until after routing is
of a public key to a RADIUS server. established. As a result, a system where keys are pushed by a
central management system is an undesirable result for router keying.
However central servers may play a role in authorization and key
rollover. For example a node could send a hash of a public key to a
RADIUS server.
If central servers do play a role it will be critical to make sure If central servers do play a role it will be critical to make sure
that they are not required during routine operation or a cold-start that they are not required during routine operation or a cold-start
of a network. They are more likely to play a role in enrollment of of a network. They are more likely to play a role in enrollment of
new peers or key migration/compromise. new peers or key migration/compromise.
Another area where central servers may play a role is for group key Another area where central servers may play a role is for group key
agreement. As an example, [I-D.liu-ospfv3-automated-keying-req] agreement. As an example, [I-D.liu-ospfv3-automated-keying-req]
discusses the potential need for key agreement servers in OSPF. discusses the potential need for key agreement servers in OSPF.
Other routing protocols that use multicast or broadcast such as IS-IS Other routing protocols that use multicast or broadcast such as IS-IS
skipping to change at page 14, line 19 skipping to change at page 14, line 19
a peer for a given routing action. As discussed previously, the a peer for a given routing action. As discussed previously, the
following objects are potentially required: following objects are potentially required:
o Key objects are required. Symmetric keys may be preshared and o Key objects are required. Symmetric keys may be preshared and
knowledge of the key used as the decision factor in authorization. knowledge of the key used as the decision factor in authorization.
Knowledge of the private key corresponding to Asymmetric public Knowledge of the private key corresponding to Asymmetric public
keys may be used directly for authorization as well. During key keys may be used directly for authorization as well. During key
transitions more than one key may refer to a given peer. Group transitions more than one key may refer to a given peer. Group
preshared keys may refer to multiple peers. preshared keys may refer to multiple peers.
o A peer is a router that this router might wish to communicate o Peer objects are required. A peer is a router that this router
with. Peers may be identified by names or keys. might wish to communicate with. Peers may be identified by names
or keys.
o Groups of peers may be authorized for a given routing protocol. o Objects representing peer groups are required. Groups of peers
may be authorized for a given routing protocol.
Establishing a management model is difficult because of the complex Establishing a management model is difficult because of the complex
relationships between each set of objects. As discussed there may be relationships between each set of objects. As discussed there may be
more than one key for a peer. However in the preshared key case, more than one key for a peer. However in the preshared key case,
there may be more than one peer for a key. This is true both for there may be more than one peer for a key. This is true both for
group security association protocols such as an IGP or one-to-one group security association protocols such as an IGP or one-to-one
protocols where the same key is used administratively. In some of protocols where the same key is used administratively. In some of
these situations, it may be undesirable to explicitly enumerate the these situations, it may be undesirable to explicitly enumerate the
peers in the configuration; for example IGP peers are auto-discovered peers in the configuration; for example IGP peers are auto-discovered
for broadcast links but not for non-broadcast multi-access links. for broadcast links but not for non-broadcast multi-access links.
skipping to change at page 14, line 52 skipping to change at page 15, line 5
In many cases peers will explicitly be identified in routing protocol In many cases peers will explicitly be identified in routing protocol
configuration. In these cases it is possible to attach the configuration. In these cases it is possible to attach the
authorization information (keys or identifiers) to the peer's authorization information (keys or identifiers) to the peer's
configuration object. Two cases do not involve enumerating peers. configuration object. Two cases do not involve enumerating peers.
The first is the case where preshared keys are shared among a group The first is the case where preshared keys are shared among a group
of peers. It is likely that this case can be treated from a of peers. It is likely that this case can be treated from a
management standpoint as a single peer representing all the peers management standpoint as a single peer representing all the peers
that share the keys. The other case is one where certificates in a that share the keys. The other case is one where certificates in a
PKI are used to introduce peers to a router. In this case, rather PKI are used to introduce peers to a router. In this case, rather
than configuring peers, , the router needs to be configured with than configuring peers, , the router needs to be configured with
information on what certificates represent acceptable peers. information on which certificates represent acceptable peers.
Another consideration is what routing protocols share peers. For Another consideration is which routing protocols share peers. For
example it may be common for LDP peers to also be peers of some other example it may be common for LDP peers to also be peers of some other
routing protocol. Also, RSVP-TE may be associated with some TE-based routing protocol. Also, RSVP-TE may be associated with some TE-based
IGP. In some of these cases it would be desirable to use the same IGP. In some of these cases it would be desirable to use the same
authorization information for both routing protocols. authorization information for both routing protocols.
Finally, as discussed in Section 7, it is sometimes desirable to Finally, as discussed in Section 7, it is sometimes desirable to
override some aspect of the configuration for a peer in a group. As override some aspect of the configuration for a peer in a group. As
an example, when rotating to a new key, it is desirable to be able to an example, when rotating to a new key, it is desirable to be able to
roll that key out to each peer that will use the key even if in the roll that key out to each peer that will use the key even if in the
stable state the key is configured for a peer group. stable state the key is configured for a peer group.
skipping to change at page 23, line 28 skipping to change at page 23, line 28
11.2. Informative References 11.2. Informative References
[I-D.ietf-karp-design-guide] [I-D.ietf-karp-design-guide]
Lebovitz, G. and M. Bhatia, "Keying and Authentication for Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", Routing Protocols (KARP) Design Guidelines",
draft-ietf-karp-design-guide-10 (work in progress), draft-ietf-karp-design-guide-10 (work in progress),
December 2011. December 2011.
[I-D.ietf-sidr-rtr-keying] [I-D.ietf-sidr-rtr-keying]
Turner, S., Patel, K., and R. Bush, "Router Keying for Turner, S., Patel, K., and R. Bush, "Router Keying for
BGPsec", draft-ietf-sidr-rtr-keying-01 (work in progress), BGPsec", draft-ietf-sidr-rtr-keying-03 (work in progress),
February 2013. September 2013.
[I-D.liu-ospfv3-automated-keying-req] [I-D.liu-ospfv3-automated-keying-req]
Liu, Y., "OSPFv3 Automated Group Keying Requirements", Liu, Y., "OSPFv3 Automated Group Keying Requirements",
draft-liu-ospfv3-automated-keying-req-01 (work in draft-liu-ospfv3-automated-keying-req-01 (work in
progress), July 2007. progress), July 2007.
[I-D.polk-saag-rtg-auth-keytable] [I-D.polk-saag-rtg-auth-keytable]
Polk, T. and R. Housley, "Routing Authentication Using A Polk, T. and R. Housley, "Routing Authentication Using A
Database of Long-Lived Cryptographic Keys", Database of Long-Lived Cryptographic Keys",
draft-polk-saag-rtg-auth-keytable-05 (work in progress), draft-polk-saag-rtg-auth-keytable-05 (work in progress),
 End of changes. 21 change blocks. 
51 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/