Subject: [Hipsec] Text for solving the R2 losses problem

From: [email-masked] (Henderson, Thomas R)
Date: Fri Mar 12 10:33:01 2004

Pekka,
I am still wondering whether this deserves to be defined as
a full state in the state machine.  In other signaling protocols
that I have helped to define in the past, there is always
the possibility that the last packet in the handshake gets
lost.  This is usually handled with no problem by just resending
the last packet of the handshake again, and cycling in the
same ESTABLISHED state. =20

Your point is that it would be odd to get an I2 when the SA
has been in use, and would like to suppress response to such
an I2 if it seems unusual to be receiving it.  Another=20
way to do this, that seems basically equivalent, is to define=20
"I2 received" in ESTABLISHED state as follows:

     Receive I2, process
          if success and I2 appears to be retransmission, resend R2 and =
stay in ESTABLISHED**
          if fail, stay at ESTABLISHED
          **NOTE:  An implementation MAY choose to ignore this
          **       I2 if the inbound SA has already been used

>=20
> Comments/questions:
> - should we have a timeout?  What if we do, should the
>    Responder move to ESTABLISHED, send yet another R2 and
>    move to ESTABLISHED, or drop the association?

It would be preferable to avoid specifying a mechanism that
requires putting a timer there.

Whether to require an application to use the SA in a timely
manner is an interesting question.  On the one hand, it=20
might be useful to not force the sender to use the SA
for the state machine to function correctly, since it is possible
that some application of HIP may pre-establish the SA in the
absence of any user data, just so it is in place for eventual
forthcoming data transfer to cut down on the initial latency.
On the other hand, setting up meaningless HIP SAs with no
intention of ever using them is an avenue for resource
depletion attack.

> - In practice, an implementation may just stay in R2-SENT
>    for a brief period of time (few seconds), poll the SA
>    to see if any traffic has been received, and if so, move
>    to ESTABLISHED.

If we define "R2-SENT" as an implicit optional substate of=20
ESTABLISHED, then we do not require any polling to move to=20
ESTABLISHED, and only poll if you receive an I2.  This
optimizes for the common case.=20

We are really debating about presentation style in the spec;
implementation can probably be the same, except that the
spec may lead people to implement it one way or the other.

Tom

---

From: [email-masked] (Pekka Nikander)
Date: Mon Mar 15 04:17:04 2004

Tom,

> a full state in the state machine.

Well, as you state later, that is a matter of taste.  In
general, I think that we have to state more explicitly in
Section 5 that the presented state machine is *not* normative
in any way, and that Section 8 contains the (more) normative
text.  But let's also keep in mind Jim Bound's comment about
implementation details...

> In other signaling protocols
> same ESTABLISHED state.

We seem to have multiple issues here:

  1. Do we want to preserve the distinction between the
     initiator and responder once we are in ESTABLISHED?
     The original goal was NOT to have any distinction.

  2. Is it secure to process I2s in ESTABLISHED?  At minimum,
     it may lead to unnecessary DoS.  An attacker can exchange
     I1/R1, then solve the puzzle, and send an I2 with a valid
     puzzle.  IIRC, one of the reasons for dropping I2s in
     ESTABLISHED is to avoid this DoS; I remember that we came
     into some problems with this in attacks where an attacker
     bumps up birthday thereby making this attack feasible.
     (One of the reasons why we have been moving away from
     resynching and the birthday concept)

  3. The whole purpose of this discussion is to make sure that
     we recover from a lost R2, by allowing the responder to
     process I2s even after it is otherwise established.

I think that we need to have a "state / substate / whatever"
for a transient period of time where the responder is willing
to reprocess I2s and send copies of R2.  I think we agree there.
The problem is in the details (as usual).

> an I2 if it seems unusual to be receiving it.

Its more about the DoS attack outlined above.

> Another  way to do this, that seems basically equivalent, is to define
>           if success and I2 appears to be retransmission, resend R2 
> and stay in ESTABLISHED**

 From the functional point of view, this would be OK.  However,
this would be counter to the architectural goal where the
distinction between the responder and initiator is lost when
they enter the ESTABLISHED state.

> requires putting a timer there.

The question is that if we want to make the peers equal in
ESTABLISHED, we have to use something to trigger the responder
to move to "fully ESTABLISHED" state, not answering to I2s any
more.

> manner is an interesting question.

Right...  It is also a question about return routability.
Remember, the responder has no state before processing I2
and responding with R2.  Hence, it has no assurance that the
source address listed in I2 really belongs to the initiator.

In the opportunistic case, I can imagine an application where
the responder starts sending large amounts of data immediately
once it has entered ESTABLISHED.  That would be a source of
flooding attacks, unless we have some RR in place.  (Of course,
this is not a problem if we are not using opportunistic HIP but
where the initiators are required to be pre-configured and
trusted.)

> On the one hand, it

Agreed.

> intention of ever using them is an avenue for resource

That too.  However, I guess the responder will just timeout
such state after a short period of inactivity.  In any case,
it is _allowed_ to do so.

> If we define "R2-SENT" as an implicit optional substate of
> ESTABLISHED, then we do not require any polling to move to
> optimizes for the common case.

Indeed.  Much better to do it in that way.

> spec may lead people to implement it one way or the other.

Agreed.

We seem to have a (slight) disagreement on two points:
- the architectural goal of no distinction between responder
   and initiator in ESTABLISHED state
- the question about whether we need initial RR

--Pekka

---

From: [email-masked] (Andrew McGregor)
Date: Mon Mar 15 06:29:00 2004

>      The original goal was NOT to have any distinction.

Which is, I think, pretty much essential to retain.  That way it is always 
safe for either end to be the initator of any further mechanisms, without 
having to deal with differences to do with who was the initiator of the 
whole session.

> to move to "fully ESTABLISHED" state, not answering to I2s any

Sequence number zero no longer in the replay window?  That might be tricky 
to do in some implementations, but makes a certain kind of sense.

> source address listed in I2 really belongs to the initiator.

In the presence of NAT, it may well not belong to the initiator, and the 
initiator may not know if the reverse mapping in the NAT works, so even a 
polite initiator can cause this to happen without meaning to.

>> forthcoming data transfer to cut down on the initial latency.

I have some applications in mind that will do exactly that, although they 
may well also be doing keepalive checks.

> it is _allowed_ to do so.

Of course, the mere presence of an SA may have some meaning, too, without 
having to send anything across it.  It might count as some kind of 
authentication success, for instance.  One would presume that the responder 
policy would involve long timeouts in this case.

Andrew

---------
Andrew McGregor
Director, Scientific Advisor
IndraNet Technologies Ltd
http://www.indranet-technologies.com/

---

From: [email-masked] (Petri Jokela)
Date: Fri Mar 26 03:57:00 2004

Andrew McGregor wrote:
> Which is, I think, pretty much essential to retain.  That way it is 
> always safe for either end to be the initator of any further mechanisms, 
> without having to deal with differences to do with who was the initiator 
> of the whole session.

Folks, it's time for shooting: shoot the following ideas down.

1)
If we calculate an R2 packet every time we enter the ESTABLISHED state 
(even if we are originally the Initiator), we could always respond to an 
incoming I2 with this precalculated R2. We should not make any 
verification on the I2 packet, just respond to it like in case I1/R1. 
This reveals our SPI to a possible attacker. Is it a threat? The SPI is 
visible also in other packets, although not directly sent to an attacker.

With this, we don't have to maintain any information about our previous 
status as an Initiator or Responder.

When the SPI changes, also the precalculated R2 must be recalculated.

(When traffic arrives on the SA, the R2 could be removed, after which we 
do not respond to any I2s.)

Is there any possibility for a DoS attack?

2)
And, in fact, if we are originally Initiator, the precalculated R2 could 
contain garbage because future incoming I2s are false anyway...

3)
Further developing the idea: store R2 when we as responder send it out. 
As an initiator, we do nothing. Define in ESTABLISHED that respond to an 
I2 with an R2 if stored, otherwise drop the I2. In this case, I think, 
we move in the grey zone (as the term is in sports when you use 
something "almost" doping), because we "know" that we are a responder if 
we have an R2.

/petri

-- 
Petri Jokela                        Tel:    +358 9 299 2413
Research scientist                  Fax:    +358 9 299 3535
NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
Oy L M Ericsson Ab                  email: [email-masked]