Subject: [Hipsec] ICE/HIP Integration: A Solution Space Analysis

From: Christian Vogt <[email-masked]>
Date: Fri, 07 Sep 2007 09:54:30 +0300

Folks,

[draft-ietf-hip-nat-traversal-02] builds ICE functionality into HIP.  An
integration like this requires, of course, design decisions WRT which
ICE-related meaning/action HIP messages should bear/trigger.

I was missing some rationale for the specific solution in [draft-ietf-hip-nat-
traversal-02].  So I made my own evaluation of the solution space for ICE/HIP
integration.  I am attaching this because it may be interesting for you as well.

Since the result of my evaluation is supportive of [draft-ietf-hip-nat-
traversal-02], I suggest to use it as a new "Rationale" section in the draft.

Best regards,
- Christian

P.S.:  The attached evaluation may be useful also for [draft-tschofenig-hip-
ice-00], but I did not look into this yet.

Solution Space Analysis for HIP-ICE Integration
Christian Vogt, September 7, 2007
-----------------------------------------------

To integrate ICE functionality into a HIP base exchange, three
questions must be answered for both the initiator's side and the
responder's side:

- When should a host discover local candidate locators?

- Which HIP packets should carry candidate locators?

- Which HIP packets should initiate reachability checks?

Answering these questions involves a trade-off.  On one hand,
performing these tasks at a late stage during the HIP base exchange
allows a host to defer spending the effort involved in candidate
locator discovery and reachability checks until the correspondent host
has proven its identity and provided reasonable assurance that its
desire to communicate is genuine.  Candidate locator discovery and
reachability checks require both signaling as well as memory and
processing on a host.  Care must be taken that this cannot be
exploited for resource (memory or processing) exhaustion attacks
against the host, or for reflection-based flooding attacks against
arbitrary victims elsewhere on the Internet.  On the other hand, all
HIP packets up to the ones carrying candidate locators must go through
a rendezvous server to ensure successful delivery.  Exchanging
candidate locators early during the HIP base exchange therefore
reduces the load on the rendezvous server and enables an earlier
switch to more efficient communications via a direct path.

We propose the following integration of ICE into the HIP base exchange
and provide rationale for this below:

- The responder sends its local candidate locators to the initiator
  with the R1 message.  It discovers its local candidate locators any
  time before this.

- The initiator begins reachability checks when it receives the R1
  message from the responder.

- The initiator sends its local candidate locators to the responder
  with the I2 message.  It discovers its local candidate locators any
  time before this.

- The responder begins reachability checks when it receives the I2
  message from the initiator.

The discovery of local candidate locators is thus effectively
decoupled from any particular session establishment.  This is
necessary because a host discovers local candidates once, and it can
use them with multiple correspondent hosts later on.  Moreover, the
threats involved in candidate locator discovery are very limited
anyway.  Since the procedure is a one-time task, misusing it for
resource exhaustion is hard.  The procedure also involves signaling
only between a host and its STUN, TURN, or rendezvous servers.  This
signaling cannot be redirected by an attacker for a flooding attack.

Reachability checks are more vulnerable to resource exhaustion and
flooding attacks for the following two reasons:

(1) Reachability checks are tied to a particular correspondent host,
    and must hence be redone for each correspondent host.  This would
    give an attacker the ability to trigger reachability checks if it
    could spoof identities.

(2) An attacker can amplify both resource exhaustion and flooding
    attacks via the number of (possibly spoofed) local candidate
    locators that it advertises to a victim host.  The host pairs each
    of these locators with typically multiple local candidate locators
    of its own, and it performs a reachability check on each such
    pair.  In addition, reachability checks that are directed against
    a spoofed locator fail to solicit a reponse.  This causes the host
    to retransmit the reachability checks, increasing amplification
    further.

It is hence important for a host to defer its reachability checks for
a correspondent host until that correspondent host has proven its
identity and, in case the correspondent host is the session initiator,
provided reasonable assurance that its desire to communicate is
genuine.  With the proposed HIP-ICE integration approach, the
initiator of a HIP base exchange defers its reachability checks until
it has received the R1 message because this proves the responder's
identity (via a signature).  The proposed approach calls for the
responder to defer its reachability checks until the receipt of the I2
message because this proves the initiator's identity (via a signature)
and willingness to communicate (via a puzzle solution).

Alternative HIP-ICE Integration Approach
----------------------------------------

The proposed HIP-ICE initegration approach protects the initiator
against the (comparatively small) threat of misuse of candidate
locator discovery because it could defer candidate locator discovery
until after the receipt of the responder's signature.  However, the
responder is currently not thus protected as it needs to discover its
local candidate locators already upon receipt of the unauthenticated
I1 message.  To also protect the responder against misuse of candidate
locator discovery, exchange of the responder's candidate locators must
take place only after the receipt of the initiator's I2 message.  The
responder would then start candidate locator discovery after
verification of the signature in the I2 message, and send its local
candidate locators to the initiator with the R2 message.

Rendezvous Server Considerations
--------------------------------

Exchanging candidate locators in the R1 and I2 messages requires at
least the I1, R1, and I2 messages of the base handshake to be relayed
via a rendezvous server in order to ensure delivery.  All messages
from the HIP base exchange must be sent via the rendezvous server if
the candidate locators get exchanged in the I2 and R2 messages.
Either case requires a deviation from the procedure defined in
[HIPRVS], which calls for the R1, I2, and R2 messages to be sent via
the direct path.

Mobility and Multi-Homing Considerations
----------------------------------------

The HIP mobility and multi-homing extensions [HIPMM] allow a responder
to advertise new locators in the R1 message, and an initiator may
advertise new locators in the I2 message.  This is in-line with the
exchange of candidate locators in these same messages.
_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Philip Matthews <[email-masked]>
Date: Fri, 7 Sep 2007 11:48:52 -0400

See inline.

> Christian Vogt, September 7, 2007

My concern with this is that there can be a lot of work creating the  
list of locators.
How do we avoid the following attacks:
a) Sending a lot of I1 packets from a large number of hosts to a  
responder more
or less simultaneously, where the responder wants to use a different  
locator
set for each association.
b) Sending I1 packets from a single host to a responder at 3 minute  
intervals,
requiring the responder to assemble a locator list and keep various  
server-reflexive
addresses alive (e.g., by sending UDP packets every 15 seconds).
In both cases, the  work at the responder is much larger than the  
work of the various
initiators.

Furthermore, the ICE security solution requires that the signaling  
channel between
the two endpoints be secure. At present, I believe that there is not  
a secure channel
when the R1 packet is sent (but correct me if I am wrong).

For these reasons, I advocate using the I2 and R2 messages to  
exchange locators
(in ICE terms, to carry the Offer and Answer).  This means that the  
responder can delay
the gathering of candidates/locators until after it receives the  
puzzle solution.

> signaling cannot be redirected by an attacker for a flooding attack.
What if a host wishes to use different UDP ports (at the UDP  
encapsulation layer)
for different HIP associations?
Furthermore, as soon as a host has gathered locators (candidates) it  
must keep
them alive, which can be a burden and certainly consumes resources on  
the host,
resources that will only be freed once a path is selected.

>     to retransmit the reachability checks, increasing amplification
The so-called "ICE Hammer" attack.

> Alternative HIP-ICE Integration Approach
Yup, though I don't agree with the "(comparatively small)"  
characterization.

> Rendezvous Server Considerations
Yes. The current RVS proposal works only in the absence of NATs.

---

From: Christian Vogt <[email-masked]>
Date: Mon, 10 Sep 2007 10:24:09 +0300

>> - The responder sends its local candidate locators to the initiator with
>> the R1 message.  It discovers its local candidate locators any time before
>> this.
> 
> My concern with this is that there can be a lot of work creating the list of
> locators. How do we avoid the following attacks: a) Sending a lot of I1
> packets from a large number of hosts to a responder more or less
> simultaneously, where the responder wants to use a different locator set for
> each association. b) Sending I1 packets from a single host to a responder at
> 3 minute intervals, requiring the responder to assemble a locator list and
> keep various server-reflexive addresses alive (e.g., by sending UDP packets
> every 15 seconds). In both cases, the  work at the responder is much larger
> than the work of the various initiators.
> 
> Furthermore, the ICE security solution requires that the signaling channel
> between the two endpoints be secure. At present, I believe that there is not
> a secure channel when the R1 packet is sent (but correct me if I am wrong).
> 
> For these reasons, I advocate using the I2 and R2 messages to exchange 
> locators (in ICE terms, to carry the Offer and Answer).  This means that the 
> responder can delay the gathering of candidates/locators until after it
> receives the puzzle solution.

Philip,

using I2 and R2 messages to exchange locators is what I was describing in
section "Alternative HIP-ICE Integration Approach".

The reason I preferred using the R1 and I2 messages is that it allows earlier
use of a direct path, and that I considered the residual vulnerabilities small.
 Now, while I don't see a reason for a responder to enforce a different locator
set per association (your item a above), I do see your point that keep-alives
for server-reflexive addresses might be exploitable (your item b above).  Using
I2 and R2 messages to exchange locators would mitigate this.

> What if a host wishes to use different UDP ports (at the UDP encapsulation
> layer) for different HIP associations? Furthermore, as soon as a host has
> gathered locators (candidates) it must keep them alive, which can be a burden
> and certainly consumes resources on the host, resources that will only be
> freed once a path is selected.

These issues are similar to what you described further up as items a and b.
Again, I do not see a reason for a responder to enforce different ports per
association.  But the issue of exploitable keep-alive overhead is valid.

Best,
- Christian

---

From: Philip Matthews <[email-masked]>
Date: Mon, 10 Sep 2007 13:28:47 -0400

> I2 and R2 messages to exchange locators would mitigate this.

Just to be clear, I am not proposing that we _enforce_ the use of a  
different locator
set for each association. However, I would like it to be a viable  
option.

Otherwise, you are enforcing the reverse: a responder _must_ use the  
same locator set
for all associations.

- Philip

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 10 Sep 2007 20:44:52 +0300

> set for each association. However, I would like it to be a viable  

I don't see any reason why we should mandate that the locators are  
exchanged in either R1/I2, I2/R2 or even later with UPDATEs.  That  
is, just like in the case of the HIP mobility extension, to me the  
HIP "ICE extension" would be a more-or-less independent protocol run  
on the top of the "HIP substrate", created by the base exchange, and  
then enhancing and modifying the properties of the "substrate".

Hence, if I understand the situation right, we can have both, and  
leave the choice to a local policy at execution time.

--Pekka

---

From: Christian Vogt <[email-masked]>
Date: Tue, 11 Sep 2007 09:03:04 +0300

Pekka and Philip:

Pekka Nikander wrote:
> Hence, if I understand the situation right, we can have both, and leave
> the choice to a local policy at execution time.

Right.  What the specification would have to provide is a description of the
security considerations that apply to either of the approaches.

Best regards,
- Christian

---

From: Miika Komu <[email-masked]>
Date: Tue, 11 Sep 2007 15:33:49 +0300 (EEST)

On Fri, 7 Sep 2007, Christian Vogt wrote:

Hi,

thanks for text! I'll consider it in the next version, but for the time 
being we should postpone until there is design team which has decided on 
the direction to go.

-- 
Miika Komu                                       http://www.iki.fi/miika/

---

From: Miika Komu <[email-masked]>
Date: Tue, 11 Sep 2007 15:40:11 +0300 (EEST)

On Mon, 10 Sep 2007, Philip Matthews wrote:

> Just to be clear, I am not proposing that we _enforce_ the use of a different 
> locator
> set for each association. However, I would like it to be a viable option.
>
> Otherwise, you are enforcing the reverse: a responder _must_ use the same 
> locator set
> for all associations.

Hi,

FYI, the locators are not in included in R2 in the 02 version of the draft 
because I wanted first to gather some feedback on this issue. I have no 
strong objection to it and it actually seems a useful feature.

---

From: Philip Matthews <[email-masked]>
Date: Tue, 11 Sep 2007 16:54:29 -0400

One additional point on all this.

The ICE security analysis relies on the fact that ICE information  
exchanged is done so in a manner that prevents an attacker from  
eavesdropping. So I am guessing that, in order to include the locator  
info in the R1 packet, the Initiator would need to include its public  
key in the I1 packet, which is a (small) change from the way things  
are done right now. Am I correct?

- Philip

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 12 Sep 2007 09:14:30 +0300

> eavesdropping. So I am guessing that, in order to include the  
> locator info in the R1 packet, the Initiator would need to include  
> its public key in the I1 packet, which is a (small) change from the  
> way things are done right now. Am I correct?

Well, sending the public key in I1 and changing when session key is  
created would be a *major* change to HIP, changing its security  
properties to a very large extend.  See Aura, T., Nagarajan, A. &  
Gurtov, A. (2005), Analysis of the HIP Base Exchange Protocol, in  
'the 10th Australasian Conference on Information Security and Privacy  
(ACISP 2005)', Vol. 3574 of Lecture Notes in Computer Science,  
Springer-Verlag, Brisbane, Australia, pp. 481--493.  http:// 
infrahip.hiit.fi/papers/analysis_hip.pdf  (Please note that the  
changes proposed in the paper have been mostly incorporated to the  
present versions of the protocol.)

What comes to ICE security, I'm intrigued about your claim.  Where  
can I read the security analysis?

--Pekka

---

From: Philip Matthews <[email-masked]>
Date: Wed, 12 Sep 2007 15:33:20 -0400

On 12-Sep-07, at 02:14 , Pekka Nikander wrote:

>> its public key in the I1 packet, which is a (small) change from  
>> the way things are done right now. Am I correct?
>
> 'the 10th Australasian Conference on Information Security and  
> Privacy (ACISP 2005)', Vol. 3574 of Lecture Notes in Computer  
> Science, Springer-Verlag, Brisbane, Australia, pp. 481--493.   
> http://infrahip.hiit.fi/papers/analysis_hip.pdf  (Please note that  
> the changes proposed in the paper have been mostly incorporated to  
> the present versions of the protocol.)

What about the I2 and R2 packets? My understanding is that the  
ENCRYPTED TLV can be included in those messages, and they can in turn  
include multiple sub-attributes (such as LOCATOR). Is this correct?

> can I read the security analysis?

http://tools.ietf.org/html/draft-ietf-mmusic-ice-17#section-18

See in particular the discussion related to a secure offer/answer  
exchange or secure signaling.
In a nutshell, the two ICE endpoints exchange a "username fragment"  
and a "password" as part of the offer/answer exchange. These are used  
as follows:

     L                                           R
     |===========Offer;ufrag:UL,pass:PL=========>|
     |<========Answer;ufrag:UR,pass:PR===========|
     |                                           |
     |-----STUN Request user:"UR:UL"------------>|
     |<---------STUN Response--------------------|
     |                                           |
     |<----STUN Request user:"UL:UR"-------------|
     |----------STUN Response------------------->|

The two username fragments are concatenated together to form the  
username in the STUN Request message. This shows that the request is  
sent and received by the correct endpoints (see the discussion in  
section B.4 of the ICE spec). The password is used as the keying  
material for the MESSAGE-INTEGRITY attribute in the STUN messages,  
which ensures that the STUN messages have not been corrupted or faked.

- Philip

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 13 Sep 2007 15:19:58 +0300

>>> locator info in the R1 packet, the Initiator would need to  
>>> include its public key in the I1 packet, which is a (small)  
>>> change from the way things are done right now. Am I correct?
>>
>> Well, sending the public key in I1 and changing when session key  
>> is created would be a *major* change to HIP...
>
> ENCRYPTED TLV can be included in those messages, and they can in  
> turn include multiple sub-attributes (such as LOCATOR). Is this  
> correct?

Yes, that  is correct, but ...

> http://tools.ietf.org/html/draft-ietf-mmusic-ice-17#section-18

... based on my very quick skimming of the section, the issue seems  
to be the integrity of the messages, not their secrecy.  In the  
current ICE solution the password is used as a (quite weak) integrity  
mechanism; HIP can do better.

If that is true (someone please read the ICE sec cons section more  
thoroughly), then we can start the offer/answer already in R1 in the  
case where the responder's offer is independent of the initiator.  On  
the other hand, when the responder's locator set is initiator- 
dependent, we have to defer the start of the exchange until I2.  In  
neither case you should need to use ENCRYPTED.  The existing  
integrity checks (SIG/HMAC) should suffice, if I understand the  
situation correctly.

--Pekka