Last Call Review of draft-ietf-rohc-rfc4995bis-
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
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  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.