draft-ietf-karp-ops-model-07.txt   draft-ietf-karp-ops-model-08.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: January 6, 2014 Huawei Expires: March 3, 2014 Huawei
July 5, 2013 August 30, 2013
Operations Model for Router Keying Operations Model for Router Keying
draft-ietf-karp-ops-model-07.txt draft-ietf-karp-ops-model-08.txt
Abstract Abstract
Developing an operational and management model for routing protocol Developing an operational and management model for routing protocol
security that works with all the routing protocols will be critical security that works with all the routing protocols will be critical
to the success of routing protocol security efforts. This document to the success of routing protocol security efforts. This document
discusses issues and begins to consider development of these models. discusses issues and begins to consider development of these models.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 January 6, 2014. This Internet-Draft will expire on March 3, 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 2, line 26 skipping to change at page 2, line 26
4.1.1. Sharing Keys and Zones of Trust . . . . . . . . . . . 10 4.1.1. Sharing Keys and Zones of Trust . . . . . . . . . . . 10
4.1.2. Key Separation and Protocol Design . . . . . . . . . . 11 4.1.2. Key Separation and Protocol Design . . . . . . . . . . 11
4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 11 4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 11
4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 12 4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 12
4.4. The role of Central Servers . . . . . . . . . . . . . . . 12 4.4. The role of Central Servers . . . . . . . . . . . . . . . 12
5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 14 5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 14
6. Administrator Involvement . . . . . . . . . . . . . . . . . . 16 6. Administrator Involvement . . . . . . . . . . . . . . . . . . 16
6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 16 6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 16
7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 18 7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The KARP working group is designing improvements to the cryptographic The KARP working group is designing improvements to the cryptographic
authentication of IETF routing protocols. These improvements include authentication of IETF routing protocols. These improvements include
improvements to how integrity functions are handled within each improvements to how integrity functions are handled within each
protocol as well as designing an automated key management solution. 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
skipping to change at page 4, line 5 skipping to change at page 3, line 27
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 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
other security domains. routers need to function in order to
establish network connectivity. As a result, centralized services
cannot typically be used for authentication or other security tasks;
see Section 4.4. In addition, routers' roles affect how new routers
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
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.
skipping to change at page 18, line 13 skipping to change at page 18, line 13
service. service.
7. Upgrade Considerations 7. Upgrade Considerations
It needs to be possible to deploy automated key management in an It needs to be possible to deploy automated key management in an
organization without either having to disable existing security or organization without either having to disable existing security or
disrupting routing. As a result, it needs to be possible to perform disrupting routing. As a result, it needs to be possible to perform
a phased upgrade from manual keying to automated key management. a phased upgrade from manual keying to automated key management.
This upgrade procedure needs to be easy and have a very low risk of This upgrade procedure needs to be easy and have a very low risk of
disrupting routing. Today, many operators do not update keys because disrupting routing. Today, many operators do not update keys because
the perceived risk of an attack is lower than the complexity of and the perceived risk of an attack is lower than the cost of an update
update and risk of routing disruptions. combined with the potential cost of routing disruptions during the
update. Even when a routing protocol has technical mechanisms that
permit an update with no disruption in service, there is still a
potential cost of service disruptions as operational procedures and
practices need to correctly use the technical mechanisms.
For peer-to-peer protocols such as BGP, this can be relatively easy. For peer-to-peer protocols such as BGP, this can be relatively easy.
First, code that supports automated key management needs to be loaded First, code that supports automated key management needs to be loaded
on both peers. Then the adjacency can be upgraded. The on both peers. Then the adjacency can be upgraded. The
configuration can be updated to switch to automated key management configuration can be updated to switch to automated key management
when the second router reboots. Alternatively, if the key management when the second router reboots. Alternatively, if the key management
protocols involved can detect that both peers now support automated protocols involved can detect that both peers now support automated
key management, then a key can potentially be negotiated for an key management, then a key can potentially be negotiated for an
existing session. existing session.
skipping to change at page 20, line 5 skipping to change at page 20, line 11
removed will generate a new fresh key. Group key management removed will generate a new fresh key. Group key management
protocols are RECOMMENDED to support an option to export existing protocols are RECOMMENDED to support an option to export existing
manual keys during initial deployment of automated key management. manual keys during initial deployment of automated key management.
8. Security Considerations 8. Security Considerations
This document does not define a protocol. It does discuss the This document does not define a protocol. It does discuss the
operational and management implications of several security operational and management implications of several security
technologies. technologies.
Close synchronization of time can impact the security of routing
protocols in a number of ways. Time is used to control when keys MAY
begin being used and when they MUST NOT be used any longer as
described in [I-D.ietf-karp-crypto-key-table]. Routers need to have
tight enough time synchronization that receivers permit a key to be
utilized for validation prior to the first use of that key for
generation of integrity-protected messages or availability will be
impacted. If time synchronization is too loose, then a key can be
used beyond its intended lifetime. The Network Time Protocol (NTP)
can be used to provide time synchronization. For some protocols,
time synchronization is also important for replay detection.
9. IANA Considerations 9. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
10. Acknowledgments 10. Acknowledgments
Funding for Sam Hartman's work on this memo is provided by Huawei. Funding for Sam Hartman's work on this memo is provided by Huawei.
The authors would like to thank Bill Atwood , Randy Bush, Wes George, The authors would like to thank Bill Atwood , Randy Bush, Wes George,
Gregory Lebovitz, and Russ White for valuable reviews. Gregory Lebovitz, and Russ White for valuable reviews.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-karp-crypto-key-table] [I-D.ietf-karp-crypto-key-table]
Housley, R., Polk, T., Hartman, S., and D. Zhang, Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys", "Database of Long-Lived Symmetric Cryptographic Keys",
draft-ietf-karp-crypto-key-table-07 (work in progress), draft-ietf-karp-crypto-key-table-08 (work in progress),
March 2013. July 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
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),
 End of changes. 8 change blocks. 
15 lines changed or deleted 38 lines changed or added

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