Issues with Existing Cryptographic Protection Methods for Routing Protocols
draft-ietf-opsec-routing-protocols-crypto-issues-07

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>,
    opsec mailing list <opsec@ietf.org>,
    opsec chair <opsec-chairs@tools.ietf.org>
Subject: Document Action: 'Issues with existing Cryptographic Protection Methods for Routing Protocols' to Informational RFC

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/

Ballot Text

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.

RFC Editor Note