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

From: [email-masked] (Henderson, Thomas R)
Date: Mon Oct 4 23:48:01 2004

I plan to submit this draft as WG version -00 in a few days,
but have put it up for any early comments:

http://hip4inter.net/documentation/drafts/draft-nikander-hip-mm-02.txt

I have tried to address the issues that people have raised on
the list, and issues that have been discovered upon implementing
the previous draft version.  Below is a summary of open issues:

Update on HIP mobility management open issues
---------------

Note:  The first four issues are logged at the issue tracker.
The remainder are issues that have arisen during revision
of the text, and open issues raised on the mailing list.

On the hip-mm issue tracker, I would suggest to keep issues
1, 2, and 3 open, close issue 4, and add 6, 10, and 11 (below)
to the issue tracker.

1.  (Roundup issue tracker #1):  Potential conflict in updating
SPI values

Suggested resolution:  Keep open.  This issue pertains to whether=20
we can abandon the address group abstraction.  We agreed to leave it
open until we had more insight.

2. (Roundup issue tracker #2):  Problems with middleboxes

Suggested resolution:  Keep open.  Middlebox traversal needs
to be considered more carefully before this issue can be closed.
For example, should one-way REAs be deprecated?

3.  (Roundup issue tracker #3):  address check RR design

Suggested resolution:  Keep open.  The use of ECHO_REQUEST/REPLY
has plugged the main issue raised here, but additional work
ongoing in mobike and multi6 design team on failover detection
and validation of alternate addresses that may apply also to HIP.

4.  (Roundup issue tracker #4):  Use of multiple SAs

Suggested resolution:  Close this issue (resolved).

5.  REA parameter type is "to be defined"

Suggested resolution:  Tentatively, we have used the value
"3" in our implementation.  The desire has been to keep REA
forward in the list of parameters, to make middlebox parsing
easier.  Whether REA should precede SPI (value "1") or
vice versa might be debatable. =20

6.  Bidirectionality of NES conflicting with unidirectionality
of SAs and REA in multihoming case

Mika has suggested in a recent mail that, when there are
multiple SAs in a REA, and REA is paired with NES, that
it can become ambiguous as to which SA should be rekeyed
upon receipt of a REA/NES.

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,=20
and may fail to interoperate.

Also, issue should be opened in issue tracker.

7.  The issue was raised on the list whether there needs
to be an API to allow an application to select the source
or destination IP address when there are multiple choices.

Suggested resolution:  Should be left outside of the draft,
or discussed in an appendix.  For now, there is no proposed
text that would address this issue. =20

8.  Discussion on the use of multihomed SAs for load balancing

Suggested resolution:  There are many unsolved issues with
respect to load balancing across multiple addresses.  For now,=20
we recommend that multihoming is just used/specified for=20
failover purposes, although experimentation is recommended.

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.

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=20
is included in R1 and it includes a new preferred address,=20
that the puzzle solution MUST be valid for both responder=20
addresses.  The conflict is in using Appendix D (base spec)=20
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.

11.  Use of SPI parameter when REA is present-- is it necessary?

Suggested resolution:  Open until middlebox implications are
better understood.

Also, issue should be opened in issue tracker.

---

From: [email-masked] (Miika Komu)
Date: Tue Oct 5 02:06:01 2004

> exclusively on link-local addresses.

(the same goes for site-local addresses)

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

I'd vote for the inclusion in the R2. This way, the R1s don't have to be
prebuilt every time the responder moves.

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

---

From: [email-masked] (Mika Kousa)
Date: Tue Oct 5 05:14:01 2004

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. Host A sends UPDATEs according to section 5.2 Host 
multihoming, REA containing addresses as much as there are room in the 
UPDATE, NES with Old SPI=New SPI=some_index, and of course SEQ. Actually 
host A does not create any SAs, it just sets the SPI value. Then assume 
that host A is able to respond to B from the addresses included in the 
REA when B will be sending reply UPDATEs.

When the peer host B receives the UPDATE, it thinks that the peer has 
really created a new SA, so it stores the addresses (memory usage) and 
creates a new SA (heavy operation, memory usage), and acknowledges the A's 
UPDATE. Then A acknowledges the B's UPDATE. At this time B is quite surely 
finished creating the SA, and it starts verifying the addresses.

Now the evil host A repeats the procedure, with the only difference of 
just increasing the index number in NES. B creates again a new SA and 
stores the addresses. Repeat this for a long time and host B is out of 
memory.

Surely host B will free the memory reserved for the addresses 
under verification, if it will not receive any ACKs for them. This will 
still be slower than A's ability to allocate B's memory using fake 
UPDATEs.

Solutions: rate limit UPDATE handling, mamimum amount of simultaneous SAs
allowed (send NOTIFY if SA was not created ?).

---

From: [email-masked] (Mika Kousa)
Date: Tue Oct 5 05:37:01 2004

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

>From the issue tracker #4: "is there still a need to create a new SA for 
each new address put in use?". Why create separate SAs even for the IP 
addresses ? If each address would have its own SA and therefore own SPI, 
how can you assign them to SPI groups as in Figure 2 ? Somehow I think 
creating one SA per one peer address is overkill.

I've been playing with "same SA for all addresses belonging to the same 
SPI", as in Figure 2. I have managed to create multiple simultaneous SAs, 
but I do not have support for REAs yet.

-> 6.  Bidirectionality of NES conflicting with unidirectionality
-> of SAs and REA in multihoming case
-> 
-> Mika has suggested in a recent mail that, when there are
-> multiple SAs in a REA, and REA is paired with NES, that
-> it can become ambiguous as to which SA should be rekeyed
-> upon receipt of a REA/NES.
-> 
-> 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.
-> 
-> Also, issue should be opened in issue tracker.

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.

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

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

---

From: [email-masked] (Mika Kousa)
Date: Tue Oct 5 07:55:01 2004

Comments on address verification:

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

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

---

From: [email-masked] (Mika Kousa)
Date: Tue Oct 5 09:26:00 2004

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 ?

---

From: [email-masked] (Pekka Nikander)
Date: Tue Oct 5 13:38:01 2004

> One possible Denial of Service attack occurred in my mind:

I don't find this very serious.  Firstly, the host must be
already communicating in order for this to happen.  Hence,
there should be some minimum level of trust between the hosts.
Secondly, creating an SA is not that heavy since it does not
involve any public key crypto, just hash functions in order
to generate new key material.

> allowed (send NOTIFY if SA was not created ?).

I agree that each implementation should have some sensible,
configurable limit of how many SAs it by default is creating
for peer hosts.  I think something like 5 should be more than
enough for the time being.

Anyway, I think it would be good to have a brief explanation
of this in the Security Considerations section, with a
RECOMMENDATION of having an upper bound for parallel SAs per
host, with some RECOMMENDED default value.

Would you Mika be willing to write some raw text?

--Pekka

---

From: [email-masked] (Mika Kousa)
Date: Tue Oct 5 18:33:01 2004

On Tue, 5 Oct 2004, Pekka Nikander wrote:

-> > One possible Denial of Service attack occurred in my mind:
-> 
-> I don't find this very serious.  Firstly, the host must be
-> already communicating in order for this to happen.  Hence,
-> there should be some minimum level of trust between the hosts.

Surely, but by assumption the evil host is willing to spend some cpu time 
needed for the base exchange. After a couple of seconds it can launch this 
long lasting attack against the victim. Compared to the effects this 
causes, the cpu power needed for the base exchange is close to zero.

A really naive implementation might assume that if the base exchange was 
successful, then the rest of the communication could be consired as 
trustworthy.

-> Secondly, creating an SA is not that heavy since it does not
-> involve any public key crypto, just hash functions in order
-> to generate new key material.

Ah, all right then. But anyway, creation and updating SAs need quite a lot 
more resources elsewhere than just on HIP level, SA related stuff in the 
kernel etc.

-> > Solutions: rate limit UPDATE handling, mamimum amount of simultaneous SAs
-> > allowed (send NOTIFY if SA was not created ?).
-> 
-> I agree that each implementation should have some sensible,
-> configurable limit of how many SAs it by default is creating
-> for peer hosts.  I think something like 5 should be more than
-> enough for the time being.

Assuming that each interface has its own SA, as described in the current 
draft, this might be sufficient. But if we follow the proposals which 
suggest own SA for each of the (IP) addresses, five might be too low. I do 
not know so much about real life situations, such as how many addresses 
some busy host might have at a time. Five SAs is probably sufficient for 
99% of the time.

Limit could also be dynamic, e.g. based on the trust. That is, policy 
issue.

-> Anyway, I think it would be good to have a brief explanation
-> of this in the Security Considerations section, with a
-> RECOMMENDATION of having an upper bound for parallel SAs per
-> host, with some RECOMMENDED default value.
-> 
-> Would you Mika be willing to write some raw text?

Let's see if I can write some short text about this issue during this 
week, something like we have been discussing right now.

---

From: [email-masked] (Pekka Nikander)
Date: Wed Oct 6 06:44:01 2004

> more resources elsewhere than just on HIP level, SA related stuff in 

Depending on implementation that may or may not be that much.

> Five SAs is probably sufficient for 99% of the time.

Agreed.  We need some conservative default; hence the suggestion
for five.

> Limit could also be dynamic, e.g. based on the trust. That is, policy

Sure.  The text should reflect this, being suggestive and
outlining some sensible default values.

> week, something like we have been discussing right now.

Good!

--Pekka

PS.  If you want me to react to your mail quickly, even if
it is a mailing list reply, please make the To: directly to me
(or at least CC: me).  Otherwise my filters will direct it to
a separate folder, and it may take a few days before I read it.

---

From: [email-masked] (Mika Kousa)
Date: Wed Oct 6 09:16:01 2004

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.

---

From: [email-masked] (Mika Kousa)
Date: Wed Oct 6 19:53:01 2004

Here is the initial text to the Security Considerations section I wrote 
about the issue on maximum allowed outbound SAs. I'm not so familiar with 
the correct usage of these capitalized RECOMMENDED/SHOULD/MUST/etc. words, 
but you might want to edit this text anyway. The text digests the mailing 
list discussion, nothing new was added.

When a host has an additional network interface to use, the host might
want to inform its peer about it by sending the SPI of the newly
created SA associated with the network interface. Consequently,
information on this SA must also be stored in the peer host. Because
this operation requires allocation and usage of limited resources,
such as memory and cpu, it is RECOMMENDED that there is an upper bound
limit for the number of simultaneous outgoing SAs a host is willing
to create.

Because the exact number of network interfaces the peer host could have is 
usually not known in advance, it is RECOMMENDED that this value is 
configurable during runtime or at least at compile time. The suggested 
RECOMMENDED default value of five (5) maximum outbound SAs is assumed to 
be enough for most of the situations. In general, the value depends on 
enforced policy and the level of trust a host has against its peer host. 
Lower level of trust SHOULD decrease the maximum value. For trusted 
systems the value could even be unlimited, but this is highly NOT 
RECOMMENDED.

---

From: [email-masked] (Pekka Nikander)
Date: Thu Oct 7 00:27:00 2004

> list discussion, nothing new was added.

Tnx.  A slightly edited version below.

--Pekka

Managing multiple outgoing Security Associations for a peer host
consumes some memory and also some CPU resources.  Because the HIP
protocol has been designed to support communication with peer hosts
that are not fully trusted, there SHOULD be a means to limit the
amount of resources reserved per any given peer.  In particular,
it is RECOMMENDED that there is a total upper bound limit and a
per-peer upper bound limit for the number of simultaneous outgoing
SAs a host is willing to create.

Because the exact number of network interfaces a given peer host could
have is usually not known in advance, it is RECOMMENDED that the upper
limit values be user configurable. The RECOMMENDED default value of
five (5) outbound SAs per peer host is assumed to be enough for most
of the situations.  In general, the value depends on the enforced
policy and the level of trust a host has against the given peer host.
Lower level of trust, e.g. HIP associations with hosts using non-public
keys, MAY decrease the maximum value.  For trusted systems the upper
bound may be increased or even lifted.  To support smooth handovers,
the upper bound MUST always be at least two (2).

[Rationale for the keywords:  In general, these advice deal with
local resource consumption, and do not directly affect interoperability.
However, hosts that have a high number of IP addresses may need to be
aware of these recommendations, in order to better react to their
peer's behaviour.  (The peer may be limiting the number of SAs.)
Not following the advice may lead to DoS vulnerabilities, hence the
RECOMMENDATION.  On the other hand, decreasing the default value may
lead to interoperability problems if the other host is expecting the
default upper bound of five.  Hence the MAY for reducing the upper
bound, and MUST for at least two outgoing SAs per host.]