Subject: Re: [Hipsec] changes to base spec?

From: Julien Laganier <[email-masked]>
Date: Mon, 16 May 2005 21:13:11 +0200

Hi,

On Wednesday 11 May 2005 14:45, Petri Jokela wrote:
> Andrei Gurtov wrote:
> > Hi,
> >
> > Tuomas and Aarthi wrote a paper on the Analysis of the HIP Base
> > Exchange Protocol that will appear in ACISP'05, July 2005.
> > http://www.cs.helsinki.fi/u/gurtov/papers/analysis_hip.pdf
> >
> > They suggest several changes to the HIP specs for improving
> > security. Do you think we should adopt any of the changes for the
> > base spec?
>
> Few comments:
>
> Problem 1 & solution:
>
> Adding the nonce to I1 and R1 is not a big problem, but I currently
> can't see much help of it. The attacker should know when the I1 is
> sent from the initiator and send the R1 at a suitable moment. The
> attacker, being not on the path, does not know when the I1 is sent,
> so it must just guess when to attack. Maybe there are cases, when
> this is easy to do and I just can't see them now...
>
> If the attacker is on the path, it gets the nonce in I1, in which
> case there is naturally no protection from that.

There is a related problem when an opportunistic initiator tries to 
reach a node via its rendezvous server.

The initiator sends an I1 to the NULL destination HIT at the RVS IP 
address, which relays it to the responder. If the responder replies 
an R1 directly to the initiator, there's currently no way for the 
initiator to identify the correct context, apart from the RVS IP 
address included in an optional VIA_RVS parameter.

A similar problem exists if an opportunistic initiator which accept 
from an off-path attacker an R1 containing its HIT and a LOCATOR 
parameter pointing to its own location (like below in the figure 10 
excerpted from hip-mm-01).

Having nonce in I1/R1 would help w.r.t. to this scenario, and can be 
implemented with ECHO_REQUEST in I1, and an ECHO_REPLY placed after 
the R1's SIGNATURE.

What do you think? Thanks.

--julien

----------------------------------------------------------------
            Initiator                                Responder

                              R1 with LOCATOR
                  <-----------------------------------
   record additional addresses
   change responder address
                     I2 with new SPI in SPI parameter
                  ----------------------------------->
                                                     (process 
                                  R2                 normally)
                  <-----------------------------------
   (process normally)

                   Figure 10: LOCATOR inclusion in R1

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Jan Mikael Melen <[email-masked]>
Date: Tue, 17 May 2005 22:41:03 +0300

Hi,

> address included in an optional VIA_RVS parameter.

You are probably referring to a case where RVS acts as an sentinel node for a 
farm of servers. This is really a special case but yes you have a valid point 
that in order this kind of scenario to work you would need a nonce. Perhaps 
the solution would be to add optional ECHO_REQUEST to I1 and a ECHO_RESPONSE 
that is outside the signature to R1 as you suggested. If this kind of 
scenario should be supported at all? Normally the destination HITs of these 
computer farms are probably well known.

> excerpted from hip-mm-01).

Still the off-path attacker would have to know the source IP address and the 
HIT of the node that is sending the I1 with NULL HIT and also the timing must 
be correct. One can't just randomly send the R1's because if the host has not 
sent a I1 it will drop the packet and if the destination HIT is wrong it 
should drop the packet so the probability of  getting these right is not 
really that big unless the attacker is on the path when even the nonce 
doesn't protect you.

  Regards,
 Jan

---

From: Jan Mikael Melen <[email-masked]>
Date: Tue, 17 May 2005 22:41:03 +0300

Hi,

  Regards,
 Jan

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 18 May 2005 15:28:50 +0300

>> address included in an optional VIA_RVS parameter.

I think we should forbid that behavior.  Firstly, if the destination HIT
is NULL then the rendezvous server cannot reliably know to which
destination the I1 is really intended to, unless it is serving just a
single destination host.

IMHO the right way forward here is to state (in the rendezvous doc)
that if you want to support rvs with NULL dest HITs, then the return
R1 *MUST* go through the rendezvous server and appear coming from
the rendezvous server's IP address.

Or am I missing something?

> computer farms are probably well known.

I have no objection in adding *optional* (for Initiator) support for 
that.
Apparently, the support in the Responder should be RECOMMENDED or 
REQUIRED.
I'd be in favor of making it RECOMMENDED, meaning that the Initiator
must be prepared to receive an R1 without an ECHO_RESPONSE even if they
sent an ECHO_REQUEST in I1.

--Pekka

---

From: Julien Laganier <[email-masked]>
Date: Wed, 18 May 2005 15:47:01 +0200

On Wednesday 18 May 2005 14:28, Pekka Nikander wrote:
> >> There is a related problem when an opportunistic initiator tries
> >> to reach a node via its rendezvous server.
> >>
> >> The initiator sends an I1 to the NULL destination HIT at the RVS
> >> IP address, which relays it to the responder. If the responder
> >> replies an R1 directly to the initiator, there's currently no
> >> way for the initiator to identify the correct context, apart
> >> from the RVS IP address included in an optional VIA_RVS
> >> parameter.
>
> I think we should forbid that behavior.  

Okay. I'd like to hear more opinions before we take a decision.

> Firstly, if the 
> destination HIT is NULL then the rendezvous server cannot reliably
> know to which destination the I1 is really intended to, unless it
> is serving just a single destination host.

With IPv6 there is an additional possibility: it might be reasonable 
for a RVS to have a per-client IPv6 address, and to demultiplex 
incoming I1s based on their destination IP address.

> that if you want to support rvs with NULL dest HITs, then the
> return R1 *MUST* go through the rendezvous server and appear coming
> from the rendezvous server's IP address.
>

That's in the current draft. Security considerations says:

   If an Initiator has not an a priori knowledge of the Responder's HI
   (so called Opportunistic Initiators), it is almost impossible to
   defend the HIP exchange against MitM attacks (cannot authenticate
   public keys exchanged).  The only solution is to mitigate hijacking
   threats on the HIP state by requiring an R1 answering an
   Opportunistic I1 to come from the IP address where the I1 was
   initially sent. That way we retain a level of security which is
   equivalent to what exists today in the Internet: By sending an IP
   packet to an IP address, and receiving an answered IP packet from
   this same IP address, I know that the routing fabric trusts my
   correspondent to be represented by this IP address. While it is 
   true that such security is weak, it is better than none, and avoids
   to introduce additional threats at the IP layer.

> > that is outside the signature to R1 as you suggested. If this
> > kind of scenario should be supported at all? Normally the
> > destination HITs of these
> I have no objection in adding *optional* (for Initiator) support
> for that.
> I'd be in favor of making it RECOMMENDED, meaning that the
> Initiator must be prepared to receive an R1 without an
> ECHO_RESPONSE even if they sent an ECHO_REQUEST in I1.

Okay.

So I'd like to hear more voice for/against the opportunistic mode with 
RVS. Do we keep the current text (reply R1 via the RVS) or do we 
forbid this behavior as Pekka proposed?

Thanks.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Fri, 20 May 2005 10:11:15 +0200

Folks,

On Wednesday 18 May 2005 15:47, Julien Laganier wrote:
> > >> There is a related problem when an opportunistic initiator
> > >> tries to reach a node via its rendezvous server.
> > >>
> > >> The initiator sends an I1 to the NULL destination HIT at the
> > >> RVS IP address, which relays it to the responder. If the
> > >> responder replies an R1 directly to the initiator, there's
> > >> currently no way for the initiator to identify the correct
> > >> context, apart from the RVS IP address included in an optional
> > >> VIA_RVS parameter.
> >

(...)

> So I'd like to hear more voice for/against the opportunistic mode
> with RVS. Do we keep the current text (reply R1 via the RVS) or do
> we forbid this behavior as Pekka proposed?

Until now nobody has objected to Pekka's proposal, so if nobody still 
don't object in the following days, I will put some text in the draft 
to forbid opportunistic mode with rendezvous relaying: 

-An initiator MUST not send an I1 with a NULL destination HIT to an IP 
address which is known to be a rendezvous server address. 

-A rendezvous server MUST drop incoming I1 with a NULL destination 
HIT.

-A rendezvous client, acting as responder, MUST drop incoming I1 with 
a NULL destination HIT which were relayed by a rendezvous server.

I'm not sure of the requirements level, however. Perhaps MUST is too 
strong, and SHOULD would be sufficient. 

Opinions?

Thanks.

--julien

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 20 May 2005 11:52:21 +0300

> -A rendezvous server MUST drop incoming I1 with a NULL destination

Alternatively, it could interpret it as an I1 to itself.  That
would be perfectly OK from a semantics point of view, provided
that the rendezvous server is a HIP host itself.

> a NULL destination HIT which were relayed by a rendezvous server.

I don't quite understand the rationale of this.  In some cases the
client may not even know that it is coming from its rendezvous
server and not directly from another host?  Or am I missing something
here?

> strong, and SHOULD would be sufficient.

I think SHOULD is enough.  Little harm is done if someone
acts badly, so we shouldn't use MUST.

--Pekka

---

From: Julien Laganier <[email-masked]>
Date: Fri, 20 May 2005 11:20:30 +0200

Hi Pekka,

Thanks for your quick answer. More below,

On Friday 20 May 2005 10:52, Pekka Nikander wrote:
> > -A rendezvous server MUST drop incoming I1 with a NULL
> > destination HIT.
>

You're right. Let's have this text:

-A rendezvous server SHOULD interpret any incoming opportunistic I1 
(i.e. with a NULL destination HIT) as an I1 to itself and SHOULD NOT 
attempt to relay it to one of its clients.

> > -A rendezvous client, acting as responder, MUST drop incoming I1
> > with a NULL destination HIT which were relayed by a rendezvous
> > server.
>
> server and not directly from another host?  Or am I missing
> something here?

I should have been more precise: I was thinking to the case where the 
responder get an opportunistic I1 including a FROM:ip_address 
parameter, indicating that the packet was relayed. I propose this 
text:

-A rendezvous client acting as responder SHOULD drop opportunistic I1s 
including a FROM parameter because that means the I1 has been 
relayed.

Along with their initiator counterparts:

-An initiator SHOULD not send an opportunistic I1 with a NULL 
destination HIT to an IP address which is known to be a rendezvous 
server address.

-An initiator SHOULD drop R1s replying to an opportunistic I1 if it 
does not come from the IP address the I1 was sent to.

Is that okay with everybody? Thanks.

--julien

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 20 May 2005 12:31:26 +0300

> destination HIT to an IP address which is known to be a rendezvous

You might want to add in parenthesis:  (If the Initiator knows
that a given IP address belongs to a rendezvous server, it most
probably also knows the HIT of this rendezvous server.)

Or, alternatively, you could simply add:

, unless it wants to establish a HIP association with the
rendezvous server itself and does not know the HIT of the
rendezvous server.

I am not quite sure which one is the right choice.

> Is that okay with everybody? Thanks.

Other than the note above, looks very good to me.

--Pekka

---

From: Julien Laganier <[email-masked]>
Date: Fri, 20 May 2005 14:29:57 +0200

Folks,

Here is the pre-version of the updated rendezvous draft (based on 
feedback from the hipsec ML) that we plan to submit before the end of 
May.

Changelog from -01 to -02-200505: Removed multiple relaying techniques 
but simple I1 header rewriting. Updated new HIP parameters type 
numbers (consistent with new layout and assigning rules from 
draft-ietf-hip-base.) Updated IANA Considerations. 

Please take a look and let me know if you disagree with the approach 
we took.

<http://julien.laganier.free.fr/draft-ietf-hip-rvs-02-200505.txt>
<http://julien.laganier.free.fr/draft-ietf-hip-rvs-02-200505.html>
<http://julien.laganier.free.fr/draft-ietf-hip-rvs-02-200505.xml>

Thanks in advance,

--julien