Subject: Re: [MOBILE-IP] micromobility in IPv6 ?

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 11 Jul 2000 15:13:59 -0700

Hello folks,

I am preparing a new revision for RFC2002bis, incorporating all
of the comments over the past months.

Recently, RFC 2794 has been promoted to Proposed Standard.
This specification makes it legal for a Mobile IP registration
message to be accepted by the Home Agent without containing
a Mobile-Home authentication extension.  Therefore, I propose
to change the relevant portions of RFC2002bis to allow for this
possibility.

I hope this is O.K.  It is a lot of work!  I expect that I will
make it more easily digestible by defining a new piece of
terminology called something like "Admissible Authentication Extension",
where admissible means admissible to the home agent.  This might
otherwise be ambiguous, except that in RFC2002bis there is only
one context where it matters.

Comments?   Sorry for the short notice, but like everybody else
I put this task off a little too long for extended debate.

Regards,
Charlie P.

---

From: Steven Glass - Solaris Software <[email-masked]>
Date: Tue, 11 Jul 2000 18:38:59 -0400

> of the comments over the past months.

    How about the comments on the "V" bit?  Yes, late for anything resembling
extended debate...

> where admissible means admissible to the home agent.
                                           ^^^^^^^^^^
    More like the "home authentication agent", which is similar to 'home
agent' only it may not be the home agent doing the authenticating?

                              Cheers,
                                  Steve

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 11 Jul 2000 16:11:05 -0700

Hello Steve,

I'll take the `V' bit out unless somebody complains.  I never
implemented it either.

> > where admissible means admissible to the home agent.

Well, all that is needed is that whatever authentication is performed
has to be _acceptable_ to the home agent.  So, I sort-of like the
"admissible" terminology better for that reason, but I'm still open
to suggestion...

Regards,
Charlie P.

---

From: Steven Glass - Solaris Software <[email-masked]>
Date: Wed, 12 Jul 2000 14:43:01 -0400

> I'll take the `V' bit out unless somebody complains.  I never

    I don't think it's even implementable, but as I've never tried, how would
I know!  Personally, my take is if the bit can be shown to have been
unimplimentable, we can label it reserved for now, and reuse it later, though
I don't know how the general internet community feels about this.  Another
argument is as 2002-bis is going to obsolete 2002, only people with current
Mobile IP implementations [of the V-bit] can object (and SHOULD object!);
anyone implementing in the future should be implementing to 2002-bis as RFC,
so if there are no objections now...  (nice theory, but does it work?)

> "admissible" terminology better for that reason, but I'm still open

    We're comming towards the same point from different sides, so lets just
get a little closer.  "Admissible Mobile-Home Authentication Extension" where
admissible means authenticated in a way acceptable to the home agent.  This
means we can also use the term "Admissible Mobile-Foreign Authentication
Extension" where admissible means authenticated in a way acceptable to the
foreign agent (FA passes M-F authentication extension to its AAA server, etc),
and "Admissible Foreign-Home Authentication Extension", etc...

                              Cheers,
                                  Steve

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 12 Jul 2000 13:22:16 -0700

Hello Mr. Solaris Software,

As I understand it, you would like to have a proper (and general)
definition for "admissible authentication extension", even though
RFC 2002bis does not need the extra generality.

Here is what I've come up with, in the Terminology section:

==============================================================================
      Admissible Authentication extension
               An authentication which makes a (registration) message
               acceptable to the ultimate recipient of the registration
               message.  In this document, all uses of admissible
               authentication extension refer to authentication
               extensions that enable the Registration Request message
               to be acceptable to the home agent.  Using additional
               protocol structures specified outside of this document,
               it may be possible for the mobile node to provide
               authentication of its registration to the home agent, by
               way of another authenticating entity within the network
               that is acceptable to the home agent (for example, see
               RFC 2794 [5]).  An admissible authentication extension
               MUST contain an SPI.

==============================================================================

Plus, I made the clarification later in the text that an admissible
authentication extension to the Registration Request _MUST_ be
the _first_ authentication extension.

Hope this works!

Regards,
Charlie P.

PS. Just kidding about the appellation... :-)

---

From: Steven Glass - Solaris Software <[email-masked]>
Date: Wed, 12 Jul 2000 16:38:55 -0400

> Hello Mr. Solaris Software,

    Hi, Mr. Nokia!

> RFC 2002bis does not need the extra generality.

    I just think if you're going to replace "allowable to the home link" with
"allowable to the home domain" (in spirit), and add a term, it should be
defined.

> Here is what I've come up with, in the Terminology section:

    What about the other types of "admissible authentication extensions" such
as MN-Foreign, and F-H?  I'm not saying we need to define these in 2002-bis,
but we shouldn't preclude these by not calling this the "Admissible
Mobile-Home Authentication extension".  There are extensions the MN sends the
FA which may be authenticated (e.g. RFC2344, Vendor-specific, etc), which in
the analogous authentication mechanisms on the foreign subnet may involve
authenticators for the foreign AAA servers, and not specifically (only) the
FA.  (Actually, I think this is the crux of our entire discussion).

    I agree that *any* admissible authentication extension MUST contain an SPI.

> the _first_ authentication extension.

    Again, this is because this definition of admissible authentication
extension excludes everything except MN-HomeDomain.  You can say, however,
that an admissible mobile-home authentication extension MUST be the first
authentication extension.

                              Cheers,
                                  Steve

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 12 Jul 2000 14:11:41 -0700

Hello again Steve,

Thanks for your comments to help illuminate what is needed here.

> "allowable to the home domain" (in spirit), and add a term, it should be

I think it's important for RFC2002 to require allowable to the _home agent_.
Anything else would push the specification too far past the limit of what
would be considered refinement to a Proposed Standard.  I don't want to
take that step just yet.

> as MN-Foreign, and F-H?

These are not prohibited by the suggested definition.  In fact the
definition was written exactly to make them allowable.

Would it be better to make two paragraphs in the definition, so that
the second paragraph could be construed to be specific only to the
uses within RFC2002bis?

>              I'm not saying we need to define these in 2002-bis,
> Mobile-Home Authentication extension".

Isn't the existing definition good enough, if everywhere in context it
is clear that the admissibility is from the point of view of the home agent?

>                                       There are extensions the MN sends the

I agree with you, but I am not getting why it matters for the purposes
of defining an admissible authentication extension.

> authentication extension.

Doesn't the original statement work if instead you understand it
to mean something about the way the mobile node sends an authentication
admissible from the point of view of the home agent?

Regards,
Charlie P.

---

From: Steven Glass - Solaris Software <[email-masked]>
Date: Wed, 12 Jul 2000 19:08:11 -0400

Charlie,

    I'm working on my own draft right now, and as I refered to a section on
the colocated MN, I realized another good example for Appendix D "Example
Scenarios" would be the apparently always confusing situation of a colocated
mobile node registering with a FA because it set the 'R' bit.  (As if you
don't have enough editing to do already!)

                              Cheers,
                                  Steve

---

From: Steven Glass - Solaris Software <[email-masked]>
Date: Thu, 13 Jul 2000 16:46:35 -0400

> >    What about the other types of "admissible authentication extensions"
> > such as MN-Foreign, and F-H?
>

    Well, I don't want this to start ballooning into it's own section (!).
Actually, now that I'm seeing the document with this definition in context,
this helps.  The first paragraph of the definition in section 1.6 meets my
generic requirements, and the second then says that 2002-bis only uses the
term in the context of the "generic" mobile-to-home authenticator as being
acceptable to the home agent.  This is fine, except I don't think 2002-bis
needs to confine itself only to the MN-HA bit.  2002[-bis] talks about
MN-to-FA, FA-to-MN, and HA-to-FA which are all Admissible Authentication
extensions (by the definition; please don't change it).  In the AAA model,
there may be a MN which includes a Mobile-to-Foriegn Admissible Authentication
extension, which the FA relays to its AAA server, then gets an "alls-well"
back.  I see your point - 2002-bis shouldn't go there, and I agree, but I
don't think 2002-bis needs to limit the discussion of "Admissible
Authentication extensions" to only what's acceptable to the HA.

    Let me comment on specific sections to see if we can make our minds meet...

>>2002-bis
>
>  3.5.2. Mobile-Home Authentication Extension
>
>   Exactly one admissible authentication extension MUST be present in
>   all Registration Requests, and also in all Registration Replies
>   generated by the Home Agent.

    Do you mean *at least* one?  "Exactly one" is required here because your
earlier (section 1.6) "disclaimer" says the document doesn't (therefore can't)
refer to AAE's in any other context except what's acceptable to the HA.  What
about MN->FA in the request, and HA->FA in the reply?  These are also
"admissible authentication extensions" by the definition in section 1.6.

>>2002-bis
>
>  3.6.1.3. Extensions
>
>  This section describes the ordering of any mandatory and any optional
>  Extensions that a mobile node appends to a Registration Request.
>  This following ordering MUST be followed:
>
>     a)   The IP header, followed by the UD header, followed by the
>          fixed-length portion of the Registration Request, followed by
>
>     b)   If present, any non-authentication Extensions expected to be
>          used by the home agent (which may or may not also be useful
>          to the foreign agent), followed by
>
>     c)   An admissible authentication extension, followed by
>
>     d)   If present, any non-authentication Extensions used only by
>          the foreign agent, followed by
>
>     e)   The Mobile-Foreign Authentication Extension, if present.

    Again, e) is a "admissible authentication extension" as defined by 1.6.
If you change c) to read "An admissible mobile-home authentication extension",
and e) to read "An admissible mobile-foreign authentication extention" then
maybe my point is a little clearer.

    I also really like the way this is put in sectino 3.7.2.2:

>>2002-bis:
>
>  3.7.2.2. Forwarding a Valid Request to the Home Agent
...
>  The foreign agent MUST NOT modify any of the fields beginning with the
>  fixed portion of the Registration Request up through and including the
>  Mobile-Home Authentication Extension or other authentication extension
>  supplied by the mobile node as an admissible authentication extension
>  for the home agent. ...

    Similarly, in section 3.8.2.1 section a) says something similar, but then
it says "...if no admissible authentication extension is found, or if more
than one admissible authentication extension is found, ..." which by the
definition in section 1.6 is incorrect.  "If no admissible mobile-home
authentication extension is found, or if more than one admissible mobile-home
authentication extension is found, ..." is accurate to the definition in
section 1.6.  If the FA attaches a FA-HA authenticator, then more than one
admissible authentication extension may be found.

    I've tried to locate them all for you in case you want to update them as
there isn't a lot of time left.  I really feel the solution is to leave the
definition generic, then specify which admissible authentication extension you
mean in context.  This wont change the specification more than what would be
considered refinement to a Proposed Standard.

    Also, two off-topic comments I came across when searching out all
"admissible" references:

>>2002-bis:
>
>   3.2. Authentication
>
>   Each mobile node, foreign agent, and home agent MUST be able to
>   support a mobility security association for mobile entities, indexed
>   by their SPI and IP address.

   Each mobile node doesn't have to support a mobility security association
for mobile entities (unless you mean for itself).  Also, HAs MUST be able to
do this, FA's MAY (SHOULD?) be able to do this, and both FAs and HAs SHOULD
(MUST?) be able to support mobility security associations for mobile entities
indexed by SPI and NAI.  It's probably best to break this section into two
paragraphs, one for mobile nodes, the other for mobility agents.

     Section 3.6.2.1, paragraph "a)" the mobile node only checks for the
presence of a mobile-foreign authenticator if the code indicates the
registration was denied by the FA, and the MN and FA share a security
association (that is, start 'a)' by saying "If the Code field indicates the
service is denied by the foreign agent...").

                              Cheers,
                                  Steve