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

[Tom Henderson <[e-mail]>]

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)