draft-ietf-opsec-igp-crypto-requirements-00.txt   draft-ietf-opsec-igp-crypto-requirements-01.txt 
Internet Draft January 2010 Internet Draft September 2010
Network Working Group Manav Bhatia Network Working Group Manav Bhatia
Internet Draft Alcatel-Lucent Internet Draft Alcatel-Lucent
Expires: July 31, 2010 Vishwas Manral Expires: March 28, 2011 Vishwas Manral
Intended Status: Informational IP Infusion Intended Status: Informational IP Infusion
January 30, 2010 September 27, 2010
Cryptographic Authentication Algorithm Implementation Cryptographic Authentication Algorithm Implementation
Best Practices for Routing Protocols Requirements for Routing Protocols
draft-ietf-opsec-igp-crypto-requirements-00.txt draft-ietf-opsec-igp-crypto-requirements-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with
provisions of BCP 78 and BCP 79. This document may contain material the provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-Drafts
material or to cite them other than as "work in progress." as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 31, 2010. This Internet-Draft will expire on March 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Abstract
The routing protocols Open Shortest Path First version 2 (OSPFv2) The routing protocols Open Shortest Path First version 2 (OSPFv2),
[RFC2328], Intermediate System to Intermediate System (IS-IS) [ISO] Intermediate System to Intermediate System (IS-IS) and Routing
[RFC1195] and Routing Information Protocol (RIP) [RFC2453] currently Information Protocol (RIP) currently define Clear Text and MD5
define Clear Text and MD5 (Message Digest 5) [RFC1321] methods for (Message Digest 5) methods for authenticating protocol packets.
authenticating protocol packets. Recently effort has been made to add Recently effort has been made to add support for the SHA (Secure Hash
support for the SHA (Secure Hash Algorithm) family of hash functions Algorithm) family of hash functions for the purpose of authenticating
for the purpose of authenticating routing protocol packets for RIP routing protocol packets for RIP, IS-IS and OSPF.
[RFC4822], IS-IS [RFC5310] and OSPF [RFC5709].
To encourage interoperability between disparate implementations, it To encourage interoperability between disparate implementations, it
is imperative that we specify the expected minimal set of algorithms is imperative that we specify the expected minimal set of algorithms
thereby ensuring that there is at least one algorithm that all thereby ensuring that there is at least one algorithm that all
implementations will have in common. implementations will have in common.
This document examines the current set of available algorithms with This document examines the current set of available algorithms with
interoperability and effective cryptographic authentication interoperability and effective cryptographic authentication
protection being the principle considerations. Cryptographic protection being the principle considerations. Cryptographic
authentication of these routing protocols requires the availability authentication of these routing protocols requires the availability
of the same algorithms in disparate implementations. It is desirable of the same algorithms in disparate implementations. It is desirable
that newly specified algorithms should be implemented and available that newly specified algorithms should be implemented and available
in routing protocol implementations because they may be promoted to in routing protocol implementations because they may be promoted to
requirements at some future time. requirements at some future time.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. [RFC2119]
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Requirements Terminology.......................................4 2. Intermediate System to Intermediate System (IS-IS).............4
3. Intermediate System to Intermediate System (IS-IS).............4 2.1 Authentication Scheme Selection............................4
3.1 Authentication Scheme Selection............................4 2.2 Authentication Algorithm Selection.........................5
3.2 Authentication Algorithm Selection.........................5 3. Open Shortest Path First Version 2(OSPFv2).....................5
4. Open Shortest Path First Version 2(OSPFv2).....................5 3.1 Authentication Scheme Selection............................5
4.1 Authentication Scheme Selection............................6 3.2 Authentication Algorithm Selection.........................6
4.2 Authentication Algorithm Selection.........................6 4. Open Shortest Path First Version 3 (OSPFv3)....................6
5. Open Shortest Path First Version 3 (OSPFv3)....................6 5. Routing Information Protocol Version 2 (RIPv2).................6
6. Routing Information Protocol Version 2 (RIPv2).................7 5.1 Authentication Scheme Selection............................7
6.1 Authentication Scheme Selection............................7 5.2 Authentication Algorithm Selection.........................7
6.2 Authentication Algorithm Selection.........................7 6. Routing Information Protocol for IPv6 (RIPng)..................8
7. Routing Information Protocol for IPv6 (RIPng)..................8 7. Security Considerations........................................8
8. Security Considerations........................................8 8. Acknowledgements...............................................9
9. Acknowledgements...............................................9 9. IANA Considerations............................................9
10. IANA Considerations...........................................9 10. References....................................................9
11. References....................................................9 10.1 Normative References......................................9
11.1 Normative References......................................9 10.2 Informative References...................................10
11.2 Informative References...................................10
Author's Addresses...............................................10 Author's Addresses...............................................10
1. Introduction 1. Introduction
Most routing protocols include three different types of Most routing protocols include three different types of
authentication schemes: Null authentication, Clear Text Password and authentication schemes: Null authentication, Clear Text Password and
a Cryptographic Authentication scheme. NULL authentication is a Cryptographic Authentication scheme. Null authentication is
equivalent to having no authentication scheme at all. equivalent to having no authentication scheme at all.
In a clear text scheme, also known as, simple password scheme, the In a clear text scheme, also known as, simple password scheme, the
password is exchanged in the clear on the network and anyone with password is exchanged in the clear on the network and anyone with
physical access to the network can learn the password and compromise physical access to the network can learn the password and compromise
the integrity of the routing domain. While the Password scheme the integrity of the routing domain. While the Password scheme
protects from accidental establishment of routing session in a given protects from accidental establishment of routing session in a given
domain, it offers little additional protection. domain, it offers little additional protection.
In a cryptographic authentication scheme, routers share a secret key In a cryptographic authentication scheme, routers share a secret key
which is used to generate a keyed MD5 (or other) digest which is used which is used to generate a message authentication code for each of
for authenticating the protocol packets. the protocol packets. Today, message authentication codes often use
a keyed MD5 digest. The recent escalating series of attacks on MD5
There have been an escalating series of attacks on MD5 which raises raise concerns about its remaining useful lifetime. These attacks may
concerns about the remaining useful lifetime of this hash algorithm. not necessarily result in direct vulnerabilities for keyed MD5
digests as message authentication codes because the colliding message
It should be noted that these attacks may not necessarily result in may not correspond to a syntactically correct protocol packet. There
direct vulnerabilities in Keyed-MD5 as used in the routing protocols is a however a need felt to deprecate MD5 [RFC1321] in favor of
for authentication purposes, because the colliding message may not stronger message authentication code algorithms.
necessarily be a syntactically correct protocol packet. There is a
however a need felt to deprecate MD5 in favor of stronger hash
algorithms.
In light of these considerations there have been proposals for adding In light of these considerations there have been proposals for adding
support of the SHA family of hash algorithms for authenticating support of the SHA [SHS] family of hash algorithms for authenticating
routing protocol packets in RIP, IS-IS and OSPF. routing protocol packets in RIP [RFC2453], IS-IS [ISO] [RFC1195] and
OSPF [RFC2328].
However, the nature of cryptography is that algorithmic However, the nature of cryptography is that algorithmic
improvement is an ongoing process and as is the exploration and improvement is an ongoing process and as is the exploration and
refinement of attack vectors. An algorithm believed to be strong refinement of attack vectors. An algorithm believed to be strong
today may be demonstrated to be weak tomorrow. Given this, the choice today may be demonstrated to be weak tomorrow. Given this, the choice
of preferred algorithm should favor the minimization of the of preferred algorithm should favor the minimization of the
likelihood of it being compromised quickly. likelihood of it being compromised quickly.
It should be recognized that preferred algorithm(s) will change over It should be recognized that preferred algorithm(s) will change over
time in to adapt to the evolving threats. The selection of preferred time to adapt to the evolving threats. The selection of preferred
algorithms may well not be reflected in the base protocol algorithms may well not be reflected in the base protocol
specification. As protocols are extended the preference for presently specification. As protocols are extended the preference for presently
stronger algorithms presents a problem both on the question of stronger algorithms presents a problem both on the question of
interoperability of existing and future implementations with respect interoperability of existing and future implementations with respect
to standards and operational preference for the configuration as to standards and operational preference for the configuration as
deployed. This document intends to provide guidance to implementors deployed. This document intends to provide guidance to implementers
in anticipation of operational preference. in anticipation of operational preference.
2. Requirements Terminology It is expected an implementation should support changing of Security
(Authentication) Keys. Changing Keys periodically is a good security
practice.
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and Implementations can support in-service key change so that no control
"MAY" that appear in this document are to be interpreted as described packets are lost. During such Key change more than one key can be
in RFC2119. [RFC2119] active for receiving packets for a session. Some protocols support
Key ID which allows the two ends of a session to have multiple keys
simultaneously for a session. Key change however is managed outside
the scope of the protocols themselves and can be done manually via
operator intervention, or dynamically based on some timer or a
security protocol.
3. Intermediate System to Intermediate System (IS-IS) 2. Intermediate System to Intermediate System (IS-IS)
The IS-IS specification allows for authentication of its Protocol The IS-IS specification allows for authentication of its Protocol
Data Units (PDUs) via the authentication TLV (TLV 10) in the PDU. The Data Units (PDUs) via the authentication TLV (TLV 10) in the PDU. The
base specification had provisions only for clear text passwords. RFC base specification had provisions only for clear text passwords. RFC
5304 [RFC5304] extends the authentication capabilities by providing 5304 [RFC5304] extends the authentication capabilities by providing
HMAC-MD5 authentication for IS-IS PDUs. HMAC-MD5 authentication for IS-IS PDUs.
RFC 5310 [RFC5310] adds support for the use of SHA family of hash RFC 5310 [RFC5310] adds support for the use of the SHA family of hash
algorithms for authenticating IS-IS PDUs. algorithms for authenticating IS-IS PDUs.
3.1 Authentication Scheme Selection 2.1 Authentication Scheme Selection
In order for IS-IS implementations to interoperate, they must support In order for IS-IS implementations to interoperate with the use of
one or more authentication schemes in common. This section specifies security, they must support one or more authentication schemes in
the preference for standards conformant IS-IS implementations, which common. This section specifies the preference for standards
desire to utilize the security feature. conformant IS-IS implementations, which desire to utilize the
security feature.
The earliest interoperability requirement for authentication as The earliest interoperability requirement for authentication as
stated by [ISO] [RFC1195] required all implementations to support stated by [ISO] [RFC1195] required all implementations to support
Clear Text Password. This authentication scheme's utility is limited Clear Text Password. This authentication scheme's utility is limited
to precluding the accidental introduction of a new IS into a to precluding the accidental introduction of a new IS into a
broadcast domain. We believe that operators should not use this broadcast domain. We believe that operators should not use this
scheme as provides no protection against an attacker with access to scheme as it provides no protection against an attacker with access
the broadcast domain as anyone can determine the secret password to the broadcast domain as anyone can determine the secret password
through inspection of the PDU. It MUST presently be implemented but through inspection of the PDU. This mechanism does not provide any
its use should be deprecated. significant level of security and should be avoided.
[RFC5304] defines HMAC-MD5 implementation as a MUST for
cryptographically authenticating the IS-IS PDUs. HMAC-MD5 is
currently the preferred algorithm for IS-IS deployments and it may
be superseded by the generic cryptographic authentication scheme
defined in [RFC5310]. HMAC-MD5 MUST be implemented, but its use may
be deprecated in future.
IS-IS implementations SHOULD provide support for the generic [RFC5304] mandates the use of HMAC-MD5 for cryptographically
cryptographic authentication scheme [RFC5310] and it is our authenticating the IS-IS PDUs. It is likely that this may get
understanding that interoperability considerations will require deprecated in favor of the generic cryptographic authentication
change to a MUST as operators migrate to this authentication scheme. scheme defined in [RFC5310] in the future deployments, so new
implementations should support this scheme.
3.2 Authentication Algorithm Selection 2.2 Authentication Algorithm Selection
For IS-IS implementations to interoperate, they must have support for For IS-IS implementations to interoperate, they must have support for
one or more authentication algorithms in common. one or more authentication algorithms in common.
This section details the authentication algorithm requirements for This section details the authentication algorithm requirements for
standards conformant IS-IS implementations. standards conformant IS-IS implementations.
HMAC-MD5 is a MUST as defined in [RFC5304]. It is our belief that [RFC5304] mandates the use of HMAC-MD5 for cryptographically
this will be superseded by HMAC-SHA-1 as defined in [RFC5310]. HMAC- authenticating the IS-IS PDUs. It is likely that this may get
MD5 MUST be implemented, but its use may be deprecated in future. deprecated in favor of HMAC-SHA-1 as defined in [RFC5310] in the
Operators should consider migration to HMAC-SHA-1. future deployments, so new implementations should support this
algorithm.
Implementations may start providing support for HMAC-SHA-256/HMAC- Implementations may start providing support for HMAC-SHA-256/HMAC-
SHA-384/HMAC-SHA-512 as these algorithms may be necessary in the SHA-384/HMAC-SHA-512 as these algorithms may be necessary in the
future. future.
4. Open Shortest Path First Version 2(OSPFv2) 3. Open Shortest Path First Version 2(OSPFv2)
OSPFv2 as defined in [RFC2328] includes three different types of OSPFv2 as defined in [RFC2328] includes three different types of
authentication schemes: Null authentication, simple password and authentication schemes: Null authentication, simple password and
cryptographic authentication. NULL authentication is semantically cryptographic authentication. Null authentication is semantically
equivalent to no authentication. In the simple password scheme of equivalent to no authentication. In the simple password scheme of
authentication, the passwords are exchanged in the clear on the authentication, the passwords are exchanged in the clear on the
network. Anyone with physical access to the network can learn the network. Anyone with physical access to the network can learn the
password and compromise the security of the OSPFv2 domain. password and compromise the security of the OSPFv2 domain.
In the cryptographic authentication scheme, the OSPFv2 routers on a In the cryptographic authentication scheme, the OSPFv2 routers on a
common network/subnet are configured with a shared secret which is common network/subnet are configured with a shared secret which is
used to generate a keyed MD5 digest for each packet. A monotonically used to generate a keyed MD5 digest for each packet. A monotonically
increasing sequence number scheme is used to protect against replay increasing sequence number scheme is used to protect against replay
attacks. attacks.
RFC 5709 [RFC5709] adds support for the use of SHA family of hash RFC 5709 [RFC5709] adds support for the use of the SHA family of hash
algorithms for authentication of OSPFv2 packets. algorithms for authentication of OSPFv2 packets.
4.1 Authentication Scheme Selection 3.1 Authentication Scheme Selection
For OSPF implementations to interoperate, they must have one or more For OSPF implementations to interoperate with the use of security,
authentication schemes in common. This section specifies the they must have one or more authentication schemes in common. This
requirements for standards conformant OSPFv2 implementations, which section specifies the preference for standards conformant OSPFv2
desire to utilize the authentication feature. implementations, which desire to utilize the security feature.
Null Authentication is a MUST as defined in [RFC2328], its use is While [RFC2328] mandates the use of NULL Authentication, its use is
deprecated in any context where the operator wishes to authenticate deprecated in any context where the operator wishes to authenticate
the OSPFv2 packets in their network. the OSPFv2 packets in their network.
Simple Password defined as a MUST in [RFC2328] should only be used Similarly Simple Password, also mandatory per [RFC2328], should be
when the operator is seeking only to preclude the accidental used when the operator only wants to preclude the accidental
introduction of a router into the domain. This scheme is not useful introduction of a router into the domain. This scheme is not useful
when the operator wants to authenticate the OSPFv2 packets. when the operator wants to authenticate the OSPFv2 packets.
Cryptographic Authentication is a MUST as defined in [RFC2328] and Cryptographic Authentication is a mandatory scheme as defined in
all conformant implentations MUST support this. [RFC2328] and all conformant implementations must support this.
4.2 Authentication Algorithm Selection 3.2 Authentication Algorithm Selection
For OSPFv2 implementations to interoperate, they must support one or For OSPFv2 implementations to interoperate, they must support one or
more cryptographic authentication algorithms in common. more cryptographic authentication algorithms in common.
Keyed MD5 as defined in [RFC2328] is a MUST. It is our belief that [RFC2328] states that implementations must offer keyed MD5
HMAC-SHA-1 and HMAC-SHA-256 as defined in [RFC5709] will likely be authentication. It is likely that this will be deprecated in favor of
preferred in the future. Keyed MD5 MUST be implemented, but its use HMAC-SHA-1 and HMAC-SHA-256 [RFC5709] in future deployments, so new
may be deprecated in future. Implementations must provide support for implementations should support these algorithms.
HMAC-SHA-256 as this will become the algorithm of choice.
Operators should consider migration to HMAC-SHA-256 if they desire a Operators should consider migration to HMAC-SHA-256 if they desire a
stronger cryptographic algorithm for authentication of OSPFv2 stronger cryptographic algorithm for authentication of OSPFv2
packets. packets.
Implementations may start providing support for HMAC-SHA-1/HMAC-SHA- Implementations may start providing support for HMAC-SHA-1/HMAC-SHA-
384/HMAC-SHA-512 as these algorithms may be preferred in the future. 384/HMAC-SHA-512 [RFC5709] as these algorithms may be preferred in
the future.
5. Open Shortest Path First Version 3 (OSPFv3) 4. Open Shortest Path First Version 3 (OSPFv3)
OSPFv3 [RFC5340] relies on the IPv6 Authentication Header (AH) OSPFv3 [RFC5340] relies on the IPv6 Authentication Header (AH)
[RFC4302] and IPv6 Encapsulating Security Payload (ESP) [RFC4303] in [RFC4302] and IPv6 Encapsulating Security Payload (ESP) [RFC4303] in
order to provide integrity, authentication, and/or confidentiality. order to provide integrity, authentication, and/or confidentiality.
[RFC4522] mandates the use of ESP for authenticating OSPFv3 packets.
The implementations could also provide support for using AH to
protect these packets.
The algorithm requirements for AH and ESP are described in [RFC4835] The algorithm requirements for AH and ESP are described in [RFC4835]
and are not discussed here. and are not discussed here.
6. Routing Information Protocol Version 2 (RIPv2) 5. Routing Information Protocol Version 2 (RIPv2)
RIPv2, originally specified in [RFC1388], then [RFC1723], has been RIPv2, originally specified in [RFC1388], then [RFC1723], has been
finalized in STD56 [RFC2453]. If the Address Family Identifier of the updated and published as STD56 [RFC2453]. If the Address Family
first (and only the first) entry in the message is 0xFFFF, then the Identifier of the first (and only the first) entry in the RIPv2
remainder of the entry contains the authentication. The [RFC2453] message is 0xFFFF, then the remainder of the entry contains the
version of the protocol provides for authenticating packets using a authentication information. The [RFC2453] version of the protocol
simple password of not more than 16 octets, in which the password is provides for authenticating packets using a simple password of not
sent in clear. more than 16 octets, in which the password is sent in clear.
"RIP-2 MD5 Authentication" [RFC2082] added support for Keyed-MD5 "RIP-2 MD5 Authentication" [RFC2082] added support for Keyed-MD5
authentication, where a digest is appended to the end of the RIP authentication, where a digest is appended to the end of the RIP
packet. "RIPv2 Cryptographic Authentication" [RFC4822] obsoleted packet. "RIPv2 Cryptographic Authentication" [RFC4822] obsoleted
[RFC2082] and added the SHA family of hash algorithms to the list of [RFC2082] and added the SHA family of hash algorithms to the list of
cryptographic authentications that can be used to protect RIPv2, cryptographic authentications that can be used to protect RIPv2,
whereas [RFC2082] previously specified only the use of Keyed MD5. whereas [RFC2082] previously specified only the use of Keyed MD5.
6.1 Authentication Scheme Selection 5.1 Authentication Scheme Selection
For RIPv2 implementations to interoperate, one or more authentication
schemes must be supported in common. This section specifies the
requirements for standards conformant RIPv2 implementations, which
utilize the authentication feature.
Simple Password defined as a MUST in [RFC2453] should only be used For RIPv2 implementations to interoperate with the use of security,
when the operator wishes to preclude the accidental introduction of a one or more authentication schemes must be supported in common. This
RIP router into the domain. This authentication scheme is useful, but section specifies the preference for standards conformant RIPv2
not when the operator wants to protect RIPv2 message exchange in a implementations, which desire to utilize the security feature.
potentially hostile environment.
Implementations MUST provide support for Simple Password, but its Simple Password is a mandatory to implement scheme as defined in
operational use is deprecated. [RFC2453] and should only be used when the operator wishes to
preclude the accidental introduction of a RIP router into the domain.
This authentication scheme is useful, but not when the operator wants
to protect RIPv2 message exchange in a potentially hostile
environment.
Keyed-MD5 as defined in [RFC2082] is a MUST. However, [RFC2082] has [RFC2082] mandates the use of Keyed-MD5. However, [RFC2082] has been
been obsoleted by [RFC4822] Cryptographic Authentication. Compliant obsoleted by [RFC4822] Cryptographic Authentication. Compliant
implementations MUST provide support for Keyed-MD5 as described in implementations must provide support for Keyed-MD5 but should
[RFC2082] but should recognize that this is superseded by recognize that this is superseded by Cryptographic Authentication as
Cryptographic Authentication as defined in [RFC4822]. defined in [RFC4822].
Implementations should provide support for [RFC4822] Cryptographic Implementations should provide support for [RFC4822] Cryptographic
Authentication as it will likely be the preferred authentication Authentication as it will likely be the preferred authentication
method in the future. method in the future.
6.2 Authentication Algorithm Selection 5.2 Authentication Algorithm Selection
For RIPv2 implementations to interoperate, one or more authentication For RIPv2 implementations to interoperate, one or more authentication
algorithms must be supported in common that can be used for algorithms must be supported in common that can be used for
authentication. authentication.
The keyed MD5 algorithm in [RFC2082] and [RFC4822] must be The keyed MD5 algorithm in [RFC2082] and [RFC4822] must be
implemented. It is our belief that it will be superseded by HMAC-SHA- implemented. It is our belief that it will be superseded by HMAC-SHA-
1 also available in [RFC4822]. Keyed MD5 MUST be implemented for 1 also available in [RFC4822]. Keyed MD5 must be implemented for
interoperability purposes, but its use may be deprecated in future. interoperability purposes, but its use may be deprecated in the
future.
Implementations should provide support for HMAC-SHA-1 used in Implementations should provide support for HMAC-SHA-1 used in
preference to keyed MD5 the future. preference to keyed MD5 the future.
Operators should consider migration to HMAC-SHA-1 if they want to use Operators should consider migration to HMAC-SHA-1 if they want to use
stronger cryptographic algorithms for authenticating RIPv2 packets. stronger cryptographic algorithms for authenticating RIPv2 packets.
Implementations should consider providing support for HMAC-SHA- Implementations should consider providing support for HMAC-SHA-
256/HMAC-SHA-384/HMAC-SHA-512 as these algorithms may be preferred in 256/HMAC-SHA-384/HMAC-SHA-512 as these algorithms may be preferred in
the future. the future.
7. Routing Information Protocol for IPv6 (RIPng) 6. Routing Information Protocol for IPv6 (RIPng)
RIPng [RFC2080] relies on the IPv6 AH and IPv6 ESP to provide RIPng [RFC2080] relies on the IPv6 AH and IPv6 ESP to provide
integrity, authentication, and/or confidentiality. integrity, authentication, and/or confidentiality.
The algorithm requirements for AH and ESP are described in [RFC4835] The algorithm requirements for AH and ESP are described in [RFC4835]
and are not discussed here. and are not discussed here.
8. Security Considerations 7. Security Considerations
The cryptographic mechanisms referenced in this document provide only The cryptographic mechanisms referenced in this document provide only
authentication algorithms. These algorithms do not provide authentication algorithms. These algorithms do not provide
confidentiality. Encrypting the content of the packet and thereby confidentiality. Encrypting the content of the packet and thereby
providing confidentiality is not considered in the definition of the providing confidentiality is not considered in the definition of the
routing protocols. routing protocols.
The cryptographic strength of the HMAC depends upon the cryptographic The cryptographic strength of the HMAC depends upon the cryptographic
strength of the underlying hash function and on the size and quality strength of the underlying hash function and on the size and quality
of the key. The feasibility of attacking the integrity of routing of the key. The feasibility of attacking the integrity of routing
protocol messages protected by Digests may be significantly more protocol messages protected by Digests may be significantly more
limited than that of other data, however preference for one family of limited than that of other data, however preference for one family of
algorithms over another may also change independently of the algorithms over another may also change independently of the
perceived risk to a particular protocol. perceived risk to a particular protocol.
To ensure greater security, the keys used should be changed To ensure greater security, the keys used should be changed
periodically and implementations MUST be able to store and use more periodically and implementations must be able to store and use more
than one key at the same time. Operational experience suggests that than one key at the same time. Operational experience suggests that
the lack of periodic rekeying is a source of significant exposure and the lack of periodic rekeying is a source of significant exposure and
that the lifespan of shared keys in the network is frequently that the lifespan of shared keys in the network is frequently
measured in years. measured in years.
While simple password schemes are well represented in the document While simple password schemes are well represented in the document
series and in conformant implementations of the protocols, the series and in conformant implementations of the protocols, the
inability to offer either integrity or identity protection are inability to offer either integrity or identity protection are
sufficient reason to strongly discourage their use. sufficient reason to strongly discourage their use.
This document concerns itself with the selection of cryptographic This document concerns itself with the selection of cryptographic
algorithms for use in the authentication of routing protocol packets algorithms for use in the authentication of routing protocol packets
being exchanged between adjacent routing processes. The being exchanged between adjacent routing processes. The
cryptographic algorithms identified in this document are not known to cryptographic algorithms identified in this document are not known to
be broken at the current time, and ongoing cryptographic research so be broken at the current time, and ongoing cryptographic research so
far leads us to believe that they will likely remain secure in the far leads us to believe that they will likely remain secure in the
foreseeable future. We expect that new revisions of this document foreseeable future. We expect that new revisions of this document
will be issued in the future to reflect current thinking on best will be issued in the future to reflect current thinking on the
practice in this area. algorithms various routing protocols should employ to ensure
interoperability between disparate implementations.
9. Acknowledgements 8. Acknowledgements
We would like to thank Joel Jaeggli for this comments and feedback on We would like to thank Joel Jaeggli for this comments and feedback on
this draft that resulted in significant improvement of the same. this draft that resulted in significant improvement of the same.
10. IANA Considerations 9. IANA Considerations
This document places no requests to IANA. This document places no requests to IANA.
11. References 10. References
11.1 Normative References 10.1 Normative References
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998
[ISO] "Intermediate system to Intermediate system routeing [ISO] "Intermediate system to Intermediate system routeing
information exchange protocol for use in conjunction with information exchange protocol for use in conjunction with
the Protocol for providing the Connectionless-mode the Protocol for providing the Connectionless-mode
Network Service (ISO 8473) ", ISO/IEC 10589:1992 Network Service (ISO 8473) ", ISO/IEC 10589:1992
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[RFC2453] Malkin, G., "RIP Version 2", RFC 2453, November 1998 [RFC2453] Malkin, G., "RIP Version 2", RFC 2453, November 1998
[RFC4822] R. Atkinson and M. Fanto, "RIPv2 Cryptographic [RFC4822] R. Atkinson and M. Fanto, "RIPv2 Cryptographic
Authentication", RFC 4822, February 2007 Authentication", RFC 4822, February 2007
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119
[RFC5304] Li, T. and R. Atkinson, "Intermediate System to [RFC5304] Li, T. and R. Atkinson, "Intermediate System to
Intermediate System (IS-IS) Cryptographic Intermediate System (IS-IS) Cryptographic
Authentication", RFC 5304, October 2008 Authentication", RFC 5304, October 2008
[RFC5340] Coltun, R., et. al, "OSPF for IPv6", RFC 5340, July [RFC5340] Coltun, R., et. al, "OSPF for IPv6", RFC 5340, July
2008. 2008.
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation [RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4835, April 2007 Authentication Header (AH)", RFC 4835, April 2007
[RFC2080] Malkin, G. and Minnear, R., "RIPng for IPv6", RFC 2080, [RFC2080] Malkin, G. and Minnear, R., "RIPng for IPv6", RFC 2080,
January 1997 January 1997
[RFC5310] Bhatia, M., et. al., "IS-IS Generic [RFC5310] Bhatia, M., et. al., "IS-IS Generic
Cryptographic Authentication", RFC 5310, February 2009 Cryptographic Authentication", RFC 5310, February 2009
[RFC5709] Bhatia, M., Manral, V., et al., "OSPF HMAC-SHA [RFC5709] Bhatia, M., Manral, V., et al., "OSPF HMAC-SHA
Cryptographic Authentication", RFC 5709, October 2009 Cryptographic Authentication", RFC 5709, October 2009
11.2 Informative References 10.2 Informative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992 1321, April 1992
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005. 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005. 4303, December 2005.
[RFC4522] Gupta, M. and Melam, N.,"Authentication/Confidentiality
for OSPFv3", RFC 4522, June 2006
[RFC1388] Malkin, G., "RIP Version 2 Carrying Additional [RFC1388] Malkin, G., "RIP Version 2 Carrying Additional
Information", RFC 1388, January 1993. Information", RFC 1388, January 1993.
[RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional [RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional
Information", STD 56, RFC 1723, November 1994. Information", STD 56, RFC 1723, November 1994.
[RFC2082] Baker, F. and Atkinson, R., "RIP-2 MD5 [RFC2082] Baker, F. and Atkinson, R., "RIP-2 MD5
Authentication", RFC 2082, January 1997 Authentication", RFC 2082, January 1997
[SHS] National Institute of Standards and Technology (NIST),
FIPS Publication 180-3: Secure Hash Standard, October
2008.
Author's Addresses Author's Addresses
Manav Bhatia Manav Bhatia
Alcatel-Lucent Alcatel-Lucent
Bangalore, India Bangalore, India
Email: manav@alcatel-lucent.com Email: manav.bhatia@alcatel-lucent.com
Vishwas Manral Vishwas Manral
IP Infusion IP Infusion
Almora, Uttarakhand Almora, Uttarakhand
India India
Email: vishwas@ipinfusion.com Email: vishwas@ipinfusion.com
 End of changes. 61 change blocks. 
167 lines changed or deleted 160 lines changed or added

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