Subject: [Hipsec] some comments for mm-03

From: Miika Komu <[email-masked]>
Date: Mon, 3 Apr 2006 18:51:52 +0300 (EEST)

Some comments for mm-03, part 1/2 (I'll send the rest later this evening).
Should keep Thomas busy until then :)

I haven't read the mm-03 draft for a long time (1-2 years) througly,
so decided to do it now with fresh eyes. Below are my suggested
changes, but before that, a short executive summary of the
proposed changes:

* Mainly consists of many readability/understandability enchancements and
  requests for clarifications.
* Mainly, no new features. In fact, I suggest removing one
  feature/use-case (readdress with peer-initiated rekey) in favour of
  simplifying state machine, interaction with middle-boxes and
  interoperable implementations.
  Suggest removal of it from this draft and adding to a follow-up
  draft.
* An initial proposal for a state machine for mobility and multihoming
  based on the current text in the draft, excluding the (readdress with
  peer-initiated rekey). The actual state machine is in separate email.
* Some new text on closing of SAs in multihoming case.

I feel that the current draft is too "loose", just for the sake of
experimentation but IMHO it makes the implementation too complex in
practice and also makes the situation bad for the interoperability of
implementations. I believe that this can be accomplished by reducing
the functionality: removing the "readdress with peer-initiated
rekey" use case, sticking to three-way packet exchange and adding a
reference state machine.

Editorial comments:

> Abstract
>
> This document defines mobility and multihoming extensions to the Host
> Identity Protocol (HIP).

Add after this: The document assumes that ESP <xref="hip-esp"> is
being used.

(because the draft really assumes this)

> Table of Contents:

Section 3.2 assumes detailed knowledge (especially the three first
sections) of sections 4 and 5. Suggest making a forward reference in
the intro of the section 3.2 and some patience from the reader :)

Suggest adding section 3.2.9 (and perhaps 5.7) on "Closing of Security
Associations":

The SAs are closed as defined as in <xref="hip-base"> in the general
case. As such, closing of the SAs causes all of the SAs to be closed
also in multihoming scenarios. A host MAY add an ESP_INFO parameter to
a CLOSE message to signal that a specific SA is to be close. The
CLOSE-ACK message should also include the same ESP_INFO parameter. In
the ESP_INFO parameter, the old SPI corresponds to SA to be
removed. The new SPI and keymat index are set to zero.

> 1.  Introduction and Scope

Add somewhere: The document assumes that ESP <xref="hip-esp"> is
being used.

> We also do not consider localized mobility management extensions;

Please define "localized mobility management extensions" or give an
example of such a protocol.

> 2.  Terminology and Conventions
>
> Locator... It may also include transport port numbers or IPv6 Flow
> Labels as demultiplexing context, or it may simply be a network
> address.

Further extensions of this document may also include transport port
numbers or IPv6 Flow Labels as demultiplexing context. This document
only defines it simply as a network address.

Suggest adding also the definition of "SA selector" that later pops up
in the text suddenly. Perhaps it would be nice to have some
definitions also for SA and SPI also for the inexperienced reader.

> 3.  Protocol Model

Add an small intro? Here would be a good place to mention that the
UPDATE processing details are in sections 4 and 5.

> 3.1.  Operating Environment
> ..
> This document specifies extensions to the HIP protocol to enable
> end-host mobility and multihoming.

This document specifies extensions to the HIP protocol to enable
end-host mobility and basic multihoming.

> In summary, these extensions to the HIP protocol can carry new
> addressing information to the peer and can enable direct
> authentication of the message via a signature or keyed hash message
> authentication code (HMAC) based on its host identity.

In summary, these extensions to the HIP base protocol enable carrying
of new address related information to the peer in HIP messages. The
messages are authenticated using public key signatures and keyed hash
message authentication codes (HMAC).

> Figure 2: Architecture for  HIP mobility and multihoming

* The MH abbreviation is not explained in the text, nor in the caption.
* I am not still convinced that the figure is more illustrative than
  confusing but I have nothing better to offer, so I let it be. Perhaps
  you need to be sure to mention in the text that it is neither a picture
  of the  networking stack to be used for packet en/decapsulation nor a
  software module organization.
* You may want to say that MH box is separate from HIP for i.e. to be
  usable also for other protocols?

> The SPI (or other context tag if ESP is not used with HIP), and not
> necessarily the IP addresses, is used to associate an incoming packet
> with the right HITs.

The SPI is used to associate an incoming packet with the right HITs.

> The HIP base exchange establishes the HITs in use between the hosts,
> the SPIs to use for ESP, and the IP addresses (used in the HIP
> signaling packets).

The HIP base exchange establishes the HITs in use between the hosts,
the SPIs to use for ESP, and the IP addresses (used both in the HIP
signaling packets and ESP data packets).

> Note that there can only be one such binding in the outbound
> direction for any given packet, and the only selectors for the
> binding at the HIP layer are the fields exposed by ESP (the SPI and
> HITs).

What binding? HIT-to-IP or HIT-to-SPI or IP-to-SPI? What selectors,
and what are they supposed to select?

> This document specifies the messaging and elements of procedure for
> such a mobility event.

This sentence can be safely removed.

> Finally, consider the case when a host is multihomed (has more than
> one globally routable address) and wants to make these multiple
> addresses available for use by the upper layer protocols, for fault
> tolerance.

Finally, consider the case when a host is multihomed (has more than
one globally routable address) and makes these multiple addresses
available for use by the upper layer protocols, for example, for fault
tolerance.

> However, only one SPI and address can be used for any given packet, so
> the job of the "MH" block depicted above is to dynamically manipulate
> these bindings.

However, only one SPI and address pair can be used for an ESP packet, so
the job of the "MH" block depicted above is to dynamically manipulate
these bindings.

Comment: seems like the MH is really required for:

* Selection of outgoing SAs if multiple present (for incoming it is not
  really necessary because we just use SPI present in the packet)
* Perhaps for tracking the CBA credits and communicating them to HIP.

Maybe you want to de-blur the meaning of the MH somewhere in section
3.1. See also my next comment.

> This document does not specify the "MH" block, nor does it specify
> detailed elements of procedure for how to handle various multihoming
> (perhaps combined with mobility) scenarios.

The document wants to specify a blurry concept of MH but really does
not do it? Compare to my previous comment.

> 3.1.1.  Locator
>
> Or locators may merely be traditional network addresses.  In Section
> 4, a generalized HIP LOCATOR parameter is defined that can contain
> one or more locators (addresses).

It is also possible that locators are merely traditional network
addresses. The actual format of the locators is defined in section 4.

> 3.1.2.  Mobility overview
>
> This UPDATE packet is acknowledged by the peer, and is
> protected by retransmission.

This UPDATE packet is acknowledged by the peer. To ensure that packets
are not lost or corrupted, proper retransmission mechanisms are used.

> However, the peers are not able to reply before they can reliably and
> securely update the set of addresses that they associate with the
> sending host.

s/reply/comminicate/

> 3.1.3.  Multihoming overview
>
> Although this document defines a mechanism for  multihoming,

basic mechanism

> 3.2.  Protocol Overview

It might be good to explain the ESP_INFO old and new SPI fields
because they are not introduced but still used the subsections.

> Each of the scenarios below assumes that the HIP base exchange has
> completed, and the hosts each have a single outbound SA to the peer
> host.  Associated with this outbound SA is a single destination
> address of the peer host-- the source address used by the peer
> during the base exchange.

The scenarios below assume that the two hosts have completed a single
HIP base exchange with each other. Both of the hosts have one incoming
and one outgoing SA. Further, each SA contains the two IP addresses
the hosts were using for the base exchange.

> The main packets on which the LOCATOR parameters are expected to be
> carried are UPDATE packets.

The majority of packets on which the LOCATOR parameters are expected
to be carried on are UPDATE packets.

> 3.2.1.  Mobility with single SA pair (no rekeying)

Add some text between the figure and numbered bullets:

  The steps of the packet processing are as follows:

In second bullet: s/hte/the/

> 3.2.1.2.  Mobility with single SA pair (peer-initiated rekey)

What was the use case for doing this? If there is no really strong use
case, I suggest removing this section from the draft and perhaps
adding it a follow-up draft. This way, the state machine has a simpler
design (three packets) and is easier to implement. See my following
email.

> 3.2.2.  Host multihoming
>
> Consider the case between two single-homed hosts, in which one of
> the host notifies the peer of an additional address.

Consider the case between hosts, one single-homed and the other
multi-homed. The multihomed host notifies the peer of an additional
address.

> It is RECOMMENDED that the host set up a new SA pair for use on this
> new address.

s/host/multihomed host/

> A Locator Type of "1" is used to associate the new address with the
> new SPI.  The LOCATOR parameter also contains a second Type 1
> locator: that of the original address and SPI.

The latter sentence does not really make sense:

  * The sentence above basically says that there is a locator parameter
    embedded inside another locator parameter.

  * If it was meant that there are actually two separate locators this
does
    make sense because in the figure below shows only one and somewhere
    in the draft it was said that multiple locator parameters are out of
scope.

> To simplify parameter processing and avoid explicit protocol
> extensions to remove locators, each LOCATOR parameter must list all
> locators in use on a connection (a complete listing of inbound
> locators and SPIs for the host).

s/must/MUST/

> The multihomed host transitions to state REKEYING, waiting for a
> ESP_INFO (new outbound SA) from the peer and an ACK of its own
> UPDATE.

REKEYING state does not exist anymore.

> As in the mobility case, the peer host must perform an
> address verification before putting the new address into active use.

s/putting/changing/

> Figure 6 illustrates the basic packet exchange.

Figure 6 illustrates this scenario.

> Figure 6: Basic multihoming scenario

Is the ECHO_RESPONSE 100 % sure way to map the last incoming UPDATE to
certain SA? Why don't we just include the ESP_INFO? If this is the
case, why don't we do also for the other use cases for generality's
sake.

> When processing inbound LOCATORs that establish new security
> associations on an interface with multiple addresses, a host uses the
> destination address of the UPDATE containing LOCATOR as the local
> address to which the LOCATOR plus ESP_INFO is targeted.  Hosts may
> send UPDATEs with the same IP address in the LOCATOR to different
> peer addresses-- this has the effect of creating multiple inbound SAs
> implicitly affiliated with different peer source addresses.

This text was just somehow too confusing. Suggest rewriting again with
simplicity in mind, or removing (I am almost sure that this text is
described also later on).

> 3.2.4.  Dual host multihoming
>
> In Figure 7, consider that host1 wants to add address addr1b.

Please explain what addresses and SPIs are negotiated before this.

> It would send an UPDATE with LOCATOR to host2 located at addr2a, and
> a new set of SPIs would be added between hosts 1 and 2 (call them
> SPI1b and SPI2b).

Please make sure that this sentence makes sense after describing the
initial scenario better. Also, SPI1b and SPI2b are not shown in the
figure.

> 3.2.6.  Using LOCATORs across addressing realms
>
> In such a case, some type
> of mechanism for interworking between the different realms must be
> employed; such techniques are outside the scope of the present text.

Maybe you could still mention few experimental techniques. The problem
is as follows:

* Host I has run base exchange with host R using IPv6
* IPv4 address is added to host I
* Host I is supposed to send UPDATE to host R
  * LOCATOR = the new IPv4 address
  * IP header source address = the new IPv4 address
  * IP header dst address = <unknown>

So, the problem is that the host I has no knowledge of the R's IPv4
address. This can be handled in at least in two ways:

a) Both the IPv4 and IPv6 address of R are known by host I before it
   initiates base exchange, e.g., they are configured manually or
   DNS.

b) Host R communicates both its IPv4 and IPv6 address to host I in the
   R1 packet in LOCATOR (as defined in section 3.2.8).

(The methods above were obtained from a discussion with Jan)

> 3.2.8.  Initiating the protocol in R1 or I2

3.2.8. Communicating LOCATORs in R1 or I2

> All new non-preferred locators must still undergo address
> verification.

as defined in section XX ...but only after the base exchange has
completed.

> Even if the I2 packet contains LOCATOR parameters, the Responder
> MUST still send the R2 packet to the source address of the I2.

I1 and I2 source address must be the same?

> The new preferred locator SHOULD be identical to the I2 source
> address.  If the I2 packet contains LOCATOR parameters, all new
> locators must undergo address verification as usual.

Finally, the possibly following ESP traffic uses the negotiated
preferred locators.

Perhaps also the ESP traffic could be illustrated also in the
figures. Also, a figure for the case where both hosts include
additional locators would be nice.

> 3.3.2.  Credit-Based Authorization
>
> Credit-Based Authorization allows a host to securely use a new
> locator even though the peer's reachability at the address embedded
> in this locator has not yet been verified.

s/this/the received/

> 1.  A flooding attacker typically seeks to somehow multiply the
>     packets it generates itself for the purpose of its attack because
>     bandwidth is an ample resource for many attractive victims.

s/itself//
s/attractive//

> 3.  Consequently, the additional effort required to set up a
>     redirection-based flooding attack would pay off for the attacker
>     only if amplification could be obtained this way.

3.  Consequently, the additional effort required to set up a
    redirection-based flooding attack (without CBA and return routability
    checks) would pay off for the attacker only if amplification could be
    obtained this way.

> On this basis, rather than eliminating malicious packet redirection in
> the first place, Credit-Based Authorization prevents any amplification
> that can be reached through it.

On this basis, rather than eliminating malicious packet redirection in
the first place, Credit-Based Authorization prevents any packet
amplifications.

> Figure 10 illustrates Credit-Based Authorization: Host B measures
> the bytes recently received from peer A and, when A readdresses,
> sends packets to A's new, unverified address as long as the sum of
> their sizes does not exceed the measured, received data volume.

What is "their" referring to?

> Figure 10.

Can the "+ address change" in the lower left corner be removed?

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

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

---

From: Miika Komu <[email-masked]>
Date: Tue, 4 Apr 2006 00:29:30 +0300 (EEST)

> Some comments for mm-03, part 1/2 (I'll send the rest later this

Here we go again.. decided to split the email on separate sections. Here
is (the end of section three and) section 4.

> 3.3.4.  Interaction with Security Associations
>
> This document specifies a new HIP protocol parameter, the LOCATOR
> parameter (see Section 4), that allows the hosts to exchange information
> about their locator(s), and any changes in their locator(s).

This document specifies a new HIP protocol parameter, the LOCATOR
parameter (see Section 4), that allows the hosts to exchange
information about changes their locator(s).

> The relation between these entities for an association negotiated as
> defined in the base specification [2] and ESP transform [5] is
> illustrated in Figure 11.

What entities? There is also something other fishy with this sentence.

> The addresses addr1a and addr2a are the source addresses that each host
> uses in the base HIP exchange.

The addresses addr1a and addr2a are the source addresses that the hosts
use in the base HIP exchange.

> These are the "preferred" (and only) addresses conveyed to the peer for
> each SA; even though packets sent to any of the hosts' interfaces can
> arrive on an inbound SPI, when a host sends packets to the peer on an
> outbound SPI, it knows of a single destination address associated with
> that outbound SPI (for host1, it sends a packet on SPI2a to addr2a to
> reach host2), unless other mechanisms exist to learn of new addresses.

* Perhaps you just replace the SA with SPI because SA is not really
  illustrated in the figure.
* This is an overly long sentence, suggest splitting into 2-3 sentences.
* I think that "arrive on SPI", "send to peer SPI" and
  "send packet on SPI" could be said in a better way.

> In this figure, a host can have multiple inbound SPIs (and, not shown,
> multiple outbound SPIs) between itself and another host.

s/between/associated with/

> These addresses bound to an SPI are not used as SA selectors.

(I suggested writing the term "SA selector" to the terminology in the
beginning)

> The LOCATOR parameter allows for IP addresses and SPIs to be combined to
> form generalized locators.

I am not sure if "generalized" is the right term, but rather "locators for
suitable for IPsec use" etc. In any case, this sentence can be removed
from here as it is repeated elsewhere.

> Figure 12

This figure reminds me that is it possible to have both SPI1 and SPI2
mapping to the same ADDR21?

> The main purpose of having multiple SPIs is to group the addresses into
> collections that are likely to experience fate sharing.

The main purpose of having multiple SPIs with a peer is to group the
addresses into collections that are likely to experience fate sharing.

> For this reason, HIP provides a mechanism to affiliate destination
> addresses with inbound SPIs, if there is a concern that anti-replay
> windows might be violated otherwise.

s/if/when/
s/otherwise//

> Moreover, even if the destination addresses used for a particular SPI
> are held constant, the use of different source interfaces may also cause
> packets to fall outside of the ESP anti-replay window, since the path
> traversed is often affected by the source address or interface used.

s/if/when

> A host has no way to influence the source interface on which a peer uses
> to send its packets on a given SPI.

A host has no way to influence the source interface on which a peer sends
its packets using a given SPI.

> Hosts SHOULD consistently use the same source interface and address when
> sending to a particular destination IP address and SPI.

s/Hosts/A host/

> If the LOCATOR parameter is sent in an UPDATE packet, then the
> receiver will respond with an UPDATE acknowledgment.

When the LOCATOR parameter is sent in an UPDATE packet, then the
receiver responds with an UPDATE acknowledgment.

> If the LOCATOR parameter is sent in a NOTIFY, I2, or R2 packet, then the
> recipient may consider the LOCATOR as informational, and act only when
> it needs to activate a new address.

If the LOCATOR parameter is sent in a NOTIFY, I2, or R2 packet, the
recipient MUST consider the LOCATOR as informational, and act only when it
needs to activate a new address.

What does "act" mean here?

> The use of LOCATOR in a NOTIFY message may not be compatible with
> middleboxes.

> 4.  LOCATOR parameter format

Is there are specific reason why the reserved field cannot be just flags?

> Length: Length in octets, excluding Type and Length fields, and
> excluding padding.

Minimum length (is a locator without any address allowed)? Maximum length?

> Locator Length: Defines the length of the Locator field, in units of
> 4-byte words (Locators up to a maximum of 4*255 bytes are supported).

s/bytes/octets/

> Locator: The locator whose semantics and encoding are indicated by the
> Locator Type field.  All Locator sub-fields are integral multiples of
> four bytes in length.

It is slightly confusing that there is LOCATOR and Locator :) Perhaps this
should be noted in the terminology.

s/bytes/octets/

> The address is expected to become deprecated when the specified number
> of seconds has passed since the reception of the message.

Also, CLOSE can be used for premature expiration of addresses.

> A deprecated address SHOULD NOT be used as an destination address if an
> alternate (non-deprecated) is available and has sufficient scope.

In the case of many alternatives, the host chooses according to
local host policies.

> 4.1.  Traffic Type and Preferred Locator
>
> The "P" bit, when set, has scope over the corresponding Traffic Type
> that precedes it.

s/precedes it//

> That is, if a "P" bit is set for Traffic Type "2", for example, that
> means that the locator is preferred for data packets.

That is, when a "P" bit is set for Traffic Type "2", for example, it means
that the locator is preferred for data packets.

> If there is a conflict (for example, if P bit is set for an address of
> Type "0" and a different address of Type "2"), the more specific Traffic
> Type rule applies.

If there is a conflict (for example, if P bit is set for an address of
Type "0" and a different address of Type "2"), the more specific Traffic
Type rule applies (in this case it was "2").

This seems to complicate the processing rules. Unless there is a special
reason for doing this, it migth be easier to forbid mixing type 0 locators
with type 1 or 2 locators.

> 4.2.  Locator Type and Locator

> 0:  An IPv6 address or an IPv4-in-IPv6 format IPv4 address [7] (128
>     bits long).

Suggest adding: Currently, mostly for non-ESP based usage.

> 1:  The concatenation of an ESP SPI (first 32 bits) followed by an
>     IPv6 address or an IPv4-in-IPv6 format IPv4 address (an additional
>     128 bits).

Suggest adding: Recommend for ESP based usage.

> 4.3.  UPDATE packet with included LOCATOR

Add to this section some text about the correspondence between ESP_INFO
and Type 1 LOCATORS.

---

From: Miika Komu <[email-masked]>
Date: Tue, 4 Apr 2006 02:05:44 +0300 (EEST)

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

---

From: Miika Komu <[email-masked]>
Date: Wed, 5 Apr 2006 10:34:01 +0300 (EEST)

My last comments, from section six:

> 6.  Security Considerations
>
> If no precautionary measures are taken, an attacker could misuse this
> feature to impersonate a victim's peer from any arbitrary location.

s/this/the redirection/

> If an attacker somehow uses a bug in the implementation or weakness in
> some protocol to redirect a HIP connection, the original owner can
> always reclaim their connection (they can always prove ownership of the
> private key associated with their public HI).

How is this possible if the private key is compromised?

> MitM attacks are always possible if the attacker is present during the
> initial HIP base exchange and if the hosts do not authenticate each
> other's identities, but once the base exchange has taken place even a
> MitM cannot steal an opportunistic HIP connection because it is very
> difficult for an attacker to create an UPDATE packet (or any HIP packet)
> that will be accepted as a legitimate update.

This does not make sense because it is too obvious? After opportunistic
connection (leap of faith) the connection is no longer opportunistic.
Maybe this text can be just removed.

> 6.2.  Denial of Service attacks

> This threat is mitigated through reachability checks and credit-based
> authorization.

This threat is mitigated through reachability checks and credit-based
authorization strategies.

> As a result, the combination of a reachability check and credit-based
> authorization makes a HIP redirection-based flooding attack as effective
> and applicable as a normal, direct flooding attack in which the attacker
> itself sends the flooding traffic to the victim.

As a result, the combination of a reachability check and credit-based
authorization degrades a HIP redirection-based flooding attack to the
level of a direct flooding attack in which the attacker itself sends the
flooding traffic to the victim.

> First, when a reachability packet is received, this nonce packet MUST be
> ignored if the HIT is not one that is currently active.

First, when a reachability packet is received, the nonce in the packet
MUST be ignored if the HIT is not one that is currently active.

What does a currently active HIT mean? You probably mean address...

> Second, if the attacker is a MitM asnd can capture this nonce packet
> then it can respond to it, in which case it is possible for an attacker
> to redirect the connection.

How?

> 6.2.2.  Memory/Computational exhaustion DoS attacks

Suggest adding some text that central servers may have to deal with
multiple mobile clients that change their location rapidly. This may
burn too many CPU cycles of the server, and in such a case, the server may
want to e.g. increase its SA lifetimes or increase cookie difficulty to
slow down acceptance of new connections.

> 6.3.  Mixed deployment environment

s/user/host/ in this section?
s/their/its/ in this section

I did not get the purpose of this section. If you user A uses IPsec, user
B does not get anything meaninful even though the IPsec data is redirected
from A to B.

> ..connection with and then attempts to use a IPv6 change of address
> request to steal the HIP user's connection.

..connection with and then attempts to change its IPv6 address to steal
the HIP user's connection.

> 4. ..

What is a session here? TCP session?

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 7 Apr 2006 09:51:29 -0700

Miika, thank you for this detailed review.  I will answer them in-line,
and eventually put out a new -04 preview corresponding to these changes.

> -----Original Message-----
> From: Miika Komu [mailto:[email-masked]] 
> Sent: Monday, April 03, 2006 8:52 AM
> To: [email-masked]
> Subject: [Hipsec] some comments for mm-03
> 

I would suggest not including this in the abstract.  It may be that much
of this is reusable for other transport formats.  It is stated in the
Introduction:

      While HIP can potentially be used with transports other than
      the ESP transport format,
      this document largely assumes the use of ESP and leaves other
      transport for further study.

and also in Section 3.2:
   These scenarios assume that HIP is
   being used with the ESP transform [5], although other scenarios may
   be defined in the future.  

> the intro of the section 3.2 and some patience from the reader :)

OK

> removed. The new SPI and keymat index are set to zero.

I do not necessarily agree with this, and would like to hear other
opinions.  CLOSE should close all security associations; if a specific
SA is to be closed while others remain open, it should be possible to do
so through the UPDATE protocol. 

> Add somewhere: The document assumes that ESP <xref="hip-esp"> is

This is already in the Introduction (see above).

> example of such a protocol.

An example might be the protocols defined in netlmm or mipshop groups.
I will clarify by adding "localized mobility management extensions
(i.e., mobility management techniques that do not involve directly
signaling the correspondent node)"

> UPDATE processing details are in sections 4 and 5.

OK

> end-host mobility and basic multihoming.

OK

> message authentication codes (HMAC).

OK

> * The MH abbreviation is not explained in the text, nor in 

added to caption.  It is defined later in the text.

>   software module organization.

I think it is what it says it is-- a layered architectural description.

>   usable also for other protocols?

Added.

> The SPI is used to associate an incoming packet with the right HITs.

OK

> signaling packets and ESP data packets).

OK

> and what are they supposed to select?

s/such binding/such set of bindings/
The selectors are those fields that are used to select the next field
that needs to be assigned (in this case, the SPI and HITs are the fields
available to select the IP addresses)

> This sentence can be safely removed.

OK

> available for use by the upper layer protocols, for example, for fault

OK

> the job of the "MH" block depicted above is to dynamically manipulate

OK

> * Perhaps for tracking the CBA credits and communicating them to HIP.

also possibly transport triggers to signal path change events.

> not do it? Compare to my previous comment.

Well, I think that it just indicates that some kind of functional block
is needed there, without trying to specify it.  IMO, this will be harder
to specify than mobility, and will have some commonality with what shim6
is trying to define.

> addresses. The actual format of the locators is defined in section 4.

OK

> > securely update the set of addresses that they associate with the

s/reply/send packets to these new addresses/

> > Although this document defines a mechanism for  multihoming,

OK

> because they are not introduced but still used the subsections.

Added a little text for this.

> the hosts were using for the base exchange.

OK (I slightly modified).
> to be carried on are UPDATE packets.

OK

>   The steps of the packet processing are as follows:
OK
> In second bullet: s/hte/the/
OK
> design (three packets) and is easier to implement. See my following

I am fine with this (will respond to your other mail), as long as we
cleanly deal with the possibility of collision of UPDATEs.  
> multi-homed. The multihomed host notifies the peer of an additional
OK

> > It is RECOMMENDED that the host set up a new SA pair for use on this

OK
>     in the draft it was said that multiple locator parameters 

I think you are confusing LOCATOR (parameter type) with locator (address
within the parameter).  I think the sentence is correct and necessary.

> > locators and SPIs for the host).

OK

> REKEYING state does not exist anymore.

Right-- deleted this.

> > address verification before putting the new address into active use.
s/putting the new address into active use/actively using the new
address/
> Figure 6 illustrates this scenario.

OK
> case, why don't we do also for the other use cases for generality's

I had always thought that the HIP daemon would use the SEQs and ACKs to
map
these packets.  I do not have a problem with including ESP_INFO, either
as a MUST or a MAY, to help implementors (although it would have to be
treated as a protocol error if it didn't match the original ESP_INFO).
What do other implementors think?

> described also later on).

I think that the point is important-- tried to clarify it.

> Please explain what addresses and SPIs are negotiated before this.

OK

> initial scenario better. Also, SPI1b and SPI2b are not shown in the

Clarified.

> (The methods above were obtained from a discussion with Jan)

OK, added some discussion along these lines.

> as defined in section XX ...but only after the base exchange has
OK

> I1 and I2 source address must be the same?

What does it matter?  I1 state is not kept by responder.

> Finally, the possibly following ESP traffic uses the negotiated

OK
 
> additional locators would be nice.

I am electing to skip these optional mods.

> > in this locator has not yet been verified.
s/this/the
>     checks) would pay off for the attacker only if 

OK

> What is "their" referring to?
s/their/the packet/
> Can the "+ address change" in the lower left corner be removed?

I will check with Christian about this figure, as your question has
raised also a question in my mind whether it is correct.

Tom

---

From: Miika Komu <[email-masked]>
Date: Sat, 8 Apr 2006 14:58:32 +0300 (EEST)

>    be defined in the future.

Fine.

> so through the UPDATE protocol.

So, there seems to be some redundancy with CLOSE and UPDATE. In fact, I'd
say that the CLOSE could be replaced with UPDATE as it implements only a
subset of UPDATE. Petri, Pekka, others - comments?

> cleanly deal with the possibility of collision of UPDATEs.

Waiting for the follow-up email, no hurry.

> within the parameter).  I think the sentence is correct and necessary.

You are correct. This should be clarified at least in the terminology
section. Another way, perhaps a more clear way, to do this is to rename
LOCATOR to LOCATOR_{SET|GROUP|BAG|ETC}.

> map these packets.  I do not have a problem with including ESP_INFO,
> either as a MUST or a MAY, to help implementors (although it would have
> to be treated as a protocol error if it didn't match the original
> ESP_INFO). What do other implementors think?

Now rethinking this again, base draft says "The Update ID has scope within
a single HIP association, and not across multiple associations or multiple
hosts.". As a result, the update ID should be enough information to map
the incoming packet to a SA.

However, requiring the use of ESP_INFO in all UPDATE packets would be at
least systematical and implementor friendlier. Less indexing required
in the implementation. Maybe it is also better for middleboxes.

> What does it matter?  I1 state is not kept by responder.

Cookies might get burned if the indexing is affected by the IP addresses
:)

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 10 Apr 2006 06:37:41 +0300

[Answering bit-by-bit as most probably I won't have time to go
over all related messages at this point of time.]

> subset of UPDATE. Petri, Pekka, others - comments?

IIRC, CLOSE was added fairly late in order to allow the _HIP_  
association to be cleanly torn down.  I think Erik Nordmark suggested  
adding it.

I don't think it is a good idea to use CLOSE for closing SAs, or for  
any other purpose than closing the who HIP SA.  If I understand  
correctly the text above, you Miika are suggesting to use CLOSE to  
close only specific ESP SAs but not the HIP association.  That sounds  
like a pretty bad idea to me, confusing the semantics of CLOSE.  But  
perhaps I don't understand what you are suggesting, Miika?

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 10 Apr 2006 06:51:25 +0300

>>> Is the ECHO_RESPONSE 100 % sure way to map the last incoming  
>>> UPDATE to certain SA? Why don't we just include the ESP_INFO? If  
>>> this is the case, why don't we do also for the other use cases  
>>> for generality's sake.
>>
>> I had always thought that the HIP daemon would use the SEQs and  
>> ACKs to map these packets.  I do not have a problem with including  
>> ESP_INFO, either as a MUST or a MAY, to help implementors  
>> (although it would have to be treated as a protocol error if it  
>> didn't match the original ESP_INFO). What do other implementors  
>> think?

> Now rethinking this again, base draft says "The Update ID has scope  
> within a single HIP association, and not across multiple  
> associations or multiple hosts.". As a result, the update ID should  
> be enough information to map the incoming packet to a SA.
>
> However, requiring the use of ESP_INFO in all UPDATE packets would  
> be at least systematical and implementor friendlier. Less indexing  
> required in the implementation. Maybe it is also better for  
> middleboxes.

I could imagine privacy reasons why you may not want to add ESP_INFO  
in those UPDATE packets that you use to verify address reachability.   
Not particularly strong privacy reasons, but still.  Hence, IMHO  
including ESP_INFO in those packets should be at most SHOULD, and  
probably MAY, if people want it.  On the other hand, I don't  
understand this issue from the implementers' point of view, and would  
be very interested in hearing counter arguments.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 10 Apr 2006 07:33:56 +0300

> How is this possible if the private key is compromised?

If the private key is compromised, there is nothing you can do.  The  
only think you can do is to revoke the public key; something the (so  
far) have deliberately left out of scope.

> Maybe this text can be just removed.

It may be obvious to you and me, but not to everyone.

--Pekka

---

From: Jan Mikael Melen <[email-masked]>
Date: Mon, 10 Apr 2006 09:05:09 +0300

Hi,

I just want to say that I agree with Pekka that using the CLOSE message for 
closing something else than the whole HIP association is a bad idea. IMHO the 
semantics of CLOSE and UPDATE are different. UPDATE means that you are 
updating something and still want to continue using the previously created 
HIP association. CLOSE means that you want to end the communication, you 
don't want to send anymore anything using the existing HIP association.

  Regards,
    Jan

---

From: Jan Mikael Melen <[email-masked]>
Date: Mon, 10 Apr 2006 09:05:09 +0300

Hi,

  Regards,
    Jan

---

From: Miika Komu <[email-masked]>
Date: Mon, 10 Apr 2006 12:16:43 +0300 (EEST)

On Mon, 10 Apr 2006, Jan Mikael Melen wrote:

Agree. Thomas, may be you can add a similar text to the mm draft?

> > >> opinions.  CLOSE should close all security associations; if a
> > From [email-masked] Mon Apr 10 05:16:53 2006
Date: Mon, 10 Apr 2006 12:16:43 +0300 (EEST)
From: Miika Komu <[email-masked]>
To: Jan Mikael Melen <[email-masked]>
Subject: Re: [Hipsec] some comments for mm-03: CLOSE vs. UPDATE
Cc: [email-masked], [email-masked]

On Mon, 10 Apr 2006, Jan Mikael Melen wrote:

Agree. Thomas, may be you can add a similar text to the mm draft?

---

From: Miika Komu <[email-masked]>
Date: Mon, 10 Apr 2006 12:16:43 +0300 (EEST)

> semantics of CLOSE and UPDATE >> specific

---

From: Miika Komu <[email-masked]>
Date: Mon, 10 Apr 2006 12:16:43 +0300 (EEST)

> > >> specific

are different. UPDATE means that you are
> > >> specific

---

From: Miika Komu <[email-masked]>
Date: Mon, 10 Apr 2006 12:35:08 +0300 (EEST)

On Mon, 10 Apr 2006, Pekka Nikander wrote:

> Not particularly strong privacy reasons, but still.

What are the privacy reasons in this case? The SPIs are already exposed in
the two first packets, so why not also in the third?

> Hence, IMHO including ESP_INFO in those packets should be at most
> SHOULD, and probably MAY, if people want it.

I'd like it to be MUST (or SHOULD) just to reduce the (probability of)
different combinations. Or as an alternative, leave it as it is now.

> On the other hand, I don't understand this issue from the implementers'
> point of view, and would be very interested in hearing counter
> arguments.

My point was to reduce the number of indexing mechanisms required in the
implementations. When you receive an UPDATE packet containing an ECHO
RESPONSE but without ESP_INFO, you need yet another index (the UPDATE ID)
to map the packet to the corresponding SA. However, if we had the the
ESP_INFO included, we'd find the SA just with the existing SPI search
mechanisms that are already required for base exchange.

---

From: Miika Komu <[email-masked]>
Date: Mon, 10 Apr 2006 12:39:28 +0300 (EEST)

> It may be obvious to you and me, but not to everyone.

This was mostly a readibility comment. I suggest changing the text as
follows:

MitM attacks are always possible when the attacker is present during the
initial HIP base exchange and the hosts do not authenticate each other's
identities. However, once the opportunistic base exchange has taken place,
even a MitM cannot steal the HIP connection anymore because it is very
difficult for an attacker to create an UPDATE packet (or any HIP packet)
that will be accepted as a legitimate update.

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 10 Apr 2006 12:49:24 +0300

> mechanisms that are already required for base exchange.

How come?  Why don't you just include the necessary info in you  
ECHO_REQUEST?  You can even include a direct memory pointer if you  
dare (but I wouldn't do that... :-)  You are free to include any  
information you want there, aren't you?

--Pekka

---

From: Miika Komu <[email-masked]>
Date: Mon, 10 Apr 2006 15:16:11 +0300 (EEST)

On Mon, 10 Apr 2006, Pekka Nikander wrote:

> > My point was to reduce the number of indexing mechanisms required in
> > the implementations. When you receive an UPDATE packet containing an
> > ECHO RESPONSE but without ESP_INFO, you need yet another index (the
> > UPDATE ID) to map the packet to the corresponding SA. However, if we
> > had the the ESP_INFO included, we'd find the SA just with the existing
> > SPI search mechanisms that are already required for base exchange.
>

You are correct. The implementation can "hide" e.g. a SPI in the
ECHO_REQUEST or even in SEQ/ACK update if this explicit handling is not
wanted. So, it appears now to me that this idea can be forgotten. However,
I'd like to see a hint for the silly implementor in section 5.4.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 10 Apr 2006 10:27:39 -0700

> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Sunday, April 09, 2006 8:51 PM
> To: Miika Komu
> Cc: Henderson, Thomas R; [email-masked]
> Subject: Re: [Hipsec] some comments for mm-03: including 
> ESP-INFO in all (relevant) UPDATES
> 

The main reason that ESP_INFO is in the first two packets is for
middlebox traversal.  Note that if there is no mobility-initiated rekey,
there is no strict reason to include ESP_INFO in all mobility exchanges
(the LOCATOR contains all the necessary information for mobility), but
then you cannot guarantee that future SPI-aware middleboxes will admit
the flow.  However, the third UPDATE (with ECHO_RESPONSE) has the same
ESP_INFO as the first, so we do not replicate it there.

The main possible argument for including ESP_INFO in this third mobility
packet is for SPI-aware middleboxes, if it makes it any easier for them.
I agree with Pekka's point that if an implementation wants to use this
info to correlate UPDATEs with ACKs, it can put the information into the
nonce however it chooses.

Also, note that we do not include ESP_INFO in the third packet of the
rekeying exchange (Section 4.1.2 of ESP base draft), and we are trying
to overlay those parameters on this mobility exchange.  

So I would support adding it as a MAY but am not yet convinced to add
more strong requirement at this time.

Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 13 Apr 2006 08:19:39 -0700

Returning to the mm draft comments from Miika.

> raised also a question in my mind whether it is correct.

Christian has provided the following corrected figure.

        +-------+                        +-------+
        |   A   |                        |   B   |
        +-------+                        +-------+
            |                                |
    address |------------------------------->| credit += size(packet)
     ACTIVE |                                |
            |------------------------------->| credit += size(packet)
            |<-------------------------------| don't change credit
            |                                |
            + address change                 |
            + address verification starts    |
    address |<-------------------------------| credit -= size(packet)
 UNVERIFIED |------------------------------->| credit += size(packet)
            |<-------------------------------| credit -= size(packet)
            |                                |
            |<-------------------------------| credit -= size(packet)
            |                                X credit < size(packet)
            |                                | => do not send packet!
            + address verification concludes |
    address |                                |
     ACTIVE |<-------------------------------| don't change credit
            |                                |

             Figure 10: Readdressing Scenario

In the course of revising this, I discussed with Christian some
additional clarifying text and would like to propose the following text
that we worked out together:

- Section 3.3.2:  Add the following sentence right before the figure:

"Not shown in Figure 10 are the results of credit aging (Section
5.5.2), a mechanism used to dampen possible time-shifting attacks."

- Section 5.5:  At the beginning of this section (before reaching 5.5.1)
add:

"To prevent redirection-based flooding attacks, the use of
a Credit-Based Authorization (CBA) approach is mandatory when a host
sends data to an UNVERIFIED locator.  The following algorithm meets
the security considerations for prevention of amplification and
time-shifting attacks.  Other forms of credit aging--- and other values
for the CreditAgingFactor and CreditAgingInterval parameters in
particular--- are for further study, and so are the advanced CBA
techniques specified in [1]."

[1]
http://doc.tm.uka.de/2005/draft-vogt-mobopts-credit-based-authorization-
00.txt

(note to Christian:  This document [1] will need some official status or
republishing as a technical report)

- Section 6.  Add the following sentence just before starting Section
6.1:

"Security considerations for Credit-Based Authorization are discussed in
[2]."

[2]
http://doc.tm.uka.de/2006/draft-vogt-mobopts-simple-cba-00.txt

(note:  Christian says that he is working with Jari to publish this
draft)

Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 13 Apr 2006 12:54:19 -0700

Miika, resuming the response to your detailed coments:

> Sent: Monday, April 03, 2006 2:30 PM
> To: [email-masked]
> Subject: Re: [Hipsec] some comments for mm-03
> 

disagree with this editorial suggestion, since it is not only changes
that
can be conveyed in LOCATOR.

> What entities? There is also something other fishy with this sentence.
s/entities/levels
s/negotiated/constructed

OK

>   "send packet on SPI" could be said in a better way.

performed some cleanup as you suggested

> s/between/associated with/
s/between itself and/associated with/

> (I suggested writing the term "SA selector" to the terminology in the

acutally, on a message from Wed. Mar 22, 2006 to the list, Francis
Dupont
corrected my usage of "SA selector"-- should be "SA lookup".  Have
made the appropriate changes (do not use the term selector in the
document
anymore).

> from here as it is repeated elsewhere.

removed

> mapping to the same ADDR21?

Yes, in general, there may be different source addresses and hence 
different paths to the same destination address.

OK
OK

OK

OK

OK

OK

> What does "act" mean here?

First, there is an error here-- R2 should be R1.  We corrected this
elsewhere in last draft version, but this is a loose end that needs 
changed.

> Cookies might get burned if the indexing is affected by the 
I1 and I2 source addresses can be different, because the responder
can include a new preferred address in the R1 LOCATOR, and the 
change in responder address might require a change in initiator
source address.

Now, back to the text at hand.  NOTIFY perhaps should be separated
from the R1/I2 cases.  It may be the case that a LOCATOR in an I2
can override the preferred address used for the base exchange, so
saying that it is informational may mean that the receiver can ignore
it.  The issue is really with NOTIFY, which could be replayed.  What
may work better here is to treat NOTIFY as informational, which means
that it cannot drive any particular state change (this also just
discussed in the Bellovin-Rescorla analysis thread).

Perhaps this wording is better:

"       When the LOCATOR parameter is sent in an UPDATE packet, then the
        receiver will respond with an UPDATE acknowledgment.  When the
        LOCATOR parameter is sent in an R1 or I2 packet, the base
exchange
        retransmission mechanism will confirm its successful delivery.  
        LOCATORs may experimentally be used in NOTIFY packets; in this
case,
        the recipient MUST consider the LOCATOR as informational and not
        immediately change the current preferred address, but can test
the 
        additional locators when the need arises.  The use of LOCATOR 
        in a NOTIFY message may not be compatible with middleboxes."

> Is there are specific reason why the reserved field cannot be 

I do not understand this request.  Aren't undefined flags the same
as reserved bits?

> Minimum length (is a locator without any address allowed)? 

I would say yes, and this corresponds to moving all addresses to
DEPRECATED.

Suggest:  
       "A LOCATOR contaning zero Locator fields
       is permitted but has the effect of DEPRECATING all addresses."

> Maximum length?

There is already a maximum for HIP Parameters field.

OK

Added.

OK

> Also, CLOSE can be used for premature expiration of addresses.

Ignoring this one based on previous discussion.

> In the case of many alternatives, the host chooses according to

I don't think this sentence is really needed here since the issue
of picking among multiple addresses is dealt with elsewhere.

OK

OK

OK

> with type 1 or 2 locators.

Since we do not presently define multiple LOCATORs in a single packet, 
this would mean that we cannot handle different interfaces differently.
It may be that one interface requires the separation of signaling and
data, while another does not.  So I'd slightly prefer to keep it open.
I don't see it as seriously complicating things.

> Suggest adding: Currently, mostly for non-ESP based usage.

This locator type is defined primarily for non-ESP-based usage.

> Suggest adding: Recommend for ESP based usage.
This locator type is defined primarily for ESP-based usage.

> Add to this section some text about the correspondence 

   The relationship between the
   announced Locators and any ESP_INFO parameters present in the packet
   is defined in Section 5.2.

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 14 Apr 2006 20:52:42 +0300

> Christian has provided the following corrected figure.

I am not convinced that increasing credits based on packets from an  
unverified source is a good idea.  I can imagine situations where one  
is able to spoof the source IP address, causing a continued  
reflection attack.

Other than that, seems ok to me.

>              Figure 10: Readdressing Scenario

<remainder snipped>

--Pekka

---

From: Christian Vogt <[email-masked]>
Date: Sun, 16 Apr 2006 20:50:08 +0200

Hi Pekka.

>  is able to spoof the source IP address, causing a continued

In this case, the attacker would still get credit only for packets that
it has sent, so no amplification will happen.  This is in line with the
invariant of CBA to not permit amplification.

But without amplification, why would an attacker use HIP MM to realize
its reflection attack?  A direct flooding attack, where the attacker
itself sends the flooding packets to its victim, would have the same
potential--- and it could be done without speaking the HIP MM protocol.

And given that the attacker you are describing can spoof the source
address of its packets, it could just as well do so during a direct
flooding attack.

If the attacker wants the flooding packets to be generated by a third
node and propagate along a path that does not originate at the attacker
itself, then the attacker could use existing reflection strategies.
E.g., it could send spoofed ICMP Echo Request packets to a third node
that have the victim's address as a source address.  This would give the
attacker a non-amplified reflection attack as well--- again, without
having to speak the HIP MM protocol.

Other strategies, such as spoofing the source address in TCP SYNs, would
have the same effect.  In fact, a TCP SYN attack might actually be more
effective than a non-amplified HIP-MM-based reflection attack, because
some TCP servers retransmit a TCP SYN-ACK a couple of times before they
give up.  This creates even some amplification.

In summary, I think we are save as long as we do not allow for
amplification.  Even if we give the attacker credit for packets
originating from an unverified address.  Without amplification, the
attacker has so many other options to realize a reflection attack that
misusing the HIP MM protocol becomes really unattractive.

And if we give a /legitimate/ mobile node credit while its address is
unverified, we help it to not run out of credit before the handoff
process is over.

> Other than that, seems ok to me.

Ok, thanks.

- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

Pekka Nikander wrote:
> I am not convinced that increasing credits based on packets from an  unverified source is a good idea.  I can imagine situations where one  is able to spoof the source IP address, causing a continued  reflection attack.
>

---

From: Miika Komu <[email-masked]>
Date: Mon, 17 Apr 2006 22:17:15 +0300 (EEST)

> can be conveyed in LOCATOR.

Ok.

> different paths to the same destination address.

Maybe this could be also mentioned briefly in the text. It is not obvious
from figure or text.

> change in responder address might require a change in initiator

Let me further illustrate my original point. In the Appendix A. (Using
Responder Puzzles) of base draft, an example puzzle algorithm is
illustrated. Even though the algorithm is only illustrative, I believe
that any DoS resistant puzzle algo will use the I1 and I2 source IP
address as part of the indexing scheme in practice, and this will most
probably cause the base exchange to fail. The initiator keeps
retransmitting I2 packets from I2_SENT state and responder just drops them
due to failed cookie solutions. I believe that this is a very practical
and real problem; I've encountered similar problems many times in our
implementation, albeit on when implementing other things (NAT, rvs).

> discussed in the Bellovin-Rescorla analysis thread).

Yes.

>         in a NOTIFY message may not be compatible with middleboxes."

The wording is better, but I claim that there is still a practical problem
and important problem with cookie indexing. Perhaps we can just mention
somewhere in the text (3.2.8. Initiating the protocol in R1 or I2?)
something like this:

I1 and I2 may be arriving from the different source addresses if the
LOCATOR parameter is present in R1. In this case, implementations using
pre-created R1 indexed with IP addresses may be failing cookie solutions
of I2 packets inadvertly. As a solution, the responder's R1 indexing
mechanism must be flexible enough to accomodate the situation when R1
includes a LOCATOR parameter.

> I do not understand this request.  Aren't undefined flags the same

Effectively yes. However, now thinking this again, the difference in using
"reserved bits" rather than "undefined flags" may be that reserved bits
could be allocated as a type field rather than single bit flags. As a
consequence, it is more modular. So I am fine with this as it is, it seems
to be case also in the base draft.

>        is permitted but has the effect of DEPRECATING all addresses."

Excellent.

Fine.

Fine.

> This locator type is defined primarily for ESP-based usage.

Suggest adding the proposed hints for the sake of ease-of-readability. If
I recall correctly, I started to wonder the difference between the
locator types at this point. After reading the whole draft, I just added
the sentences that would have satisfied my curiousity on the first reading
round.

>    is defined in Section 5.2.

This was a readability note because the text references something that has
not been discussed yet.

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 18 Apr 2006 10:28:46 +0300

> unverified, we help it to not run out of credit before the handoff

Hmm.  I am still a little bit worried.  As you mention, there are  
easier ways to cause reflection today, but what about the future  
where it may not be so.

What about crediting the incoming traffic but not crediting it  
fully?  For example, instead of increasing the credits by sizeof 
(incoming packet) just increase them by 0.5 * sizeof(incoming  
packet)?  That would still allow the moving host to send in traffic  
to increase credits but would make the system as an attack vehicle  
much less attractive.

Right now I am worried about a situation where the attacker creates  
the association, immediately signals a mobility event (without  
accumulating *any* credits at all), and then making the reflection to  
continue by sending packets with spoofed source address.  For the  
reverse case where the attacker accumulates a big credit and then  
"flushes" it to a victim address, IIRC we have already mechanisms  
for, don't we?

Taking a step back, we have to strike a balance between security  
(conservatism) and optimisation (optimism).  The optimistic view is  
that it is good if the mobile host can keep functioning for a longish  
time it may take to verify the new address.  The conservative view is  
that the shorter time the potential attacker can get traffic sent to  
the victim's address, the better.

--Pekka

---

From: Christian Vogt <[email-masked]>
Date: Wed, 19 Apr 2006 20:53:16 +0200

Pekka -

> to increase credits but would make the system as an attack vehicle

Actually, it /is/ technically feasible to give no credit for packets
received from an unverified IP address.  But one should note that, in
this case, the protocol becomes more sensitive to the chosen parameters
of credit aging (CreditAgingFactor and CreditAgingInterval).

The reason is that, since a MN would not be able to increase its credit
during the handoff period, the performance of applications during the
handoff would solely depend on the amount of credit that was built up
/before/ the handoff.  This credit amount is limited by credit aging.

Contrariwise, credit aging has no impact on credit that is directly
used.  Credit-aging parameters could therefore be stricter--- with a
benefitial effect on security--- if the MN would be able to earn credit
while its IP address is unverified.

Anyway, I think that the credit-aging parameters currently defined in
draft-ietf-hip-mm-03.txt provide a reasonable trade-off between security
and application performance.  They allow a MN downloading a file via TCP
to obtain the credit it requires for a 500ms reachability-verification
period.  See [1] for a calculation.

And as [1] shows--- and as we have also seen in our testbed---,
application performance is also fine with these parameters, even if no
credit is given while the MN's IP address is unverified.

[1] http://www.atm.tut.fi/list-archive/MIPshop-2005/msg00153.html

> "flushes" it to a victim address, IIRC we have already mechanisms

Right, this is why we exponenially age existing credit.  I.e., the
credit that a MN (or an attacker) shrinks over time.  Building up credit
over a long time and flushing it all at once thence becomes impossible.

>  time it may take to verify the new address.  The conservative view
> is that the shorter time the potential attacker can get traffic sent
> to the victim's address, the better.

Yes.  And, as said above, the parameters of credit aging contribute to
this balance as well.

- Christian

Pekka Nikander wrote:
>>  attacker has so many other options to realize a reflection attack
>> that misusing the HIP MM protocol becomes really unattractive.
>> 
>> And if we give a /legitimate/ mobile node credit while its address
>> is unverified, we help it to not run out of credit before the
>> handoff process is over.
> 
> 
>  time it may take to verify the new address.  The conservative view
> is that the shorter time the potential attacker can get traffic sent
> to the victim's address, the better.
> 
> --Pekka

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 21 Apr 2006 13:22:51 -0700

Miika, I'm still plowing through your comments: 

> Sent: Monday, April 03, 2006 4:06 PM

      "This section describes rules for sending and receiving
      the LOCATOR parameter, testing address reachability, and
      using Credit-Based Authorization (CBA) on UNVERIFIED locators."
> What conflicting means here?

I changed to "Rapidly sending LOCATORs that force the peer to change 
              the preferred address SHOULD be avoided."

> locators, selection according to a local policy.

I would prefer that source address selection is out of scope of this
draft, beyond referring to RFC 3484.  Marcelo Bagnulo has written a
recent draft that states that shim6 multihoming will require additional
work beyond RFC 3484:  draft-bagnulo-shim6-addr-selection-00

IMO, this is a piece of the multihoming work that is for further study,
and probably can build on future work done in shim6.

I added a comment in the Section 3.1.3 to this effect.

> s/single-homed/multi-homed/ 

s/single-homed/(previously) single-homed/

OK

> > A host SHOULD be prepared to receive a LOCATOR parameter in any HIP

s/in any HIP packet, excluding I1/in the following HIP packets:  R1, I2,
UPDATE, and NOTIFY/

OK

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

I think this comment does not require any actions.

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

I believe that this sentence needs the following correction (and not
your
proposed modification):

s/new inbound/new outbound/

> reachability problems after the host moves to another network.

This clarification pertains to the sending of LOCATOR, not receiving.

I added the following to section 5.2, third paragraph:

"Hosts MUST NOT announce broadcast or multicast addresses in LOCATORs.  
The announcement of link-local addresses is a policy decision; such
addresses
used as preferred locators will create reachability problems when the
host
moves to another link."

OK

OK

OK

> Should this be actually the first bullet instead of fourth?

Yes.  I think there are a few misalignments of this section.  
Recall that we were talking about making the processing more modular
(process ESP_INFO then process LOCATOR)

Here is how I propose to fix this section:

"   The processing of ESP_INFO and LOCATOR parameters is intended to be
   modular and support future generalization to the inclusion of
   multiple ESP_INFO and/or multiple LOCATOR parameters.  A host SHOULD
   first process the ESP_INFO before the LOCATOR, since the ESP_INFO may
   contain a new SPI value mapped to an existing SPI, while a Type 1
   locator will only contain reference to the new SPI.

   When a host receives a validated HIP UPDATE with a LOCATOR and
   ESP_INFO parameter, it processes the ESP_INFO as follows.  The
   ESP_INFO parameter indicates whether a SA is being rekeyed, created,
   deprecated, or just identified for the benefit of middleboxes.  The
   host examines the Old SPI and New SPI values in the ESP_INFO
   parameter:

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

   2.  (rekeying) 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 by
       creating a new outbound SA with an SPI corresponding to the New
       SPI, with no addresses bound to this SPI.  Note that Locators
       in the LOCATOR parameter will reference this new SPI instead of
       the old SPI.

   3.  (new SA) If the Old SPI value is zero and the New SPI is a new
       non-zero value, then a new SA is being requested by the peer.
       This case is also treated like a rekeying event; the receiving
       host must create a new SA and respond with an UPDATE ACK.

   4.  (deprecating of SA) If the Old SPI indicates an existing SPI and
       the New SPI is zero, the SA is being deprecated and all locators
       uniquely bound to the SPI are put into DEPRECATED state.

   If none of the above cases apply, a protocol error has occurred and
   the processing of the UPDATE is stopped.

   Next, the locators in the LOCATOR parameter are processed.  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.  Note that some
   implementations MAY accept addresses that indicate the local host,
   since it may be allowed that the host runs HIP with itself.

   The below assumes that all Locators are of Type 1 with a Traffic Type
   of 0; other cases are for further study.

   For each Type 1 address listed in the LOCATOR parameter, the host
   checks whether the address is already bound to the SPI indicated.  If
   the address is already bound, its lifetime is updated.  If the status
   of the address is DEPRECATED, the status is changed to UNVERIFIED.
   If the address is not already bound, the address is added, and its
   status is set to UNVERIFIED.  Mark all addresses corresponding to the
   SPI that were NOT listed in the LOCATOR parameter as DEPRECATED.

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

   Once the host has processed the locators, 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.5."
> Do you mean Type 0 Locators? Type 1 Locators have an 

Type 1 (clarified this)

> >     bound to the SPI are put into DEPRECATED state.

these two I think I will just ignore (I think "if" is OK here).

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

yes it is processed (new text clarifies this)

OK

> 5. Otherwise, drop?

I added:
"   If none of the above cases apply, a protocol error has occurred and
   the processing of the UPDATE is stopped."

> > 5.  Mark all locators on each SPI that were NOT listed in 

this text went away

> with the peer. See Section 5.6.

I like the former text better.

> source address of ECHO_REQUEST is the preferred address of 

I disagree that the preferred address is the source address of
ECHO_REQUEST in all cases-- it may not be even in the same address
family as the address being tested.  Also, there is the possibility that
other messages serve as a surrogate for the nonce-- see end of paragraph
2.   I don't know whether there is much value in adding further
clarification as you suggest because it seems to me to be pretty clear
already.

OK

OK

> Responder's preferred address.

OK (did not use the word "new" preceding LOCATOR).

I went back and checked the text on sending LOCATOR in R1 and I2, and
noticed that we said "one or more LOCATORs" there, so I changed it back
to say "a LOCATOR" (i.e., singular).  Note that these locators in the
R1 must be Type 0 locators since no SAs are set up yet.  So I added
the following sentence to the end of Section 5.2:

"Note that the inclusion of LOCATOR in an R1 packet requires the use
      of Type "0" locators since no SAs are set up at that point."

That should cover the R1 case adequately for now.

OK

> Incorrect. The state is not changed as described 5.5.1.

I deleted this sentence because I didn't think it added anything.

> it is the "Peer Host" that is sending the SPI. 

Mobility and multihoming are kind of conflated in this figure.  I think
that it is correctly labeled for the mobility case (we are talking about
the use of the new SA instead of the reception of ECHO_RESPONSE allowing
the right hand side host to move the address to ACTIVE).  I think I will
delete the "in R2, or" clause in the figure and just make it refer to
mobility.

> Maybe "Peer 
> Host" can be

Elsewhere we have referred to Peer Host-- I will keep it the same.

> used for redirection amplification attacks."

I added a separate intro (discussed in a separate email regarding CBA
issues).

OK

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

My guess is zero.

> > CreditAgingInterval length.

I think it should be:

CreditAgingFactor (a fractional value less than one), in fixed time...

> 5.6.  Changing the Preferred Locator

Elsewhere it is "Preferred locator" so I have made it uniform throughout
the document.

> This section could be moved before CBA, that is, between 

Agreed.  I moved it to after existing 5.4.

Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 21 Apr 2006 13:48:11 -0700

> Sent: Monday, April 10, 2006 5:16 AM
> To: Pekka Nikander
> ESP-INFO in all(relevant) UPDATES
> 

I am not sure what hint you are looking for.  Placing the SPI in the
ECHO_REQUEST is discussed in the second paragraph of Section 5.4
already.

Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 21 Apr 2006 14:11:22 -0700

Here is the response to the last batch of initial comments:

> Sent: Wednesday, April 05, 2006 12:34 AM

OK

> How is this possible if the private key is compromised?

As pekka suggested, this case is out of scope.

OK

> authorization strategies.

I think Christian would object to this additional word because it may
suggest that alternate CBA strategies are equivalent, so I will leave it
out.

> flooding traffic to the victim.

s/degrades/lowers
otherwise, I'm OK with the change

> What does a currently active HIT mean? You probably mean address...

No, I think it pertains to the case when multiple HITs are on a host-- I
have tried to clarify this.

> > to redirect the connection.

I think it would require the ECHO_REQUEST/RESPONSE to be outside the
signature, and for another HIP packet to be available to be replayed.  I
think that is unlikely scenario in this case.

But reading this has raised an interesting question in my mind.
Currently, there is no requirement for the nonce to be signed.  The base
spec and this spec do not specify whether ECHO_REQUEST is inside or
outside the signature.  Should it be one way or the other?

I think that the last paragraph in Section 6.2.1 can be safely deleted.

> slow down acceptance of new connections.

How about:
"         A central server that has to deal with a large number of
mobile
         clients may consider increasing the SA lifetimes to try to slow
         down the rate of rekeying UPDATEs or increasing the cookie
         difficulty to slow down the rate of attack-oriented
connections."

> the HIP user's connection.

s/IPv6/IP/; otherwise OK

Also, I changed the last case a little bit as follows:
           " A HIP host attempts to steal a non-HIP host's session.
               A HIP host could spoof the non-HIP host's IP address
               during the base exchange or set the non-HIP host's IP
address
               as its preferred address via an UPDATE.  Other
               possibilities exist but a simple solution is to prevent
               use of HIP address check information to influence non-HIP
sessions."

> What is a session here? TCP session?

upper layer session-- TCP or otherwise

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 21 Apr 2006 14:23:54 -0700

> Sent: Monday, April 17, 2006 12:17 PM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: RE: [Hipsec] some comments for mm-03
> 
> > > > Figure 12
> > >

I have looked at this and am not sure whether there is an easy way to
add this without complicating the description more than necessary-- I
would be willing to consider a specific proposal, though.

> implementation, albeit on when implementing other things (NAT, rvs).

I see your practical point.  It seems to me that a host sending a R1
LOCATOR should not use the algorithm in Appendix A in the base draft
without some modification.  Maybe there should be a note to that effect.

> includes a LOCATOR parameter.

I am willing to add this-- thanks for pointing it out.

> to be case also in the base draft.

OK, will leave it as is.

> the sentences that would have satisfied my curiousity on the 

I did add those hints-- in my response, I should have made it clearer by
enclosing them in quotes.

> This was a readability note because the text references 

Ditto-- I actually added the above sentence, but didn't enclose it in
quotes, so you misunderstood my comment.  (i.e., it is now in there)

Tom

---

From: Miika Komu <[email-masked]>
Date: Sat, 22 Apr 2006 12:21:55 +0300 (EEST)

> would be willing to consider a specific proposal, though.

I think this is notified in the text already:

   An address may appear on more than one SPI.  This creates no ambiguity
   since the receiver will ignore the IP addresses during SA lookup anyway.
   However, this document does not specify such cases.

This text is fine.