RE: [Hipsec] some comments for mm-03

["Henderson, Thomas R" <[e-mail]>]

Miika, I'm still plowing through your comments: 

> -----Original Message-----
> From: Miika Komu [mailto:[e-mail]] 
> Sent: Monday, April 03, 2006 4:06 PM
> To: [e-mail]
> Subject: Re: [Hipsec] some comments for mm-03
> 
> On Tue, 4 Apr 2006, Miika Komu wrote:
> 
> > > Some comments for mm-03, part 1/2 (I'll send the rest later this
> > > evening).
> >
> > Here we go again.. decided to split the email on separate 
> sections. Here
> > is (the end of section three and) section 4.
> 
> And here are comments from section five.
> 
> > 5.  Processing rules
> 
> (perhaps a tiny intro)

      "This section describes rules for sending and receiving
      the LOCATOR parameter, testing address reachability, and
      using Credit-Based Authorization (CBA) on UNVERIFIED locators."
> 
> > 5.1.  Locator data structure and status
> >
> > Rapidly sending conflicting LOCATORs SHOULD be avoided.
> 
> What conflicting means here?

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

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

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.

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

s/single-homed/(previously) single-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.

OK

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

s/in any HIP packet, excluding I1/in the following HIP packets:  R1, I2,
UPDATE, and NOTIFY/
> 
> > The ESP_INFO parameter is included if there is a need to 
> rekey or key a
> > new SPI
> 
> s/if/when/
> 

OK

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

I think this comment does not require any actions.

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

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

s/new inbound/new outbound/

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

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

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

OK

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

OK

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

OK

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


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

Type 1 (clarified this)

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

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)
> 
> > 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/

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 
> the LOCATOR
> >     parameter as DEPRECATED.
> 
> s/on/for/

this text went away

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

I like the former text better.

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

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.

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

OK

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

OK

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

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.

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

OK

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

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

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

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
> changed to "Corresponding Node".

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

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

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

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

OK

> 
> > 5.5.2.  Credit Aging
> 
> Is not obvious to me what should be the initial credit size?

My guess is zero.

> 
> > 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/ ?

I think it should be:

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

> 
> > 5.6.  Changing the preferred locator
> 
> 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 
> sections 5.4 and
> 5.5.

Agreed.  I moved it to after existing 5.4.

Tom

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