draft-ietf-karp-ops-model-03.txt   draft-ietf-karp-ops-model-04.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 13, 2013 Huawei Expires: April 25, 2013 Huawei
July 12, 2012 October 22, 2012
Operations Model for Router Keying Operations Model for Router Keying
draft-ietf-karp-ops-model-03.txt draft-ietf-karp-ops-model-04.txt
Abstract Abstract
Developing an operational and management model for routing protocol Developing an operational and management model for routing protocol
security that works across protocols will be critical to the success security that works across protocols will be critical to the success
of routing protocol security efforts. This document discusses issues of routing protocol security efforts. This document discusses issues
and begins to consider development of these models. 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 13, 2013. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 22 skipping to change at page 2, line 22
3.3. Interactions with Automated Key Management . . . . . . . . 7 3.3. Interactions with Automated Key Management . . . . . . . . 7
3.4. VRFs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. VRFs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Credentials and Authorization . . . . . . . . . . . . . . . . 8 4. Credentials and Authorization . . . . . . . . . . . . . . . . 8
4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 11 4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 11
4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 11 4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 11
4.4. The role of Central Servers . . . . . . . . . . . . . . . 12 4.4. The role of Central Servers . . . . . . . . . . . . . . . 12
5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 13 5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 13
6. Administrator Involvement . . . . . . . . . . . . . . . . . . 15 6. Administrator Involvement . . . . . . . . . . . . . . . . . . 15
6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 15 6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 16
7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 17 7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
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 15, line 38 skipping to change at page 15, line 38
secure environment where keys can be generated, and public keys secure environment where keys can be generated, and public keys
copied to a management server to push out the new public key to copied to a management server to push out the new public key to
potential peers. Then, the router needs to be packaged, moved to potential peers. Then, the router needs to be packaged, moved to
where it will be deployed and set up.Alternatives are possible; it is where it will be deployed and set up.Alternatives are possible; it is
critical that we understand how what we propose impacts operators. critical that we understand how what we propose impacts operators.
We need to work through examples with operators familiar with We need to work through examples with operators familiar with
specific real-world deployment practices and understand how proposed specific real-world deployment practices and understand how proposed
security mechanisms will interact with these practices. security mechanisms will interact with these practices.
Initial discussions suggest that this will be one more configuration
item that needs to be set up to establish service. There is no
significant security value in protecting routing protocol keys more
than administrative password or Authentication, Authorization and
Accounting (AAA) secrets that can be used to gain login access to a
router. These existing secrets can be used to make configuration
changes that impact routing protocols as much as disclosure of a KARP
key. Operators already have procedures in place for these items.
So, it is appropriate to use similar procedures for KARP. It is
reasonable to improve these procedures and the KARP-related
procedures over time. However it is more desirable to deploy KARP
with security similar to that used for managing existing secrets than
to delay deploying KARP.
Operators that have existing procedures for managing hardware
encryption devices such as VPN gateways MAY use those procedures for
managing KARP keys. This MAY be used for example if cost savings in
terms of training and auditing justify the re-use of a procedure.
6.2. Handling Faults 6.2. Handling Faults
Faults may interact with operational practice in at least two ways. Faults may interact with operational practice in at least two ways.
First, security solutions may introduce faults. For example if First, security solutions may introduce faults. For example if
certificates expire in a PKI, previous adjacencies may no longer certificates expire in a PKI, previous adjacencies may no longer
form. Operational practice will require a way of repairing these form. Operational practice will require a way of repairing these
errors. This may end up being very similar to deploying a router errors. This may end up being very similar to deploying a router
that is connecting a new site as the security fault may have that is connecting a new site as the security fault may have
partitioned the network. However, unlike a new deployment, the event partitioned the network. However, unlike a new deployment, the event
is unplanned. Strategies such as configuring a router and shipping is unplanned. Strategies such as configuring a router and shipping
skipping to change at page 16, line 21 skipping to change at page 16, line 40
still have adequate operational mechanisms to recover from these still have adequate operational mechanisms to recover from these
situations. Also, some faults, such as those resulting from a situations. Also, some faults, such as those resulting from a
compromise or actual attack on a facility are inherent and may not be compromise or actual attack on a facility are inherent and may not be
prevented. prevented.
A second class of faults is equipment faults that impact security. A second class of faults is equipment faults that impact security.
For example if keys are stored on a router and never moved from that For example if keys are stored on a router and never moved from that
device, failure of a router implies a need to update security device, failure of a router implies a need to update security
provisioning on the replacement router and its peers. provisioning on the replacement router and its peers.
To address these operational considerations, we should identify One approach, recommended by work on securing BGP
circumstances surrounding recovery from today's faults and understand [I-D.ietf-sidr-rtr-keying] is to maintain the router's keying
how protocols will impact mechanisms used today. material. One option is to maintain a copy of the router's keys near
the router. For example, keys cys could be maintained on a USB
storage driver. Another approach is to maintain router keys on a
central server. These approaches permit the credentials of a router
to be recovered. This provides valuable options in case of hardware
fault. The failing router can be recovered without changing
credentials on other routers. One disadvantage of this approach is
that even if public-key cryptography is used, the private keys still
need to leave the router. Exporting private keys increases the
chance that an attacker may be able to impersonate a router. In many
environments favoring the ability to quickly replace a router makes
sense.
More generally keying is another item of configuration that needs to
be restored to restore service when equipment fails. Operators
typically perform the minimal configuration necessary to get a router
back in contact with the management server. The same would apply for
keys. Operators who do not maintain copies of key material for
performing key recovery on routers would need to perform a bit more
work to regain contact with the management server. It seems
reasonable to assume that management servers will be able to cause
keys to be generated or distributed sufficiently to fully restore
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 complexity of and
skipping to change at page 17, line 25 skipping to change at page 18, line 25
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.
The situation is more complex for organizations that have not
upgraded from TCP MD5 [RFC2385] to the TCP Authentication Option
[RFC5925]. Today, routers typically need to understand whether a
given peer supports TCP MD5 or TCP-AO before opening a TCP
connection. In addition, many implementations support grouping
configuration of related peers including security configuration
together. Implementations make it challenging to move from TCP-MD5
to TCP-AO before all peers in the group are ready. Operators
perceive it as high risk to update the configuration of a large
number of peers. One particularly risky situation is upgrading the
configuration of iBGP peers.
The situation is more complicated for multicast protocols. It's The situation is more complicated for multicast protocols. It's
probably not reasonable to bring down an entire link to reconfigure probably not reasonable to bring down an entire link to reconfigure
it as using automated key management. Two approaches should be it as using automated key management. Two approaches should be
considered. One is to support key table rows supporting the considered. One is to support key table rows supporting the
automated key management and manually configured keying for the same automated key management and manually configured keying for the same
link at the same time. Coordinating this may be tricky. Another link at the same time. Coordinating this may be tricky. Another
possibility is for the automated key management protocol to actually possibility is for the automated key management protocol to actually
select the same traffic key that is being used manually. This could select the same traffic key that is being used manually. This could
potentilaly be accomplished by having an option in the key management potentilaly be accomplished by having an option in the key management
protocol to export the current manual group key through the automated protocol to export the current manual group key through the automated
skipping to change at page 19, line 9 skipping to change at page 20, line 9
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.
9. Acknowledgments 9. 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 Gregory Lebovitz, Russ White and Bill The authors would like to thank Bill Atwood , Randy Bush, Wes George,
Atwood for valuable reviews. Gregory Lebovitz, and Russ White for valuable reviews.
10. References 10. References
10.1. Normative References 10.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-03 (work in progress), draft-ietf-karp-crypto-key-table-03 (work in progress),
June 2012. June 2012.
skipping to change at page 20, line 26 skipping to change at page 21, line 26
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References 10.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]
Turner, S., Patel, K., and R. Bush, "Router Keying for
BGPsec", draft-ietf-sidr-rtr-keying-00 (work in progress),
May 2012.
[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),
November 2010. November 2010.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006. Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5",
RFC 4808, March 2007. RFC 4808, March 2007.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010. Authentication Option", RFC 5925, June 2010.
 End of changes. 10 change blocks. 
17 lines changed or deleted 78 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/