Issues with Existing Cryptographic Protection Methods for Routing Protocols
RFC 6039
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
Lars Eggert (was Discuss) No Objection
(Adrian Farrel; former steering group member) Yes
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; former steering group member) Yes
(Jari Arkko; former steering group member) (was Discuss) Yes
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; former steering group member) Yes
(Gonzalo Camarillo; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
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
(Sean Turner; former steering group member) No Objection
I support Tim's DISCUSSes.
(Stewart Bryant; former steering group member) No Objection
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.
(Tim Polk; former steering group member) (was Discuss) No Objection
(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.