Subject: Re: [mobile-ip] URGENT - rfc3012 interpretation question

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 11 Nov 2001 13:55:24 -0800

Hello Ahmad,

I have been puzzling over your question, and I do not find
a perfectly satisfying answer.

ext Ahmad Muhanna wrote:

> One more issue that needs clarification:
> RFC3012 Section 3.2. states:
> 
> "If a mobile node retransmits a Registration Request with the same
> Identification field and the same Challenge extension, and the Foreign
> Agent still has a pending Registration Request record in effect for the
> mobile node, then the Foreign Agent forwards the Registration Request to
> the Home Agent again. In all other circumstances, if the Foreign Agent
> receives a Registration Request with a Challenge extension containing a
> Challenge value previously used by that mobile node, the Foreign Agent
> SHOULD send a Registration Reply to the mobile node containing the Code
> value STALE_CHALLENGE."
> 
> However, RFC2002 section 3.6.3. defines the retransmission of
> Registration Request as the following:
> 
> "3.6.3. Registration Retransmission:
> When no Registration Reply has been received within a reasonable time,
> another Registration Request MAY be transmitted. When timestamps are
> used,
> a new registration Identification is chosen for each retransmission;
> ........"

What this boils down to, is that RFC 3012 wanted the Identification field
to stay the same for retransmissions, and RFC 2002{,bis} allows it
to change.

The problem is that RFC 2002 wasn't written to make it very convenient
for intermediate nodes (e.g., foreign agents) to recognize retransmissions.
I think the best solution for the Challenge extension is to cause the
foreign agent to do more work.  Thus, if a registration is pending, and
all the fields _except possibly the Identification field_ (!) are the
same, then the foreign agent SHOULD send the registration to the home
agent again.  It was always the intention that the foreign agent should
forward retransmitted registrations only when they are actually retransmissions,
and checking the Identification field was supposed to be a shortcut for
verifying that point.  However, you have now identified a reason why
we should not use the shortcut.

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

Here is the new relevant text, in the same paragraph as your original
quote:

      ....      The Foreign Agent SHOULD check that the mobile node is
   actually performing a retransmission, by verifying that the relevant 
   fields of the retransmitted request are the same as represented in
   the visitor list entry for the pending Registration Request (section
   3.7.1 of [8]).  This verification MUST NOT include the "remaining
   Lifetime of the pending registration", or the Identification field
   since those values are likely to change even for requests that are
   merely retransmissions and not new Registration Requests.  In all
   other circumstances, if the Foreign Agent receives   .... 

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

Comments?

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 11 Nov 2001 15:02:20 -0800

ext Ahmad Muhanna wrote:

Hello again Ahmad,

> Hello All;
> 
> I believe after reading section 3.2., RFC3012, anyone can come up with
> the following concepts which has been highlighted and addressed directly
> or indirectly:
> 
> 1.      The term of unused challenge. Paragraph 1 section 3.2.
>                        .............
> 2.      The term of previously used challenge. Paragraph 3, section 3.2
>                        .............
> 3.      The term of UNKNOWN_CHALLENGE, Paragraph 4, section 3.2.
>                        .............
> I believe the RFC needs to identify the following:
> 1.      USED_CHALLENGE_WINDOW with a default value of 2 just like the
> CHALLENGE_WINDOW.

I didn't see the need for USED_CHALLENGE_WINDOW.  It would allow the
foreign agent to distinguish between used challenges and unknown
challenges, but I don't exactly see why it is important to be precise
about this.  Presumably the foreign agent will keep track of some number
of used challenges, and it's not important for the mobile node to know
the foreign agent's algorithm for doing so.

> 2.      The meaning of the USED Challenge is any challenge that has been
> used in a RRQ message and accepted by the PDSN as a valid CHALLENGE and
> PDSN  relayed/generated a RRP in response to that RRQ message.

Use of the term "PDSN" is not appropriate for this specification.
I have used "foreign agent" instead in the following definitions:

===========================================================================
      previously used challenge
               Any challenge that has been used in a Registration
               Request message and accepted by the Foreign Agent as a
               valid challenge in a corresponding Registration Reply
               message.
   
      stale challenge
               Same as "previously used challenge".
   
      unknown challenge
               Any challenge that the foreign agent has no record of
               having put into one of its Agent Advertisements.

      unused challenge
               A challenge that has not been already accepted
               by the Foreign Agent as a valid challenge in a
               Registration Reply message -- i.e., a valid challenge
               that is neither unknown nor previously used.

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

> 3.      "In all other circumstances" in paragraph 3 is very vague. We
> may need to elaborate a little bit to explicitly say that
> STALE_CHALLENGE will be generated whenever a USED CHALLENGE
> is sent in a RRQ message.

The sentence following that phrase does exactly express that point.
Can you be specific about what you would like to see changed?

> NOW the UNKNOWN CHALLENGE becomes any Challenge value other than the one
> which was offered in last (NO Successful is mentioned) Registration
> Reply issued to the Mobile Node, or else advertised as one of the last
> CHALLENGE_WINDOW (see section 9) Challenge values inserted into the
> immediately preceding Agent advertisements, or else has previously been
> used as one of the last USED_CHALLENGE_WINDOW (see section 9).

I think I understand this issue, and I agree that the foreign agent 
should be able to do this.  In fact, I thought we had already made
the appropriate changes, but you have identified language in the draft
where more work needed to be done.  I think I have found all the offending
parts and fixed them now.

Regards,
Charlie P.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sun, 11 Nov 2001 21:45:39 -0600

Charlie;
Thanks very much for your great effort in clarifying these issues.
Please see my comments inline.

Regards;

Ahmad Muhanna
Nortel Networks

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Sunday, November 11, 2001 5:02 PM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]
Cc: 'Patil Basavaraj (NET/Dallas)'; 'Pat Calhoun'; Wenzel, Pete
[RICH2:2Q00:EXCH]; Mobile IP Working Group
Subject: Re: [mobile-ip] URGENT - rfc3012 interpretation question

ext Ahmad Muhanna wrote:

Hello again Ahmad,

Ahmad Muhanna:
I just wanted to be inline with the CHALLENGE_WINDOW proposed in this RFC.
"....and it's not important for the mobile node to know the foreign agent's
algorithm for doing so."

The same argument could be said about the CHALLENGE_WINDOW. 
I do not see any problem in not having this parameter. However, it helps in
making wording a little easier.

Ahmad Muhanna:
I agree.

Ahmad Muhanna:
I am afraid that some one may interpret 
"... and accepted by the Foreign Agent as a valid challenge in a
corresponding Registration Reply message."
as the following:

The corresponding RRP should have the same challenge back in the RRP for the
challenge to be marked as USED.
This wording make it hard, since generating a new Challenge in RRP is an
option for the Foreign Agent not a MUST.

If I may suggest a slight change:

               Any challenge that has been used in a Registration
               Request message and accepted by the Foreign Agent as a
               valid challenge by relaying/generating a corresponding
Registration Reply
               message.

      stale challenge

Ahmad Muhanna:
		   Same as "previously used challenge" and the Foreign Agent
still has a record of.
   
      unknown challenge

Ahmad Muhanna: May I suggest a slight change here, otherwise MN can not use
challenge values received in RRP messages.

               Any challenge that the foreign agent has no record of
               having put into one of its Agent Advertisements nor 
               a corresponding registration reply message.

      unused challenge

Ahmad Muhanna: I am not sure if we need to have a definition for unused
challenge included.

Ahmad Muhanna:
		The above definition of Stale Challenge takes care of this.

Regards,
Charlie P.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sun, 11 Nov 2001 22:50:26 -0600

Hello Charlie;

Regards;
Ahmad Muhanna

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Sunday, November 11, 2001 3:55 PM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]
Cc: 'Patil Basavaraj (NET/Dallas)'; Wenzel, Pete [RICH2:2Q00:EXCH];
Mobile IP Working Group; Pat Calhoun
Subject: Re: [mobile-ip] URGENT - rfc3012 interpretation question

Hello Ahmad,

forward retransmitted registrations only when they are actually
retransmissions,

Comments?

Ahmad Muhanna:
I hope you would agree that the following change will satisfy the need:

"If a mobile node retransmits a Registration Request with the same
Identification field and the same Challenge extension, and the Foreign
Agent still has a pending Registration Request record in effect for the
mobile node, then the Foreign Agent forwards the Registration Request to
the Home Agent again (see Registration Retransmission, section 3.6.3[8]). 
In all other circumstances, if the Foreign Agent receives a Registration 
Request with a Challenge extension containing a Challenge value previously 
used by that mobile node, the Foreign Agent SHOULD send a Registration 
Reply to the mobile node containing the Code value STALE_CHALLENGE."

Regards,
Charlie P.

---

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Tue, 13 Nov 2001 16:20:10 -0600

>>Reply to the mobile node containing the Code value STALE_CHALLENGE." 
 
I think the text that Charlie proposes makes it quite clear as to what
the FA must do in order to recognize, if it is a retransmission. So I
would recommend going with Charlie's text in the revision for this
spec. 
 
-Basavaraj

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 13 Nov 2001 21:34:01 -0600

Hello Charlie;
I am sorry I may sound silly here. 
But can you please put this paragraph all together in order to see how the
final version will read?
I assume that we are revising paragraph No. 3 under section 3.2. which
starts "If a mobile node..."
 
Thanks a lot.

Regards; 

Ahmad Muhanna 
Nortel Networks 
Shasta PDSN-MIP Development 
Phone. + 1 972 685 1416 ESN. 445-1416 
[email-masked] 

-----Original Message-----
From: Patil Basavaraj (NET/Dallas) [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 4:20 PM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; Perkins Charles (IPRG)
Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; Mobile IP Working Group; Pat Calhoun
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question

 
 
-Basavaraj