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

From: "Kristofer Sandlund" <[email-masked]>
Date: Wed, 13 Jan 2010 14:40:03 +0100

Hi Stephen,

sorry for the extremely late reply. Inlined below are answers to points
2 and 3.

Stephen Hanna wrote:
>> 
>> 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.
>> 

Agreed, we've updated this for version -03. Thanks for finding it.

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

We discussed this comment a bit, and we think it is going a bit too far.
A bad implementation of a protocol is always going to have the potential
to cause more problems than not having the protocol in the first place;
therefore it seems obvious that one should try to make the
implementation "good".
So we're not planning to change the security considerations.

BR,
  Kristofer