Subject: [Hipsec] Issue 5: Rules for extensions

From: [email-masked] (Pekka Nikander)
Date: Fri Sep 26 08:17:01 2003

Background
----------

The variable length parameters in HIP packets are encoded
in the TLV format, which consists of a 16 bit Type field,
16 bit Length field, and a variable length value.  All the
parameters must have a length that is a multiple of 8, but
the Length field does NOT include the padding.  Hence,
a Parameter whose length is 14 bytes actually takes 16
bytes in the packet.  It has also been specified that the
parameters must be ordered by the Type field.

The following parameter Types are currently defined:

    SPI_LSI                1      0x0001
    BIRTHDAY_COOKIE        2/3    0x0002/3
    NES_INFO               4      0x0004
    DIFFIE_HELLMAN         6      0x0006
    HIP_TRANSFORM         16      0x0010
    ESP_TRANSFORM         18      0x0012
    ENCRYPTED             20      0x0014
    HOST_ID               32      0x0020
    HOST_ID_FQDN          33      0x0021
    CERT                  64      0x0040

    HMAC               49152      0xC000
    HIP_SIGNATURE2     65533      0xFFFD
    HIP_SIGNATURE      65534      0xFFFE

The reason for the sparse spacing is to allow later
addition of other types in between.  The reason for
the large type values for HMAC and signatures is so
that they will be located in the end of the packet.
Otherwise the exact values have not that much meaning,
and have their current value largely either due to
historical reasons or by the whim of the author.

Problem
-------

An extension mechanism should allow new parameter
types.  There must be at least two classes of new
parameters:

   - parameters that will be ignored by a recipient
     that does not understand them

   - parameters that will cause the recipient to drop
     the packet if it does not understand them

Furthermore, it would be nice if new parameters could
be defined in such a way that they could be located
in a "natural" order in the packets.  With that I mean
that the processing of packets would be as easy as
possible, without unnecessary complications.

Proposal
--------

Let's devide the possible Type values into regions,
with some regions requiring recognition while others
allowing the parameter to be ignored.  Futhermore,
let's assign the regions so that they are trivial
to recognize.

There are various ways how we could achieve that.

   1) Renumber the current type codes so that they are
      all even values.  That would allow one to
      use any odd values as optional parameters,
      making even values ones that must be recognized.

      This requires that we renumber SPI_LSI (to 0),
      BIRTHDAY (to 2/4), preferably NES_INFO (to make
      room for BIRTHDAY response as 4), HOST_ID_FQDN (to 34),
      and HIP_SIGNATURE2 (to 0xFFFC).  A new value for
      NES_INFO could be 48.

   2) Define regions at the small type codes (e.g. 0-256)
      and large type codes (e.g 2^16-256 - 2^16-1) where
      all type codes must be recognized.  Renumber HMAC
      to the upper range.

      Divide the are in the middle somehow (how?) to a
      number of alternating regions.

   3) Some other way (I am too tired to figure out any)

I would prefer 1), but it would require an incompatible
change to the protocol.  Can we still do that?  Does anyone
have any troubles if we do it?

Opinions?

--Pekka Nikander

---

From: [email-masked] (Julien Laganier)
Date: Fri Sep 26 09:20:01 2003

Hi Pekka, 

Please find some thoughts below.

On Thursday 25 September 2003 20:06, Pekka Nikander wrote:

<\snip>

>    3) Some other way (I am too tired to figure out any)

One solution might be to define some Type prefixes for extensions, that make 
regognition easier, for example:

o 0x8 for standardized  extensions that can be ignored
o 0x9 for private extensions that can be ignored
o 0xa for standardized  extensions that cannot be ignored
o 0xb for private extensions that cannot be ignored

That allows space for 2^12 = 4096 different subtypes under each prefixes while 
not requiring renumbering of existing Types. I guess that would be sufficient 
for quite a long time.

> have any troubles if we do it?

I have no troube with doing any of the above, so let's others people speak.

Thanks,

--julien

---

From: [email-masked] (Jari Arkko)
Date: Sat Sep 27 13:34:01 2003

> have any troubles if we do it?

I would be in favor of approach #1.

--Jari

---

From: [email-masked] (Miika Komu)
Date: Sat Sep 27 16:20:02 2003

> have any troubles if we do it?

Option 1 sounds better and simpler.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

---

From: [email-masked] (George Gross)
Date: Sat Sep 27 16:55:01 2003

Hi,

	I noticed that on the original post on this topic, the encoding
scheme allowed the combination "mandatory" and "private". In other IETF
protocols I've observed, this wasn't allowed. One could potentially
stumble across inter-op problems that might occur when Vendor X marks a
TLV mandatory and its implementation is proprietary.

br,
	George

---

From: [email-masked] (Pekka Nikander)
Date: Mon Sep 29 06:06:01 2003

Hi George,

> TLV mandatory and its implementation is proprietary.

Since we are dealing with a security protocol, I think that it makes
perfect sense to have a combination of "mandatory" and "private".
As you notice, it will lead to the situation where the hosts fail
to communicate, but that is most probably the desired behaviour.

The reason for marking someting "mandatory" in a cryptographic protocol
is that the option requires some positive action from the peer,
or otherwise the protocol will not be secure.

Maybe we should include some normative text making clear the
conditions under which it is acceptable to define a "mandatory private"
HIP parameter?  And make those conditions fairly strict?

Yet another issue:  Maybe we should define an "Error" parameter,
something similar to ICMP errors but carried if there *is* some
existing keying material?  (HIP uses currently ICMP if there is
no keying material and no security assocation.  This has its
dangers, most of which are (hopefully) documented.)

--Pekka Nikander

---

From: [email-masked] (Pekka Nikander)
Date: Mon Sep 29 06:34:01 2003

> not requiring renumbering of existing Types. I guess that would be sufficient 

I thought about that, but from my point of view it has two drawbacks:
Firstly, the code would be somewhat more complex.  But that is a minor
one.  A more serious one is that we require that the parameters
are ordered in a strictly increasing order by their type values.
Hence, allocating regions would make it hard to "insert" parameters
between existing ones.  I don't know how often such a feature would
be needed, but perhaps sometimes.

> I have no troube with doing any of the above, so let's others people speak.

I'd like to get word from the people actually doing implementations.

Right now it looks like that -08 will contain a number of incompatible
changes compared to -07.  Hence, it looks improbable that we could
reach full interoperability between -07 and -08 implementations.
Hence, I don't know if changing the parameter type code values would
be that bad at this stage.  On the other hand, the base protocol does
not change that much, so without this change -07 and -08 implementations
might still be able to interoperate to an extend, at least when IPv6
is used.

Right now my proposal is the following:

   1. Use the low order bit to distinquish between mandator-to-recognize
      and ok-to-ignore parameters.

   2. Reserve the ranges 0-511 and (2^16-512 - 2^16-1) for future
      base protocol extensions, to be assinged only through RFCs.

   3. Define a range, e.g. (2^15) - (2^15+2^14-1) for experimentation
      and private extensions.

   4. Make the rest assignable by IANA under some rules that prevent
      people from "hoarding" large amounts of type codes.

Would that sound reasonable?

--Pekka Nikander

---

From: [email-masked] (George Gross)
Date: Mon Sep 29 07:16:01 2003

Hi Pekka,

> to communicate, but that is most probably the desired behaviour.

I took a look at the IKE-v2 draft in the hope of finding a precedent, and
could only infer that setting "critical" for a proprietary payload was
allowed; there didn't seem to be an explicit guidance. Perhaps the IPSEC
archive has a thread on this topic but I didn't look....

In Diameter, there is the ability to negotiate mutually supported
Vendor-specific AVP lexicons on a per session basis. Vendor IDs are
assigned by an IANA SMI. The negotiation requires mutual configuration at
the respective session endpoint management interfaces, and falls back to
standard AVP only mode.

In RFC2661 section 4.2 (for L2TP) it says:

" Use of the M-bit with new AVPs (those not defined in this document)
   MUST provide the ability to configure the associated feature off,
   such that the AVP is either not sent, or sent with the M-bit not set.

So bottom line is that setting any mandatory bit should be configurable
on/off at the management interface for vendor-specific uses. In other
words, the management interface MUST allow vanilla standards only mode as
a default configuration setting, and MAY allow vendor-specific critical
payloads to be configured on (and off).

> or otherwise the protocol will not be secure.

As per above, MPOV this is a security policy decision that must be
configurable at the management interface.

> HIP parameter?  And make those conditions fairly strict?

yes, normative text should say this, in addition to what I mentioned
earlier about the management interface.

> existing keying material?

sounds alot like an IKE notify payload. Perhaps borrow from that arena?

br,
	George

>  (HIP uses currently ICMP if there is

---

From: [email-masked] (Pekka Nikander)
Date: Tue Sep 30 03:11:01 2003

George and Juline,

I wrote the following text to the draft.  Ok?

6.2.1 TLV format

   [snip]

        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            |C|             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       /                          Contents                             /
       /                                               +-+-+-+-+-+-+-+-+
       |                                               |    Padding    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type         Type code for the parameter
         C          Critical.  Zero if this parameter is critical, and
                    MUST be recognized by the recipient, one otherwise.
                    The C bit is considered to be a part of the
                    Type field.
                    Consequently, critical parameters are always even
                    and non-critical have an odd value.
       Length       Length of the parameter, in bytes.
       Contents     Parameter specific, defined by Type
       Padding      Padding, 0-7 bytes, added if needed

    Critical parameters MUST be recognized by the recipient. If a
    recipient encounters a critical parameter that it does not recognize,
    it MUST NOT process the packet any further.

    Non-critical parameters MAY be safely ignored.  If a recipient
    encounters a non-critical parameter that it does not recognize, it
    SHOULD proceed as if the parameter was not present in the received
    packet.

6.2.2 Defining new parameters

    Future specifications may define new parameters as needed.  When
    defining new parameters, care must be taken to ensure that the
    parameter type values are appropriate and leave suitable space for
    other future extensions.  One must remember that the parameters MUST
    always be arranged in the increasing order by the type code, thereby
    limiting the order of parameters.

    The following rules must be followed when defining new parameters.

    1.  The low order bit C of the Type code is used to distinquish
        between critical and non-critical parameters.

    2.  A new parameter may be critical only if an old recipient ignoring
        it would cause security problems.  In general, new parameters
        SHOULD be defined as non-critical, and expect a reply from the
        recipient.

    3.  If a system implements a new critical parameter, it MUST provide
        the ability to configure the associated feature off, such that
        the critical parameter is not sent at all.  The configuration
        option must be well documented.  By default, sending of such a
        new critical parameter SHOULD be off.  In other words, the
        management interface MUST allow vanilla standards only mode as a
        default configuration setting, and MAY allow new critical
        payloads to be configured on (and off).

    4.  The following type codes are reserved for future base protocol
        extensions, and may be assigned only through an appropriate WG or
        RFC action.

            0 - 511
            65024 - 65535

    5.  The following type codes are reserved for experimentation and
        private use.  Types SHOULD be selected in a random fashion from
        this range, thereby reducing the probability of collisions.  A
        method employing genuine randomness (such as flipping a coin)
        SHOULD be used.

            32768 - 49141

    6.  All other parameter type codes MUST be registed by the IANA.  See
        Section 14.

---

From: [email-masked] (Julien Laganier)
Date: Tue Sep 30 04:14:01 2003

On Tuesday 30 September 2003 09:38, Pekka Nikander wrote:
> George and Julien,

Pekka,

The new text is fine with me.

Thanks,

--julien

--
Julien Laganier

---

From: [email-masked] (George Gross)
Date: Tue Sep 30 08:33:00 2003

Hi Pekka,

	your proposed text for TLV encoding and extensions is very good.

thank you,

	George