Subject: [Hipsec] Preliminary version of draft-moskowitz-hip-09

From: [email-masked] (Henderson, Thomas R)
Date: Mon Feb 2 10:26:01 2004

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]]=20
> Sent: Monday, February 02, 2004 7:49 AM
> To: Henderson, Thomas R; Petri Jokela; [email-masked]
> Subject: Re: [Hipsec] Preliminary version of draft-moskowitz-hip-09
>=20
>=20
> If we move the RESYNC mechanism in another draft, IMHO the birthday=20
> count should be 1) optionnal and 2) defined in the new draft.

I agree that these parameters (birthday, cookie) do not need to=20
be coupled.  I support such a change.

=20
> > - I must have missed this in previous drafts, but why do we need
> > to have different parameter type codes for BIRTHDAY_COOKIE?
>=20
> My understanding is that R1s carry a cookie request, while=20
> I2s carry a=20
> cookie response, hence the different parameter type.
>=20

I was assuming that request/response is inferred by R1 or I2.
I don't really care either way that much, but if we keep separate
parameter types, I suggest naming them differently (e.g.,=20
"COOKIE_REQUEST" and "COOKIE_RESPONSE"), or "COOKIE" if one=20
parameter type is used.

Tom

---

From: [email-masked] (Petri Jokela)
Date: Tue Feb 3 03:01:01 2004

This mail includes now two separate issues:

1) Remove the Birthday from the BIRTHDAY_COOKIE and divide COOKIE
    into two different parameters. The Birthday will be completely
    moved into the new draft discussing about the resync.

    These changes are realistic in draft version -10 where the resync
    handling is removed.

2) HOST_ID_FQDN: Remove the current HOST_ID and rename the HOST_ID_FQDN
    as HOST_ID. The FQDN Length field tells if there is a FQDN or not (
    length = 0 if not).

    This change could be done already in the draft version -09. I suppose
    that the reason for separating these two was originally the parameter
    structure that caused packet handling problems in the end-hosts. With
    the current HOST_ID_FQDN structure there should not be that kind of
    problems.

New parameters follow. Opinions?

/petri

1) BIRTHDAY_COOKIE
==================

6.2.4 COOKIE_REQUEST

        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                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Random # I, 8 bytes                                           |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | K, 8 bytes                                                    |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type           3
       Length         28
       Reserved       Zero when sent, ignored when received
       Random # I     random number
       K              K is the number of verified bits

    Random #I and K are represented as 64-bit integers, in network byte
    order.

6.2.5 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                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Random # I, 8 bytes                                           |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Random # J, 8 bytes                                           |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type           5
       Length         28
       Reserved       Zero when sent, ignored when received
       Random # I     random number
       Random # J     random number

    Random #I and Random #J are represented as 64-bit integers, in
    network byte order.

2) HOST_ID
==========

6.2.9 HOST_ID

        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            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          HI Length            |          FQDN Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Host Identity                         /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       /                               |             FQDN              /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       /                                               |    Padding    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type           35
       Length         length in octets, excluding Type, Length, and
                      padding
       HI length      length of the Host Identity
       FQDN length    length of the FQDN
       Host Identity  actual host identity
       FQDN           Fully Qualified Domain Name, in the binary format.

    The Host Identity is represented in RFC2535 [9] format.  The
    algorithms used in RDATA format are the following:

          Algorithms       Values

          RESERVED         0
          DSA              3 [RFC2536] (REQUIRED)
          RSA              5 [RFC3110] (OPTIONAL)

    The format for the FQDN is defined in RFC1035 [2] Section 3.1.
    If there is no FQDN, the FQDN Length field is set to zero.

-- 
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: Tue Feb 3 05:02:00 2004

Petri,

>    These changes are realistic in draft version -10 where the resync

This sounds good.

>    as HOST_ID. The FQDN Length field tells if there is a FQDN or not (

Ok for me.

> 6.2.4 COOKIE_REQUEST

How about removing reserved and making K only 4 bytes and before #I?
Would save a few bytes.  R1 and I2 are so different from each other
anyway that having the same structure doesn't really matter any more.

--Pekka

---

From: [email-masked] (Pekka Nikander)
Date: Thu Feb 12 09:19:01 2004

On Feb 2, 2004, at 18:04, Henderson, Thomas R wrote:
>> My understanding is that R1s carry a cookie request, while
>> I2s carry a
> parameter types, I suggest naming them differently (e.g.,
> "COOKIE_REQUEST" and "COOKIE_RESPONSE"), or "COOKIE" if one
> parameter type is used.

I agree with Tom, especially now that the cookies will
be separated from the birthday value.

--Pekka