Subject: RE: [mobile-ip] RE: A Question about:draft-ietf-mobileip-aaa-nai- 00.txt

From: "Ahmad Muhanna"<[email-masked]>
Date: Fri, 26 Apr 2002 14:18:51 -0500

Hi Bob;
You are right.

Once more we find that Backward compatibility presents itself as an
issue which needs a permanent solution before we run out of bits and bytes. 
I am working on a solution and I hope I will be able to submit a draft in
couple of weeks.

Regards; 
Ahmad Muhanna 

++++++++++++++++++++++++++++++++++++++++++++

Hi Ahmad,
 
I received your previous email correctly, but was still considering my
reply. Please excuse the delay.
 
I'm concerned with the following scenario. If a FA supports both RFC3012 and
this I-D, then it will include a Challenge Extension in any Agent
Advertisement it sends. A MN entering an area served by the FA will not know
whether the FA "also" supports this I-D, and so must include the AAA NAI
Extension to cover that possibility. I grant that once the MN receives a
Registration Reply, it will know what to do as long as it stays in the area
serviced by the FA. However, this is Mobile IP, not Nomadic IP, so I expect
the MN to move, often, and to face the exact same situation with the next FA
it encounters.
 
I guess no one wants to use another bit in the advertisement to indicate the
type of AAA infrastructure in use. So is there some other way to provide a
clue to the MN and still support backward compatibility and still conserve
bandwidth?
 
Bob
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ahmad Muhanna
Sent: Friday, April 26, 2002 8:44 AM
To: [email-masked]'; 'Tony Johansson'
Cc: 'Fredrik Johansson'; [email-masked]
Subject: RE: [mobile-ip] RE: A Question
about:draft-ietf-mobileip-aaa-nai-00.txt

Hello Bob; 
I am resending this email because I am not sure if it made it earlier. 
I think the whole idea is to prevent this draft from mandating all Mobile
Nodes to include 
AAA NAI extension with subtype 1 "HA" in the following scenarios: 
1. When the Mobile Node sends a Registration Request for Re-Authentication: 
MN will never be able to send the AAA NAI extension in the Registration 
request unless it recognizes and support that extension. Because, it
received 
it from HAAA through the FAAA and the FA in the Registration Reply message. 
Legacy MN does not support any feature which requires this anyway. 
2. When the Mobile Node request a static Mobile IP call. "specific IP
address" 
ONLY those Mobile Node which again support and recognizes this extension 
will be able to send it. Because, legacy Mobile Node are not configured with

AAA NAI extension for the HA anyway. Also, legacy MN does not support 
any feature which requires this to be added to the Registration Request. 
However, I agree the proposed text may be very broad. 
Tony/Bob, 
Do you think the following text would be more specific? 
It include all the text I proposed so far. 
section 4. should read: 
" 
   The HA identity uses subtype 1 of the AAA NAI Extension.  It contains 
   the NAI of the AAA interface of the HA in the form hostname@realm. 
   Together the hostname and realm forms the complete FQDN 
   (hostname.realm) of the HA's AAA interface. 
   The home agent MUST provide HA identity in every registration reply 
   sent to the mobile node destined through the AAA infrastructure. 
   A mobile node which support AAA NAI extension MUST provide HA 
   identity in every registration request sent when re-authenticating, 
   or when requesting a specific IP address at initial authentication. 
" 
section 5. should read: 
" 
   The AAAH identity uses subtype 2 of the AAA NAI Extension.  It 
   contains the NAI of the home AAA server in the form hostname@realm. 
   Together the hostname and realm forms the complete FQDN 
   (hostname.realm) of the home AAA servers interface. 
   The home agent MUST provide this in every registration reply sent to 
   the mobile node destined through the AAA infrastructure. 
   A mobile node which support the AAA NAI extension MUST always 
   save the latest AAAH Identity received in the registration reply message 
   and MUST provide the AAAH Identity in every registration request sent 
    when re-authenticating. 
   If the AAAH identity is present, the foreign agent MUST direct an 
   authentication request to this home AAA server when authenticating 
   the mobile node through the AAA infrastructure by means described in 
   [2] 
" 
This will eliminate the need for the following text: 
"The AAA NAI extension MUST only be used with the Diameter Mobile IPv4 
application and MUST NOT be used with any other AAA protocol." 

Regards; 
Ahmad Muhanna 
****************************************************************************
*************************** 

Hello Ahmad, 
  
I'm still not totally comfortable with this new technique and its impact on
bandwidth-constrained links. 
  
For RFC2002, the MN sent only the authentication extensions it knew it
needed. It knew if it had a 
security association with the FA, and had to have a security association
with the HA. 
  
For RFC3012, the MN could use the presence (or absence) of the Challenge to
determine which 
extensions and parameters (like NAI) it included in the Registration
Request. 
  
But for this new I-D, the MN does not get any clue at all. Therefore it
needs to include the extension 
because it might be needed. This, it seems to me, is not so good for
bandwidth-constrained links. 
As Tony pointed out, it seems that the MN must be configured to send or not
to send - I'd rather the 
FA provided some clue. 
  
Bob

---

From: Tony Johansson <[email-masked]>
Date: Fri, 26 Apr 2002 15:48:16 -0700

Hello Bob and Ahmad,

Thanks a lot for your valuable points here and I agree backward
compatibility is an issue. In the existing deployments of Mobile IP
clients, especially those that will soon be deployed for IS-835 (the
cdma2000 standard) will not have AAA NAI extension support. However, I
don't think we need to change any of the wording that we have agreed on
in the draft-ietf-mobileip-aaa-nai-00.txt draft, instead the changes
should be done in the Diameter Mobile IPv4 application. I rather see
that we let the network side takes care and deal with the consequences
of the possible backward compatibility issues for those legacy clients
that don't have AAA NAI support then adding even more complexity to the
mobile IP client side. I've sent a new issue to the aaa-wg list
regarding this
(http://www.merit.edu/mail.archives/aaa-wg/msg03958.html).

Comments / objections to this?

Regards,

/Tony

Ahmad Muhanna wrote:

> I am working on a solution and I hope I will be able to submit a draft
> in couple of weeks.
>
> Regards;
> Ahmad Muhanna
>
> I'm concerned with the following scenario. If a FA supports both
> RFC3012 and this I-D, then it will include a Challenge Extension in
> any Agent Advertisement it sends. A MN entering an area served by the
> FA will not know whether the FA "also" supports this I-D, and so must
> include the AAA NAI Extension to cover that possibility. I grant that
> once the MN receives a Registration Reply, it will know what to do as
> long as it stays in the area serviced by the FA. However, this is
> Mobile IP, not Nomadic IP, so I expect the MN to move, often, and to
> face the exact same situation with the next FA it encounters.
>
>
> I guess no one wants to use another bit in the advertisement to
> indicate the type of AAA infrastructure in use. So is there some other
> way to provide a clue to the MN and still support backward
> compatibility and still conserve bandwidth?
>
>
> Bob
> I think the whole idea is to prevent this draft from mandating all
> Mobile Nodes to include
> ******************************************************************************************************
>
> Hello Ahmad,
>
> I'm still not totally comfortable with this new technique and its
> impact on bandwidth-constrained links.
>
> security association with the FA, and had to have a security
> association with the HA.
>
> For RFC3012, the MN could use the presence (or absence) of the
> Challenge to determine which
> But for this new I-D, the MN does not get any clue at all. Therefore
> it needs to include the extension
> As Tony pointed out, it seems that the MN must be configured to send
> or not to send - I'd rather the
> FA provided some clue.
>
> Bob
>

---

From: "Fredrik Johansson" <[email-masked]>
Date: Mon, 29 Apr 2002 09:23:29 +0200

Hi,

I agree that we need to be backward compatible, however as Tony points out,
I don't believe that we should put the complexity in the client. If the
client supports AAA NAI it will send it as stated in the draft today, it's
then up to the access network to decide what's needed, if the extensions are
not understood by the access network they are simply dropped and no harm is
done (except for a few extra bytes over the air). On the other hand, if the
extensions are required by the access network I agree with Tony that it
should be handled in the Diameter Mobile IPv4 application. My guess is that
"old" mobile ip clients can receive a limited set of the services provided,
e.g. only have a home agent assigned in the home network, etc. In this way,
this draft is not doing anything different than rfc3012

/Fredrik

>From: Tony Johansson [mailto:[email-masked]]
>Sent: den 27 april 2002 00:48
>To: Ahmad Muhanna; [email-masked]'
>Subject: Re: [mobile-ip] RE: A Question