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

  Please consider the comments in the Gen-ART Review from
  Enrico Marocco on 10-May-2010.  The review can be found at:

    http://www.softarmor.com/rai/temp-gen-art/
    draft-ietf-opsec-routing-protocols-crypto-issues-04-marocco.txt

I support Tim's DISCUSSes.

Scenario 1: 
      
      R1 sends an authenticated RIP message to R2 with a cryptographic  
      sequence num X. 
    
      The attacker then needs 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.

Where did the LAN come from?


========


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 a different cost C2, the attacker can replay  
      the captured packet, modifying the source IP to a new  
      arbitrary IP address thereby masquerading as a different router.  
    
      R2 will accept this route and the router as a new gateway, and  
      R2 would then use the non existent router as a next hop for that  
      network. This would only be effective if the cost C1 is less than  
      C2. 

There is surely a simpler attack. 

Attacker replaces R1 with bogus router foo in the original C1 packet, thereby creating an ECMP and causing a black hole for some fraction of the traffic.

=========

o BFD allows a mode called the echo mode. Echo packets are not
  defined in the BFD specification, though they can keep the BFD
  session UP. There are no guidelines on the properties of the echo
  packets. Any security issues in the echo mode or packets will
  directly effect the BFD protocol and session states and hence the
  network stability.

Having spoken to the BFD authors, I find that technically the echo packet can contain anything or nothing. Given the contents aren't evaluated by any device I'm not certain I understand the threat.

The guideline is to use the general format but it isn't strict.

The text should be updated to reflect this.

(a) On discuss issue #1, here are some papers that could be referenced
regarding concerns with SHA-1 and SHA-2:

        Wang, X., et alia, "Finding Collisions in the Full SHA-
        1" Proceedings of Crypto 2005, Lecture Notes in Computer
        Science, Volume 3621, pp. 17-36, Springer-Verlag,
        Berlin, August 31, 2005.

        Praveen Gauravaram, Adrian McCullagh and Ed Dawson,
        "Collision Attacks on MD5 and SHA-1: Is this the 
        'Sword of Damocles' for Electronic Commerce?",
        Information Security Institute (ISI), 
        Queensland University of Technology (QUT) 
        2 George Street, GPO Box 2434, Brisbane,
        Queensland 4001, Australia.

        Philip Hawkes1, Michael Paddon1, and Gregory G. Rose,
        "On Corrective Patterns for the SHA-2 Family",
        Qualcomm Australia, Level 3, 230 Victoria Rd, 
        Gladesville, NSW 2111, Australia

        Arjen K. Lenstra, "Further progress in hashing 
        cryptanalysis", Lucent Bell Laboratories, 
        February 26, 2005

        Praveen Gauravaram, William Millan and Juanma Gonzalez Neito,
        "Some thoughts on Collision Attacks in the Hash Functions 
        MD5, SHA-0 and SHA-1", Information Security Institute (ISI), 
        QUT, Australia. 

The references in RFC 5709 have a few more...

(b) Some of the issues with manual keying are inherently limitations in
the protocols while others are really deployment issues.  Introduction
of key IDs such as in TCP-AO enables out-of-band automated keying as
described in draft-housley-saag-crypto-key-table-02 and
draft-polk-saag-rtg-auth-keytable-02

It might be usueful to review the discussion of manual keying to ensure
that thesdifferent cases are clearly differentiated.

(c) The document uses "digest" and "signature" interchangably,
but actually, those terms are well-defined in cryptography
and have different meanings (and provide different properties).  
Only RFC-2154 provides signatures.  All the other mechanisms 
(e.g. TCP-Auth for BGP, OSPF, RIP, ISIS) simply provide 
cryptographic digests for message origin authentication.