Gen-ART Review of draft-ietf-manet-rfc6622-bis-02
Russ Housley <housley@vigilsec.com> Fri, 14 June 2013 20:23 UTC
Return-Path: <housley@vigilsec.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132D521F9CC3; Fri, 14 Jun 2013 13:23:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.511
X-Spam-Level:
X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, 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 RfgaREJGLlGQ; Fri, 14 Jun 2013 13:23:48 -0700 (PDT)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id E8E5A21F9B82; Fri, 14 Jun 2013 13:23:47 -0700 (PDT)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 8BB39F2407D; Fri, 14 Jun 2013 16:23:51 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id o1kzzxD7pdlj; Fri, 14 Jun 2013 16:23:44 -0400 (EDT)
Received: from [192.168.2.109] (pool-96-241-156-29.washdc.fios.verizon.net [96.241.156.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id BC3DFF24078; Fri, 14 Jun 2013 16:23:50 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Gen-ART Review of draft-ietf-manet-rfc6622-bis-02
Date: Fri, 14 Jun 2013 16:23:45 -0400
Message-Id: <90D2B755-F68F-4C58-A645-84E4445C73BE@vigilsec.com>
To: IETF <ietf@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
Cc: IETF Gen-ART <gen-art@ietf.org>, manet@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jun 2013 20:23:53 -0000
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-manet-rfc6622-bis-02 Reviewer: Russ Housley Review Date: 2013-06-15 IETF LC End Date: 2013-06-27 IESG Telechat date: Unknown Summary: The document is almost ready for publication as a standards track RFC. I raise one major concern, and once it is resolved, the document will be ready. Major Concern: In Section 12.2.3, is there any difference in processing when the source IP address is IPv4 as opposed to IPv6? Obviously, the two have a different length. Off the top of my head I cannot find a way for an attacker to exploit one party using IPv4 in the ICV calculation and the other party using IPv6. Since the IPv6 address is 12 octets longer than the IPv4 address, there may be some opportunity for an attacker. Anyway, concerns like this are usually thwarted by including the length of the overall hash function input as the first octet or two of the value-to-be-hashed. Such a value does not need to be transmitted. Each party knows how many octets it passed to the hash function. Minor Concerns: I find Section 1.1 a bit confusing. I think it should start by saying that RFC 6622 defined two ICV TLV extension types (0 and 1). This document repeats those definitions and adds a third ICV TLV extension type (2). Section 5 says: An ICV TLV with type extension = 2 specifies a modified version of this definition. This is unclear. I believe that an ICV TLV with type extension = 2 is an update to ICV TLV with type extension = 1. It would be good to introduce the need for this update. I suggest: An ICV TLV with type extension = 2 is the same as an ICV TLV with type extension = 1, except that the integrity protection also covers the source address of the IP datagram carrying the packet, message, or address block. If you accept this suggestion, the following paragraph should also be revised. I suggest: Specifically, with type extension = 1 or type extension = 2, the <value> field contains the result of combining a cryptographic function and a hash function. The <value> field contains multiple sub-fields indicating which hash function and cryptographic function have been used as specified in Section 12.
- Gen-ART Review of draft-ietf-manet-rfc6622-bis-02 Russ Housley
- RE: Gen-ART Review of draft-ietf-manet-rfc6622-bi… Dearlove, Christopher (UK)