Re: [Hipsec] a review of ietf-hip-rfc5206-bis-10

Miika Komu <miika.komu@ericsson.com> Wed, 20 April 2016 08:19 UTC

Return-Path: <miika.komu@ericsson.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBED212B05F for <hipsec@ietfa.amsl.com>; Wed, 20 Apr 2016 01:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Cg0bOHVolhsF for <hipsec@ietfa.amsl.com>; Wed, 20 Apr 2016 01:19:02 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E7812DD80 for <hipsec@ietf.org>; Wed, 20 Apr 2016 01:19:02 -0700 (PDT)
X-AuditID: c1b4fb3a-f795d6d000004243-9a-57173b731cb4
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 52.D1.16963.37B37175; Wed, 20 Apr 2016 10:19:00 +0200 (CEST)
Received: from [153.88.190.38] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.248.2; Wed, 20 Apr 2016 10:18:59 +0200
To: hip WG <hipsec@ietf.org>
References: <alpine.LRH.2.01.1604191011300.16100@hymn04.u.washington.edu>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <57173B73.3020808@ericsson.com>
Date: Wed, 20 Apr 2016 11:18:59 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <alpine.LRH.2.01.1604191011300.16100@hymn04.u.washington.edu>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050006010501040003040101"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7om6JtXi4wcUv7BZTF01mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqw3j5gLPqdXzFyzjqWBcWdEFyMnh4SAicTmBY/ZIWwxiQv3 1rN1MXJxCAkcYZR4uqGDGSQhJLCaUeLdv6IuRg4OYQFLifs7i0DCIgIyEhs2vWCFKPGU+Dhv N9gcNgEtiVV3roO18gtISmxo2A1m8wpoS8z59g7MZhFQlVi9/C4LiC0qECHxZO5JRogaQYmT M5+AxTkFvCTeTWgBu4dZoJtR4ual0+wgNwgJqEhcPBY8gVFgFpKWWcjKQBLMArYSd+buZoaw tSWWLXwNZVtLzPh1kA3CVpSY0v0Qqt5U4vXRj4wQtrHEsnV/2RYwcqxiFC1OLS7OTTcy0kst ykwuLs7P08tLLdnECAz9g1t+W+1gPPjc8RCjAAejEg+vwkTRcCHWxLLiytxDjCpAcx5tWH2B UYolLz8vVUmEt9hCPFyINyWxsiq1KD++qDQntfgQozQHi5I4b07kvzAhgfTEktTs1NSC1CKY LBMHp1QDo5K0qvUj80t5z1weRGkE9zrqXq564+rxY8PZtWkOEw3Tflp3trWZlJgUzBOcu9fU ZuXd5+L8kcf/ONvGK744Lvs+6tdZB24PBeF96n+lav5bVF8Mm7auxmvp5gXFPxgWbtt4oo4p f7HfqwfRs44m7LDZ9llTPevNnneatvL5Bk8LHnHVTFisq8RSnJFoqMVcVJwIAAm4R3WFAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/nXyDBjXsi0cKOI12OR3GLNkkm2M>
Subject: Re: [Hipsec] a review of ietf-hip-rfc5206-bis-10
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 20 Apr 2016 08:19:13 -0000

Hi Tom,

your changes are fine, thanks for the quick response.

On 04/19/2016 08:11 PM, Tom Henderson wrote:
> Hi Miika, thanks for the review; some responses are inline below.  I will continue later in a second message.
>
> - Tom
>
> On 04/17/2016 01:26 PM, Miika Komu wrote:
>> Hi,
>>
>> I read through ietf-hip-rfc5206-bis-10, and it is in pretty good shape.
>> Below are a few nits.
>>
>>   > 3.1.  Operating Environment
>>   >
>>   > [...]
>>   >
>>   > Consider next a mobility event, in which a host moves to another IP
>>   > address.  Two things must occur in this case.  First, the peer must
>>   > be notified of the address change using a HIP UPDATE message.
>>   > Second, each host must change its local bindings at the HIP sublayer
>>   > (new IP addresses).  It may be that both the SPIs and IP addresses
>>   > are changed simultaneously in a single UPDATE; the protocol described
>>   > herein supports this.  However, elements of procedure to recover from
>>
>> I think simultaneous mobility is covered as already mentioned in the intro?
>
> Fixed
>
>>
>>   > 3.2.3.  Mobility messaging through rendezvous server
>>   >
>>   > 3.  A host receiving an UPDATE packet MUST be prepared to process the
>>   > FROM and RVS_HMAC parameters, and MUST include a VIA_RVS
>>   > parameter in the UPDATE reply that contains the ACK of the UPDATE
>>   > SEQ.
>>
>> (I would add that the return routability test should be invoked to the
>> end-host's addresses rather than the ones in VIA_RVS)
>
> I added another numbered item:
>
>            An initiator receiving a VIA_RVS in the UPDATE reply should
>            initiate address reachability tests (described later in this
>            document) towards the end host's address and not towards the
>            address included in the VIA_RVS.
>
>>
>>   > 4.  This scenario requires that hosts using rendezvous servers also
>>   > take steps to update their current address bindings with their
>>   > rendezvous server upon a mobility event.
>>   > [I-D.ietf-hip-rfc5204-bis] does not specify how to update the
>>   > rendezvous server with a client host's new address.
>>   > [I-D.ietf-hip-rfc5203-bis] Section 3.2 describes how a host may
>>   > send a REG_REQUEST in either an I2 packet (if there is no active
>>   > association) or an UPDATE packet (if such association exists).
>>
>> (Maybe this should have been actually step 0)
>
> It really should not be in the sequential list; I moved it outside of the list.
>>
>>   > The procedures described in [I-D.ietf-hip-rfc5203-bis] for
>>   > sending a REG_REQUEST and REG_RESPONSE to the rendezvous server
>>   > apply also to this mobility scenario.
>>
>> This was a bit vague, how?
>
> Here is how I clarified it; do you agree?
>
>            According to procedures described in [I-D.ietf-hip-rfc5203-bis],
>            if a mobile host
>            has an active registration, it may use mobility updates specified
>            herein, within the context of that association, to readdress the
>            association.
>
>>
>>   > 3.2.4.  Network Renumbering
>>   >
>>   > It is expected that IPv6 networks will be renumbered much more often
>>   > than most IPv4 networks.  From an end-host point of view, network
>>   > renumbering is similar to mobility.
>>
>> ...and?
>
> added " , and  procedures described herein also apply to notify a peer of
>          a changed address."
>>
>>   > 3.3.  Other Considerations
>>   >
>>   > 3.3.1.  Address Verification
>>   >
>>   > When a HIP host receives a set of locators from another HIP host in a
>>   > LOCATOR_SET, it does not necessarily know whether the other host is
>>   > actually reachable at the claimed addresses.  In fact, a malicious
>>   > peer host may be intentionally giving bogus addresses in order to
>>   > cause a packet flood towards the target addresses [RFC4225].
>>   > Therefore, the HIP host must first check that the peer is reachable
>>   > at the new address.
>>   >
>>   > An additional potential benefit of performing address verification is
>>   > to allow middleboxes in the network along the new path to obtain the
>>   > peer host's inbound SPI.
>>   >
>>   > Address verification is implemented by the challenger sending some
>>   > piece of unguessable information to the new address, and waiting for
>>   > some acknowledgment from the Responder that indicates reception of
>>   > the information at the new address.  This may include the exchange of
>>   > a nonce, or the generation of a new SPI and observation of data
>>   > arriving on the new SPI.
>>
>> I suggest would move the second paragraph after the third one.
>
> OK
>
>>
>>   > 3.3.2.  Credit-Based Authorization
>>   >
>>   > On this basis, rather than eliminating malicious packet redirection
>>   > in the first place, Credit-Based Authorization prevents
>>   > amplifications.  This is accomplished by limiting the data a host can
>>   > send to an unverified address of a peer by the data recently received
>>   > from that peer.  Redirection-based flooding attacks thus become less
>>   > attractive than, for example, pure direct flooding, where the
>>   > attacker itself sends bogus packets to the victim.
>>
>> Reference section 5.6?
>
> OK
>
>>
>>   > 4.3.  UPDATE Packet with Included LOCATOR_SET
>>   >
>>   > A number of combinations of parameters in an UPDATE packet are
>>   > possible (e.g., see Section 3.2).  In this document, procedures are
>>   > defined only for the case in which one LOCATOR_SET and one ESP_INFO
>>   > parameter is used in any HIP packet.  Furthermore, the LOCATOR_SET
>>   > SHOULD list all of the locators that are active on the HIP
>>   > association (including those on SAs not covered by the ESP_INFO
>>   > parameter).
>>
>> What do you mean by "including those on SAs..."?
>
> This is related to multihoming and can be deleted here.
>
>>
>>   > Any UPDATE packet that includes a LOCATOR_SET parameter
>>   > SHOULD include both an HMAC and a HIP_SIGNATURE parameter.
>>
>> Please add a paragraph break here.
>
> OK
>
>>
>>   > The UPDATE MAY also include a HOST_ID parameter (which may be useful for
>>   > middleboxes inspecting the HIP messages for the first time).  If the
>>   > UPDATE includes the HOST_ID parameter, the receiving host MUST verify
>>   > that the HOST_ID corresponds to the HOST_ID that was used to
>>   > establish the HIP association, and the HIP_SIGNATURE must verify with
>>   > the public key assodiated with this HOST_ID parameter.
>>
>> assodiated -> associated
>>
>> Please add a paragraph break here.
>
> OK
>>
>>   > The relationship between the announced Locators and any ESP_INFO
>>   > parameters present in the packet is defined in Section 5.2.  This
>>   > draft does not support any elements of procedure for sending more
>>   > than one LOCATOR_SET or ESP_INFO parameter in a single UPDATE.
>>
>> draft -> document
>
> OK
>
> (remainder of comments will be addressed in a second message)
>