Subject: [Hipsec] Comments on draft-eggert-hip-rendezvous-01pre1

From: Kristian Slavov <[email-masked]>
Date: Fri, 18 Jun 2004 16:44:46 +0300

Hi,

Is there a problem (for example) in 7.2.3: Once the responder receives I1 with 
FROM parameter from the RVS, it sends the R1 straight to the Initiator.
The R1, that is sent, needs to have REA and VIA_RVS parameters added. The 
VIA_RVS is not covered by the signature, so it is not a problem. However, the 
REA parameter is. It effectively hinders us to use precreated R1s.
Now a trivial DoS attack would be to send I1s with FROM field and force the 
responder to create a lots of R1s.
The responder can have some intelligence, like checking that the I1 with FROM 
parameter originates from a certain IP address(es) but that is easily forged.

An another question related to the soft-HA (or RVA) creation:
When is the correct time to create the RVA? The HIP base draft says that the 
responder should transition to ESTABLISHED state no sooner than it has received 
ESP data for that connection or some time has passed.

Currently I've solved the above issues like this:

1) When an R1 is received and is discovered to be valid, its source IPv6 address 
is saved to the address list of the HIP Host Association in question. The rest 
of the base exchange uses this new address. This way we can use the precreated R1s.

2) As soon as the I2 is deemed to be valid and the R2 created, we create the 
RVA. We are in R2-SENT state at that time.

-- 
Kristian Slavov, Researcher
Helsinki Institute for Information Technology
Gsm: +358-40-7220960
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Julien Laganier <[email-masked]>
Date: Mon, 21 Jun 2004 10:42:54 +0200

On Friday 18 June 2004 15:44, Kristian Slavov wrote:
> Hi,
>
> Is there a problem (for example) in 7.2.3: Once the responder
> receives I1 with FROM parameter from the RVS, it sends the R1
> straight to the Initiator. The R1, that is sent, needs to have REA
> and VIA_RVS parameters added. The VIA_RVS is not covered by the
> signature, so it is not a problem. However, the REA parameter is.
> It effectively hinders us to use precreated R1s. 

The REA parameter contain the _responder_'s IP addess, which is not 
supposed to change with each initiator attempting to associate. So we 
can precompute a pool of R1 per responder's IP address.

> Now a trivial DoS 
> attack would be to send I1s with FROM field and force the responder
> to create a lots of R1s.
> The responder can have some intelligence, like checking that the I1
> with FROM parameter originates from a certain IP address(es) but
> that is easily forged.

I don't think this applies.

> When is the correct time to create the RVA? The HIP base draft says
> that the responder should transition to ESTABLISHED state no sooner
> than it has received ESP data for that connection or some time has
> passed.

While creating a RVA, I believe that the responder (i.e., the RVS) 
should  transition to ESTABLISHED state  no sooner than it has 
received incoming R1s to be relayed, or some time has passed. That 
way we are consistent with the HA state model.  

> 1) When an R1 is received and is discovered to be valid, its source
> IPv6 address is saved to the address list of the HIP Host
> Association in question. The rest of the base exchange uses this
> new address. This way we can use the precreated R1s.
>
> 2) As soon as the I2 is deemed to be valid and the R2 created, we
> create the RVA. We are in R2-SENT state at that time.

This is equivalent to the HA state model with a time limit of zero. 
What do people think of this issue? 

Thanks,

--julien

---

From: Kristian Slavov <[email-masked]>
Date: Mon, 21 Jun 2004 15:33:44 +0300

> can precompute a pool of R1 per responder's IP address.

The pool aproach might be inefficient in long run. We would have
a situation where there are 4 variables in R1: DH group, puzzle K, HI and the
responder's IPv6 address. Now, say we have 2 different values for each
of the variables. That means 2^4 different R1s and we probably will want
to have more than one of each R1 (say 10). So, we will need to create
160 R1s.

However, I don't have anything better to suggest right now.