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

From: [email-masked] (Henderson, Thomas R)
Date: Mon Apr 19 16:40:02 2004

see inline below

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]=20
> Sent: Monday, April 19, 2004 1:24 AM
> To: [email-masked]
> Cc: Petri Jokela
> Subject: Re: [Hipsec] Text for solving the R2 losses problem
>=20
>=20
> We still need changes to Section 8.7. and probably a new
> section handling moving out from R2-SENT.  The following
> changes are against -10-pre1
>=20
> For Section 8.7, I would suggest the following:
>=20
>    Add new steps between current 2 and 3:
>=20
>      2.1  If the system is in the R2-SENT state, it MAY check
>           if the newly received I2 is similar to the one that
>           triggered moving to R2-SENT.  If so, it MAY retransmit
>           a previously sent R2, reset the R2-SENT timer, and stay
>           in R2-SENT.
>=20
>      2.2  If the system is in any other state, it SHOULD
>           check that the birthday value in I2 is larger than
>           the currently stored peer birthday value, if there is
>           a stored value.  If the newly received I2 has a lower
>           or equal birthday value than the stored one, the I2 is
>           stale (perhaps replayed) and SHOULD be dropped.
>=20
>    Remove step 9, as the birthday check is now performed earlier.
>=20
>    Change Step 17 to read:
>=20
>       17. Upon successful processing of an I2 in states UNASSOCIATED,
>           I1-SENT, I2-SENT, and R2-SENT, an R2 is sent and the state
>           machine transitions to state R2-SENT.
>=20
>    In Step 18, replace
>=20
>       s/transitions to ESTABLISHED,/transitions to R2-SENT,/
>=20
>    Add a new step after 18:
>=20
>      19. Upon transitioning to R2-SENT, start a timer.  Leave
>          R2-SENT if either the timer expires (allowing for
>          maximal retransmission of I2s), some data has been
>          received on the incoming SA, or an UPDATE packet has
>          been received (or some other packet that indicates
>          that the peer has moved to ESTABLISHED).  Implementing
>          this step is OPTIONAL.
>=20
> Question:  Should #19 be RECOMMENDED instead of OPTIONAL?

If step 17 says to move to R2-SENT, but step 19 is optional, won't
implementations not implementing step 19 get stuck in state R2-SENT?

I think we need to have this state transition described-- how it
is implemented is optional.  So I would delete the last sentence
in 19.

(by the way, there is no discussion in the text of what happens
when moving from ESTABLISHED to UNASSOCIATED, or what triggers
such a transition)

>=20
> Are there anything else with this issue (#23), or could we
> close it?
>=20

Issue #12 seems to cover the birthday check being badly defined,
so otherwise we could probably close #23.  Birthday check still
needs more definition, IMO.

Perhaps update issue #12 with the following from Pekka (embedded
in issue #33):
> Finally, due to the desire to make it possible for Alice
> to make a difference between a replayed and fresh R1s,
> I think that we need to retain the birthday parameter
> even if we remove resynchronization out of the base spec,
> and even make it stronger.  Basically, it seems to me best
> to increment birthday count whenever old R1s are not
> accepted any more.  This is apparently a change to the
> current draft, and therefore probably requires opening
> a new issue.  [Petri, please.]

Tom

---

From: [email-masked] (Pekka Nikander)
Date: Tue Apr 20 06:29:00 2004

> implementations not implementing step 19 get stuck in state R2-SENT?

Yes.  In practice, that would mean that such implementation
makes no difference between ESTABLISHED and R2-SENT in the
case it is a Responder.  Is that a problem?  [I don't know,
I am just trying to play open options.  But see below.]

> is implemented is optional.  So I would delete the last sentence

I would be happy with that.  I think R2-SENT is a useful state,
but there was some debate earlier on.  I am personally
in favour of deleting the last sentence, and thereby clearly
making R2-SENT and ESTABLISHED different states.

Perhaps just making it clearer that the whole state machine is
just a concept, and implementations are free to implement it
differently as long as the external behaviour is close enough?

> when moving from ESTABLISHED to UNASSOCIATED, or what triggers

I guess a new section is in place.  Maybe just after processing R2,
before starting to speak about rekeying?

   8.9.  Dropping HIP associations

     A HIP implementation is free to drop a HIP association at
     any time, based on its own policy.  If a HIP host decides
     to drop an HIP association, it deletes the IPsec SAs related
     to that association and the corresponding HIP state, including
     the keying material.  The implementation MUST also drop the
     birthday value, unless a local policy explicitly defines that
     the birthday value of that particular host is stored.  An
     implementation MUST NOT store birthday values by default, but
     storing birthday values, if done, MUST be configured by explicit
     HITs.

Ok?

> needs more definition, IMO.

Yes, but isn't that covered well enough in issue #12?  At least

>> a new issue.  [Petri, please.]

--Pekka