[Hipsec] comments on draft-ietf-hip-rfc5201-bis-04

"Ahrenholz, Jeffrey M" <jeffrey.m.ahrenholz@boeing.com> Fri, 21 January 2011 22:22 UTC

Return-Path: <jeffrey.m.ahrenholz@boeing.com>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 266D128B797 for <hipsec@core3.amsl.com>; Fri, 21 Jan 2011 14:22:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.399
X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id smIoMwQZWl8d for <hipsec@core3.amsl.com>; Fri, 21 Jan 2011 14:22:58 -0800 (PST)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com []) by core3.amsl.com (Postfix) with ESMTP id ED8B828B23E for <hipsec@ietf.org>; Fri, 21 Jan 2011 14:22:57 -0800 (PST)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com []) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p0LMPbcR012971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <hipsec@ietf.org>; Fri, 21 Jan 2011 16:25:42 -0600 (CST)
Received: from slb-av-01.boeing.com (localhost []) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p0LMPaEU002782 for <hipsec@ietf.org>; Fri, 21 Jan 2011 14:25:36 -0800 (PST)
Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com []) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p0LMPVqF002518 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for <hipsec@ietf.org>; Fri, 21 Jan 2011 14:25:36 -0800 (PST)
Received: from XCH-NW-12V.nw.nos.boeing.com ([]) by XCH-NWHT-07.nw.nos.boeing.com ([]) with mapi; Fri, 21 Jan 2011 14:25:36 -0800
From: "Ahrenholz, Jeffrey M" <jeffrey.m.ahrenholz@boeing.com>
To: "hipsec@ietf.org" <hipsec@ietf.org>
Date: Fri, 21 Jan 2011 14:25:35 -0800
Thread-Topic: comments on draft-ietf-hip-rfc5201-bis-04
Thread-Index: Acu5uh9qjaIKuHLRQvSV4fgumskJ/Q==
Message-ID: <FD98F9C3CBABA74E89B5D4B5DE0263B9379A848940@XCH-NW-12V.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [Hipsec] comments on draft-ietf-hip-rfc5201-bis-04
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jan 2011 22:22:59 -0000

Here are some comments on (the first part of) the 5201-bis draft. First are some high-level comments and then small editorial nits.

(1) The terms "Host Identity" and "Host Identifier" do not mean the same thing in 4423-bis and 5201-bis, when comparing the definitions/terminology sections. Section 3 also uses "Identifier Tag" and "Identity Tag" inconsistently. I'd prefer to always call the HIT the "Host Identity Tag".

(2) I think the draft-ietf-hip-rfc4843-bis-00 document needs to be updated to reflect the new HIT format of: 28-bit prefix + 4-bit OGA + 96-bit pubkey. Section 3 mentions 96 bits from the HI while 4843-bis still has 100 bits. The OGA (Section 3.1, Appendix E) is not mentioned in 4843-bis, just the Context ID.

(3) Section 5.2 the 2nd table of parameter type ranges lists "handshake", and this is used elsewhere in the document, but not necessarily defined. We know the "HIP handshake" is synonymous with "HIP base exchange" but maybe that should be spelled out somewhere?

Below are the nits...


Section 1. Intro
s/called HIP association/called a HIP association/
s/That is it should be a part/That is, it should be a part/

Section 1.3
s/define the detail packet formats/define the detailed packet formats/

Section 3.1
The text that says "Firstly, the fixed length .... Secondly, it presents ...", I think this should use same text as Section 5.3 of 4423-bis; or revise it with something like:
"First, the fixed length of the HIT keeps packet sizes manageable and eases
protocol coding. Second, it presents a consistent format for the protocol,
independent of the underlying identity technology in use."

Section 3.2 references FIPS.95-1.1993 and if you follow this reference, it is
not about SHA-1 (it is much more dreary); it seems like the latest FIPS 180 reference is good enough for both SHA-1 and SHA-256 (I think the RFC 5201 [FIPS95] reference to PUB 180-1 1995 somehow became FIPS.95-1.1993)

Section 3.2 second paragraph, the HTML version says "Section Section 5.2.8"
(where "Section 5.2.8" is a link)

Section 3.2 mentions Section 4.2 and 6 of [I-D.mcgrew-fundamental-ecc]
the HTML tool incorrectly links Section 4.2 (of current doc)

Section 4.1 says "In the first two packets, the hosts agree on a set of cryptographic identifiers and algorithms..."; wouldn't you say the first 3 packets, since the 3rd/I2 packet contains the chosen HIP_CIPHER?

Section 4.1.1 s/Second, hand, the design/Second, the design/
(leftover text from RFC 5201)

Section 4.1.2 s/limits the usability of an old/limits the usability that an old/

Section 4.1.3 s/as well as it uses/as well as uses/

Section 4.1.7 s/if they are remain/if they remain/

Section 4.2 "rekey expiring user data security associations" - I'm not sure
that the words "user data" are needed?

Section 4.3 s/sendin an I1/sending an I1/

Section 4.5.1 s/in the place of the/in place of the/

Section 5.3.1 says "The HIP packet, however, MUST NOT be fragmented." while
Section 5.1.3 says "A HIP implementation must support IP fragmentation/reassembly." ...I think 5.3.1 is discussing HIP packets having an upper-layer payload, but this should be clarified.