Subject: Re: [MOBILE-IP] MIER V01

From: Patrice Calhoun <[email-masked]>
Date: Tue, 14 Dec 1999 07:21:32 -0800

>
>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!

No problem. been there :)

>
>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.
This is where I get heartburns. I would hope that extensions of a specific
type get grouped under a sub-type. It really doesn't seem to make sense to
group "extensions" that have widely different meaning, and processing,
under a sub-type.

>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?
>
so to recap, I would prefer zero. If an extension has some special processing
conditions, leave it alone. Don't group it with other extensions just because
it's convenient. If we start doing this, with the number of extensions that
can be grouped in a subtype, we may find ourselves running out of flags bits
quite. Further, it really makes generic encoding/decoding routines really
ugly (and I care about bad coding practices :(.

PatC