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 -> documentOK (remainder of comments will be addressed in a second message)
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
