Subject: [Hipsec] responding to unknown SPIs

From: [email-masked] (Henderson, Thomas R)
Date: Tue Apr 13 11:20:01 2004

> -----Original Message-----
> From: Petri Jokela [mailto:[email-masked]]=20
> Sent: Tuesday, April 13, 2004 4:38 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: Re: [Hipsec] responding to unknown SPIs
>=20
>=20
> Now, the new COOKIE=20
> (issue 33) would contain the birthday in any case, so this=20
> issue is now=20
> related to this issue 33 and not yet closed.
>=20
I recall that there was originally discussion about separating
the birthday and cookie parameters.  However, it seems that now,
in either case that birthday is needed (resync or R1 replay
avoidance), it is needed in R1, so it seems reasonable to=20
bind these (separate birthday TLV could be created if needed
in the future).  So I am fine with the new cookie format=20
(issue 33).

one small typo-- in 6.2.4, K is not a 64-bit integer

also, I suggest defining in COOKIE_REQUEST

Opaque   optional field, set by responder and padded to 32-bit
         boundary

and in COOKIE_RESPONSE

Opaque   echoed to responder if Opaque field was included in
         the R1 COOKIE_REQUEST

(since I don't think we need to explicitly show a padding field
if we force Opaque to be 32-bit aligned).

Finally, it is not clear in the proposed text in issue 33, but
Opaque and I are both left out of the signature.

---

From: [email-masked] (Petri Jokela)
Date: Wed Apr 14 05:26:03 2004

> if we force Opaque to be 32-bit aligned).

In REQUEST, this would go nicely. The RESPONSE requires 4-byte padding 
to meet the 8-byte alignment requirement when the Opaque field is copied 
from the REQUEST. It might be better in that case to define a 4-byte 
reserved field in the RESPONSE, instead of adding 4-byte padding each time:

COOKIE_RESPONSE:

  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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          reserved                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...

> Opaque and I are both left out of the signature.

There will be text modifications in sections 7 and 8 that will cover 
also these.

/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]

---

From: [email-masked] (Pekka Nikander)
Date: Thu Apr 15 03:38:03 2004

Petri and others,

The ability to send opaque data and get it back seems to be
useful for more than one purposes.  So far we have at least
two distinct purposes:

   - For cookies, to include some state in R1 so that it
     gets echoed back in I2

   - For RSV, to include some state in I1 so that it gets
     echoed back in R1.

Hence, I would suggest making this opaque data echo back
service a separate parameter, and put it after the SIG.

For the TLV table:

       ECHO_REQUEST     65281 variable   Opaque data to be echoed back
       ECHO_RESPONSE    65283 variable   Opaque data echoed back

For the actual text:

    The ECHO_REQUEST parameter contains an opaque blob of data that
    the sender wants to get echoed back in the corresponding reply 
packet.
    The ECHO_RESPONSE parameter contains the echoed back data.

    The ECHO_REQUEST and ECHO_RESPONSE parameters MAY be used for any
    purpose where a node wants to carry some state in a request packet
    and get it back in a response packet.  Note that ECHO_REQUEST and
    ECHO_RESPONSE parameters are not covered by the HMAC or SIGNATURE.

    It is currently defined how to use the ECHO parameters for extended
    COOKIES, see Section XXX.

        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            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Opaque data (variable length)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type         65281 or 65283
       Length       variable
       Opaque data  Opaque data, supposed to be meaningful only to the
                    node that sends ECHO_REQUEST and receives a 
corresponding
                    ECHO_RESPONSE.

--Pekka

---

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

>       ECHO_RESPONSE    65283 variable   Opaque data echoed back

Silly for me to reply to myself, but apparently it would make more
sense to have the ECHO_REQUEST always after the signature, but allow
the ECHO_RESPONSE to be included also before the signature.  Hence, we
would have something like:

       ECHO_RESPONSE     1024 variable   Opaque data echoed back; under 
signature
       ECHO_REQUEST     65281 variable   Opaque data to be echoed back
       ECHO_RESPONSE    65283 variable   Opaque data echoed back; after 
signature

More specifically, for the I2 processing it might be better to have
the ECHO_RESPONSE signed by the Initiator.  (That doesn't help early
in the process since the Responder can't check the Initiator's signature
but much later, but it gives some more assurance once everything has
been completed.  Hence, even though the I2 ECHO_RESPONSE would be
protected by the Initiator's signature, it should still be protected
by the Responder using a symmetric key.)

Maybe we should allow the same for ECHO_REQUEST, too, just for the
sake of symmetry?

--Pekka

---

From: [email-masked] (Andrew McGregor)
Date: Thu Apr 15 16:36:01 2004

I was tasked with figuring out how to do RTT estimation in AC/ACR... this 
seems to me to be part of the solution, but it can clearly be used for lots 
of other purposes.  Great idea,

Andrew

--On Thursday, 15 April 2004 11:28 a.m. +0300 Pekka Nikander 
<[email-masked]> wrote:

>     the sender wants to get echoed back in the corresponding reply packet.
> corresponding                     ECHO_RESPONSE.
>
> --Pekka
>
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec
>
>

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