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

From: "Ahmad Muhanna"<[email-masked]>
Date: Fri, 22 Mar 2002 12:32:46 -0600

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.

     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.

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 15:44:43 -0600 (CST)

Hi, Ahmad,

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

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

 > 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

 > <!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 conflictbetween  RFC3220 &amp; RFC3012 (RFC3012bis)</TITLE>
 > </HEAD>
 > <BODY>
 > 
 > <P><FONT SIZE=2>Hi Pete;</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>With the understanding as in my response to Charlie in the previous email.</FONT>
 > <BR><FONT SIZE=2>There is no backward compatibility issue with existing HA (RFC2002 &amp; RFC3012) receiving a RRQ message with ONLY a MN-AAA authentication extension (see previous email)</FONT></P>
 > 
 > <P><FONT SIZE=2>There are several places where we need to address the issue of EXACTLY vs. At least. The following are the proposed texts:</FONT></P>
 > 
 > <P><FONT SIZE=2>1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8.2.1. Validity Checks</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&nbsp; Registration Requests with an invalid, non-zero UDP checksum MUST be</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; silently discarded by the home agent.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&nbsp; The authentication in the Registration Request MUST be checked.&nbsp; This</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; involves the following operations:</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&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; authorization-enabling extension, and perform only one of the indicated</FONT>
 > <BR><FONT SIZE=2>&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; MUST be present in the Registration Request; and the home agent</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST either check the Authenticator value in the extension or</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; verify that the authenticator value has been checked by another</FONT>
 > <BR><FONT SIZE=2>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authorization-enabling extension is found, or if the</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Authenticator is invalid, the home agent MUST reject the mobile</FONT>
 > <BR><FONT SIZE=2>&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;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the Request and SHOULD log the error as a security exception. </FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the home agent receives a Registration Request without a Mobile-Home</FONT>
 > <BR><FONT SIZE=2>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; security association with this home agent, the home agent MAY </FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; discard the Mobile Node's Registration Request.</FONT>
 > </P>
 > <BR>
 > 
 > <P><FONT SIZE=2>&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; field is correct using the context selected by the SPI within</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the authorization-enabling extension that the home agent used to authenticate the </FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile Node's Registration Request.&nbsp; See Section 5.7 for a description of how this is performed.&nbsp; </FONT>
 > <BR><FONT SIZE=2>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; send a Registration Reply to the mobile node with Code 133, including an</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Identification field computed in accordance with the rules</FONT>
 > <BR><FONT SIZE=2>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; processing with such a Request, though it SHOULD log the error</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as a security exception.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A minor correction:</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>section 3.8.2.3 should read</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>&quot;If the Registration Request does not satisfy all of the validity checks</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; in Section 3.8.2.1,...&quot; </FONT>
 > </P>
 > 
 > <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>NOT </FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>&quot;If the Registration Reply does not satisfy all of the validity checks</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; in Section 3.8.2.1,...</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A slight change to your proposed text for section 3.6.1.3 item (e)</FONT>
 > </P>
 > 
 > <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>(e) An authorization-enabling extension other than mobile-home authentication, if present, followed by</FONT>
 > </P>
 > 
 > <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Otherwise, the text will allow the possibility of having two Mobile-Home Authentication extension in the RRQ.</FONT>
 > </P>
 > <BR>
 > 
 > <P><FONT SIZE=2>Thanks for consideration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>Regards;</FONT>
 > <BR><FONT SIZE=2>Ahmad Muhanna</FONT>
 > </P>
 > <BR>
 > <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: Wednesday, March 20, 2002 10:37 AM</FONT>
 > <BR><FONT SIZE=2>To: Charlie Perkins</FONT>
 > <BR><FONT SIZE=2>Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; [email-masked]'</FONT>
 > <BR><FONT SIZE=2>Subject: Re: [mobile-ip] A proposal for resolving a very Possible</FONT>
 > <BR><FONT SIZE=2>conflictbetween RFC3220 &amp; RFC3012 (RFC3012bis)</FONT>
 > </P>
 > <BR>
 > <BR>
 > 
 > <P><FONT SIZE=2>Hi, Charlie,</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>Ok, understanding the urgency, how about the following text:</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>Change the first paragraph of Section 3.5.2 to read:</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp; At least one authorization-enabling extension MUST be present in all</FONT>
 > <BR><FONT SIZE=2>&nbsp; Registration Requests, and also in all Registration Replies generated</FONT>
 > <BR><FONT SIZE=2>&nbsp; by the Home Agent.&nbsp; This requirement is intended to eliminate problems</FONT>
 > <BR><FONT SIZE=2>&nbsp; [2] which result from the uncontrolled propagation of remote redirects</FONT>
 > <BR><FONT SIZE=2>&nbsp; in the Internet.&nbsp; The location of the extension marks the end of the</FONT>
 > <BR><FONT SIZE=2>&nbsp; authenticated data covered by that extension.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp; The Mobile-Home Authentication Extension is always an</FONT>
 > <BR><FONT SIZE=2>&nbsp; authorization-enabling for registration messages specified in this</FONT>
 > <BR><FONT SIZE=2>&nbsp; document; future specifications may define additional</FONT>
 > <BR><FONT SIZE=2>&nbsp; authorization-enabling extensions.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>And the first sentence of Section 3.6:</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&nbsp; A mobile node MUST be configured with a netmask and a mobility</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; security association for each of its pre-assigned home agents or</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; home agents that could be discovered on a home subnet according</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; to procedures in Section 3.6.1.2.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>Also, I assume that the missing text people have been discussing</FONT>
 > <BR><FONT SIZE=2>covers the subnet-directed broadcast discovery mechanism in 3.6.1.2; I </FONT>
 > <BR><FONT SIZE=2>can't find it there now.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>Also, I think the text in 3.6.1.3 (section header currently missing)</FONT>
 > <BR><FONT SIZE=2>needs to change to:</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a) The IP header, followed by the UDP header, followed by the</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fixed-length portion of the Registration Request, followed by</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b) If present, any non-authentication Extensions expected to be</FONT>
 > <BR><FONT SIZE=2>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the foreign agent), followed by</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c) A mobile-home authentication extension, if present, followed by</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; d) If present, any non-authentication Extensions used only by the</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; foreign agent, followed by</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; e) An authorization-enabling extension, if present, followed by</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; f) The Mobile-Foreign Authentication Extension, if present.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&nbsp; Note that item (a) and at least one of (c) or (e) MUST appear in</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; every Registration Request sent by the mobile node.&nbsp; Items (b), (d),</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; and (f) are optional.&nbsp; However, item (f) MUST be included when the</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; mobile node and the foreign agent share a mobility security</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; association.</FONT>
 > </P>
 > <BR>
 > 
 > <P><FONT SIZE=2>I think that should do it.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>-Pete</FONT>
 > </P>
 > <BR>
 > <BR>
 > <BR>
 > <BR>
 > <BR>
 > 
 > <P><FONT SIZE=2>Charlie Perkins writes:</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Hello Pete,</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Pete McCann wrote:</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&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; &gt; sometimes.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; &gt;</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; &gt; Maybe the right approach is to update the text in 3220 to explicitly</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; &gt; allow zero security associations with home agents, if some other</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; &gt; &quot;authorization enabling extension&quot; is present in the message.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&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; the same time we supply the mysteriously vanished text, and update the</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; &quot;exactly one&quot;, and relieve the possibility for misinterpretation that was</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; noticed during Connectathon.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Regards,</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Charlie P.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > </P>
 > 
 > </BODY>
 > </HTML>