Subject: [Hipsec] Rendezvous server

From: [email-masked] (Henderson, Thomas R)
Date: Fri Apr 9 21:32:28 2004

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]
> Sent: Tuesday, April 06, 2004 11:48 PM
> To: Tim Shepard
> Cc: [email-masked]
> Subject: Re: [Hipsec] Rendezvous server=20
>=20
>=20
>=20
> An alternative would be to add an unprotected FROM to the
> I1, let the responder answer back to the RSV, and let the
> R1 carry a TO parameter, letting the RSV to pass the R1
> back to the original initiator.  No triangular routing,
> no worries about amplification or reflection.
>=20

I wonder whether, generally, this will be needed anyway
for middlebox traversal-- consider rendezvous server in domain
C for a mobile host in domain B which a corresponding host
in domain A wants to talk to-- the boxes traversed from
A-C-B may be different than the boxes from B-A.  Then,
as Tim alluded to, the I2/R2 exchange sets up the state
between B and A middleboxes, while the R1 uses the
binding established by I1 (or as Tim suggested, if there
is already an IPsec association between Rendezvous Server
and mobile host, then that could be used for R1 as well).

But does this then degenerate to loose source record route
at the HIP layer I1/R1 for the case of cascading RSVs?

Tom

---

From: [email-masked] (Pekka Nikander)
Date: Sun Apr 11 01:49:00 2004

> binding established by I1.

Maybe so.  Depends on network configuration.  In general,
I think that on the protocol level we should aim towards
not unnecessarily blocking some configurations, and leaving
the details for operational considerations.  That is, aiming
simultaneously towards simplicity and flexibility.

Thinking more about this, what if the FROM parameter includes
an opaque blob that the RSV can use to route back the R1
to the sender of I1?  Consider the following:

   1. Init, at A_I, sends an I1 to the RSV, at A_RSV.
      In I1, src=A_I and dst=A_RSV

   2. The RSV processes the packet, and determines A_R.
      It adds FROM to I1, and forwards it.
      In I1, src=A_SRV and dst=A_R.
      In FROM, from=A_I, hmac=HMAC(K_R,RSV; A_I, I1), and
         blob=HMAC(K_RSV; A_I, HIT_I, HIT_R)

   3. If the Responder policy is to answer back via the
      RSV, it sends an R1 to the RSV:
      In R1, src=A_R and dst=A_RSV
      In TO, to=A_I, hmac=HMAC(K_R,RSV, A_I, R1), and
         blob=copied from I1

   4. If the Responder policy is to answer directly to
      the Initiator, it sends an R1 to the Initiator:
      In R1, src=A_R and dst=A_I
      In VIA, via=A_RSV, and blob=copied from I1

where

   K_R,RSV is a shared secret between the Responder and the
   RSV,

   K_RSV is a symmetric key known only to the RSV

   FROM, TO, VIA are new parameters to be defined.

Would that be a good approximation that would support both
scenarios (R->RSV->I and R->I) while still having enough
information for operational diagnosis?

On the other hand, it might also be a good idea to consider
some ideas from SOS (Secure Overlay Service by Keromytis et al)
or Secure-I3 (by Atkins, Stoica et al.).  In other words, in
some cases it might be a good idea to _prevent_ the initiator
from knowing the responders IP address until R2.

> (or as Tim suggested, if there

As I already said, I think passing both I1 and R! over
existing ESP SAs is a good MAY, but not good as the default
behaviour.  Further, passing *both* I1 and R1 is better
than just passing I1.

> at the HIP layer I1/R1 for the case of cascading RSVs?

Yes it does.  It also may be engineered to make HIP RSVs
to behave more like I3.  In either case, the security
issues seem to be tricky, and depend on the goals.  Finding
the right balance between simplicity and flexibility seems
to get, hmm, difficult...  Combine this with the desire of
supporting LHIP, and we get an interesting problem...

--Pekka

---

From: [email-masked] (Julien Laganier)
Date: Thu Apr 15 06:20:02 2004

Hi Pekka,

Please find more thoughts below:

> information for operational diagnosis?

I like this proposal.

> from knowing the responders IP address until R2.

If both I1 and R1 are passing through the RVS, it's straightforward to 
hide to the Initiator the Responder's IP address until R2: The 
Initiator will get an R1 coming from the RVS's IP address in answer 
to an I1 sent to the RVS's IP address.

I		RVS		R

------(I1)------> --(I1:From I)-->

<-----(I1)------- <--(R1:To I)----

------(I2)------> --(I2:From I)-->

<----------(R2:Via RVS)-----------

Furthermore, if there's two (or more) cascaded RVS, the initiator will 
ignore even the secondth RVS's IP address until it receives R2, and 
the first RVS will ignore the Responder's IP address:

I		RVS_1		RVS_2				R

------(I1)------> --(I1:From I)--> -----(I1:From I:From RVS_1)-->

<-----(I1)------- <--(R1:To I)---- <----(I1:To I:To RVS_1)-------

------(I2)------> --(I2:From I)--> -----(I2:From I:From RVS_1)-->

<-------------------(R2:Via RVS_1: Via RVS_2)--------------------

> behaviour.  Further, passing *both* I1 and R1 is better

Wether only I1 or both I1 and R1 should be passed through an existing 
ESP SA between the RVS and the Responder should be a policy choice. 
If a responder want to hide its IP address until it gets I2, then 
both should passed over the SA. If a responder doesn't want to hide 
its IP address, then it is ok to pass just the I1.

> supporting LHIP, and we get an interesting problem...

Talking about I3, the triggers (i.e., in HIP terminology, an 
association between a Responder and a RVS, or Rendez-Vous Association 
== RVA) are tuple <Id, Id> or <Id, Loc>. 

In HIP, a RVA is a tuple <Id, Loc> (i.e., <HIT, Address>).

So I am not sure to really understand what you mean; Do you just mean 
that we should be able to cascade RVS, or do you mean that we should 
be able to handle RVA of the form <Id, Id> (i.e., <HIT, HIT>)?

BTW, Below is a strawman proposal for FROM, TO and VIA parameters, 
based on your proposal of having opaque blobs:

_________________________________________________________________

FROM:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                             Address                           |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                             HMAC                              |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                             BLOB                              |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type           65400
Length         56
Address        An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
HMAC           160 low order bits of the HMAC keyed with a
               symetric key shared between the Responder and the 
               Rendez-Vous Server, computed over the HIP
               packet, including the Type, Length and Address fields
               of the FROM parameter, and excluding the HMAC and
               BLOB fields. The checksum field MUST be set to zero
               and the HIP header length in the HIP common header
               MUST be calculated not to cover any excluded
               parameters when the HMAC is calculated.
BLOB           160 low order bits of the a HMAC keyed with a
               symetric key chosen by the Rendez-Vous Server,
               computed over the Address field, and the
               Initiator and Responder HITs of the HIP packet.

TO:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                             Address                           |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                             HMAC                              |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                             BLOB                              |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type           65402
Length         56
Address        An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
HMAC           160 low order bits of the HMAC keyed with a
               symetric key shared between the Responder and the 
               Rendez-Vous Server, computed over the HIP
               packet, including the Type, Length and Address fields
               of the TO parameter, and excluding the HMAC and
               BLOB fields. The checksum field MUST be set to zero
               and the HIP header length in the HIP common header
               MUST be calculated not to cover any excluded
               parameters when the HMAC is calculated.
BLOB           160 low order bits of the a HMAC keyed with a
               symetric key chosen by the Rendez-Vous Server,
               computed over the Address field, and the
               Initiator and Responder HITs of the HIP packet.

VIA:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                             Address                           |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type           70
Length         16
Address        An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
_________________________________________________________________

Any thoughts whelcomed; Tnx.

--julien

---

From: [email-masked] (Pekka Nikander)
Date: Thu Apr 15 07:28:00 2004

> to an I1 sent to the RVS's IP address.

Right.  However, we can do better here.  Instead of using
FROM and TO, the RSV can just use ECHO_REQUEST and
ECHO_RESPONSE and hide even the Initiator's address.
In that case the Responder doesn't even have an
option of answering directly to the Initiator.

> ESP SA between the RVS and the Responder should be a policy choice.

Yes, but the draft should also be very pragmatic about the
consequences of such policy choices, especially wrt. middle boxes.

> be able to handle RVA of the form <Id, Id> (i.e., <HIT, HIT>)?

I don't know.  I'm still struggling in trying to understand
the similarities and differences between I3 and HIP.

> BLOB

A point is that the blob is opaque, just like in the
ECHO_REQUEST and ECHO_RESPONSE.  Any BLOB in FROM
is just echoed back in TO.  An important issue is that any
packet containing a TO _MUST_NOT_ be forwarded unless
there is a BLOB that authenticates properly.

A better name for the BLOB would be Authenticator.

> VIA

Maybe the VIA should not be named VIA but VIA-RSV or
something that makes it clear that it does not refer to
the route of the original packet, not this one?

I think VIA should be variable length, allowing one
VIA to have multiple addresses.

--Pekka