Subject: Re: [MOBILE-IP] MIER V01

From: "N. Asokan" <[email-masked]>
Date: Mon, 13 Dec 1999 15:58:31 +0200

PatC wrote:
| > [... example showing use of subtypes ...]
|
| This, IMHO, is not great protocol design. It sounds like
| a recipe for
| disaster.

I think the ability to subtype protocol messages is a good idea for the
same reason why subtyping is good in programming: it allows related
messages to be grouped together in a hierarchical way.  This could be
useful if two different entities react to the same message. For example,
in a particular message type, the FA may look only at the supertype while
the HA looks also at the subtypes.  That way, a new subtype can be added
without having to change the FA.

In addition, MIER specifies a clean and simple way to extend
the type space.  Even if we are not running out of numbers
right now, it doesn't hurt to be systematic in assigning future
type numbers.

| If something is encrypted, then let's find a
| real way to encrypt,
| and not rely on some bit-field in the MIER header. The
| problem here is
| how would one encrypt a non-MIER extension? I, for one,
| don't want two
| encryption routines, one for MIER and one for non-MIER
| extensions.
[....]

I would suggest a different example: suppose "flag=0" implies that
"an SPI follows".  I think this is the way to support optionally
encrypted or otherwise security-enhanced NAIs etc.

Additional comments on the new MIER-01 draft (from a mail I sent to
Mohamed et al earlier today):
> - if you use two bytes for the length field, all MIER extensions have
>   to be unskippable (for backward compatibility).  This wouldn't be
>   a good idea, esp. if it is mandated that all new extensions have
>   to be in MIER style.
>
>   I'd suggest that you propose two types of MIER extensions: regular
>   and "unskippable jumbo" extensions.  Regular extensions use only
>   1 byte length field and can be either skippable or unskippable.
>   "Unskippable jumbo" extensions have 2 byte length fields and
>   must be unskippable.
>
> - For the generic NAI extension, you probably want to have an
>   optional SPI.  I'd recommend using one of the rsv bits to indicate
>   "SPI follows".

Regards,
- Asokan

---
N. Asokan, Communication Systems Lab, Nokia Research Center, Helsinki

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 13 Dec 1999 06:26:52 -0800

> right now, it doesn't hurt to be systematic in assigning future

hmmm... just to be clear, I like subtyping (and the draft), I don't like
unused flag bits in the subtype field.  To re-state  my previous comment, if
someone *can* come up with a good reason for the flag bits, then I will back
off, but so far the arguments for the bits have been weak.

Also, I think my statement that you referred to may have been a tad too
strong. I did not mean to imply that the authors did not have good protocol
design skills.

> encrypted or otherwise security-enhanced NAIs etc.

Why does the sub-type have *anything* to do with encryption?!? Why not have a
separate draft that defines how extensions can be encrypted? This wouldn't tie
the encryption code to sub-type ONLY extensions, and make the protocol must
cleaner.

Again, to re-state another previous comment. This is an opportunity to publish
something very simple, and elegant. In fact, the appendixes may actually also
not be necessary, if the various drafts that they relate to were updated. This
would make a very short, non-controversial draft.

PatC

---

From: "N. Asokan" <[email-masked]>
Date: Tue, 14 Dec 1999 09:05:33 +0200

Hi Pat,

Sorry for misinterpreting that you were objecting to the notion of
subtypes. I must have been flipping through accumulated nobile-ip messages
a little too fast!

On Mon, 13 Dec 1999, EXT [email-masked] wrote:
[...]
| >
| > | If something is encrypted, then let's find a
| > | real way to encrypt,
| > | and not rely on some bit-field in the MIER header. The
| > | problem here is
| > | how would one encrypt a non-MIER extension? I, for one,
| > | don't want two
| > | encryption routines, one for MIER and one for non-MIER
| > | extensions.
| > [....]
| >
| > I would suggest a different example: suppose "flag=0" implies that
| > "an SPI follows".  I think this is the way to support optionally
| > encrypted or otherwise security-enhanced NAIs etc.
|
| Why does the sub-type have *anything* to do with encryption?!? Why not have a
| separate draft that defines how extensions can be encrypted? This wouldn't tie
| the encryption code to sub-type ONLY extensions, and make the protocol must
| cleaner.

Here is how I understand this:
1. In some cases, extension-specific processing is necessary.
2. MIER is the draft that is supposed to tell how to rationalize
   MIP extensions; so it seems natural that any solution to 1 belongs
   here.
3. If MIER is accepted by the WG, then _all_ future extensions will be
   defined according to the MIER style.  So all new extensions, regardless
   of whether they have subtypes or not, will be able to use any flags
   defined by MIER.

Having said that, the only example of item 1 above I know so far is the
optional inclusion of an SPI in the case of the Generic NAI extension.
(This is to support the possibility of doing some security enhancement on
the NAI -- including, but not limited to, "encryption").

Whether to solve item 1 by using flag bits is probably debatable.  One
could also use the original MIP approach: extend the ST field to 8-bits,
and subdivide the ST field only in the case of specific extensions that
require extension-specific processing (e.g., Generic NAI extensiosn
subtypes 129->255 could imply that an SPI follows).  I guess which choice
to make depends on how many examples of extension-specific processing we
can think of?

Regards,
- Asokan

---
N. Asokan, Communication Systems Lab, Nokia Research Center, Helsinki
E-mail: [email-masked],  [email-masked] (private)
Phone:  +358 40 743 1961; PGP Key for private use at http://www.acm.org/~asokan

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 14 Dec 1999 08:33:48 -0800

Hello Asokan,

> 1. In some cases, extension-specific processing is necessary.

Isn't this generically true for non-skippable extensions?

>    MIP extensions; so it seems natural that any solution to 1 belongs

The test of naturalness will be in how many extensions are handled
well by MIER.  But no matter how good MIER is, I can't believe that
it would be appropriate for ALL future extensions.

Instead, and maybe I missed something here, I thought that MIER
was supposed to be for collecting together similar extensions
under a type/subtype plan.

>    of whether they have subtypes or not, will be able to use any flags

Accodring to my above idea, I am not in agreement with this statement.
Maybe the authors could clarify their intention.  This should also be
understood before the draft is taken as a working group item.

> the NAI -- including, but not limited to, "encryption").

Until the flag handling is understood better, I'd be more in favor
of just defining a new subtype for encryption variations, and leaving
the entire 8 bits for the subtype range.  Or, alternatively, we could
have the following:
1. Type A, no flag bits, 256 subtypes
2. Type B, 1 flag bit, 128 subtypes
3. Type C, 2 flag bits, 64 subtypes
4. Type D, 3 flag bits, 32 subtypes

That ought to do it.  Four (4) types.  Not bad.

Regards,
Charlie P.