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

"Kristofer Sandlund" <> Wed, 13 January 2010 13:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C3A13A68D8; Wed, 13 Jan 2010 05:40:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8vIdhRgCHgIt; Wed, 13 Jan 2010 05:40:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 98D753A6874; Wed, 13 Jan 2010 05:40:24 -0800 (PST)
X-AuditID: c1b4fb24-b7bb6ae000001052-d1-4b4dcd35e661
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 1E.53.04178.53DCD4B4; Wed, 13 Jan 2010 14:40:05 +0100 (CET)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 14:40:04 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 13 Jan 2010 14:40:03 +0100
Message-ID: <>
In-Reply-To: <>
Thread-Topic: secdir review of draft-ietf-rohc-rfc4995bis-01
Thread-Index: Acp4MKAIMZ3QHusWS0yAOB7er4hAdgCe2nhgAAsvEsAAElokIAZMQcYA
References: <>
From: "Kristofer Sandlund" <>
To: "Stephen Hanna" <>
X-OriginalArrivalTime: 13 Jan 2010 13:40:04.0824 (UTC) FILETIME=[E9BF4D80:01CA9455]
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Wed, 13 Jan 2010 06:05:09 -0800
Subject: Re: [secdir] secdir review of draft-ietf-rohc-rfc4995bis-01
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Jan 2010 13:40:26 -0000

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.