Re: [Hipsec] WGLC: draft-ietf-hip-rfc5204-bis

Julien Laganier <> Thu, 11 June 2015 01:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4C9361A0404 for <>; Wed, 10 Jun 2015 18:08:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7KLfYIdV8VCm for <>; Wed, 10 Jun 2015 18:08:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 52F2E1A0377 for <>; Wed, 10 Jun 2015 18:08:22 -0700 (PDT)
Received: by ykfl8 with SMTP id l8so30779924ykf.1 for <>; Wed, 10 Jun 2015 18:08:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+jRk4uS5pYezOwxeUWmkBZ1QklJtfb/nuCwwdaA19ts=; b=FKdMAzbMBZQ768LLruK0gSSp4guwAk1SL6F/zGyFhIgfJRn+f/L3tJfGfoWJGjUyLU 7l0R3UGcWpk3uJtjdya5VGzZ8fTCrHfkDGugpsOjVZ9QWnYVdx+KllKYjSl4op3Vfema SteJq/7t2mb5W1XpmyoEgePwKZKpCEuTBAh4EQVP8RQWanYwn/Oq4PXnqSFn4Q9MHVM7 8MjdZYlkYrvKXXmhjLOa72KRPSn7ZQx2GF+67lGIA3pySQKy5lgeA//n2L6QWArHzoE4 RvEfpf5CtV8MWEoFIdlZcUhEehMV0DT6nTxRs3GqWiEeROIBAxTHHHwuMgJdUa2Fq+75 sJNA==
MIME-Version: 1.0
X-Received: by with SMTP id z123mr7728942ywf.145.1433984901640; Wed, 10 Jun 2015 18:08:21 -0700 (PDT)
Received: by with HTTP; Wed, 10 Jun 2015 18:08:21 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 10 Jun 2015 18:08:21 -0700
Message-ID: <>
From: Julien Laganier <>
To: Gonzalo Camarillo <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: HIP <>
Subject: Re: [Hipsec] WGLC: draft-ietf-hip-rfc5204-bis
X-Mailman-Version: 2.1.15
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: Thu, 11 Jun 2015 01:08:24 -0000

Hi Tom,

Thank for the review. Please see inline below the proposed resolution
for your WGLC comments.


> On 05/05/2015 2:02 AM, Tom Henderson wrote:
>> On 04/17/2015 03:47 AM, Gonzalo Camarillo wrote:
>>> Hi,
>>> I would like to start a WGLC on the following draft. This WGLC will end
>>> on May 4th:
>>> Please, send your comments to this list.
>>> Thanks,
>>> Gonzalo
>>> _______________________________________________
>>> Hipsec mailing list
>> Here are a few questions/comments on this draft.
>> Technical
>> ---------
>> Section 4.3.3 (including VIA_RVS) seems to conflict with 4.2.3 (VIA_RVS
>> parameter definition).  Section 4.3.3 states that VIA_RVS is mandatory
>> if the I1 arrived via a RVS, but 4.2.3 says that the responder MAY
>> choose to send it for debugging purposes.

I have made it mandatory everywhere.

>> Another point regarding Section 4.2.3:  it states that the responder may
>> include "a subset of the IP addresses of its RVSs in some of the
>> packets."  What use cases are there for including more than a single RVS
>> address (the one that was used)?   Would more than one RVS ever need to
>> be traversed between initiator and responder?  I don't think the draft
>> supports such security relationships, so perhaps it would be best to
>> explicitly say it is out of scope.

I've added a disclaimer than including more than one RVS IP address is
out of scope.

The paragraph in 4.2.4 now  reads:

   After the responder receives a relayed I1 packet, it can begin to
   send HIP packets addressed to the initiator's IP address, without
   further assistance from an RVS.  For debugging purposes, it MUST
   append a newly created VIA_RVS parameter at the end of the R1 packet
   that contains the IP address of the RVS that relayed the I1 packet.
   Including more than one IP address in the VIA_RVS parameter is
   outside the scope of this specification.  The main goal of using the
   VIA_RVS parameter is to allow operators to diagnose possible issues
   encountered while establishing a HIP association via an RVS.

>> Editorial
>> ----------
>> Section 6 (IANA) needs to be updated to request the new action items of
>> IANA, not the ones previously asked when 5204 was published.
>> Accordingly, IANA is not assigning new Parameter Types but instead this
>> draft should request that IANA update the reference for these three
>> types from 5204 to this document.  The same holds for the Registration
>> Type value.

done. IANA sec. now reads:

   This document updates the IANA Registry for HIP Parameters Types by
   replacing references to [RFC5204] by references to this document.