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

[Ballot comment]
I would like to thank the authors for all their hard work.  I have cleared.  I did note
two small issues that I would like to bring ot the authors attention, but these are
only comments and are not blocking.

(1) Section 1.1 is not specific to MD5, so a title change is in order.
I suggest:

OLD
1.1 MD5 Pre-Image vs Collision Attacks
NEW
1.1 Pre-Image vs. Collision Attacks


(2) Section 6.1, bullet 3 is a little misleading.  RFC 2453 did not specify
a mandatory to implement algorithm, but 2453 was updated by RFC 4822.  RFC
4822 mandates support for HMAC-SHA1 (along with keyed MD5 for backward
compatibility).  I would suggest a clarification along the following
lines:

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.

[Ballot comment]
(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.

[Ballot discuss]
This is a useful document and I look forward to seeing it published.
However, there ae a few issues I believe need to be addressed first.

(1) This document is too focused on the weaknesses in MD5.  A reader is
likely to be left with the impression that SHA-1 based mechanisms are
acceptable for the foreseeable future.  In fact, the routing area should
be planning for transitioning to SHA-2 (and perhaps SHA-3) based
mechanisms or block cipher MACs (e.g., AES-CMAC).  In most cases, the
reliance on MD5 seemed reasoable at the tie of publication.  The mistake
was not in the selection of MD5, but in the failure to support
cryptographic agility or specify a stronger than currently needed backup.

There are analytical results against SHA-1 (and to a lesser extent SHA-2)
that should be mentioned in this specification.  While none of these
results invalidates current use of SHA-1 in routing protocols, it will
help emphasize the importance of cryptographic mobility in routing
protocols.

Adding a section 1.2 that covers these attacks would be a significant
improvement in the document.

(2) The document would benefit from some discussion of signature-based
approaches.  To my knowledge RFC 2154, OSPF with Digital Signatures,
which is an Experimantal RFC [RFC-2154] is the only protocol spec
taking this approach, but I understand it has been implemented and
demonstrated successfully.  RFC 5709, wich is standards track,
explicitly suggests this direction if stronger authentication is desired.

(3) The docment is inconsistent with respect to confidentiality.  In the
Introduction, it states that confidentiality is not a goal since the
information is potentially available elsewhere.  That is consistent with
community consensus in the routing area, as I understand it.  However,
the discussion of OSPFv3 describes this as a limitation: "However it
does not provide confidentiality of the information transmitted." While
a factual statement it implies that confidentiality is needed.

[Ballot comment]
(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.

[Ballot discuss]
This is a useful document and I look forward to seeing it published.
However, there ae a few issues I believe need to be addressed first.

(1) This document is too focused on the weaknesses in MD5.  A reader is likely to be left with the impression that SHA-1 based mechanisms are
acceptable for the foreseeable future.  In fact, the routing area should
be planning for transitioning to SHA-2 (and perhaps SHA-3) based
mechanisms or block cipher MACs (e.g., AES-CMAC).  In most cases, the
reliance on MD5 seemed reasoable at the tie of publication.  The mistake
was not in the selection of MD5, but in the failure to support
cryptographic agility or specify a stronger than currently needed backup.

There are analytical results against SHA-1 (and to a lesser extent SHA-2)
that should be mentioned in this specification.  While none of these
results invalidates current use of SHA-1 in routing protocols, it will
help emphasize the importance of cryptographic mobility in routing
protocols.

Adding a section 1.2 that covers these attacks would be a significant
improvement in the document.

(2) The document would benefit from some discussion of signature-based approaches.  To my knowledge RFC 2154, OSPF with Digital Signatures,
which is an Experimantal RFC [RFC-2154] is the only protocol spec
taking this approach, but I understand it has been implemented and demonstrated successfully.  RFC 5709, wich is standards track,
explicitly suggests this direction if stronger authentication is desired.

(3) The docment is inconsistent with respect to confidentiality.  In the
Introduction, it states that confidentiality is not a goal since the
information is potentially available elsewhere.  That is consistent with
community consensus in the routing area, as I understand it.  However,
the discussion of OSPFv3 describes this as a limitation: "However it
does not provide confidentiality of the information transmitted." While
a factual statement it implies that confidentiality is needed.

[Ballot comment]
(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.

[Ballot discuss]
This is a useful document and I look forward to seeing it published.
However, there ae a few issues I believe need to be addressed first.

(1) This document is too focused on the weaknesses in MD5.  A reader is likely to be left with the impression that SHA-1 based mechanisms are
acceptable for the foreseeable future.  In fact, the routing area should be planning for transitioning to SHA-2 (and perhaps SHA-3) based
mechanisms or block cipher MACs (e.g., AES-CMAC).  In most cases, the
reliance on MD5 seemed reasoable at the tie of publication.  The mistake
was not in the selection of MD5, but in the failure to support
cryptographic agility or specify a stronger than currently needed backup.

There are analytical results against SHA-1 (and to a lesser extent SHA-2)
that should be mentioned in this specification.  While none of these
results invalidates current use of SHA-1 in routing protocols, it will help emphasize the importance of cryptographic mobility in routing protocols.

Adding a section 1.2 that covers these attacks would be a significant
improvement in the document.

(2) The document would benefit from some discussion of signature-based approaches.  To my knowledge RFC 2154, OSPF with Digital Signatures,
which is an Experimantal RFC [RFC-2154] is the only protocol spec
taking this approach, but I understand it has been implemented and demonstrated successfully.  RFC 5709, wich is standards track,
explicitly suggests this direction if stronger authentication is desired.

(3) The docment is inconsistent with respect to confidentiality.  In the
Introduction, it states that confidentiality is not a goal since the
information is potentially available elsewhere.  That is consistent with
community consensus in the routing area, as I understand it.  However,
the discussion of OSPFv3 describes this as a limitation: "However it
does not provide confidentiality of the information transmitted." While
a factual statement it implies that confidentiality is needed.

[Ballot comment]
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.

[Ballot discuss]
This is a truly excellent and much needed document and I wanted to
ballot Yes on it. However, there was one small but annoying mistake,
and another issue that I felt would probably need a bit more discussion.

The small mistake was in this text:

  The primary problem is that all
  current key management mechanisms are designed for a one-to-one
  correlation of keys, while OSPF adjacencies are formed on a one-to-
  many basis.

This does not appear to be true, take RFC 4535 for instance. However,
I agree that there is nothing that could be used. Suggested rewording:

  The primary problem is the lack of suitable key management mechanism,
  as OSPF adjacencies are formed on a one-to-many basis and most
  key management mechanisms are designed for a one-to-one communication
  model.

The issue that needs more discussion is the treatment of the echo
mode in BFD. The document says:

  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.

I think this may be a little bit too much handwaving about possible
problems, without actually doing the analysis of what the implications
might be. If the implementation and configuration follows RFC 5881
Section 4 advice on the type of source and destination addresses,
I'm actually a bit baffled as to what can happen. AFAICT, you can
either (a) assume ability to block echo packets or (b) assume the
ability to spoof or replay echo packets. For case (a) I do not see
a real impact, because if you can block packets you can also bring
the link down. In other words, the results of the attack are equally
disastrous whether or not BFD echo packets are involved. For case
(b) you could create an illusion of a working link when it is in fact
not working, e.g., by replaying sent echo packets on the incoming
direction. However, without active involvement of the neighboring
router in some science fiction such as authenticated route-record,
there is no way to prove that a received packet came from the attacker
as opposed to being normally forwarded. This is because the attacker
is doing exactly what the real router should have been doing: forwarding
packets. Its hard to see what the attack is.

However, a possibly more real problem with BFD security is that echo
mode security is not defined. RFC 5880:

  Some form of authentication SHOULD be included, since Echo packets
  may be spoofed.

This was specified the way it is because the choice of echo packets
is a local decision. However, it also implies the lack of a well
specified and peer reviewed mechanism, possibly leading to bad designs.
Fortunately the effects of such bad design would be limited due to the
reasons stated above.

I would suggest the use of this text instead:

  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 beyond the choice of the source and destination addresses,
    and while the BFD specification recommends applying security
    mechanisms to prevent spoofing of these packets, there are no
    guidelines on what type of mechanisms are appropriate.

    Any security issues in the echo mode will directly affect the
    BFD protocol and session states and hence the network stability.
    The potential effects and remedies as understood today are somewhat
    limited, however. For instance, any replay attacks would be
    indistinguishable from normal forwarding of the tested router.
    An attack would still cause a faulty link to be believed to be up,
    but there is little that can be be done about it. However, if
    the echo packets are guessable it may be possible to spoof from
    an external source and cause BFD to believe that a one-way link
    is really bidirectional. As a result it is important that the
    echo packets contain random material that is also checked upon
    reception.

Or something along those lines.

[Ballot comment]
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.

[Ballot discuss]
This is a truly excellent and much needed document and I wanted to
ballot Yes on it. However, there was one small but annoying mistake,
and another issue that I felt would probably need a bit more discussion.

The small mistake was in this text:

  The primary problem is that all
  current key management mechanisms are designed for a one-to-one
  correlation of keys, while OSPF adjacencies are formed on a one-to-
  many basis.

This does not appear to be true, take RFC 4535 for instance. However,
I agree that there is nothing that could be used. Suggested rewording:

  The primary problem is the lack of suitable key management mechanism,
  as OSPF adjacencies are formed on a one-to-many basis and most
  key management mechanisms are designed for a one-to-one communication
  model.

The issue that needs more discussion is the treatment of the echo
mode in BFD. The document says:

  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.

I think this may be a little bit too much handwaving about possible
problems, without actually doing the analysis of what the implications
might be. If the implementation and configuration follows RFC 5881
Section 4 advice on the type of source and destination addresses,
I'm actually a bit baffled as to what can happen. AFAICT, you can
either (a) assume ability to block echo packets or (b) assume the
ability to spoof or replay echo packets. For case (a) I do not see
a real impact, because if you can block packets you can also bring
the link down. In other words, the results of the attack are equally
disastrous whether or not BFD echo packets are involved. For case
(b) you could create an illusion of a working link when it is in fact
not working, e.g., by replaying sent echo packets on the incoming
direction. However, without active involvement of the neighboring
router in some science fiction such as authenticated route-record,
there is no way to prove that a received packet came from the attacker
as opposed to being normally forwarded. This is because the attacker
is doing exactly what the real router should have been doing: forwarding
packets. Its hard to see what the attack is.

However, a possibly more real problem with BFD security is that echo
mode security is not defined. RFC 5880:

  Some form of authentication SHOULD be included, since Echo packets
  may be spoofed.

This was specified the way it is because the choice of echo packets
is a local decision. However, it also implies the lack of a well
specified and peer reviewed mechanism, possibly leading to bad designs.
Fortunately the effects of such bad design would be limited due to the
reasons stated above.

I would suggest the use of this text instead:

  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 beyond the choice of the source and destination addresses,
    and while the BFD specification recommends applying security
    mechanisms to prevent spoofing of these packets, there are no
    guidelines on what type of mechanisms are appropriate.

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

[Ballot comment]
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.

[Ballot discuss]
This is a truly excellent document and I wanted to ballot Yes on it.
However, there was a small but annoying mistake in this text:

  The primary problem is that all
  current key management mechanisms are designed for a one-to-one
  correlation of keys, while OSPF adjacencies are formed on a one-to-
  many basis.

This does not appear to be true, take RFC 4535 for instance. However,
I agree that there is nothing that could be used. Suggested rewording:

  The primary problem is the lack of suitable key management mechanism,
  as OSPF adjacencies are formed on a one-to-many basis and most
  key management mechanisms are designed for a one-to-one communication
  model.

[Ballot comment]
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 ...

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

[Ballot discuss]
This is a truly excellent document and I wanted to ballot Yes on it.
However, there was a small but annoying mistake in this text:

  The primary problem is that all
  current key management mechanisms are designed for a one-to-one
  correlation of keys, while OSPF adjacencies are formed on a one-to-
  many basis.

This does not appear to be true, take RFC 4535 for instance. However,
I agree that there is nothing that could be used. Suggested rewording:

  The primary problem is the lack of suitable key management mechanism,
  as OSPF adjacencies are formed on a one-to-many basis and most
  key management mechanisms are designed for a one-to-one communication
  model.

[Ballot comment]
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 ...

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

[Ballot discuss]
This is a truly excellent document and I wanted to ballot Yes on it.
However, there was a small but annoying mistake in this text:

  The primary problem is that all
  current key management mechanisms are designed for a one-to-one
  correlation of keys, while OSPF adjacencies are formed on a one-to-
  many basis.

This does not appear to be true, take RFC 4535 for instance. However,
I agree that there is nothing that could be used. Suggested rewording:

  The primary problem is the lack of suitable key management mechanism,
  as OSPF adjacencies are formed on a one-to-many basis and most
  key management mechanisms are designed for a one-to-one communication
  model.

[Ballot comment]
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 ...

[Ballot discuss]
This is a truly excellent document and I wanted to ballot Yes on it.
However, there was a small but annoying mistake in this text:

  The primary problem is that all
  current key management mechanisms are designed for a one-to-one
  correlation of keys, while OSPF adjacencies are formed on a one-to-
  many basis.

This does not appear to be true, take RFC 4535 for instance. However,
I agree that there is nothing that could be used. Suggested rewording:

  The primary problem is the lack of suitable key management mechanism,
  as OSPF adjacencies are formed on a one-to-many basis and most
  key management mechanisms are designed for a one-to-one communication
  model.

[Ballot comment]
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...

[Ballot discuss]
This is a truly excellent document and I wanted to ballot Yes on it.
However, there was a small but annoying mistake in this text:

  The primary problem is that all
  current key management mechanisms are designed for a one-to-one
  correlation of keys, while OSPF adjacencies are formed on a one-to-
  many basis.

This does not appear to be true, take RFC 4535 for instance. However,
I agree that there is nothing that could be used. Suggested rewording:

  The primary problem is the lack of suitable key management mechanism,
  as OSPF adjacencies are formed on a one-to-many basis and most
  key management mechanisms are designed for a one-to-one communication
  model.

[Ballot comment]
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...

[Ballot comment]
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.

[Ballot comment]
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!

[Ballot comment]
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

[Ballot discuss]
>    [RFC2385] describes the use of TCP MD5 signature option for providing
>    packet origin authentication and data integrity protection of BGP
>    packets. [RFC3562] provides suggestions for choosing the key length
>    of the ad-hoc keyed-MD5 mechanism specified in [RFC2385]. There is no
>    provision for confidentiality for any of these BGP messages. TCP
>    Maintenance and Minor Extensions (tcpm) WG has been working since
>    quite some time on a new TCP Authentication Option [TCP-AO] mechanism
>    that will eventually obsolete the TCP-MD5 Signature option of RFC-
>    2385 (TCP/MD5). [TCP-AO] specifies the use of stronger Message
>    Authentication Codes (MACs), protects against replays even for long
>    lived TCP connections, and provides more details on the association
>    of security with TCP connections than TCP-MD5.  This document however
>    still covers only TCP-MD5 as most current deployments are still using
>    BGP with TCP-MD5 and have not upgraded to [TCP-AO].

  DISCUSS: The text on TCP-AO is outdated (which is understandable,
  given that this document has been submitted in April).
  draft-ietf-tcpm-tcp-auth-opt and draft-ietf-tcpm-tcp-ao-crypto are
  approved by the IESG and days away from publication as RFCs, at which
  point RFC2385 will be officially obsoleted. It'd be unfortunate if we
  publish the text in this paragraph and it will be inaccurate a few
  days later. Suggestion: Rewrite this paragraph as if TCP-AO had been
  published, and add a normative reference to it so that things are
  consistent.

  (Especially since I just saw the document was deferred until the IESG
  telechat on 2010-06-03...)

Hi,

Document shepherd write-up for draft-ietf-opsec-routing-protocols-crypto-issues-03 follows.

>  (1.a) Who is the Document Shepherd for this document? Has the
>        Document Shepherd personally reviewed this version of the
>        document and, in particular, does he or she believe this
>        version is ready for forwarding to the IESG for publication?

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.)

>  (1.b) Has the document had adequate review both from key WG members
>        and from key non-WG members? Does the Document Shepherd have
>        any concerns about the depth or breadth of the reviews that
>        have been performed?

This document has been subjected to extensive review both in the opsec working group as well as cross area review in the routing area which is responsible for maintenance of routing protocols. This document is cited as a motivation for the survey work proposed in the karp BOF.

>  (1.c) Does the Document Shepherd have concerns that the document
>        needs more review from a particular or broader perspective,
>        e.g., security, operational complexity, someone familiar with
>        AAA, internationalization or XML?

I have no such concern.

>  (1.d) Does the Document Shepherd have any specific concerns or
>        issues with this document that the Responsible Area Director
>        and/or the IESG should be aware of? For example, perhaps he
>        or she is uncomfortable with certain parts of the document, or
>        has concerns whether there really is a need for it. In any
>        event, if the WG has discussed those issues and has indicated
>        that it still wishes to advance the document, detail those
>        concerns here. Has an IPR disclosure related to this document
>        been filed? If so, please include a reference to the
>        disclosure and summarize the WG discussion and conclusion on
>        this issue.

I have no such concern.

>  (1.e) How solid is the WG consensus behind this document? Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?

I observed consensus in the opsec working group that this document should be published as informational.

>  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
>        discontent? If so, please summarise the areas of conflict in
>        separate email messages to the Responsible Area Director. (It
>        should be in a separate email because this questionnaire is
>        entered into the ID Tracker.)

Nobody has made any such threats or identified extreme discontent.

>  (1.g) Has the Document Shepherd personally verified that the
>        document satisfies all ID nits? (See the Internet-Drafts Checklist
>        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
>        not enough; this check needs to be thorough. Has the document
>        met all formal review criteria it needs to, such as the MIB
>        Doctor, media type and URI type reviews?

I have personally passed the document through idnits -- the single error that shows up is benign (the three obsolete informational references are intentional). The few warnings relate to defensible style decisions or typos (e.g. accidental multiple spaces) that the RFC Editor will no doubt deal with in a consistent way.

>  (1.h) Has the document split its references into normative and
>        informative? Are there normative references to documents that
>        are not ready for advancement or are otherwise in an unclear
>        state? If such normative references exist, what is the
>        strategy for their completion? Are there normative references
>        that are downward references, as described in [RFC3967]? If
>        so, list these downward references to support the Area
>        Director in the Last Call procedure for them [RFC3967].

References are split. There are no problematic normative references that I can see.

>  (1.i) Has the Document Shepherd verified that the document IANA
>        consideration section exists and is consistent with the body
>        of the document? If the document specifies protocol
>        extensions, are reservations requested in appropriate IANA
>        registries? Are the IANA registries clearly identified? If
>        the document creates a new registry, does it define the
>        proposed initial contents of the registry and an allocation
>        procedure for future registrations? Does it suggest a
>        reasonable name for the new registry? See [RFC5226]. If the
>        document describes an Expert Review process has Shepherd
>        conferred with the Responsible Area Director so that the IESG
>        can appoint the needed Expert during the IESG Evaluation?

The document makes no request of the IANA, and the IANA Considerations section is present and confirms this.

>  (1.j) Has the Document Shepherd verified that sections of the
>        document that are written in a formal language, such as XML
>        code, BNF rules, MIB definitions, etc., validate correctly in
>        an automated checker?

There are no such sections.

>  (1.k) The IESG approval announcement includes a Document
>        Announcement Write-Up. Please provide such a Document
>        Announcement Write-Up? Recent examples can be found in the
>        "Action" announcements for approved documents. The approval
>        announcement contains the following sections:
>
>      Technical Summary
>        Relevant content can frequently be found in the abstract
>        and/or introduction of the document. If not, this may be
>        an indication that there are deficiencies in the abstract
>        or introduction.

Verbatim from the document's abstract:

  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
>        Was there anything in WG process that is worth noting? For
>        example, was there controversy about particular points or
>        were there decisions where the consensus was particularly
>        rough?

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
>        Are there existing implementations of the protocol? Have a
>        significant number of vendors indicated their plan to
>        implement the specification? Are there any reviewers that
>        merit special mention as having done a thorough review,
>        e.g., one that resulted in important changes or a
>        conclusion that the document had no substantive issues? If
>        there was a MIB Doctor, Media Type or other expert review,
>        what was its course (briefly)? In the case of a Media Type
>        review, on what date was the request posted?

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.