Re: [Hipsec] your DISCUSS comments on draft-ietf-hip-rfc5201-bis

Brian Haberman <brian@innovationslab.net> Tue, 22 July 2014 21:08 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4121B2A9F for <hipsec@ietfa.amsl.com>; Tue, 22 Jul 2014 14:08:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nk9BRbwysSUn for <hipsec@ietfa.amsl.com>; Tue, 22 Jul 2014 14:08:43 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C991B2831 for <hipsec@ietf.org>; Tue, 22 Jul 2014 14:08:43 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 2C20C8810D; Tue, 22 Jul 2014 14:08:43 -0700 (PDT)
Received: from dhcp-b444.meeting.ietf.org (dhcp-b444.meeting.ietf.org [31.133.180.68]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id D1C5A13680EE; Tue, 22 Jul 2014 14:08:42 -0700 (PDT)
Message-ID: <53CED2D3.4040603@innovationslab.net>
Date: Tue, 22 Jul 2014 17:08:35 -0400
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Tom Henderson <tomh@tomh.org>
References: <53CEB296.9050202@tomh.org>
In-Reply-To: <53CEB296.9050202@tomh.org>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="PFcGV7kDKMNQQVTDkC4GueWaGkteKceLo"
Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/YzAxhRRoiFZbhzNXAhaiIwiAyJo
Cc: HIP <hipsec@ietf.org>
Subject: Re: [Hipsec] your DISCUSS comments on draft-ietf-hip-rfc5201-bis
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.15
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/options/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: Tue, 22 Jul 2014 21:08:44 -0000

Hi Tom,

On 7/22/14 2:51 PM, Tom Henderson wrote:
> Brian,
> 
> You left the following DISCUSS comments on draft-ietf-hip-rfc5201-bis
> which I would like to address below:
> 
>> I have no objection to the publication of this document, but I do
>> have two small points to discuss in section 5.2.3.
>>
>> 1. The R1_COUNTER parameter was labeled as optional in RFC 5201, but
>> made mandatory in this revision.  However, the text says it SHOULD be
>> included in R1.  If it is not included in R1 (violates the SHOULD),
>> where will it be included given it is mandatory?
> 
> Support for it is mandatory (if the Responder sends it, the Initiator
> must echo it back), but the inclusion by the responder is optional.
> 
> To try to clarify this, I edited it (for version -15) to read:
> 
>            Support for the R1_COUNTER parameter is mandatory although
>            its inclusion in the R1 packet is optional.  It SHOULD be
>            included in the R1 ...
> 

The above is fine.  If this parameter is sent by the Responder, what
packets could it be sent in (i.e., violate the SHOULD) and still be useful?

The above question is just something for you to think about.  I will not
hold a discuss on it.

>>
>> 2. The Type value of R1_COUNTER was 128 in 5201 and is now 129.  Is
>> that correct?
> 
> Yes, by making its support mandatory, it is now deemed a "critical"
> parameter and the LSB of the type value must be 1.  This necessitated
> the change from 128 to 129.
> 

Is there a need to discuss any backwards compatibility issues with this
change?

Brian