[Hipsec] some comments for mm-03

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              miika@iki.fi          http://www.iki.fi/miika/

_______________________________________________
Hipsec mailing list
Hipsec@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hipsec