Re: [Hipsec] more comments on draft-ietf-hip-rfc5201-bis-04
Tobias Heer <heer@cs.rwth-aachen.de> Fri, 11 February 2011 11:23 UTC
Return-Path: <heer@informatik.rwth-aachen.de>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F22AE3A694F for <hipsec@core3.amsl.com>; Fri, 11 Feb 2011 03:23:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level:
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 8-EpzqJidx6c for <hipsec@core3.amsl.com>; Fri, 11 Feb 2011 03:23:50 -0800 (PST)
Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 6C8723A6947 for <hipsec@ietf.org>; Fri, 11 Feb 2011 03:23:50 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LGG00GBWAC32WB0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Fri, 11 Feb 2011 12:24:03 +0100 (CET)
X-IronPort-AV: E=Sophos;i="4.60,454,1291590000"; d="scan'208";a="93663346"
Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 11 Feb 2011 12:24:04 +0100
Received: from umic-i4-137-226-45-197.nn.rwth-aachen.de ([unknown] [137.226.45.197]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LGG008Q0AC3C570@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Fri, 11 Feb 2011 12:24:03 +0100 (CET)
From: Tobias Heer <heer@cs.rwth-aachen.de>
In-reply-to: <FD98F9C3CBABA74E89B5D4B5DE0263B9379A894BF5@XCH-NW-12V.nw.nos.boeing.com>
Date: Fri, 11 Feb 2011 12:24:03 +0100
Message-id: <6C39D444-8FDE-40E9-927A-F570224EFC23@cs.rwth-aachen.de>
References: <FD98F9C3CBABA74E89B5D4B5DE0263B9379A894BF5@XCH-NW-12V.nw.nos.boeing.com>
To: Jeffrey M Ahrenholz <jeffrey.m.ahrenholz@boeing.com>
X-Mailer: Apple Mail (2.1082)
Cc: hipsec@ietf.org
Subject: Re: [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: Fri, 11 Feb 2011 11:23:52 -0000
Hi Jeff, thanks for the comments. See my responses in line. Am 24.01.2011 um 22:31 schrieb Ahrenholz, Jeffrey M: > 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?) Hmmm good question. This was already that way in RFC5201-bis. I think we have three options here: a) go for "SHOULD silently drop". Implementors could use the notify if they have a good reason to do so. b) remove the NOTIFY type 26 c) state that is for debugging purposes only and sending notifies for malformed checksums MUST be turned off by default. I don't have a strong preference on either of the solutions. Any comments from the group? > > 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. > Well, the payload channel might be still functional in that case. However, the missing ACK on the control channel is certainly a sign that something is wrong with the HIP association. I think if the problem persists (sender of the update keeps retransmitting the update with the seq and receiver does not acknowledge it) it indicates that the HIP channel is broken. Trying to re-establish the connection (by first closing it and then doing another BEX (because user data is still coming) might be the best choice here. Am I missing something here? > Below are more minor editorial nits... > > -Jeff > > > 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 > All parameter descriptions are given in bytes. I think going to bits in that single case would confuse people, don't you think? On the other hand, security-related discussions (as for hash functions, etc.) mostly refer to bits in literature. So I wouldn't want to change that here either. We could try to untangle a bit by not reusing the quantity n as bit and bytes, though. We could just refer to RHASH_len/8 bytes for I and J: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | K, 1 byte | Lifetime | Opaque, 2 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random #I, RHASH_len/8 bytes | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | K, 1 byte | Reserved | Opaque, 2 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random #I, n bytes | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Puzzle solution #J, RHASH_len/8 bytes | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 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." > Thanks, Done. > Then in 5.3.3 may change s/parameter/parameter(s)/ to support the > "<ECHO_RESPONSE_UNSIGNED>i" diagram notation. Done. > > in 5.3.7 and 9 > s/an HIP_MAC/a HIP_MAC/ > (for consistency with "a HIP..." elsewhere in the document) Done. > > 5.3.8, suggest changing: > "The receiver peer MUST validate both the HMAC and the signature." > to: > "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) Good catch! Done. > > Section 6.4.1 s/SAH-1/SHA-1/ > Oops. Done. > Section 6.7 s/the Responder a HIT with/the Responder selects a HIT with/ > Done. > Section 6.8 item 6 s/a Initiator/an Initiator/ > Fixed it. > Section 5.3.2 and 6.8 item 7 s/SHOULD not/SHOULD NOT/ > Done. I checked for other SHOULD not as well. There were a few. > Section 6.9 item 12 s/packet I2/I2 packet/ Done. > Section 6.9 item 13 s/verify the HMAC/verify the HIP_MAC/ for consistency? > (elsewhere, "verify the HIP_MAC" is used) Good catch. Done. > > Section 6.11 s/steps below ./steps below./ > Done. > Section 6.11 item 2: support multiple ACKs? > replace: > "The UPDATE packet MAY also include an ACK of the peer's Update > ID found in a received UPDATE SEQ parameter, if any." > with: > "The UPDATE packet MAY also include zero or more ACKs of the peer's Update > ID(s) from previously received UPDATE SEQ parameter(s)." > Done. Thanks for providing alternative text. > Section 7 > suggest defining the first occurrence of ACL: > "This access control list (ACL) SHOULD also include..." > Done. > s/representing which hosts/representing for which hosts/ Done. > s/for such ACL also/for such ACLs, and also/ ? Done. > > 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)." > Done. Again, thanks for the alternative text. > Appendix D > s/Today should be used only when/Today these groups should only be used when/ Kudos for the review! Tobias
- [Hipsec] more comments on draft-ietf-hip-rfc5201-… Ahrenholz, Jeffrey M
- Re: [Hipsec] more comments on draft-ietf-hip-rfc5… Tobias Heer
- Re: [Hipsec] more comments on draft-ietf-hip-rfc5… Ahrenholz, Jeffrey M