Issues with Existing Cryptographic Protection Methods for Routing Protocols
RFC 6039

Note: This ballot was opened for revision 07 and is now closed.

(Jari Arkko) (was Discuss) Yes

Comment (2010-06-03)
No email
send info
The document says:

   [RFC4552] mandates the use of ESP with null encryption
   for authentication and also does encourage the use of confidentiality
   to protect the privacy of the routing information transmitted, using
   ESP encryption.

   Authentication/Confidentiality for OSPFv3 [RFC4552] mandates the use
   of ESP with null encryption for authentication and also does
   encourage the use of confidentiality to protect the privacy of the
   routing information transmitted, using ESP encryption.

In both cases I struggled with the first part of sentence seemingly
claiming that null encryption is mandatory, and then saying non-null
encryption is encouraged. I think you meant to say "The use of
authentication via ESP with null encryption is required and that
additionally, ESP encryption is encouraged to protect the privacy of
the transmitted routing information." Or something along those lines...

The document says:

   With the proliferation of available hash algorithms, as well as the
   need to upgrade the algorithms, manually configuration requires
   coordination among intermediate systems which can become tedious.

I guess this should be ... manual configuration requires ...

The document says:

     Any security issues in the echo mode or packets will
     directly effect the BFD protocol and session states and hence the
     network stability.

This should be ... affect ...

The document says:

     Echo packets are not
     defined in the BFD specification, though they can keep the BFD
     session UP.

No need for upper case UP. This should be "... session up", or "... in the
UP state" (if BFD has such a state).

I would like to voice my support for the change suggested in Lars
Eggert's Discuss.

(Ron Bonica) Yes

(Adrian Farrel) Yes

Comment (2010-06-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Please capture the changes agreed with Young Lee as the result of his
Routing Area Directorate review.

---

Nit

Abstract bullet 2
Begin with "it"
Fix trailing spaces

---

Nit

Section 1 bullet 1
     The implicit trust of routing protocol exchange  
     protected by a shared secret is intended to protect against the  
     injection of falsely generated routing data being injected into  
     the routing system by unauthorized systems. 
A bit garbled. Too much injection!

(Dan Romascanu) Yes

(Stewart Bryant) No Objection

Comment (2010-06-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) (was Discuss) No Objection

(Russ Housley) No Objection

Comment (2010-05-31 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  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

(Tim Polk) (was Discuss) No Objection

Comment (2010-06-03)
No email
send info
(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.

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection

Comment (2010-06-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support Tim's DISCUSSes.