Subject: Re: [mobile-ip] RFC3012bis - Comments from ADs (Editorial)

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 18 Oct 2002 11:41:17 -0700

Hello folks,

I have reviewed Erik's comments, and am making revisions to the
draft based on the suggested improvements.

> Editorial:
> 1. The document doesn't say that it obsoletes RFC 3012 which I gather
>    is the intent. Putting a sentence to that effect at the end
>    of the abstract would be good.

Fixed.

> 2. The abstract talks about "ironclad replay protection" and gives
>    the impression that this update provides it. But the protocol
>    seems to be suject to bogus registration replies.
>    Perhaps the abstract should be more accurate in what the protocol
>    actually provides.

I tried to be more accurate in the description, and
took out the offending word.  Now, it says:

          ................               does not provide
   the foreign agent any direct guarantee that the protocol
   is protected from replays,

> 3. The abstract talks of "use of existing techniques" but I suspect
>    that today a lot richer authentication techniques than CHAP are
>    being used elsewhere e.g. with EAP. If I read the abstract and not
>    the rest of the spec I might very well believe that this would
>    provide extensible autentication methods for mobile ip. Thus saying
>    that "this provides CHAP" would be better.
>    Same comment on the introduction.

Fixed.

> 4. Note that the RFC editor isn't happy about the abstract and
>    introduction being identical. I'm sure the actual protocol can be
>    introduced in the introduction as one way to address this general
>    concern.

Hmmm...  O.K.  They are a lot different now.

> 5. Section 1.1:
>    All SPI values defined in this document refer to values for the
>    Security Parameter Index, as defined in the base Mobile IP protocol
>    specification [7].
>    This reads oddly and is odd in the terminology section. Isn't the
>    intent to say that this document uses the term SPI as defined in
>    [7]

Yes, that is the intention, by implication of being stated
in this section.  I'll make it more explicit, using your
wording.

> 6. Why does the document need to introduce two terms (previously used
>    challenge and stale challenge) for the same thing?

The reason is because it makes certain sentence constructions
more readable and convenient.  For instance:
                ...............        if the Foreign Agent
   receives a Registration Request with a Challenge extension containing
   a Challenge value previously used by that mobile node, ...

Using "stale" in that context makes the sentence structure
inexact.  Of course, a lot of text could be rewritten
to eliminate one term or the other, but that would be done
only as a matter of conforming to personal taste, not to
correct a problem in the specification.

>       unknown challenge
>                Any challenge that the foreign agent has no record of
>                having put either into one of its Agent Advertisements or
>                a corresponding registration reply message.
> 
>   Given that is doesn't keep track of all AAs, adding "recent" before
>   AA would make sense.

Done.

>                      The word "corresponding" makes no sense to me
>   here since AA and Rreply don't correspond as far as I
>   know. "(recent) registration replies send to the Mobile Node" make
>   sense.

The registration reply has to have the challenge value,
so that the correspondence can be exact.

> 7. Section 3.1 uses the term "security association" but that term has
>    not been defined. Is it supposed to be the same as Mobility
>    Security Association in [7]?

I put that into the terminology section.

> 8. The organization of section 3 is confusing. Section 3.1 is titled
>    "Mobile Node Processing for Registration Requests" yet it talks
>    about the MN processing registration replies. If you want to
>    preserve the temporaral ordering (message flow odering) present in
>    section 3 to put the MN processing of reg replies in a new section
>    3.5.

I made a new section and tried to comply with this request.
However, sometimes what a registration reply does affects a
following registration request, so that complete separation
isn't very handy for understanding what needs to be done.

> 9. In section 3.1 I was expecting to see something about
>    retransmission behavior for registration requests sent by the MN.
>    If it is identical to [7] it would be helpful to say that. But I
>    think it also needs to say something about the challenge values
>    used in retransmitted requests.

I put in a sentence to say it is identical.  I believe that
the challenge value can be the same, since it wasn't "used".

> 10.  chosen as CHAP_SPI (see section 9), then the mobile node
>        specifies
>      Should be section 10.

Section 10 is for error values, not constants... (?)

> 11. "the authentication performed by the AAA infrastructure.  The appendix
>    provides an example of an action that could be taken by a foreign"
>    Which appendix?

Appendix C.  A cross-reference has been added.

> 12. Section 3.3 seems broken.
>     The SHOULD says that it is ok for the FA to in some cases not
>     include a new challenge extension. That is ok.
>     But if it isn't included, the challenge extension received from
>     the HA MUST be dropped. Otherwise the MN will think it received a
>     new challenge from the FA when in fact it didn't.
>     Thus the FA MUST always remove the challenge extension received
>     from the HA.

That's fine with me.  I don't remember why we didn't do this
before.  I'll remove it for now, unless someone points out
why it should be kept.

> 13. Section 6
>    Each mobile node MUST support the ability to produce the
>    authenticator by using HMAC-MD5 as shown.  Just as with Mobile IP,
>    this default algorithm MUST be able to be configured for selection at
>    any arbitrary 32-bit SPI outside of the SPIs in the reserved range
>    0-255.
> 
>    This reads as the algoritm needs to be able to be
>    configured. Switching from passive to active voice might make it
>    easier to write something comprehensible.

Fixed.

> 14.    ensures that the challenge is used exactly as is.  Additional padding
>    is never used to increase the length of the padding; the input data
>    is allowed to be shorter than 237 bytes long.
>    s/length of the padding/length of the challenge/ ??

Fixed.

> 
> 15. Appendix title:
>         A. Changes since Last Revision
>         s/last revision/rfc 3012/

Fixed.

> 16. -  Foreign agent mandated to record applicable challenge values
>     used
>     s/mandated/MUST/??

Fixed.

> 17. Figure 5 doesn't show that challenges are in the RRep from HA to FA
>     and that the Challenge sent in the RRep from FA to HA is a "new
>     challenge" (different than the one received from the HA).

I'll fix this, somehow...

> 18.     2. The mobile node creates a Registration Request including the
>        advertised Challenge Value in the Challenge Extension, along with
>        an authorization-enabling authentication extension.
> 
>        To be more specific, the example is for a MN-AAA authentication
>        extension.

Fixed.

> 19. The content of the messages when a MN-FA auth extension (which is
>     an authorization-enabling as well?) is different. Since the
>     specification allows for MN-FA auth extensions to be used as well,
>     it would be useful to have a figure to outline the message
>     flow+content in that case.

O.K.  I'll try to do this.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 18 Oct 2002 14:55:10 -0700

Hello again folks,

I made a mistake in one of my earlier discussions about
how messages "correspond".

> >                a corresponding registration reply message.
                  ..........
> so that the correspondence can be exact.

Here, I should have said that the registration has to have
the "Identification" value.  The Challenge in the registration
request "corresponds" to and advertised value, and the
registration reply "corresponds to the registration request.
So, a correspondence can be determined, but not by using
the challenge value in the way that my statement indicated.

Actually, the definition is better without that word anyway.

Sorry for the confusion!

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 18 Oct 2002 15:14:30 -0700

More details ...

> I'll fix this, somehow...

The challenge that is different, is the one from the FA to MN.
The one from HA to FA is the same, if it's present.  I made this
indication in the diagram.

>>     flow+content in that case.

The MN-FA authentication extension was not intended to
be authorization enabling.  In that case, it's just assurance
to the foreign agent that the registration request is not a
replay. 

Regards,
Charlie P.