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

"Ahrenholz, Jeffrey M" <jeffrey.m.ahrenholz@boeing.com> Mon, 24 January 2011 21:29 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 942173A6922 for <hipsec@core3.amsl.com>; Mon, 24 Jan 2011 13:29:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 wZJjXBz3HE+1 for <hipsec@core3.amsl.com>; Mon, 24 Jan 2011 13:29:02 -0800 (PST)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com []) by core3.amsl.com (Postfix) with ESMTP id 8178D3A698D for <hipsec@ietf.org>; Mon, 24 Jan 2011 13:29:02 -0800 (PST)
Received: from stl-av-01.boeing.com (stl-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 p0OLVruT025047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <hipsec@ietf.org>; Mon, 24 Jan 2011 15:31:53 -0600 (CST)
Received: from stl-av-01.boeing.com (localhost []) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p0OLVrSI024437 for <hipsec@ietf.org>; Mon, 24 Jan 2011 15:31:53 -0600 (CST)
Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com []) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p0OLVq1s024396 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for <hipsec@ietf.org>; Mon, 24 Jan 2011 15:31:53 -0600 (CST)
Received: from XCH-NW-12V.nw.nos.boeing.com ([]) by XCH-NWHT-05.nw.nos.boeing.com ([]) with mapi; Mon, 24 Jan 2011 13:31:51 -0800
From: "Ahrenholz, Jeffrey M" <jeffrey.m.ahrenholz@boeing.com>
To: "hipsec@ietf.org" <hipsec@ietf.org>
Date: Mon, 24 Jan 2011 13:31:50 -0800
Thread-Topic: more comments on draft-ietf-hip-rfc5201-bis-04
Thread-Index: Acu8DhyyWgIj3dR2QqKx6mV8xk5tnw==
Message-ID: <FD98F9C3CBABA74E89B5D4B5DE0263B9379A894BF5@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] more 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: Mon, 24 Jan 2011 21:29:03 -0000

Here are some additional comments on the 5201-bis draft.

Section 5.4.2 says:
"However, an implementation MUST NOT send an ICMP message if the checksum fails; instead, it MUST silently drop the packet." If we MUST silently drop a packet, why do we have NOTIFY type 26, "CHECKSUM_FAILED"? (Debugging?)

Section 6.11 item 4: this says the association is considered broken if an
UPDATE is not ACKed, but one circumstance where the association is NOT broken
would be when a host is informing its peer of its current address list
(without changing the current preferred locators used.) In that case, the
association may continue happily without going to CLOSING.

Below are more minor editorial nits...


5.2.4, 5.2.5 - suggest changing "n bytes" in parameter diagram to "n bits"
the descriptions that follow (for random #I, solution #J) discuss n-bit
integers, and RHASH_len is stated as a bit length

in 5.3.2
To support the "<ECHO_REQUEST_UNSIGNED>i" used in the diagram, may want to add
a note about multiple ECHO_REQUEST_UNSIGNEDs as described in 5.2.20 with text such as:
"The R1 packet may contain zero or more ECHO_REQUEST_UNSIGNED parameters as
described in Section 5.2.20."

Then in 5.3.3 may change s/parameter/parameter(s)/ to support the
 "<ECHO_RESPONSE_UNSIGNED>i" diagram notation.

in 5.3.7 and 9
(for consistency with "a HIP..." elsewhere in the document)

5.3.8, suggest changing:
"The receiver peer MUST validate both the HMAC and the signature."
"The receiver MUST verify the echo response and validate both the HIP_MAC and the signature."
(because 5.3.7 says you MUST include the ECHO_REQUEST_SIGNED)

Section 6.4.1 s/SAH-1/SHA-1/

Section 6.7 s/the Responder a HIT with/the Responder selects a HIT with/

Section 6.8 item 6 s/a Initiator/an Initiator/

Section 5.3.2 and 6.8 item 7 s/SHOULD not/SHOULD NOT/

Section 6.9 item 12 s/packet I2/I2 packet/
Section 6.9 item 13 s/verify the HMAC/verify the HIP_MAC/  for consistency?
(elsewhere, "verify the HIP_MAC" is used)

Section 6.11 s/steps below ./steps below./

Section 6.11 item 2: support multiple ACKs?
"The UPDATE packet MAY also include an ACK of the peer's Update
ID found in a received UPDATE SEQ parameter, if any."
"The UPDATE packet MAY also include zero or more ACKs of the peer's Update
ID(s) from previously received UPDATE SEQ parameter(s)."

Section 7
suggest defining the first occurrence of ACL:
"This access control list (ACL) SHOULD also include..."

s/representing which hosts/representing for which hosts/
s/for such ACL also/for such ACLs, and also/ ?

Appendix C.2 suggest re-wording slightly:
"The IPv4 checksum value for the example I1 packet equals the IPv6 checksum
 value (since the checksum components due to the IPv4 and IPv6 pseudo-header are the same)."

Appendix D 
s/Today should be used only when/Today these groups should only be used when/