Re: [Hipsec] some comments for mm-03

[Miika Komu <[e-mail]>]

On Tue, 4 Apr 2006, Miika Komu wrote:

> > Some comments for mm-03, part 1/2 (I'll send the rest later this
> > evening).
>
> Here we go again.. decided to split the email on separate sections. Here
> is (the end of section three and) section 4.

And here are comments from section five.

> 5.  Processing rules

(perhaps a tiny intro)

> 5.1.  Locator data structure and status
>
> Rapidly sending conflicting LOCATORs SHOULD be avoided.

What conflicting means here?

This section does not talk about selecting the source address for a
locator to be sent. Suggest adding text on what to choose as the source
address: the newly obtained locator or, in the case of multiple obtained
locators, selection according to a local policy.

> 3.  Host multihoming (addition of an address).  We only describe the
>     simple case of adding an additional address to a single-homed,
>     non-mobile host.

s/single-homed/multi-homed/ ?

> To do this, the multihomed host creates a new inbound SA and creates a
> new ESP_INFO parameter with an "Old SPI" parameter of "0", a "New SPI"
> parameter corresponding to the new SPI, and a "Keymat Index" as selected
> by local policy.

To do this, the multihomed host creates a new inbound SA and creates a new
SPI. For the outgoing UPDATE message, it inserts an ESP_INFO parameter
with an "Old SPI" field of "0", a "New SPI" field corresponding to the new
SPI, and a "Keymat Index" as selected by local policy.

> 5.3.  Handling received LOCATORs
>
> A host SHOULD be prepared to receive a LOCATOR parameter in any HIP
> packet, excluding I1.

...and CLOSE and notify?

> The ESP_INFO parameter is included if there is a need to rekey or key a
> new SPI

s/if/when/

> The LOCATOR parameter contains a complete map of the locators that the
> host wishes to make or keep active for the HIP association.

Currently, only a single ESP_INFO and LOCATOR are allowed in a HIP
message.

> 1.  The host checks if the New SPI listed in the ESP_INFO is a new
>     one.  If it is a new one, it creates a new inbound SA with that
>     SPI that contains no addresses.  If it is an existing one, it
>    prepares to change the address set on the existing SPI.

If the SPI is invalid, the packet MUST be dropped.

> 2.  For each locator listed in the LOCATOR parameter, check that the
>     address therein is a legal unicast or anycast address.  That is,
>     the address MUST NOT be a broadcast or multicast address.  the
>     local host, since it may be allowed that the host runs HIP with
>     itself.

Also, when receiving link local addresses, they should be used only when
no public addresses are present. The link local addresses may create
reachability problems after the host moves to another network.

> 3.  For each Type 1 address listed in the LOCATOR parameter, check if
>     the address is already bound to the SPI indicated.

For each Type 1 address listed in the LOCATOR parameter, the host checks
if the address is already bound to the SPI indicated.

> Mark all addresses on the SPI that were NOT listed in the LOCATOR
> parameter as DEPRECATED.

Mark all addresses corresponding to the SPI that were NOT listed in the
LOCATOR parameter as DEPRECATED.

> As a result, the SPI now contains any addresses listed in the LOCATOR
> parameter either as UNVERIFIED or ACTIVE, and any old addresses not
> listed in the LOCATOR parameter as DEPRECATED.

As a result, the addresses listed in the LOCATOR parameter have a either
state of UNVERIFIED or ACTIVE, and any old addresses not listed in the
LOCATOR parameter have a state of DEPRECATED.

> 4.  If the LOCATOR is paired with an ESP_INFO parameter, the ESP_INFO
>     parameter is processed as follows:

4.  Here, it is assumed that the LOCATOR is paired with an ESP_INFO
    which is processed as follows:

Should this be actually the first bullet instead of fourth?

(suggest using a different numbering style, e.g. letters, for the
following bullets)

> 1.  If the Old SPI indicates an existing SPI and the New SPI is a
>     different non-zero value, the existing SA is being rekeyed
>     and the host follows HIP ESP rekeying procedures.  Note that
>     the Locators in the LOCATOR parameter will use this New SPI
>     instead of the Old SPI.

Do you mean Type 0 Locators? Type 1 Locators have an additional SPI field.

> 2. If...

When...

> 3.  If the Old SPI indicates an existing SPI and the New SPI is
>     zero, the SPI is being deprecated and all locators uniquely
>     bound to the SPI are put into DEPRECATED state.

s/If/When/

Is the LOCATOR still processed, and if yes, how?

> 4.  If the Old SPI equals the New SPI and both correspond to an
>     existing SPI, the ESP_INFO is gratuitous (provided for
>     middleboxes) and no rekeying is necessary.

s/equals/equals to/

5. Otherwise, drop?

> 5.  Mark all locators on each SPI that were NOT listed in the LOCATOR
>     parameter as DEPRECATED.

s/on/for/

> Once the host has updated the SPI, if the LOCATOR parameter contains
> a new preferred locator, the host SHOULD initiate a change of the
> preferred locator.  This requires that the host first verifies
> reachability of the associated address, and only then changes the
> preferred locator.  See Section 5.6.

Once the host has updated the SPI and the LOCATOR parameter contains a new
preferred locator, the host SHOULD first verify the reachability of the
preferred locator. Only after that the host uses it for ESP communication
with the peer. See Section 5.6.

> 5.4.  Verifying address reachability

I'd say explicitly the following somewhere in this chapter because it is
really manifested in the text:

All of the new addresses received in a locator MUST be verified
separately. This means that for each UPDATE with LOCATOR with N new
Locators, N UPDATE ECHO_REQUEST packets must be sent and accepted. The
source address of ECHO_REQUEST is the preferred address of the local host.

> For example, if the host is changing its SPI and is sending an ESP_INFO
> to the peer, the new SPI value SHOULD be random and the value MAY be
> copied into an ECHO_REQUEST sent in the rekeying UPDATE.

s/if/when/

> If the host is not rekeying, it MAY still use the ECHO_REQUEST parameter
> in an UPDATE message sent to the new address.

However, when the host is not changing its SPI, the MAY still add the
ECHO_REQUEST parameter in an UPDATE message sent to the new address.

> Note that in the case of receiving a LOCATOR on an R1 and replying with
> an I2, receiving the corresponding R2 is sufficient proof of
> reachability for the Responder's preferred address.

Note that in the case of receiving a new LOCATOR in an R1 and replying
with an I2 to the new address in the LOCATOR, receiving the corresponding
R2 from the new address is sufficient proof of reachability for the
Responder's preferred address.

> In some cases, it may be sufficient to use the arrival of data on a
> newly advertised SA as implicit address reachability verification,
> instead of waiting for the confirmation via a HIP packet (e.g., Figure
> 14).

In some cases, it MAY be sufficient to use the arrival of data on a newly
advertised SA as implicit address reachability verification as depicted in
Figure 14, instead of waiting for the confirmation via a HIP packet.

> Marking the address ACTIVE as a part of receiving data on the SA is an
> idempotent operation, and does not cause any harm.

Incorrect. The state is not changed as described 5.5.1.

> Figure 14

I think the names of "Mobile Host" and "Peer Host" could be swapped since
it is the "Peer Host" that is sending the SPI. Maybe "Peer Host" can be
changed to "Corresponding Node".

> 5.5.  Credit-Based Authorization

Add an intro. "CBA can be used to minimize the side effects of handovers.
It allows sending of data before address reachability test has been
completed to avoid transport layer timing problems. However, CBA cannot be
used for redirection amplification attacks."

> 5.5.1.  Handling Payload Packets

> When the host has a packet to be sent to the peer, if the peers
> preferred locator is listed as UNVERIFIED and no alternative locator
> with status ACTIVE is available, the host checks whether it can send the
> packet to the UNVERIFIED locator: The packet SHOULD be sent if the value
> of the credit counter is higher than the size of the outbound packet.

When the host has a packet to be sent to the peer, and when the peers
preferred locator is listed as UNVERIFIED and no alternative locator with
status ACTIVE is available, the host checks whether it can send the packet
to the UNVERIFIED locator. The packet SHOULD be sent if the value of the
credit counter is higher than the size of the outbound packet.

> 5.5.2.  Credit Aging

Is not obvious to me what should be the initial credit size?

> Credit aging may be implemented by multiplying credit counters with a
> factor, CreditAgingFactor, less than one in fixed time intervals of
> CreditAgingInterval length.

s/one/once/ ?

> 5.6.  Changing the preferred locator

5.6.  Changing the Preferred Locator

This section could be moved before CBA, that is, between sections 5.4 and
5.5.

-- 
Miika Komu              [e-mail]          http://www.iki.fi/miika/

_______________________________________________
Hipsec mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/hipsec