I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors should treat these comments
just like any other last call comments.

Before providing my review, I will state that I do not have any
substantial experience or expertise with ROHC or with header
compression in general. My comments therefore should be taken
as those of a security expert but not a ROHC expert.

This document is an updated version of RFC 4995: The RObust Header
Compression (ROHC) Framework. Mainly, it fixes an error in the
definition of the ROHC feedback format. I won't explain the error
here since it's not significant from a security perspective and
the fix looks good to me. I am assuming that the WG participants
have dealt with any compatibility issues introduced by having the
erroneous spec out there for two years or so.

I have three comments on this document:

1) Currently, the document does not actually say what was fixed.
   The only reference to the fix is this paragraph in the abstract:

   This specification obsoletes RFC 4995.  It fixes one interoperability
   issue that was erroneously introduced in RFC 4995, and adds some
   minor clarifications.

   I suggest adding a paragraph somewhere in the Introduction (maybe
   at the end) that explains what the issue was and how it was fixed.
   Otherwise, readers will be left wondering. They may have to do a
   diff, like I did. Unfortunately, the reference format changed
   from [1] to [RFC2119] between RFC 4995 and this draft so the diff
   is about 30 pages of meaningless differences with one real change.

2) Have the editors verified that all contributors to the document
   are OK with granting the new rights granted in RFC 5378 on top
   of the rights that they originally granted under RFC 3978? This
   would include anyone who contributed text that has been held over
   from RFC 4995 and RFC 3095 and their employers at the time that
   the time of the contribution, or other assignees. I suspect that
   the answer is no. If I'm right, the editors should use the text
   designed for this situation, which is included in section 6.c.iii
   of the IETF Trust Legal Provisions Relating to IETF Documents.

3) The Security Considerations of this document are pretty good.
   However, I think that they may ignore a particular risk of
   using header compression. Namely, it seems to me that using
   header compression would substantially increase the complexity
   of the devices that perform the compression and decompression
   vs. the complexity without header compression. For example,
   a switch or router must now maintain per-flow ROHC state and
   implement the ROHC protocols, which are a bit complex. This
   complexity may result in implementation bugs that could be
   exploited by an attacker sending a packet through the system
   with a particular format designed to exploit the flaw. If
   any device along the packet's path is vulnerable, the flaw
   will be exploited. Depending on the nature of the coding
   error, such a vulnerability could result in denial of
   service or compromise of the vulnerable device. It could
   even result in a cascading failure where all the vulnerable
   devices on the path are compromised. The fact that ROHC is
   a stateful protocol means that testing will be more complex.
   And the fact that application layer protocol headers are
   compressed introduces the possibility that an untrusted
   application allowed to send application layer data could
   exploit vulnerabilities in network devices that implement
   ROHC. To address these concerns, I propose adding a new
   paragraph in the Security Considerations:

   Implementing a ROHC compressor or decompressor is not a
   trivial task. It can add vulnerabilities to a device.
   Implementors should practice safe coding techniques and
   recognize that both compressed and uncompressed packets
   can come from malicious or compromised sources that may
   send malformed packets and otherwise attempt to exploit
   vulnerabilities. Regard all packets with care to protect
   your implementation from such attacks. Otherwise, the
   compromise of one network element may result in a
   cascading sequence of compromises.

I apologize for sending this review a week after the close
of the IETF Last Call on this document. I hope that this
feedback will still be useful.

Thanks,

Steve