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

From: [email-masked]
Date: Thu, 26 Sep 2002 06:15:15 -0500

Hello,

RFC3012bis which has completed WG last call has been reviewed by the
ADs and the following is the feedback that we have received. Erik had
a number of comments that are both editorial and non-editorial. 
We (chairs) would like to get feedback from the WG on how to address
the non-editorial comments. 

Please post your comments with the appropriate issue number in the
subject line (instead of simply replying to this email).

-Chairs.

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.

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.

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.

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.  

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] 

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

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

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]? 

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. 

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. 

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

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?

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. 

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. 

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/ ??

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

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

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).

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. 

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.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 26 Sep 2002 11:22:39 -0500

I concur with this. It seems that EAP can not be encapsulated using 
Mobile IP. 802.1X does it at the frame level and HTTP/SIP at the 
application level.
It seems to be fair to say that network-initiated challange-response can 
not be provided with this document.
That makes me to conclude why do we need RFC3012bis?

Editorial comment: RFC numbers for MIPv4 and RADIUS need to be updated.

Regards,

>   Same comment on the introduction.
--behcet