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
