The IESG has approved the following document: - 'Issues with existing Cryptographic Protection Methods for Routing Protocols' <draft-ietf-opsec-routing-protocols-crypto-issues-07.txt> as an Informational RFC This document is the product of the Operational Security Capabilities for IP Network Infrastructure Working Group. The IESG contact persons are Ron Bonica and Dan Romascanu. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-opsec-routing-protocols-crypto-issues/ Technical Summary Routing protocols have over time been extended to use cryptographic mechanisms to validate data being received from a neighboring router to ensure that: o it has not been modified in transit. o 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. Working Group Summary Significant effort was made to find this document a home, and in that process the document was widely socialised. Working group consensus is strongly in favor of recommending that existing routing protocols be updated to support new cryptographic algorithms and methods where feasible. I believe that this is consistent with several conclusions of RFC 4948 whilst obviously not being a complete solution to the problems described there. As demonstrated by the karp BOF discussion and draft-lebovitz-karp-roadmap, follow up work beyond this document is already underway. Document Quality The authors and working group participants believe that the document adequately conveys concerns regarding existing cryptographic protection methods for the routing control-plane. Efforts are already underway to address these issues and documentation of solutions will likely occur in a number of subject areas touched on by the document. Personnel I (Joe Abley) am the document shepherd for draft-ietf-opsec-routing-protocols-crypto-issues. I have personally reviewed draft-ietf-opsec-routing-protocols-crypto-issues-03 and as far as technical content is concerned I believe this version is ready for publication. (There are grammatical, spelling and typographical nits, but nothing that the RFC Editor can't handle.) RFC Editor Note (1) Section 1.1 OLD 1.1 MD5 Pre-Image vs Collision Attacks NEW 1.1 Pre-Image vs. Collision Attacks (2) Section 6.1, bullet 3 OLD o RIPv2 [RFC2453] does not specify the use of any particular hash algorithm. Currently, RIP implementations support keyed MD5 [RFC2082] and [RFC4822] adds support for using HMAC-SHA for RIP. NEW o RIPv2 [RFC2453] did not specify the use of any particular hash algorithm. RFC 4822 introduced HMAC-SHA1 as mandatory to implement, along with keyed MD5 as specified in [RFC 2082]. Support for keyed MD5 was mandated to ensure compatibility with legacy implementations. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
