Subject: [Hipsec] Rendezvous server

From: [email-masked] (Pekka Nikander)
Date: Tue Apr 6 14:04:01 2004

I like the idea of just forwarding the I1, i.e. rewriting the IP
header, with a new optional parameter saying who (apparently) was
the originator.  There COULD also be an (optional) HMAC, added
by the RSV if it does have an active HIP association with the
responder.

There is one potential attack I see here:  Someone impersonates
as the RSV for many nodes, sends them I1s with the FORWARDED_FROM
TLV (and without HMAC), and makes them to send R1s in a concerted
fashion to a victim.  As R1s are bigger than I1s, this is both
amplification and  reflection, in the sense discussed during MIPv6
RO security design.

To block the attack from anywhere else but RSV addresses, the
responder should obviously check that the I1 source address matches
with an RSV one before responding to FORWARDED_FROM address.

To block the attack when the responder does have an active HIP
assoc with the RSV, the responder should check that if there is
no HMAC but there is an active HIP association, the packet is
dropped, maybe sending a NOTIFY to the RSV.

But, some things to consider and discuss further before making
any final decision...

>> If the new TLV is optional then all hosts might not process it. In
>> this case they will send an R1 to the RvS. The RvS will not reply
>> with I2 as the destination HIT in the R1 will be unknown.

> Right, they'll drop it (or forward it to the initiator if the RVS have
> kept some state in between.... not a very good idea though)

Well, I think that it might even be a _good_ idea to briefly keep
state after forwarding an I1.  You can make a hard limit to the
state, and just drop old entries if you get an I1 storm.

> But, if a HIP node register with a RVS and published its address
> (e.g., in the DNS), then we can legitimately suppose that this node
> needs RVS functionnalities. IMHO, such a HIP node MUST support the
> FORWARDED_FROM TLV, while we can keep it optionnal for other HIP
> nodes.

Sounds good.

>> Also I don't think extending the I1 will bloat the base protocol.

I'm pretty sure that we will see also other extensions to I1.

--Pekka

---

From: [email-masked] (Tim Shepard)
Date: Tue Apr 6 14:36:04 2004

> with an RSV one before responding to FORWARDED_FROM address.

I like the idea of RSV keeping an active HIP associations open with
those for whom it is doing forwarding of I1s.

In that case, you can just forward the I1 over ESP.

And since the only purpose of your locators which are served by RSV is
to get I1s sent to you, I think it reasonable to allow (encourage)
RSVs to rate-limit how many such things get forwarded your way
(perhaps with a token-bucket sort of mechanism) and just quietly drop
other stuff.

Hmm, I think we'll have to keep thinking about all of the DOS
possibilities.  Every time I think I've figured out how to defend
against one type of DOS attack, another one seems to pop up.

			-Tim Shepard
			 [email-masked]

---

From: [email-masked] (Pekka Nikander)
Date: Wed Apr 7 01:59:01 2004

>> the originator.  ...

I certainly agree that when you are mobile, you probably want to
keep an active HIP association.  However, is that really reasonable
for an RSV that servers millions of semi-static hosts?  Maybe not.
I think that we should still design for some flexibility.

> In that case, you can just forward the I1 over ESP.

Well, you could, but I don't like the idea for two specific reasons.

One reason is middle boxes.  The current HIP protocol is very
carefully designed to be middle box friendly.  For example, we
have signatures even in UPDATEs (even if HMACs would be enough),
and the SPIs are readable in all messages.   Passing I1s would
violate this design goal.

The second reason is architecture.  Personally, I like to think
HIP as a "control plane" for an "IPsec based overlay".  That is,
I think that we should allow for the case where HIP protocol
messages take a different path (slow path) than the actual ESP
traffic (fast path).  That might be the case, for example, in
high capacity firewalls.  But it could also be more general.

Hence, I think that passing I1s over ESP might be a MAY, for
such cases where it is useful, but definitely not a MUST nor
even a SHOULD.

In my opinion, in order to keep the design simple and beautiful
enough, the MUST implement and SHOULD use case should be
passing I1s by rewriting the IP header.  To secure that against
amplification and reflection, we need to add the FROM and HMAC
parameters.

> (perhaps with a token-bucket sort of mechanism) and just quietly drop

Sounds good.  But the responder should be in control, i.e. a high
capacity responder should be able to make the limit very high.

Remember, mobility is not the only reason for RSVs.  RSVs could
also be used for other purposes, e.g., for robustness or traffic
engineering / load balancing.

Returning to the passing I1s by rewriting the IP header, I think
that the case is trivial if there is an active HIP association.
Then the FROM and HMAC parameters would give adequate protection.
One thing still needs to be added:  An VIARSV parameter to the
*end* of R1 (outside of the signed area), informing the initiator
that the I1 was received via (one or more) RSVs.

However, to give even more flexibility (cascading RSVs) and to
support the case when there aren't an active HIP association
between the RSV and the responder, I would suggest the following
mechanism:

   0.  The RSV periodically generates a nonce whose lifetime
       is a few days or longer.

   1.  As a part of the RSV protocol, the RSV generates a
       per-served-host key by taking

           key_host = hash(nonce, HIT_host)

       This key is communicated (in encrypted form) to the
       host, and will be valid almost as long as the nonce
       is valid, i.e. at least a few days.

   2.  Even when the active HIP association, used for the
       RSV protocol, is dropped, the host remembers the
       key_host, and its lifetime.  The RSV does not need
       to remember this key, but it can.  (As it stores the
       IP addresses based on the HIT, storing the key is
       not that big deal either.)

   3.  When the RSV receives an I1 destined to the host,
       it adds a new FROM parameter to the I1.  The FROM
       parameter contains BOTH the original source IP
       address in the I1, and a HMAC generated using the
       above mentioned key_host as the key.

Note that if there are several cascaded RSVs, each of
them can add an independent FROM parameter.

When the responder processes a received I1, it does the
following:

   1.  If the source address does not belong to an RSV,
       process just as before.  If there is a FROM
       parameter, simply ignore it, and respond to the
       source address in the I1.

   2.  If the source address does belong to an RSV,
       check if there is a FROM parameter.  If there
       is one, check the HMAC in the FROM parameter.
       If the check fails, drop the packet (and optionally
       send a NOTIFY to the RSV).

   3.  If there are multiple FROMs, process all of
       them sequentially, up to a configurable limit.
       I would suggest default value of 2.

   4.  For each FROM, add a VIARSV to the end of the
       R1 that will be sent out.  The VIARSV does not
       need to have any protection.

In the worst case, this adds one failing HMAC computation
in the case somebody is spoofed IP packets with the source
address belonging to an RSV.  That seems to be acceptable
to me, but still needs to be documented in the security
considerations section.

Now, my only problem with this is that this is somewhat
complicated.  Fairly lot of stuff for making it possible
to send the R1 directly to the initiator.

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.

--Pekka

---

From: [email-masked] (Kristian Slavov)
Date: Wed Apr 7 07:31:00 2004

> that the I1 was received via (one or more) RSVs.

I didn't understand the need for VIARSV parameter, so I had a short
discussion with Pekka. He enlightened me that the VIARSV parameter
is targeted for network/HIP diagnostics.

>       need to have any protection.

If we have a cascading situation like this:

INIT -> RSV1 -> RSV2 -> RESP

The I1 would look like: IP (HIP ( FROM, FROM ))

The FROM parameters would carry the same IP-address (initiators
IP address). The only difference being HMACs created by the RSVs.
The responder cannot check the HMAC in first FROM, as it probably
does not know anything about the RSV1, only about the RSV2.
One advantage in this situation is that we can create those
VIARSVs so that the initiator knows I1's route.

However, if this is not that important we could have a slightly
different aproach:
Since RSV1 is providing RSV services to RSV2, once RSV2 receives
an I1 with FROM parameter, it processes it. If HMAC is valid, then
calculate new HMAC and place it in the FROM parameter (over the HMAC
of the RVS1). Now the responder receives only one FROM parameter
(initiator's IP address and HMAC created by RSV2), and it can verify
the HMAC.

> no worries about amplification or reflection.

In this case, the HIP implementation in RSV would then have to be able to 
process R1s received in UNASSOCIATED state. Or perhaps the RSV forwards I1
and transitions to I1-FORWARDED state. Waits for a while and returns to
UNASSOCIATED state. While in the I1-FORWARDED state, forwards the R1
and returns to UNASSOCIATED.

Naturally the I1-FORWARDED state would not have to exist in implementations
that do not support RSV functionality.

-- 
Kristian Slavov, Researcher
Helsinki Institute for Information Technology
Gsm: +358-40-7220960

---

From: [email-masked] (Tim Shepard)
Date: Wed Apr 7 09:29:01 2004

> violate this design goal.

Do the middle boxes really need to see the I1?   It's not clear to me
that they should do anything with I1s.  It's the I2s and R2s that
imply that state has been established and that carry SPIs that the
middlebox might want to know about.

I'm assuming that the R1 in response to an I1 would be returned
directly, not by way of the forwarder.  (Hmm... have to make sure that
the initiator can figure out what attempted association the R1
corresponds to.  That should be OK, as I don't think we'd be using a
rendezvous server in opportunistic mode, so we do have HIT's for both
ends.)

The I2s and R2s would be much more normal, following normal paths (no
forwarding involved).

			-Tim Shepard
			 [email-masked]

---

From: [email-masked] (Pekka Nikander)
Date: Thu Apr 8 02:18:01 2004

> middlebox might want to know about.

Depends.  If we have a middle box that just sits there in one
IP domain, getting packets from that single domain and passing
back, then it doesn't need to inspect current I1s.  However,
there are (at least) two cases when the situation is not so
easy:

  1. Consider a middle box between two IP domains, i.e. a
     NAT device.  It may need to see the initial I1 to learn
     the Initiator-HIT -> Initiator IP address mapping so that
     it can route back the R1.  If RSVs are used, it needs to
     see the FROM parameter in I1.

     Note that this is actually pretty similar to the RSV
     situation.  If we wanted the RSV to route back the R1,
     it needs to store a temporary Initiator HIT -> IP address
     mapping, i.e., create a temporary piece of state.

  2. Remember that the HIP spec is now open to extensions.
     It may turn that there will be important I1 extensions
     that middle boxes need to inspect.

Hence, as I wrote before, I1 over ESP is OK as a MAY, as it
may be appropriate in some situations, but not as the default
or recommended case.

--Pekka

---

From: [email-masked] (Pekka Nikander)
Date: Thu Apr 8 02:25:01 2004

> The I1 would look like: IP (HIP ( FROM, FROM ))

Yes.

> IP address).

No.  The first FROM would carry the INIT's IP address,
the second one would carry RSV1's IP address.

> The only difference being HMACs created by the RSVs.

Hmmm...  I think it should by default know about both.
There may be situations where it don't know, but in that
case RSV2 should know about RSV1.

> VIARSVs so that the initiator knows I1's route.

Yes.

> (initiator's IP address and HMAC created by RSV2), and it can verify

Otherwise good, but that would make RSV1 invisible, which
would be bad from a diagnostics point of view.  But yes,
RSV2 could verify the HMAC, and create a new FROM that
has two addresses:  INIT's address and RSV1's address.
A kind of reversed routing header.

> In this case, the HIP implementation in RSV would then have to be able 
> to process R1s received in UNASSOCIATED state. Or perhaps the RSV 
> forwards I1

Whichever way, we have to notice that the state create
DOES NOT involve the RSV's HIT, it only involves the
HITs of INIT and RESP.  Hence, different from a non-RSV
HIP node.  I would say that the state machine is completely
unrelated to the normal HIP state machine, and should NOT
be merged in any way.

--Pekka