Subject: [Hipsec] Rendezvous server

From: [email-masked] (Jan Mikael Melen)
Date: Mon Mar 29 03:48:01 2004

Hi, Kristian and others!

When rendezvous server receives a valid I1 packet how do we process it and 
forward it to the responder?

The easiest solution I could come up with would be that as the rendezvous 
server receives an I1 packet it would check that we have a existing HIP 
association between RVS and the responder. The rendezvous server then would 
create a PAYLOAD packet and set the next header in HIP header as IP or IPV6, 
source HIT would be RVS HIT and destination HIT would be responder's HIT. The 
actual payload of that packet would be the original I1 (unmodified). The 
payload packet would be used for tunneling packets between RVS and responder.

The responder would then first process the payload header and then process the 
original I1 packet as if it would have been received straight from the 
initiator. If the I1 is valid and acceptable then the responder could send an 
R1 straight back to the initiator.

Both initiator and responder could this way learn each others IP addresses 
during the HIP negotiation.

This way we would not have at least following problems:
If rendezvous server would just make a translation for destination address 
then the packet could be dropped due egress filtering in the rendezvous 
servers network.
If RVS would change the source IP address as it's own, then a new TLV should 
be defined to preserve the initiators IP address. As suggested above as the 
I1 is sent unmodified in the payload packet no need to preserve the initiator 
IP address in to a TLV.

Comments? Is this a completely stupid idea?

  Regards,
	Jan

---

From: [email-masked] (Kristian Slavov)
Date: Mon Mar 29 06:20:03 2004

> payload packet would be used for tunneling packets between RVS and responder.

This sounds ok. We haven't implemented PAYLOAD packet yet, so I can't comment on 
how easy it is to implement IP(v6)-over-HIP. :)

Now we need a way to ask the RvS if it is willing to serve us. I could imagine 
RvSes having ACLs. The NOTIFY packet could be used to inform the result 
(denied/accepted).

-- 
Kristian Slavov
Pohjoiskaari 8 B 43, 00200 Helsinki, Finland
GSM: +358-40-7220960

---

From: [email-masked] (Julien Laganier)
Date: Mon Mar 29 10:49:01 2004

> Hi, Kristian and others!

Hi,

> When rendezvous server receives a valid I1 packet how do we process
> it and forward it to the responder?

More thoughts below,

> The easiest solution I could come up with would be that as the
> rendezvous server receives an I1 packet it would check that we have
> a existing HIP association between RVS and the responder. 

Perhaps requiring an HIP association all the time between a HIP node 
and its RVS is a bit onerous, especially for the RVS. As I1s are not 
authenticated anyway, we might obtain the same security guarantees by
only requiring an HIP Association periodically, in order to create, 
update or renew a "soft HA", that would only consist in a an 
associated lifetime, Destination HIT and IP address. This would avoid 
storing on the RVS a full HA data structure with public keys and so 
on, thus increasing scalability.

> The rendezvous server then would create a PAYLOAD packet and set the
> next header in HIP header as IP or IPV6, source HIT would be RVS
> HIT and destination HIT would be responder's HIT. The actual
> payload of that packet would be the original I1 (unmodified). The
> The responder would then first process the payload header and then
> process the original I1 packet as if it would have been received
> straight from the initiator. If the I1 is valid and acceptable then
> the responder could send an R1 straight back to the initiator.
>
> Both initiator and responder could this way learn each others IP
> addresses during the HIP negotiation.
>
> If rendezvous server would just make a translation for destination
> address then the packet could be dropped due egress filtering in
> the rendezvous servers network.
> If RVS would change the source IP address as it's own, then a new
> TLV should be defined to preserve the initiators IP address. As
> suggested above as the I1 is sent unmodified in the payload packet
> no need to preserve the initiator IP address in to a TLV.
>

Well, I don't think it's a stupid idea :-)

On one hand, I like the idea of having a generic forwarding facility 
for IP packet like the one you describe in your mail. Moreover it 
allows piggybacking as well.

But on the other hand, the RVS are just supposed to forward I1, and 
you need to carry a full IP header while only the source address is 
useful.

AFAICS, because I1 are not authenticated anyway, you could probably 
just  forward them after having rewrote the source address (for 
egress filtering) and adding a (new) TLV parameter with type 
FORWARDED_FROM, containing the source address of the initiator.

This mechanism can be exploited for DoS attacks (spoofing a RVS for 
sending I1 and create R1 storms), but it's not that different from 
the base protocol (the responder answers an I1 with a R1 without 
crypto checks).

Thoughts and comments welcomed. Thanks,

--julien