RFC 6039: Issues with Existing Cryptographic Protection Methods for Routing Protocols
In plain English — editorial summary, not part of the RFC
Routing protocols have been extended over time to use cryptographic mechanisms to ensure that data received from a neighboring router has not been modified in transit and actually originated from an authorized neighboring router. The cryptographic mechanisms defined to date and described in this document rely on a digest produced with a hash algorithm applied to the payload encapsulated in the routing protocol packet. This document outlines some of the limitations of the current mechanism, problems with manual keying of these cryptographic algorithms, and possible vectors for the exploitation of these limitations. This document is not an Internet Standards Track specification; it is published for informational purposes.
Document record
- Document ID
- RFC6039
- Published
- October 2010
- Authors
- V. Manral; M. Bhatia; J. Jaeggli; R. White
- Status
- INFORMATIONAL
- Stream
- IETF
- Area
- ops
- Pages
- 21
- Also known as
- —
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 6038Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size FeaturesCurrent
October 2010
- RFC 6036Emerging Service Provider Scenarios for IPv6 DeploymentObsoleted
October 2010
- RFC 6034Unicast-Prefix-Based IPv4 Multicast AddressesCurrent
October 2010
- RFC 6049Spatial Composition of MetricsUpdated
January 2011
- RFC 6022YANG Module for NETCONF MonitoringCurrent
October 2010
- RFC 6021Common YANG Data TypesObsoleted
October 2010
- RFC 6020YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)Updated
October 2010
- RFC 6076Basic Telephony SIP End-to-End Performance MetricsCurrent
January 2011
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?