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
- [secdir] secdir review of draft-ietf-rohc-rfc4995… Stephen Hanna
- Re: [secdir] secdir review of draft-ietf-rohc-rfc… Stephen Hanna
- Re: [secdir] secdir review of draft-ietf-rohc-rfc… Kristofer Sandlund