One document matched: draft-manral-rpsec-existing-crypto-04.txt
Differences from draft-manral-rpsec-existing-crypto-03.txt
Internet-Draft Routing Protocol Protection Issues May 2007
Network Working Group Vishwas Manral
Internet-Draft IP Infusion
Expires: November 2007 Russ White
Cisco Systems
Manav Bhatia
Alcatel-Lucent
Issues with existing Cryptographic Protection Methods for Routing
Protocols
draft-manral-rpsec-existing-crypto-04.txt
Status of this Memo
Distribution of this memo is unlimited.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Routing protocols often use cryptographic mechanisms to authenticate
data being received from a neighboring router has not been modified
in transit, and actually originated from the neighboring router
purporting to have originating the data. Most of the cryptographic
mechanisms rely on hash algorithms applied to the data in the routing
protocol packet, which means the data is transported, in the clear,
along with the has signature based on the data itself. These
mechanisms rely on the manual configuration of the keys used to seed,
or build, these hash based signatures. This document outlines some
of the problems with manual keying of these cryptographic algorithms.
Manral, White and Bhatia [Page 1]
Internet-Draft Routing Protocol Protection Issues May 2007
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
1. Problem Statement..............................................2
2. Open Shortest Path First (OSPFv2)..............................3
2.1 Management Issues with OSPF................................4
2.2 Technical Issues with OSPF.................................4
3. Open Shortest Path First (OSPFv3)..............................5
3.1 Management Issues with OSPFv3..............................6
3.2 Technical Issues with OSPFv3...............................6
4. Intermediate System – Intermediate System (IS-IS)..............7
4.1 Management Issues with IS-IS...............................7
4.2 Technical Issues with IS-IS................................8
5. Border Gateway Protocol (BGP)..................................9
5.1 Management Issues with BGP.................................9
5.2 Technical Issues with BGP.................................10
6. The Routing Information Protocol (RIP)........................10
7. Security Considerations.......................................12
8. Acknowledgements..............................................12
9. IANA Considerations...........................................12
10. References...................................................12
10.1 Normative References.....................................12
10.2 Informative References...................................13
11. Contributor's Address........................................14
12. Author's Addresses...........................................14
1. Problem Statement
Routing protocols, such as OSPF [RFC2740] [RFC2328], IS-IS [RFC1195],
and BGP [BGP], rely on various mechanisms to create a cryptographic
digest of each transmitted routing protocol. Generally, these digests
are the results of a hash algorithm, such as [MD5], across the
contents of the packet being transmitted, using a private key as the
hash base (or seed). These digests are recomputed by the receiving
router, using the same key as the originating router used to create
the hash, and compared with the transmitted digest to verify:
o That the router originating this piece of data is authorized to
peer with the local router, and to transmit routing data. This
generally protects against falsely generated routing data being
injected into a routing system by rogue systems.
o That the data has not been changed while transiting between the
two neighboring routers.
Manral, White and Bhatia [Page 2]
Internet-Draft Routing Protocol Protection Issues May 2007
These sorts of authentication methods are not generally used to
protect the confidentiality of information being exchanged between
routers, since this information (entries in the routing table) is
generally freely available in many other context; if anyone has
access to the physical media between two routers exchanging routing
data, they will also probably have other ways to capture or otherwise
discover the contents of the routing tables in those routers.
The main problems with the authentication mechanisms in use today
revolve around:
o Manual configuration of shared secret keys, especially in large
scale networks, poses a major management problem, especially as
there is generally no way to gracefully move from one secret key
to another.
o In some cases, when manual keys are configured, some forms of
replay protection are disabled, allowing the routing protocol to
be attacked.
In fact, the MD5 digest algorithm was not designed to be used in the
way most routing protocols are using it, which can leads to serious
security implications in the future.
A preimage attack would enable someone to find an input message that
causes a hash function to produce a particular output. In contrast, a
collision attack finds two messages with the same hash, but the
attacker can't pick what the hash will be. The collisions against
MD4, MD5,HAVAL-128, and RIPEMD were found by the Chinese researcher
Xiaoyun Wang with co-authors Dengguo Feng, Xuejia Lai, and Hongbo Yu.
The collision vulnerability, does not introduce any obvious or known
attacks on routing protocols. However pre-image attacks could cause
problems.
Protocols themselves have some inbuilt protection against collision
attacks. A lot of values for a lot fields in the protocol are
invalid. For example for OSPF the LSA type can be from 1 to 11. Any
other value in the field will result in the packet being dropped.
Assume two packets M and M' are generated which have the same hash.
The above condition will further reduce the probability of the two
messages also being correct messages from the protocol perspective as
a lot of values are themselves not valid.
2. Open Shortest Path First (OSPFv2)
OSPF [RFC2328] describes the use of an MD5 digest with OSPF packets.
MD5 keys are manually configured. The OSPF packet Header includes an
authentication type field as well as 64-bits of data for use by the
Manral, White and Bhatia [Page 3]
Internet-Draft Routing Protocol Protection Issues May 2007
appropriate authentication scheme. OSPF also provides for a non-
decreasing sequence number to be included in each OSPF protocol
packet to protect against replay attacks.
2.1 Management Issues with OSPF
According to the OSPF specification [RFC2328], digests are applied
to packets transmitted between adjacent neighbors, rather than being
applied to the routing information originated by a router (digests
are not applied at the LSA level, but rather at the packet level).
[RFC2328] states that any set of OSPF routers adjacent across a
single link may use a different key to build MD5 digests than the key
used to build MD5 digests on any other link. Thus, MD5 keys may be
configured, and changed, on a per-link basis in an OSPF network.
OSPF does not specify a mechanisms to negotiate keys, nor does it
specify any mechanism to negotiate the hash algorithms to be used.
With the proliferation of the number of hash algorithms, as well as
the need to continuously upgrade the algorithms, manually configuring
the information becomes very tedious.
2.2 Technical Issues with OSPF
While OSPF provides relatively strong protection through the
inclusion of MD5 signatures, with additional data and sequence
numbers, in transmitted packets, there are still two possible attacks
against OSPF:
o The sequence number is initialized to zero when forming an
adjacency with a newly discovered neighbor, and is also set to
zero whenever the neighbor is brought down. If the
cryptographically protected packets of a router that is brought
down(for administrative or other reasons) are stored by a
malicious router. The new router could replay the packets from
the previous session thus forcing traffic through the malicious
router. Dropping of such packets by the router could result in
blackholes. Also wrongly forwarding packets could result in
routing loops.
o OSPF allows multiple packets with the same sequence number.
This could mean the same packet can be replayed many times before
the next legitimate packet is sent. An attacker may resend the
same packet repeatedly until the next hello packet is transmitted
and received, which means the hello interval determines the attack
window.
o OSPF does not specify the use of any particular hash algorithm,
however the use of only MD5 is specified in the document. Most
OSPF implementations only support MD5.
Manral, White and Bhatia [Page 4]
Internet-Draft Routing Protocol Protection Issues May 2007
Recently, attacks on collision-resistance properties of MD5 and
SHA-1 hash functions have been discovered; [HASH-ATTACK]
summarizes the discoveries. The attacks on MD5 are practical on
any modern computer. For this reason the use of algorithms needs
to be discouraged.
o OSPF on a broadcast network shares the same key between all
neighbors on a broadcast network. Some OSPF packets are sent on
multicast address.
This allows spoofing by any malicious neighbor very easy.
Possession of the key itself is used as an identity check. There
is no other identity check used. A neighbor could send a packet
specifying the packet came from some other neighbor and there
would be no way in which the attacked router could figure out the
identity of the packet sender.
o OSPF neighbors on the broadcast, NBMA and point to multipoint
networks are identified by the IP address in the IP header.
Because the IP header is not covered by the MAC in the
cryptographic authentication scheme as described in RFC 2328, an
attack can be made exploiting this vulnerability.
Assume the following scenario.
R1 sends an authenticated HELLO to R2. This HELLO is captured
and replayed back to R1, changing the source IP in the IP header
to that of R2.
R1 not finding itself in HELLO would deduce that the connection is
not bidirectional and would bring down the adjacency.
3. Open Shortest Path First (OSPFv3)
OSPFv3 [RFC2740] relies on the IP Authentication Header described in
[AH] and the IP Encapsulating Payload described in [ESP] to
cryptographically sign routing information passed between routers.
When using ESP, a null encryption algorithm is used, so the data
carried in the OSPFv3 packets is signed, but not encrypted. This
provides data origin authentication for adjacent routers, and data
integrity which gives the assurance data transmitted by a router has
not changed in transit.
However it does not provide confidentiality of the information
transmitted. [OSPF-AUTH] mandates the use of ESP with null encryption
for authentication and also does encourages the use of
confidentiality to protect the privacy of the routing information
transmitted, using [ESP] encryption.
Manral, White and Bhatia [Page 5]
Internet-Draft Routing Protocol Protection Issues May 2007
[OSPF-AUTH] describes OSPFv3's use of [AH] and [ESP], and specifies
that only manual keying of routing information may be used.
3.1 Management Issues with OSPFv3
[OSPF-AUTH] discusses, at length, the reasoning behind using manually
configured keys, rather than some automated key management protocol
such as [IKE]. The primary problem is that all current key
management mechanisms are designed for one-to-one correlation of
keys, while OSPF adjacencies are formed on a one-to-many basis. This
forces the system administrator to use manually configured SAs and
cryptographic keys to provide the authentication and, if desired,
confidentiality services.
OSPFv3 security document [OSPF-AUTH] states that
As it is not possible as per the current standards to provide
complete replay protection while using manual keying, the proposed
solution will not provide protection against replay attacks.
The primary administrative issue with manually configured SA's and
keys in the OSPFv3 case is the simple management issue of maintaining
matching sets of keys on all routers within a network. [OSPF-AUTH]
does not require that all OSPFv3 routers have the same key configured
for every neighbor, so each set of neighbors connected to a single
link could have a different key configured. While this makes it
easier to change the keys, by forcing the system administrator to
only change the keys on the routers on a single link, the process of
manual configuration for all the routers in a network to change the
keys used for OSPFv3 digests and confidentiality on a periodic basis
can be difficult.
3.2 Technical Issues with OSPFv3
The primary technical concern with the current specifications for
OSPFv3 is that when manual SA and key management is used, [AH]
specifies, in section 3.3.2, Sequence Number Generation: "The sender
assumes anti-replay is enabled as a default, unless otherwise
notified by the receiver (see 3.4.3) or if the SA was configured
using manual key management". Replayed OSPFv3 packets can cause
several failures in a network, including:
o Replaying hello packets with an empty neighbor list can cause all
the neighbor adjacencies with the sending router to be reset,
disrupting network communications.
o Replaying hello packets from early in the designated router
election process on broadcast links can cause all the neighbor
adjacencies with the sending router to be reset, disrupting
network communications.
Manral, White and Bhatia [Page 6]
Internet-Draft Routing Protocol Protection Issues May 2007
o Replaying database description (DB-Description) packets can cause
all FULL neighbor adjacencies with the sending router to be reset,
disrupting network communications.
o Replaying link state request (LS-Request) packets can cause all
FULL neighbor adjacencies with the sending router to be reset,
disrupting network communications.
o Capturing a full adjacency process (from two-way all the way to
FULL state), and then replaying this process when the router is no
longer attached can cause a false adjacency to be formed, allowing
an attacker to attract and black hole traffic.
o OSPFv3 on a broadcast network shares the same key between all
neighbors on a broadcast network. Some OSPF packets are sent on
multicast address.
This allows spoofing by any malicious neighbor very easy.
Possession of the key itself is used as an identity check. There
is no other identity check used. A neighbor could send a packet
specifying the packet came from some other neighbor and there
would be no way in which the attacked router could figure out the
identity of the packet sender.
4. Intermediate System – Intermediate System (IS-IS)
IS-IS [RFC1195] uses HMAC-MD5 authentication with manual keying, as
described in [RFC3567]. There is no provision within IS-IS to
encrypt the body of a routing protocol message.
4.1 Management Issues with IS-IS
[RFC3567] states that each LSP generated by an intermediate system is
signed with the HMAC-MD5 algorithm using a key manually defined by
the network administrator. Since authentication is performed on the
LSPs transmitted by an intermediate system, rather than on the
packets transmitted to a specific neighbor, it is implied that all
the intermediate systems within a single flooding domain must be
configured with the same key for authentication to work correctly.
The initial configuration of manual keys for authentication within an
IS-IS network is simplified by a state where LSPs containing HMAC-MD5
authentication TLVs are accepted, but the digest is not validated.
Once an initial set of keys are configured on all routers, however,
changing those keys becomes much more difficult.
IS-IS [RFC1195] does not specify a mechanisms to negotiate keys, nor
does it specify any mechanism to negotiate the hash algorithms to be
used.
With the proliferation of the number of hash algorithms, as well as
Manral, White and Bhatia [Page 7]
Internet-Draft Routing Protocol Protection Issues May 2007
the need to continuously upgrade the algorithms, manually configuring
the information becomes very tedious.
4.2 Technical Issues with IS-IS
[RFC3567] states: "This mechanism does not prevent replay attacks,
however, in most cases, such attacks would trigger existing
mechanisms in the IS-IS protocol that would effectively reject old
information." The few case where existing mechanisms in the IS-IS
protocol would not effectively reject old information is the case of
the hello packets (IIHs) used to discover neighbors and SNP packets.
As described in IS-IS [RFC1195], a list of known neighbors is
included in each hello transmitted by an intermediate system, to
ensure two-way communications with any specific neighbor before
exchanging link state databases.
IS-IS does not provide a sequence number. Hence IS-IS packets are
liable to replay attacks. As any packet can be replayed at any point
of time, as long as the keys used are the same.
A hello packet containing a digest within a TLV, and an empty
neighbor list, could be replayed, causing all adjacencies with the
original transmitting intermediate system to be restarted.
A replay of an old CSNP packets could cause LSP's to be flooded, thus
causing an LSP storm.
IS-IS specifies the use of the hash algorithm HMAC-MD5 to protect
IS-IS PDU's.
IS-IS does not have a notion of Key ID. During Key rollover, each
message received has to be checked for integrity against all keys
that are valid. A DoS attack may be caused by sending IS-IS packets
with random hashes. This will cause the IS-IS packet to be checked
for authentication, with all possible keys. Thus increasing the
amount of processing required.
Recently, attacks on collision-resistance properties of MD5 and SHA-1
hash functions have been discovered; [HASH-ATTACK] summarizes the
discoveries. The attacks on MD5 are practical on any modern computer.
For this reason the use of algorithms needs to be discouraged.
HMAC's are not susceptible to any known collision-reduction attack.
However IS-IS should provide a way to upgrade to other stronger
algorithms.
IS-IS on a broadcast network shares the same key between all
neighbors on a broadcast network. Some IS-IS PDU's are sent on link-
layer multicast address.
Manral, White and Bhatia [Page 8]
Internet-Draft Routing Protocol Protection Issues May 2007
This makes spoofing by any malicious neighbor very easy. Possession
of the key itself is used as an identity check. There is no other
identity check used. A neighbor could send a packet specifying the
packet came from some other neighbor and there would be no way in
which the attacked router could figure out the identity of the packet
sender.
As the lifetime is not covered in the authentication, an ISIS router
can receive its own self generated LSP segment with zero lifetime
remaining. In that case, if it has a copy with non zero life time,
then it purges the LSP i.e. it increments the current sequence number
and floods *all* the segments again. Its much worse in ISIS, as there
exists only one LSP (other than the pseudonode LSPs for the LANs on
which its the DIS).
This way you force the router to flood all segments, which can be
quite a lot if the number of routes is large. It also causes the
sequence number of all the LSPs to increase fast. If the sequence
number increases to the maximum (0xFFFFFFFF), the IS-IS process must
shut down for at around 20+ minutes (MaxAge + ZeroAgeLifetime) to
allow the old LSPs to age out of all the router databases.
5. Border Gateway Protocol (BGP)
BGP uses TCP [RFC0793] for transporting routing information between
BGP speakers which have formed an adjacency, as described in
[RFC2385], with suggestions for choosing MD5 keys described in
[RFC3562].
It is common to use the TCP MD5 signature option as described in
[RFC2385] for providing data origin authentication and data integrity
protection of these BGP packets. with suggestions for choosing MD5
key length described in [RFC3562]. There is no provision for
confidentiality for any of these BGP messages.
This problem is made worse by the nature of the environment where BGP
is typically used, between autonomous networks (under different
administrative control). While routers running interior gateway
protocols may all be configured using the same keys, and have their
key rollover policies coordinated or set by the same administrative
authority, two BGP peering BGP speakers may be in different
administrative domains, with different policies for key strength,
rollover times, etc. An autonomous system must often support a large
number of keys on different BGP borders, since each connecting AS
represents a different administrative entity.
5.1 Management Issues with BGP
Each pair of BGP speakers forming an adjacency may have a different
MD5 shared key, facilitating the configuration and changing of keys
Manral, White and Bhatia [Page 9]
Internet-Draft Routing Protocol Protection Issues May 2007
across a large scale network. Manual configuration and maintenance
of cryptographic keys on all routers is a challenge in any large
scale environment, however. Most BGP implementations will accept BGP
packets with a bad digest for the hold interval negotiated between
BGP peers at peering startup, allowing MD5 keys to be changed without
impacting the operation of the network. This technique does,
however, allow some short period of time during which an attacker may
inject BGP packets with false MD5 digests into the network, and can
expect those packets to be accepted, even though their MD5 digests
are not valid.
5.2 Technical Issues with BGP
Since BGP relies on TCP [RFC0793] for transporting data between BGP
speakers, BGP can rely on TCP's protections against data corruption
and replay to prevent replay attacks against BGP sessions. A great
deal of research has gone into the difficulty or ease with which an
attacker can overcome these protections, including [TCP-WINDOW] and
[BGP-ATTACK]. Most implementations of BGP have modified their TCP
implementations to resolve the security vulnerabilities described in
these references, where possible.
However, as mentioned earlier, MD5 is vulnerable to collision
attacks, and can be attacked through several means, such as those
explored in [MD5-ATTACK].
Though it is can be argued that the collision attacks do not have a
practical implication in this scenario, the use of MD5 is
discouraged.
Routers performing cryptographic processing of packets in software
may be easier to attack. An attacker may be able to transmit enough
traffic with false digests to a router that the router's processor
and memory resources are consumed, causing the router to be unable to
perform normal processing. This is particularly problematic at
connections to devices not under local administrative control.
6. The Routing Information Protocol (RIP)
RIP [RFC1058] does not provide for any authentication or
authorization of routing data, and thus is vulnerable to any of the
various attacks against routing protocols.
RIPv2 [RFC1388, RFC1723] provides for authenticating packets by
carrying a digest. The information is there in RIP-2 MD5
Authentication [RFC2082]. [RFC4822] obsoletes [RFC2082] and adds
details of how the SHA family of hash algorithms can be used with
RIPv2 Cryptographic Authentication, whereas [RFC2082] only specified
the use of Keyed-MD5.
Manral, White and Bhatia [Page 10]
Internet-Draft Routing Protocol Protection Issues May 2007
o The sequence number is initialized to zero, at the beginning of
time, and is also set to zero whenever the neighbor is brought
down. If the cryptographically protected packets of a router that
is brought down (for administrative or other reasons) are stored
by a malicious router. The new router could replay the packets
from the previous session thus forcing traffic through the
malicious router. Dropping of such packets by the router could
result in blackholes. Also wrongly forwarding packets could
result in routing loops.
o RIPv2 allows multiple packets with the same sequence number.
This could mean the same packet can be replayed many times before
the next legitimate packet is sent. An attacker may resend the
same packet repeatedly until the next hello packet is transmitted
and received, which means the hello interval determines the attack
window.
o RIPv2 does not specify the use of any particular hash algorithm,
RIP implementations only support MD5. MD5 is vulnerable to
attacks.
o RIPv2 cryptographic authentication as defined in RFC 4822 doesn’t
cover the UDP and the IP headers. Its thus possible for an
attacker to modify the fields in the above headers without any of
the routers getting to know about it.
There isn't much that can be done by modifying the UDP header as
RIP only uses it to compute the length of the RIP packet. Any
changes introduced in the UDP header would fail the RIP
authentication, and this attack will thus, not work.
However, RIP uses the source IP address from the IP header to
determine the RIP neighbor from which its learnt the RIP Updates.
This can be used by an attacker to disrupt the RIP routing
Sessions between two routers R1 and R2, as shown in the following
examples:
Scenario 1:
R1 sends an authenticated RIP message to R2 with a cryptographic
sequence num X.
The attacker merely needs get hold of a higher sequence number
packet from the LAN. It could also be a packet originated by R2
either from this session, or from some earlier session.
The attacker can then replay this packet to R2 by changing the
source IP to that of R1.
R2 would now no longer accept any more RIP Updates from R1 as
Manral, White and Bhatia [Page 11]
Internet-Draft Routing Protocol Protection Issues May 2007
those would have a lower cryptographic sequence number. After 180
secs (or less), R2 would time out R1 and bring down the RIP
session.
Scenario 2:
R1 announces a route with cost C1 to R2. This packet can be
captured by an attacker. Later, if this cost changes and R1
announces this with some other cost C2, the attacker can replay
the captured packet by modifying the source IP to some new
arbitrary IP address. It can this way masquerade as some other
router.
R2 will accept this route and the router as a new gateway, and
would use the non existent router as a nexthop for that network.
This would obviously only work if C1 < C2.
7. Security Considerations
This draft outlines security issues arising from the manual keying of
cryptographic keys for various routing protocols. No changes to any
protocols are proposed in this draft, and no new security
requirements result.
8. Acknowledgements
We would like to acknowledge Sam Hartman, Ran Atkinson, Steve Kent
and Brian Wies for their initial comments on this draft. Merike Kaeo
reviewed many sections of the draft and gave a lot of useful
comments.
9. IANA Considerations
This document places no requests to IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
10. References
10.1 Normative References
[AH] Kent, S., "IP Authentication Header",
RFC 4302, December 2005.
[BGP] Rekhter , Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
Manral, White and Bhatia [Page 12]
Internet-Draft Routing Protocol Protection Issues May 2007
[OSPF-AUTH] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, January 2006
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
June 1988.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC1388] Malkin, G., "RIP Version 2 Carrying Additional
Information", RFC 1388, January 1993.
[RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional
Information", STD 56, RFC 1723, November 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
[RFC3567] Li, T. and R. Atkinson, "Intermediate System to
Intermediate System (IS-IS) Cryptographic
Authentication", RFC 3567, July 2003.
[RFC2082] F. Baker and R. Atkinson, "RIP-2 MD5 Authentication", RFC
2082, January 1997
[RFC4822] R. Atkinson and M. Fanto, "RIPv2 Cryptographic
Authentication", RFC 4822, February 2007
10.2 Informative References
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992
[BGP-ATTACK] Convery, S. and M. Franz, "BGP Vulnerability Testing:
Separating Fact from FUD v1.00", June 2003.
[TCP-WINDOW] Watson, T., "TCP Reset Spoofing", October 2003.
Manral, White and Bhatia [Page 13]
Internet-Draft Routing Protocol Protection Issues May 2007
[HASH-ATTACK] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
Hashes in Internet Protocols", RFC4270, November 2005.
[MD5-ATTACK] Wang, X. et al., "Collisions for Hash Functions MD4,
MD5, HAVAL-128 and RIPEMD", August 2004,
http://eprint.iacr.org/2004/199
[RFC3562] Leech, M., "Key Management Considerations for the TCP
MD5 Signature Option", RFC 3562, July 2003.
[IKE] Kaufman, C., "The Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005
11. Contributor's Address
Sue Hares
NextHop
USA
Email: shares@nexthop.com
12. Author's Addresses
Manav Bhatia
Alcatel-Lucent
Bangalore, India
Email: manav@alcatel-lucent.com
Vishwas Manral
IP Infusion
Almora, Uttarakhand
India
Email: vishwas@ipinfusion.com
Russ White
Cisco Systems
RTP North Carolina
USA
Email: riw@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
Manral, White and Bhatia [Page 14]
Internet-Draft Routing Protocol Protection Issues May 2007
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Manral, White and Bhatia [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-21 07:39:58 |