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

Tom Henderson <tomhend@u.washington.edu> Tue, 19 April 2016 17:12 UTC

Return-Path: <tomhend@u.washington.edu>
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 6BA8312EC75 for <hipsec@ietfa.amsl.com>; Tue, 19 Apr 2016 10:12:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 wLbmZbDROD4k for <hipsec@ietfa.amsl.com>; Tue, 19 Apr 2016 10:12:10 -0700 (PDT)
Received: from mxout26.s.uw.edu (mxout26.s.uw.edu [140.142.234.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86B112EBB0 for <hipsec@ietf.org>; Tue, 19 Apr 2016 10:12:10 -0700 (PDT)
Received: from hymn04.u.washington.edu (hymn04.u.washington.edu [140.142.8.72]) by mxout26.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u3JHBajJ029101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Apr 2016 10:11:36 -0700
Received: from hymn04.u.washington.edu (localhost [127.0.0.1]) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u3JHBUuh031099; Tue, 19 Apr 2016 10:11:30 -0700
Received: from localhost (Unknown UID 17623@localhost) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u3JHBUkF031083; Tue, 19 Apr 2016 10:11:30 -0700
X-Auth-Received: from [73.239.169.224] by hymn04.u.washington.edu via HTTP; Tue, 19 Apr 2016 10:11:30 PDT
Date: Tue, 19 Apr 2016 10:11:30 -0700 (PDT)
From: Tom Henderson <tomhend@u.washington.edu>
To: hip WG <hipsec@ietf.org>, Miika Komu <miika.komu@ericsson.com>
Message-ID: <alpine.LRH.2.01.1604191011300.16100@hymn04.u.washington.edu>
User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 8BIT
X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.19.170315
X-PMX-Server: mxout26.s.uw.edu
X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, BODY_SIZE_6000_6999 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __FRAUD_BADTHINGS 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __USER_AGENT 0'
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/tdcJGQS33zNPYV_Vzhbl7GgyMPE>
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: Tue, 19 Apr 2016 17:12:12 -0000

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)