[secdir] review of Updated Specification of the IPv4 ID Field
Stephen Kent <kent@bbn.com> Sun, 01 July 2012 16:56 UTC
Return-Path: <kent@bbn.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9172111E808C for <secdir@ietfa.amsl.com>; Sun, 1 Jul 2012 09:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNQytQjEm1dl for <secdir@ietfa.amsl.com>; Sun, 1 Jul 2012 09:56:39 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5E01411E8080 for <secdir@ietf.org>; Sun, 1 Jul 2012 09:56:39 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:44020 helo=[172.18.4.197]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1SlNRa-000IV1-Qp for secdir@ietf.org; Sun, 01 Jul 2012 12:56:40 -0400
Mime-Version: 1.0
Message-Id: <p06240800cc16315859fd@[192.1.255.188]>
Date: Sun, 01 Jul 2012 12:56:01 -0400
To: secdir@ietf.org
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/mixed; boundary="============_-870960716==_============"
Subject: [secdir] review of Updated Specification of the IPv4 ID Field
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sun, 01 Jul 2012 16:56:40 -0000
I 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 and WG chairs should treat these comments just like any other last call comments. This document, "Updated Specification of the IPv4 ID Field" is a update of RFCs 791, 1122 and 2003. The primary motivation for the update is a recognition that the uniqueness requirement imposed on the field values (on a per host pair and protocol basis) would limit "connections" to about 6.4 Mb/s (for typical 1500 byte packets), an unrealistically low data rate today. This document updates the cited RFCs to reflect current practice and to more closely match IPv6. Specifically, the field value is defined only when a datagram is fragmented. The Security Considerations section is very brief, only three paragraphs. It notes that removing the prior constraints on ID field generation (MSL uniqueness) make it easier to use this field as a covert channel. It suggests that rewriting the field is a possible countermeasure. This advice is presented with the context of datagrams not protected using AH. Because AH is no longer a mandatory to implement element of the IPsec suite, I suggested an edit to avoid suggesting that AH use if common. The text goes on to discuss how removing the MSL uniqueness requirement reduces the entropy associated with the IPv4 header. It fails to explain why this might be significant. There is no indication that modern encryption algorithms used IETF security protocols are harmed by this reduction in entropy. Thus the paragraph devoted to this issue seems extraneous, possibly confusing to implementers. The final paragraph in this section notes that the proposed ID field conventions may make it more difficult to count the number of distinct devices behind a NAT or similar device. I agree with the author's observation that this side effect of the current ID field requirements is not a security feature per se and thus not a concern. Earlier sections of this document do a good job explaining how this change may impact various forms of middleboxes. The author should note in the SCC whether the change proposed in this document may adversely affect availability, if these devices are not updated to account for this change.
- [secdir] review of Updated Specification of the I… Stephen Kent
- Re: [secdir] review of Updated Specification of t… Steven Bellovin