Re: [Hipsec] rfc5201-bis-04 review
Tobias Heer <heer@cs.rwth-aachen.de> Wed, 16 March 2011 12:46 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 D66193A67FA for <hipsec@core3.amsl.com>; Wed, 16 Mar 2011 05:46:57 -0700 (PDT)
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 vOt0sXgkmLoi for <hipsec@core3.amsl.com>; Wed, 16 Mar 2011 05:46:56 -0700 (PDT)
Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 837A23A68AD for <hipsec@ietf.org>; Wed, 16 Mar 2011 05:46:56 -0700 (PDT)
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-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LI5009GVI8M9ZF0@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 16 Mar 2011 13:48:22 +0100 (CET)
X-IronPort-AV: E=Sophos;i="4.63,194,1299452400"; d="scan'208";a="100533640"
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; Wed, 16 Mar 2011 13:48:22 +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 <0LI5009PII8MYA20@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 16 Mar 2011 13:48:22 +0100 (CET)
From: Tobias Heer <heer@cs.rwth-aachen.de>
In-reply-to: <B99C38E9-41CF-4937-B01A-533615522F26@nomadiclab.com>
Date: Wed, 16 Mar 2011 13:48:21 +0100
Message-id: <FD4B0A75-796F-4ADD-BDBB-BB37FF4530FA@cs.rwth-aachen.de>
References: <B3E13881-1543-447B-B011-D5394EF086BB@nomadiclab.com> <B99C38E9-41CF-4937-B01A-533615522F26@nomadiclab.com>
To: Ari Keranen <ari.keranen@nomadiclab.com>
X-Mailer: Apple Mail (2.1082)
Cc: HIP <hipsec@ietf.org>
Subject: Re: [Hipsec] rfc5201-bis-04 review
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: Wed, 16 Mar 2011 12:46:57 -0000
Hello, Am 16.03.2011 um 13:13 schrieb Ari Keranen: > One more review comment that originally ended up in the nits but probably deserves wider consideration: > > > 5.3.3. I2 - the Second HIP Initiator Packet > > The Initiator MAY include an unmodified copy of the R1_COUNTER > parameter received in the corresponding R1 packet into the I2 packet. > > > Why is this only MAY? Wouldn't it make sense to have this as MUST (or at least SHOULD) if the Responder added the R1_COUNTER? > I am not sure why this was chosen as a MAY. From my perspective, the R1_COUNTER echo mechanism only makes sense if it is a MUST. If it is a MAY, the Receiver has to implement another mechanism anyway for the case that the Initiator does not send the I1. If there were no echo mechanism for the counter, the Responder could still use the opaque fields in the ECHO_REQUEST and the PUZZLE to index different puzzle generations. Hence, I would be fine with removing the echoing of the counter altogether or making it a MUST. I agree that the MAY makes little sense. A question for the implementors: How do the different implementations handle the indexing of puzzle generations? What do the implementations do when the R1 counter is missing in the I2? In the R1, the counter is useful for the Initiator to tell older from newer I1s. Hence, the counter in the R1 makes sense. BR, Tobias > > Cheers, > Ari > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://www.comsys.rwth-aachen.de/team/tobias-heer/ blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi pgp id: AEECA5BF
- [Hipsec] rfc5201-bis-04 review Ari Keranen
- Re: [Hipsec] rfc5201-bis-04 review Tobias Heer
- Re: [Hipsec] rfc5201-bis-04 review Ari Keranen
- Re: [Hipsec] rfc5201-bis-04 review Ari Keranen
- Re: [Hipsec] rfc5201-bis-04 review Ari Keranen
- Re: [Hipsec] rfc5201-bis-04 review Tobias Heer
- Re: [Hipsec] rfc5201-bis-04 review Ari Keranen
- Re: [Hipsec] rfc5201-bis-04 review Tobias Heer
- Re: [Hipsec] rfc5201-bis-04 review Ari Keranen