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

"Kristofer Sandlund" <kristofer.sandlund@ericsson.com> Wed, 13 January 2010 13:40 UTC

Return-Path: <kristofer.sandlund@ericsson.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3A13A68D8; Wed, 13 Jan 2010 05:40:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vIdhRgCHgIt; Wed, 13 Jan 2010 05:40:25 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 98D753A6874; Wed, 13 Jan 2010 05:40:24 -0800 (PST)
X-AuditID: c1b4fb24-b7bb6ae000001052-d1-4b4dcd35e661
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 1E.53.04178.53DCD4B4; Wed, 13 Jan 2010 14:40:05 +0100 (CET)
Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se 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: <9520E66537CC4941994C518E3E21091C022F0C00@esealmw105.eemea.ericsson.se>
In-Reply-To: <AC6674AB7BC78549BB231821ABF7A9AE8FFA34B821@EMBX01-WF.jnpr.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: secdir review of draft-ietf-rohc-rfc4995bis-01
Thread-Index: Acp4MKAIMZ3QHusWS0yAOB7er4hAdgCe2nhgAAsvEsAAElokIAZMQcYA
References: <AC6674AB7BC78549BB231821ABF7A9AE8FFA34B821@EMBX01-WF.jnpr.net>
From: Kristofer Sandlund <kristofer.sandlund@ericsson.com>
To: Stephen Hanna <shanna@juniper.net>
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
Cc: lars-erik@lejonsson.com, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-rohc-rfc4995bis-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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.

BR,
  Kristofer