Re: [Hipsec] rfc5201-bis-04 review

Tobias Heer <> Wed, 16 March 2011 12:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D66193A67FA for <>; Wed, 16 Mar 2011 05:46:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.801
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vOt0sXgkmLoi for <>; Wed, 16 Mar 2011 05:46:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 837A23A68AD for <>; 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 ([]) by (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <> for; 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 (HELO relay-auth-1) ([]) by with ESMTP; Wed, 16 Mar 2011 13:48:22 +0100
Received: from ([unknown] []) by (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <> for; Wed, 16 Mar 2011 13:48:22 +0100 (CET)
From: Tobias Heer <>
In-reply-to: <>
Date: Wed, 16 Mar 2011 13:48:21 +0100
Message-id: <>
References: <> <>
To: Ari Keranen <>
X-Mailer: Apple Mail (2.1082)
Cc: HIP <>
Subject: Re: [Hipsec] rfc5201-bis-04 review
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Mar 2011 12:46:57 -0000


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.



> Cheers,
> Ari
> _______________________________________________
> Hipsec mailing list

Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
pgp id: AEECA5BF