Re: [secdir] secdir review of draft-ietf-rohc-rfc4995bis-01

[Stephen Hanna <[e-mail]>]

I see that issue 1) below has been addressed in a new version
of the draft posted earlier this week. Never mind on that.

Thanks,

Steve

> -----Original Message-----
> From: Stephen Hanna 
> Sent: Friday, December 11, 2009 10:13 PM
> To: '[e-mail]'; 
> '[e-mail]'; '[e-mail]'
> Subject: FW: secdir review of draft-ietf-rohc-rfc4995bis-01
> 
> I think that you may not have seen this email so I'm sending
> it to you directly.
> 
> Thanks,
> 
> Steve 
> 
> -----Original Message-----
> From: Stephen Hanna 
> Sent: Friday, December 11, 2009 5:59 PM
> To: [e-mail]; 
> '[e-mail]'; [e-mail]
> Subject: secdir review of draft-ietf-rohc-rfc4995bis-01
> 
> 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
>