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

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 11 Jun 2003 07:55:25 -0500

Hi Iris,
I think your number 1 point is very valid and it is a good time to address
it NOW.
RFC3012-bis introduced the MN-FA Challenge extension to provide a replay
protection 
mechanism between the MN and the Foreign Agent. However, this mechanism does
not 
address the issue you mentioned in point 1. 

One clarification here: RRP is lost does not ONLY mean that RRP never made
it to the MN.
It also, means that RRP arrived at the MN too late that the MN already
retransmitted a new 
RRQ with a different ID (in case of timestamp) and the MN is tracking the
New RRQ ID rather
than the ID of the late received RRP. 

RFC3012-bis addresses the following:
1. replay protection between MN and the FA using MN-FA Challenge.
2. Retransmission of RRQ while the FA has a pending registration request.
(NO RRP is sent to MN)
3. Does NOT address the case when RRP is lost (i.e. NO registration request
is pending at the FA)
or received late at a MN that uses timestamp for replay protection with its
HA.

Therefore, a solution is required to address this issue listed in point 3
above.
The following solution addresses the issue of RRQ re-transmission for both
cases;
when the FA has a pending registration and in the case of lost RRP.

1. Whenever the MN retransmit RRQ message, MN SHOULD use a "retransmit
challenge" to indicate 
to the foreign agent that it (MN) is retransmitting RRQ for not receiving
RRP on time.
2. All other existing mechanism as per RFC3344 is still valid.
3. When FA receives a RRQ message with a challenge value of "retransmit
challenge" AND FA ACCEPTS
the RRQ message, FA relay the RRQ to the HA.

Now: What is the definition of Retransmit-Challenge:
It is a challenge value used when MN is retransmitting a RRQ message and It 
is related to the last challenge used by the MN in its last transmitted RRQ.

The relation of the retransmit challenge to its previous used challenge
SHOULD 
be known to the FA.
(i.e.) 

retransmit-challenge = Last-challenge + 1 (or any fixed value)

This addresses the issue of the MN retransmitting RRQ at all states of MN
and FA.
Your comments is greatly appreciated.

Regards,
Ahmad

> -----Original Message-----
> 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]
> Cc: [email-masked]
> Subject: [mobile-ip] 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
> 
> 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-rfc301
2bis-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.