Subject: [mobile-ip] Comments and questions on rfc3012bis-05

From: "Zeng, Iris [NTWK SVCS]" <[email-masked]>
Date: Wed, 28 May 2003 16:55:13 -0500

After reviewing the 3012bis-05, I have some questions and comments against the text.
Your reply would be appreciated.

Thanks,
Iris Zeng

1) What is the solution for  "lost registration reply" issue related to 3012bis? 
Issues:
* What happens when Registration Reply is lost?
Description:
* When Registration Reply is lost, the Mobile Node will perform
retransmission (as per RFC3344) with the same challenge value.
* The FA treats the retransmitted request as new Request and
generates STALE_CHALLENGE error code.

2) Section 3.4, page 9: What do you mean by HA recognizing the challenge extension?
"If the Home Agent receives a Registration Request with the Mobile-Foreign Challenge extension, and recognizes the extension, the Home Agent MUST include the Challenge extension in the Registration Reply." 
"Since the extension type for the Challenge extension is within the range 128-255, the Home Agent MUST process such a Registration Request even if it does not recognize the Challenge extension [7]. In this case, the Home Agent will send a Registration Reply to the Foreign Agent that does not include the Challenge extension." 

3) Section 3.4, page 9: Reject the Registration Reply? You mean reject the RRQ and send out the RRP with the error code, right?
"If the Mobile-AAA Authentication extension is used by the Home Agent as an authorization-enabling extension and the verification fails due to incorrect authenticator, the Home Agent MAY reject the Registration Reply with the error code BAD_AAA_AUTHENTICATION_SET_BY_HA. "

4) Appendix C, Figure 5, conflicts with section 6. Clarification is needed. The RRP coming back from the HA should include the Mobile-Home Authentication Extension, and may include the challenge extension. But are not showing in the figure. Suggestion: maybe spell out the Auth. Ext.? such as "MN-HA, MN-AAA/MN-FA"?
According to Section 6: "If the Mobile-AAA Authentication extension is present, then the Registration Message sent by the mobile node MUST contain the Mobile-Home Authentication extension [7] if it shares a security association with the Home Agent. If present, the Mobile-Home Authentication Extension MUST appear prior to the Mobile-AAA Authentication extension. The corresponding response MUST include the Mobile-Home Authentication Extension, and MUST NOT include the Mobile-AAA Authentication Extension. "

5) Use "mobile-AAA" or "MN-AAA", but not both.

-----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Wednesday, May 28, 2003 6:46 AM
Cc:	[email-masked]
Subject:	[mobile-ip] I-D ACTION:draft-ietf-mobileip-rfc3012bis-05.txt

 << File: ATT222969.TXT >> << File: draft-ietf-mobileip-rfc3012bis-05.URL >> A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF.

	Title		: Mobile IPv4 Challenge/Response Extensions (revised)
	Author(s)	: C. Perkins, P. Calhoun, J. Bharatia
	Filename	: draft-ietf-mobileip-rfc3012bis-05.txt
	Pages		: 23
	Date		: 2003-5-27
	
Mobile IP, as originally specified, defines an authentication
extension (the Mobile-Foreign Authentication extension) by
which a mobile node can authenticate itself to a foreign agent.
Unfortunately, that extension does not provide the foreign agent
any direct guarantee that the protocol is protected from replays,
and does not allow for the use of CHAP for authenticating portable
computer devices.  In this specification, we define extensions for
the Mobile IP Agent Advertisements and the Registration Request
that allow a foreign agent to use a challenge/response mechanism to
authenticate the mobile node.  This document obsoletes RFC 3012.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc3012bis-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mobileip-rfc3012bis-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mobileip-rfc3012bis-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Jayshree Bharatia" <[email-masked]>
Date: Fri, 30 May 2003 11:41:00 -0500

Hi Iris,

Please see my reply inline.

Thanks,
Jayshree

> From: Zeng, Iris [NTWK SVCS] [mailto:[email-masked]] 
> Sent: Wednesday, May 28, 2003 4:55 PM
> To: [email-masked]; [email-masked]; Bharatia, 
> Jayshree [RICH1:2H13:EXCH]
> Subject: Comments and questions on rfc3012bis-05
> 
> 
> After reviewing the 3012bis-05, I have some questions and 
> comments against the text. Your reply would be appreciated.
> 
> Thanks,
> Iris Zeng
> 
> * When Registration Reply is lost, the Mobile Node will 
> perform retransmission (as per RFC3344) with the same challenge value.

[JB]The basic functionality for "Lost Registration Reply" is discussed in
RFC 3344. This draft discusses the impact on the challenge management in
case of retransmission. Please refer to section 3.1 of the RFC3012bis draft
for the detail.
> 
> 2) Section 3.4, page 9: What do you mean by HA recognizing 
> the challenge extension? "If the Home Agent receives a 
> Registration Request with the Mobile-Foreign Challenge 
> extension, and recognizes the extension, the Home Agent MUST 
> include the Challenge extension in the Registration Reply." 
> "Since the extension type for the Challenge extension is 
> within the range 128-255, the Home Agent MUST process such a 
> Registration Request even if it does not recognize the 
> Challenge extension [7]. In this case, the Home Agent will 
> send a Registration Reply to the Foreign Agent that does not 
> include the Challenge extension." 

[JB] The term "HA recognizing the challenge extension" means "if the HA
supports the challenge extension". We need this condition in order to
support HA which are not compliant to this draft.
> 
> 3) Section 3.4, page 9: Reject the Registration Reply? You 
> mean reject the RRQ and send out the RRP with the error code, 
> right? "If the Mobile-AAA Authentication extension is used by 
> the Home Agent as an authorization-enabling extension and the 
> verification fails due to incorrect authenticator, the Home 
> Agent MAY reject the Registration Reply with the error code 
> BAD_AAA_AUTHENTICATION_SET_BY_HA. "

[JB] I will reword this statement to reflect the rejection of Registration
Request (and not really Registration Reply as indicated in the current
text).

> 
> 4) Appendix C, Figure 5, conflicts with section 6. 
> Clarification is needed. The RRP coming back from the HA 
> should include the Mobile-Home Authentication Extension, and 
> may include the challenge extension. But are not showing in 
> the figure. Suggestion: maybe spell out the Auth. Ext.? such 
> as "MN-HA, MN-AAA/MN-FA"? According to Section 6: "If the 
> Mobile-AAA Authentication extension is present, then the 
> Registration Message sent by the mobile node MUST contain the 
> Mobile-Home Authentication extension [7] if it shares a 
> security association with the Home Agent. If present, the 
> Mobile-Home Authentication Extension MUST appear prior to the 
> Mobile-AAA Authentication extension. The corresponding 
> response MUST include the Mobile-Home Authentication 
> Extension, and MUST NOT include the Mobile-AAA Authentication 
> Extension. "

[JB] I am not sure where the conflict is and hence how your suggestion can
solve the conflict.  

> 5) Use "mobile-AAA" or "MN-AAA", but not both.
[JB] I will update the draft to change "MN-AAA" to "Mobile-AAA".
> Subject:	[mobile-ip] I-D 
> ACTION:draft-ietf-mobileip-rfc3012bis-05.txt
> 
>  << File: ATT222969.TXT >> << File: 
> draft-ietf-mobileip-rfc3012bis-05.URL >> A New Internet-Draft 
> is available from the on-line Internet-Drafts directories. 
> This draft is a work item of the IP Routing for 
> Wireless/Mobile Hosts Working Group of the IETF.
> 
> which a mobile node can authenticate itself to a foreign 
> agent. Unfortunately, that extension does not provide the 
> foreign agent any direct guarantee that the protocol is 
> protected from replays, and does not allow for the use of 
> CHAP for authenticating portable computer devices.  In this 
> specification, we define extensions for the Mobile IP Agent 
> Advertisements and the Registration Request that allow a 
> foreign agent to use a challenge/response mechanism to 

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in, type
"cd internet-drafts" and then
	"get draft-ietf-mobileip-rfc3012bis-05.txt".

Send a message to:
	[email-masked].
In the body type: