Re: a review of ietf-hip-rfc5206-bis-10

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)
>

_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec