Subject: RE: [mobile-ip] A proposal for resolving a very Possible conflict between RFC3220 & RFC3012 (RFC3012bis)

From: "Ahmad Muhanna"<[email-masked]>
Date: Mon, 25 Mar 2002 16:44:16 -0600

Hi, Pete,
Please see my one comment inline. 

Also, please let me know what you think of the following part of the
proposed text:

"
        a) The home agent MUST check for the presence of at least one
           authorization-enabling extension, and perform only one of the
indicated
          authentication(s).  At least one authorization-enabling extension
          MUST be present in the Registration Request;...............
"
I proposed  ".., and perform only one of the indicated
authentication(s)....."
OVER "...., and perform at least one the indicated authentication(s)
......."
for the following reason:

In point (b) in the same section:
"
      b) The home agent MUST check that the registration Identification
          field is correct using the context selected by the SPI within
          the authorization-enabling extension that the home agent used to
          authenticate the Mobile Node's Registration Request. ....
"
The standard says that the home agent MUST check that the registration
Identification 
according to the context selected by the SPI within the
authorization-enabling extension.

Therefore, it makes more sense to define ONLY one authentication to be done
and 
use the SPI of that authorization extension to reference the context which
specifies 
the registration identification.

I hope that you did not miss this part and you still agree with it.

Regards;
Ahmad Muhanna

-----Original Message-----
From: Pete McCann [mailto:[email-masked]]
Sent: Monday, March 25, 2002 3:45 PM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; [email-masked]
Cc: 'Charles E. Perkins'
Subject: RE: [mobile-ip] A proposal for resolving a very Possible
conflict between RFC3220 & RFC3012 (RFC3012bis)

Hi, Ahmad,

I agree with most of your proposed text, but one comment below:

Ahmad Muhanna writes:
 > Hi Pete;
 > 
 > With the understanding as in my response to Charlie in the previous
email.
 > There is no backward compatibility issue with existing HA (RFC2002 &
 > RFC3012) receiving a RRQ message with ONLY a MN-AAA authentication
extension
 > (see previous email)
 > 
 > There are several places where we need to address the issue of EXACTLY
vs.
 > At least. The following are the proposed texts:
 > 
 > 1.	8.2.1. Validity Checks
 > 
 >    Registration Requests with an invalid, non-zero UDP checksum MUST be
 >    silently discarded by the home agent.
 > 
 >    The authentication in the Registration Request MUST be checked.  This
 >    involves the following operations:
 > 
 >       a) The home agent MUST check for the presence of at least one
 >          authorization-enabling extension, and perform only one of the
 > indicated
 >          authentication(s).  At least one authorization-enabling
extension
 >          MUST be present in the Registration Request; and the home agent
 >          MUST either check the Authenticator value in the extension or
 >          verify that the authenticator value has been checked by another
 >          agent with which it has a security association.  If no
 >          authorization-enabling extension is found, or if the
 >          Authenticator is invalid, the home agent MUST reject the mobile
 >          node's registration and SHOULD send a Registration Reply to the
 >          mobile node with Code 131.  The home agent MUST then discard
 >          the Request and SHOULD log the error as a security exception. 

 >          If the home agent receives a Registration Request without a
 > Mobile-Home
 >          Authentication extension from a Mobile Node that does not have a

 >          security association with this home agent, the home agent MAY 
 >          discard the Mobile Node's Registration Request.

Do we really need this last sentence above?  I think you are trying to 
account for HAs that don't know about any authorization enabling 
extensions other than MN-HA Authentication extension.  Won't the RRQs
be silently discarded in this case, simply due to normal processing
for unrecognized criticial extensions?

Ahmad Muhanna:
Well, according to RFC3012, forwarding MN-AAA authentication extension 
was forbidden in one case ONLY. If the FA did not perform authentication or
in other words, 
before performing authentication using MN-AAA. The wording of the text in
section 3.2 of RFC3012 
left it optional to forward that extension.

I believe, what I am trying to account for is existing HAs which recognize
the MN-HA 
and the MN-AAA authentication extension BUT it performs only the MN-HA
authentication 
according to RFC2002 (RFC3220).

I feel it is important to leave this text to provide 100% backward
compatibility and at 
the same time it does not affect or contradict with what RFC3220 is
proposing anyway.

 > 
 >      b) The home agent MUST check that the registration Identification
 >          field is correct using the context selected by the SPI within
 >          the authorization-enabling extension that the home agent used to
 > authenticate the 
 >          Mobile Node's Registration Request.  See Section 5.7 for a
 > description of how this is performed.  
 >          If incorrect, the home agent MUST reject the Request and SHOULD 
 >          send a Registration Reply to the mobile node with Code 133,
 > including an
 >          Identification field computed in accordance with the rules
 >          specified in Section 5.7.  The home agent MUST do no further
 >          processing with such a Request, though it SHOULD log the error
 >          as a security exception.
 > 
 > 2.	A minor correction:
 > 	section 3.8.2.3 should read
 > 	"If the Registration Request does not satisfy all of the validity
 > checks
 >    	in Section 3.8.2.1,..." 
 > 
 > 	NOT 
 > 	"If the Registration Reply does not satisfy all of the validity
 > checks
 >    	in Section 3.8.2.1,...
 > 
 > 3.	A slight change to your proposed text for section 3.6.1.3 item (e)
 > 
 > 	(e) An authorization-enabling extension other than mobile-home
 > authentication, if present, followed by
 > 
 > 	Otherwise, the text will allow the possibility of having two
 > Mobile-Home Authentication extension in the RRQ.

Yes, I agree.  I had considered similar wording myself, but discarded
it in favor of a simpler specification - perhaps it would be OK to
allow this behavior, nothing is really broken.  But I can agree with
your wording above.

-Pete

 > Thanks for consideration	
 > 
 > Regards;
 > Ahmad Muhanna
 > 
 > 
 > 
 > -----Original Message-----
 > From: Pete McCann [mailto:[email-masked]]
 > Sent: Wednesday, March 20, 2002 10:37 AM
 > To: Charlie Perkins
 > Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; [email-masked]'
 > Subject: Re: [mobile-ip] A proposal for resolving a very Possible
 > conflictbetween RFC3220 & RFC3012 (RFC3012bis)
 > 
 > 
 > 
 > Hi, Charlie,
 > 
 > Ok, understanding the urgency, how about the following text:
 > 
 > Change the first paragraph of Section 3.5.2 to read:
 > 
 >   At least one authorization-enabling extension MUST be present in all
 >   Registration Requests, and also in all Registration Replies generated
 >   by the Home Agent.  This requirement is intended to eliminate problems
 >   [2] which result from the uncontrolled propagation of remote redirects
 >   in the Internet.  The location of the extension marks the end of the
 >   authenticated data covered by that extension.
 > 
 >   The Mobile-Home Authentication Extension is always an
 >   authorization-enabling for registration messages specified in this
 >   document; future specifications may define additional
 >   authorization-enabling extensions.
 > 
 > And the first sentence of Section 3.6:
 > 
 >    A mobile node MUST be configured with a netmask and a mobility
 >    security association for each of its pre-assigned home agents or
 >    home agents that could be discovered on a home subnet according
 >    to procedures in Section 3.6.1.2.
 > 
 > Also, I assume that the missing text people have been discussing
 > covers the subnet-directed broadcast discovery mechanism in 3.6.1.2; I 
 > can't find it there now.
 > 
 > Also, I think the text in 3.6.1.3 (section header currently missing)
 > needs to change to:
 > 
 >       a) The IP header, followed by the UDP header, followed by the
 >          fixed-length portion of the Registration Request, followed by
 > 
 >       b) If present, any non-authentication Extensions expected to be
 >          used by the home agent (which may or may not also be useful to
 >          the foreign agent), followed by
 > 
 >       c) A mobile-home authentication extension, if present, followed by
 > 
 >       d) If present, any non-authentication Extensions used only by the
 >          foreign agent, followed by
 > 
 >       e) An authorization-enabling extension, if present, followed by
 > 
 >       f) The Mobile-Foreign Authentication Extension, if present.
 > 
 >    Note that item (a) and at least one of (c) or (e) MUST appear in
 >    every Registration Request sent by the mobile node.  Items (b), (d),
 >    and (f) are optional.  However, item (f) MUST be included when the
 >    mobile node and the foreign agent share a mobility security
 >    association.
 > 
 > 
 > I think that should do it.
 > 
 > -Pete
 > 
 > 
 > 
 > 
 > 
 > 
 > Charlie Perkins writes:
 >  > 
 >  > Hello Pete,
 >  > 
 >  > Pete McCann wrote:
 >  > 
 >  > > I believe we will need to update the MN-HA key in the first RRQ/RRP,
 >  > > sometimes.
 >  > >
 >  > > Maybe the right approach is to update the text in 3220 to explicitly
 >  > > allow zero security associations with home agents, if some other
 >  > > "authorization enabling extension" is present in the message.
 >  > 
 >  > If so, the time to do so would be this week, so that we can get it in
at
 >  > the same time we supply the mysteriously vanished text, and update the
 >  > "exactly one", and relieve the possibility for misinterpretation that
was
 >  > noticed during Connectathon.
 >  > 
 >  > Regards,
 >  > Charlie P.
 >  > 
 >  >

---

From: Pete McCann <[email-masked]>
Date: Mon, 25 Mar 2002 17:07:09 -0600 (CST)

Hi, Ahmad,

Yes, I think I understand the reasoning that went into this.  I agree
with your proposal.

-Pete

Ahmad Muhanna writes:
 > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
 > <HTML>
 > <HEAD>
 > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
 > <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
 > <TITLE>RE: [mobile-ip] A proposal for resolving a very Possible conflict between  RFC3220 &amp; RFC3012 (RFC3012bis)</TITLE>
 > </HEAD>
 > <BODY>
 > 
 > <P><FONT SIZE=2>Hi, Pete,</FONT>
 > <BR><FONT SIZE=2>Please see my one comment inline. </FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>Also, please let me know what you think of the following part of the proposed text:</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&quot;</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a) The home agent MUST check for the presence of at least one</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authorization-enabling extension, and perform only one of the indicated</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authentication(s).&nbsp; At least one authorization-enabling extension</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST be present in the Registration Request;...............</FONT>
 > <BR><FONT SIZE=2>&quot;</FONT>
 > <BR><FONT SIZE=2>I proposed&nbsp; &quot;.., and perform only one of the indicated authentication(s).....&quot;</FONT>
 > <BR><FONT SIZE=2>OVER &quot;...., and perform at least one the indicated authentication(s) .......&quot;</FONT>
 > <BR><FONT SIZE=2>for the following reason:</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>In point (b) in the same section:</FONT>
 > <BR><FONT SIZE=2>&quot;</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b) The home agent MUST check that the registration Identification</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; field is correct using the context selected by the SPI within</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the authorization-enabling extension that the home agent used to</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authenticate the Mobile Node's Registration Request. ....</FONT>
 > <BR><FONT SIZE=2>&quot;</FONT>
 > <BR><FONT SIZE=2>The standard says that the home agent MUST check that the registration Identification </FONT>
 > <BR><FONT SIZE=2>according to the context selected by the SPI within the authorization-enabling extension.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>Therefore, it makes more sense to define ONLY one authentication to be done and </FONT>
 > <BR><FONT SIZE=2>use the SPI of that authorization extension to reference the context which specifies </FONT>
 > <BR><FONT SIZE=2>the registration identification.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>I hope that you did not miss this part and you still agree with it.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>Regards;</FONT>
 > <BR><FONT SIZE=2>Ahmad Muhanna</FONT>
 > </P>
 > <BR>
 > 
 > <P><FONT SIZE=2>-----Original Message-----</FONT>
 > <BR><FONT SIZE=2>From: Pete McCann [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
 > <BR><FONT SIZE=2>Sent: Monday, March 25, 2002 3:45 PM</FONT>
 > <BR><FONT SIZE=2>To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; [email-masked]</FONT>
 > <BR><FONT SIZE=2>Cc: 'Charles E. Perkins'</FONT>
 > <BR><FONT SIZE=2>Subject: RE: [mobile-ip] A proposal for resolving a very Possible</FONT>
 > <BR><FONT SIZE=2>conflict between RFC3220 &amp; RFC3012 (RFC3012bis)</FONT>
 > </P>
 > <BR>
 > <BR>
 > 
 > <P><FONT SIZE=2>Hi, Ahmad,</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>I agree with most of your proposed text, but one comment below:</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>Ahmad Muhanna writes:</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Hi Pete;</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; With the understanding as in my response to Charlie in the previous email.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; There is no backward compatibility issue with existing HA (RFC2002 &amp;</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; RFC3012) receiving a RRQ message with ONLY a MN-AAA authentication extension</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; (see previous email)</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; There are several places where we need to address the issue of EXACTLY vs.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; At least. The following are the proposed texts:</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; 1.&nbsp;&nbsp; 8.2.1. Validity Checks</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; Registration Requests with an invalid, non-zero UDP checksum MUST be</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; silently discarded by the home agent.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; The authentication in the Registration Request MUST be checked.&nbsp; This</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; involves the following operations:</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a) The home agent MUST check for the presence of at least one</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authorization-enabling extension, and perform only one of the</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; indicated</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authentication(s).&nbsp; At least one authorization-enabling extension</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST be present in the Registration Request; and the home agent</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST either check the Authenticator value in the extension or</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; verify that the authenticator value has been checked by another</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; agent with which it has a security association.&nbsp; If no</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authorization-enabling extension is found, or if the</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Authenticator is invalid, the home agent MUST reject the mobile</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; node's registration and SHOULD send a Registration Reply to the</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mobile node with Code 131.&nbsp; The home agent MUST then discard</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the Request and SHOULD log the error as a security exception. </FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the home agent receives a Registration Request without a</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Mobile-Home</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Authentication extension from a Mobile Node that does not have a </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; security association with this home agent, the home agent MAY </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; discard the Mobile Node's Registration Request.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>Do we really need this last sentence above?&nbsp; I think you are trying to </FONT>
 > <BR><FONT SIZE=2>account for HAs that don't know about any authorization enabling </FONT>
 > <BR><FONT SIZE=2>extensions other than MN-HA Authentication extension.&nbsp; Won't the RRQs</FONT>
 > <BR><FONT SIZE=2>be silently discarded in this case, simply due to normal processing</FONT>
 > <BR><FONT SIZE=2>for unrecognized criticial extensions?</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>Ahmad Muhanna:</FONT>
 > <BR><FONT SIZE=2>Well, according to RFC3012, forwarding MN-AAA authentication extension </FONT>
 > <BR><FONT SIZE=2>was forbidden in one case ONLY. If the FA did not perform authentication or in other words, </FONT>
 > <BR><FONT SIZE=2>before performing authentication using MN-AAA. The wording of the text in section 3.2 of RFC3012 </FONT>
 > <BR><FONT SIZE=2>left it optional to forward that extension.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>I believe, what I am trying to account for is existing HAs which recognize the MN-HA </FONT>
 > <BR><FONT SIZE=2>and the MN-AAA authentication extension BUT it performs only the MN-HA authentication </FONT>
 > <BR><FONT SIZE=2>according to RFC2002 (RFC3220).</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>I feel it is important to leave this text to provide 100% backward compatibility and at </FONT>
 > <BR><FONT SIZE=2>the same time it does not affect or contradict with what RFC3220 is proposing anyway.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b) The home agent MUST check that the registration Identification</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; field is correct using the context selected by the SPI within</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the authorization-enabling extension that the home agent used to</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; authenticate the </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile Node's Registration Request.&nbsp; See Section 5.7 for a</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; description of how this is performed.&nbsp; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If incorrect, the home agent MUST reject the Request and SHOULD </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; send a Registration Reply to the mobile node with Code 133,</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; including an</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Identification field computed in accordance with the rules</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; specified in Section 5.7.&nbsp; The home agent MUST do no further</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; processing with such a Request, though it SHOULD log the error</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as a security exception.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; 2.&nbsp;&nbsp; A minor correction:</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; &nbsp;&nbsp;&nbsp;&nbsp; section 3.8.2.3 should read</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &quot;If the Registration Request does not satisfy all of the validity</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; checks</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; &nbsp; in Section 3.8.2.1,...&quot; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; &nbsp;&nbsp;&nbsp;&nbsp; NOT </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &quot;If the Registration Reply does not satisfy all of the validity</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; checks</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; &nbsp; in Section 3.8.2.1,...</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; 3.&nbsp;&nbsp; A slight change to your proposed text for section 3.6.1.3 item (e)</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; &nbsp;&nbsp;&nbsp;&nbsp; (e) An authorization-enabling extension other than mobile-home</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; authentication, if present, followed by</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; &nbsp;&nbsp;&nbsp;&nbsp; Otherwise, the text will allow the possibility of having two</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Mobile-Home Authentication extension in the RRQ.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>Yes, I agree.&nbsp; I had considered similar wording myself, but discarded</FONT>
 > <BR><FONT SIZE=2>it in favor of a simpler specification - perhaps it would be OK to</FONT>
 > <BR><FONT SIZE=2>allow this behavior, nothing is really broken.&nbsp; But I can agree with</FONT>
 > <BR><FONT SIZE=2>your wording above.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>-Pete</FONT>
 > </P>
 > <BR>
 > 
 > <P><FONT SIZE=2>&nbsp;&gt; Thanks for consideration&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Regards;</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Ahmad Muhanna</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; -----Original Message-----</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; From: Pete McCann [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Sent: Wednesday, March 20, 2002 10:37 AM</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; To: Charlie Perkins</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; [email-masked]'</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Subject: Re: [mobile-ip] A proposal for resolving a very Possible</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; conflictbetween RFC3220 &amp; RFC3012 (RFC3012bis)</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Hi, Charlie,</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Ok, understanding the urgency, how about the following text:</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Change the first paragraph of Section 3.5.2 to read:</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp; At least one authorization-enabling extension MUST be present in all</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp; Registration Requests, and also in all Registration Replies generated</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp; by the Home Agent.&nbsp; This requirement is intended to eliminate problems</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp; [2] which result from the uncontrolled propagation of remote redirects</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp; in the Internet.&nbsp; The location of the extension marks the end of the</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp; authenticated data covered by that extension.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp; The Mobile-Home Authentication Extension is always an</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp; authorization-enabling for registration messages specified in this</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp; document; future specifications may define additional</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp; authorization-enabling extensions.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; And the first sentence of Section 3.6:</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; A mobile node MUST be configured with a netmask and a mobility</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; security association for each of its pre-assigned home agents or</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; home agents that could be discovered on a home subnet according</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; to procedures in Section 3.6.1.2.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Also, I assume that the missing text people have been discussing</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; covers the subnet-directed broadcast discovery mechanism in 3.6.1.2; I </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; can't find it there now.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Also, I think the text in 3.6.1.3 (section header currently missing)</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; needs to change to:</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a) The IP header, followed by the UDP header, followed by the</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fixed-length portion of the Registration Request, followed by</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b) If present, any non-authentication Extensions expected to be</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used by the home agent (which may or may not also be useful to</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the foreign agent), followed by</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c) A mobile-home authentication extension, if present, followed by</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; d) If present, any non-authentication Extensions used only by the</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; foreign agent, followed by</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; e) An authorization-enabling extension, if present, followed by</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; f) The Mobile-Foreign Authentication Extension, if present.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; Note that item (a) and at least one of (c) or (e) MUST appear in</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; every Registration Request sent by the mobile node.&nbsp; Items (b), (d),</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; and (f) are optional.&nbsp; However, item (f) MUST be included when the</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; mobile node and the foreign agent share a mobility security</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp;&nbsp;&nbsp; association.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; I think that should do it.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; -Pete</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Charlie Perkins writes:</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; Hello Pete,</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; Pete McCann wrote:</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; &gt; I believe we will need to update the MN-HA key in the first RRQ/RRP,</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; &gt; sometimes.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; &gt;</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; &gt; Maybe the right approach is to update the text in 3220 to explicitly</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; &gt; allow zero security associations with home agents, if some other</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; &gt; &quot;authorization enabling extension&quot; is present in the message.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; If so, the time to do so would be this week, so that we can get it in at</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; the same time we supply the mysteriously vanished text, and update the</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; &quot;exactly one&quot;, and relieve the possibility for misinterpretation that was</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; noticed during Connectathon.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; Regards,</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; Charlie P.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt;&nbsp; &gt; </FONT>
 > </P>
 > 
 > </BODY>
 > </HTML>