Subject: [Hipsec] review of comments on draft-ietf-hip-mm-00 preview

From: [email-masked] (Henderson, Thomas R)
Date: Fri Oct 8 16:00:01 2004

Responding below to a number of (mostly Miika's) comments:

(thanks for donating Security Considerations text!  unless
there is objection, I will include the version that Pekka edited)

> 
> > 9.  If HIP negotiates base exchange using link locals, and one
> > host moves, it will not be able to find its peer
> >
> > Suggested resolution:  State that a host SHOULD provide its
> > peer with a globally reachable IP address instead of relying
> > exclusively on link-local addresses.
> 
> (the same goes for site-local addresses)

site-locals are deprecated, but I think we can address this
generally by saying "locally scoped" or "non-global" address.

> 
> > 10.  Should REA be included in R2 or R1 (R1 is presently
> > specified in text)?
> >
> > Note that there is some conflict in saying that, when REA
> > is included in R1 and it includes a new preferred address,
> > that the puzzle solution MUST be valid for both responder
> > addresses.  The conflict is in using Appendix D (base spec)
> > mapping functions.
> >
> > Suggested resolution:  Open, but leaning towards recommending
> > inclusion in R2 instead of R1, unless the reason for putting
> > it in R1 is (re)discovered.
> >
> > Also, issue should be opened in issue tracker.
> 
> I'd vote for the inclusion in the R2. This way, the R1s don't 
> have to be
> prebuilt every time the responder moves.
> 

It seems that most people (including myself) prefer the R2-- any
objection if we make that change now?

> One possible Denial of Service attack occurred in my mind:
> 
> A host could fake a creation of a new SA causing resource 
> consumption at 
> the peer host.

This covered by Miika's proposed security section.

> -> 4.  (Roundup issue tracker #4):  Use of multiple SAs
> -> 
> -> Suggested resolution:  Close this issue (resolved).
> 
> How was this resolved (I forgot..) ? The issue tracker shows only one 
> posting about this issue.

Here was the start of the thread that caused that issue:
http://honor.trusecure.com/pipermail/hipsec/2004-April/000667.html

My understanding of the consensus (or the way that the thread
eventually tailed off) was that a mechanism to have multiple SAs
to handle the case where RTTs are very different was needed, but
maybe in some cases it could be avoided (depending on how well
the anti-replay was tuned).

> -> Suggested resolution:  Add a note to the text that, in the
> -> case of multihoming with multiple SAs, it is RECOMMENDED to
> -> associate SAs in pairs, and that when a NES is received for
> -> a particular SA, the peer should rekey the paired SA.
> -> Also, state that using asymmetrically set up SAs is experimental, 
> -> and may fail to interoperate.
> -> > 
> I would like to see what is the definition for a "paired SA". 
> How it is 
> related to the peer's SAs and how it is associated when a new SA is 
> created.
> 

Here is proposed text for a replacement of the third paragraph in 
Section 5.2:
"IPsec SAs are unidirectional, and the protocol may support configurations
in which an asymmetric number of inbound and outbound SAs exist on a given
host with respect to another host.  However, for the purpose of handling
multihoming more cleanly, it is RECOMMENDED that inbound and outbound SAs 
be created and maintained in a pairwise fashion between hosts, and that
when rekeying occurs on one SA, it is also triggered on the paired SA.  For
example, the HIP base exchange results in two SAs-- one inbound and one
outbound on each host.  If one of the two hosts wants to advertise another
interface to its peer, it should add a new inbound SA and send a REA (and
NES) to the peer.  The peer should also create a new inbound SA.  These
two new SAs are also paired.  Subsequently, when a rekey occurs on one SA,
a corresponding rekey is performed on the paired SA, with no ambiguity.  
Implementations that fail to follow the above guidelines may fail to 
interoperate cleanly."

> -> 11.  Use of SPI parameter when REA is present-- is it necessary?
> 
> I have no experience yet.
> 
> -> Suggested resolution:  Open until middlebox implications are
> -> better understood.
> -> 
> -> Also, issue should be opened in issue tracker.
> 
> Then we would have SPIs in three places in the same packet. REA,
> NES, and SPI. Messy ?

REA and NES both need SPI, since REA may occur without NES.

SPI would seem to be redundant, unless a middlebox always wants SPI
to be there, for its convenience.  Suggest to leave it open for now.

> 
> Also the SPI selection algorithm for the parameter would be nice.

Suggest statement that "SPI selection is performed in the same manner
as in the base exchange."

> 
> Looks like there is a lot of text which assume the situation 
> as if there 
> is always only one address listed in the REA. That causes 
> misinterpretation (for me at least) in sentences such as:
> 
> 
> -Section 4.2 Address verification, "A simple technique to 
> verify addresses 
> is to send an UPDATE to the host at the new address." and "If 
> the peer 
> host is rekeying by sending an UPDATE with NES to the new 
> address, the 
> arrival of data on the new SPI can also be used to verify the 
> address." 
> 
> Does this verify the reachability of all addresses listed in 
> the REA ? No.
> 
> Shouldn't this be "For each of the listed addresses in the REA, .." ? 
> Something like in draft mm-00 section 4.3 Address verification: "To 
> acknowledge that it has received the REA, and to initiate an address 
> check, the HIP host receiving a REA immediately sends an AC to all 
> addresses mentioned in the REA."

Yes, should state "for each"

> -Section 5.1 Mobility with single SA pair, "Upon obtaining a new IP 
> address, the mobile host sends a REA parameter to the peer host in an 
> UPDATE message. The REA indicates the following:  the new IP 
> address, the 
> SPI associated with the new IP address, the address lifetime, 
> and whether 
> the new address is a preferred address. .. The UPDATE 
> messages sent from 
> the peer back to the mobile are sent to the newly advertised address."
> 
> And the "newly advertised address" is defined here as .. ? Preferred 
> address in the REA, if there is any (and what if not) ? All of the 
> addresses ?
> 
> Hmm..but wait..ahh..the reader must notice the word "messages", so by 
> deduction this section should also say "for all of the addresses a 
> separate UPDATE is sent by the peer..", right ?

Yes, this should be clarified as you point out.

> In section 5.1 Mobility with single SA pair, "Readdress 
> without rekeying, 
> but with address check":
> 
> When a mobile hosts sends UPDATE(REA, SEQ) (Figure 3), must it be 
> processed in any state (established or rekeying) ? How it should be 
> processed upon receive ? Can we skip some tests mentioned in the base 
> draft's section 8.11 Processing UPDATE packets ?

Yes, I will refer to 8.11 and remove the redundant text.

> A conflict in 5th paragraph of section 7.1 Sending REAs: "All 
> addresses 
> corresponding to the SPI have the same lifetime." But the rest of the 
> discussion on address lifetimes tells that each address have 
> their own 
> lifetimes.

I think that the quoted sentence should be struck (maybe Pekka has
an opinion).  The address lifetimes correspond to the IPv6 stateless
autoconfiguration lifetimes-- not necessarily the same for all
addresses.

> 5.7 Initiating the protocol in R1 or I2:
> 
> Should there be some explicit notes about the KEYMAT index to 
> be used when 
> retrieving keying materials for the SA(s) if the R1 or I2 contains 
> (multiple) REA(s) ? Or do we just assume that the 
> implementors know what 
> they are doing without telling them. That is, they use the 
> current KEYMAT 
> index right after when the HIP keys were drawn.

I do not see any harm in adding a sentence for clarity.

---

From: [email-masked] (Jari Arkko)
Date: Sat Oct 9 01:16:00 2004

> generally by saying "locally scoped" or "non-global" address.

Statistically unique site-local addresses would probably be OK
too, for usage within a site. The problem with the link-local
and old site local addresses was not just the connectivity
but also potential collisions; you could attempt talking to
a node which had nothing to do with the previous node you
talked with. The connectivity part is, however, not a major
problem as far as I can see. Even global addresses might
have connectivity problems in some cases, and we provide
multihoming primarily to combat this problem.

--Jari

---

From: [email-masked] (Pekka Nikander)
Date: Mon Oct 11 06:15:01 2004

> multihoming primarily to combat this problem.

I agree.

However, I think a SHOULD for non-global is the right choice now,
as we the Hinden-Haberman addresses are not quite RFC yet.
If they become an RFC, we can return to this and revise?

--Pekka

---

From: [email-masked] (Pekka Nikander)
Date: Mon Oct 11 06:22:01 2004

> Implementations that fail to follow the above guidelines may fail to

Looks good to me other than the last statement, which I would tune down.
Maybe:

   "Note that it is possible that implementations that fail to follow the
    above guidelines may fail to interoperate with some implementations.
    However, it is recommended that implementations attempt to support
    peers that prefer to utilise non-paired SAs."

And, maybe add at least the following:

   "It is expected that this section and behaviour will be modified in
    some future revision of this protocol, once the issue and its
    implications are understood better."

> autoconfiguration lifetimes-- not necessarily the same for all

That sentence was an optimisation that allowed only one lifetime
to be sent for a group of addresses.  I don't remember how the
packet format is today; the sentence can be removed if the packet
format supports different lifetimes.

--Pekka

---

From: [email-masked] (Jari Arkko)
Date: Mon Oct 11 06:32:00 2004

> If they become an RFC, we can return to this and revise?

Works for me.

--Jari

---

From: [email-masked] (Mika Kousa)
Date: Mon Oct 11 06:38:00 2004

5.1  Mobility with single SA pair

Mobile Host                         Peer Host

         UPDATE(REA, SEQ)
 ----------------------------------->
         UPDATE(SPI, SEQ, ACK, ECHO_REQUEST)
 <-----------------------------------
         UPDATE(ACK, ECHO_RESPONSE)
 ----------------------------------->

  Figure 3: Readdress without rekeying, but with address check

Now that we have seen the change needed for address check procedure 
(ECHO_REQUESTs are sent to each of the addresses listed in the REA, see 
this same thread), this section needs some editing.

Peer Host does not need to send ACK for the REA-UPDATE in every UPDATE it 
sends related to address check procedure, it could send just ACK-UPDATE 
and after that the Peer Host sends the ECHO_REQUEST-UPDATEs:

For example:

Mobile Host                         Peer Host

         UPDATE(REA(addr_1,addr_2), SEQ)
 ----------------------------------->
         UPDATE(ACK)
 <-----------------------------------

  sent to addr_1: UPDATE(SPI, SEQ, ECHO_REQUEST)
 <-----------------------------------
         UPDATE(ACK, ECHO_RESPONSE)
 ----------------------------------->

  sent to addr_2: UPDATE(SPI, SEQ, ECHO_REQUEST)
 <-----------------------------------
         UPDATE(ACK, ECHO_RESPONSE)
 ----------------------------------->
...

Maybe the other figures and related texts in section 5 need similar 
changes when there is a possibility that REA contains many addresses, too.

---

From: [email-masked] (Miika Komu)
Date: Mon Oct 11 07:36:01 2004

> Responding below to a number of (mostly Miika's) comments:

(You are confusing me with Mika. Most of the comments were from Mika. To
confuse even more, we also have a "Miikka" at work. Fortunately, for your
sake, he is not working on anything related to HIP ;)

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