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 09:44:22 -0500

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
 
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ahmad Muhanna
Sent: Monday, April 22, 2002 3:38 PM
To: 'Tony Johansson'; [email-masked]
Cc: 'Fredrik Johansson'; [email-masked];
[email-masked]
Subject: RE: [mobile-ip] RE: A Question
about:draft-ietf-mobileip-aaa-nai-00.txt

Hi Bob; 
Let me add to what Tony just said. 
I do not think that any MN needs to know anything about the type 
of AAA infrastructure the FA and HA are using to authenticate the MN. 
However, the MN Application is developed with certain standard in mind. 
(certain method of authentication) 
for example: 
1. ONLY RFC2002 Compliant MN: 
It assumes that it has a security association with both the FA and the 
HA. If it visit any FA where it shares a security association with, MN sends

RRQ message with MN-FA Authentication extension and it works just fine. 
2. ONLY RFC2002 & RFC3012 Compliant MN: 
RFC 3012 addressed properly the case of MN in 1 but offered a new 
mechanism for authenticating the MN to the FA using the FA Challenge 
and MN-AAA authentication extension. 
3. Now Latest MN with all of the above (RFC3220) and diameter compliant: 
MN includes AAA NAI extension and those FA which support diameter 
will use process it and those FA which does not support AAA NAI (skippable) 
will continue to use either method in 2 or 1. 

Regards; 
Ahmad Muhanna 

> -----Original Message----- 
> From: Tony Johansson [mailto:[email-masked]] 
> Sent: Monday, April 22, 2002 4:15 PM 
> To: [email-masked] 
> Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Fredrik Johansson'; 
> [email-masked]; [email-masked] 
> Subject: Re: [mobile-ip] RE: A Question 
> about:draft-ietf-mobileip-aaa-nai-00.txt 
> 
> 
> Hi Bob, 
> 
> Yes, it's based on MN configuration and FA configuration. Same as e.g 
> the handling of RFC3012/RFC3012bis and the 
> draft-ietf-mobileip-aaa-key-09.txt. 
> 
> The advertisements will not tell you anything reading this. 
> 
> /Tony 
> 
> Robert J Marks wrote: 
> 
> >  Perhaps someone can explain how the MN knows the type of AAA 
> > infrastructure used by the FA nd HA. I don't believe any information 
> > is included in any advertisement. Does this "solution" rely 
> only upon 
> > MN configuration, or am I missing something here? Thanks.Bob 
> > -----Original Message----- 
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Ahmad 
> > Muhanna 
> > Sent: Monday, April 22, 2002 1:59 PM 
> > To: 'Tony Johansson' 
> > Cc: 'Fredrik Johansson'; [email-masked]; 
> > [email-masked] 
> > Subject: RE: [mobile-ip] RE: A Question 
> > about:draft-ietf-mobileip-aaa-nai-00.txt 
> > 
> > Hello Tony; 
> > YES; this solves the problem. 
> > 
> > Regards; 
> > Ahmad Muhanna 
> > 
> > > -----Original Message----- 
> > > From: Tony Johansson [mailto:[email-masked]] 
> > > Sent: Monday, April 22, 2002 2:51 PM 
> > > To: Muhanna, Ahmad [RICH1:2Q20:EXCH] 
> > > Cc: 'Fredrik Johansson'; [email-masked]; 
> > > [email-masked] 
> > > Subject: Re: [mobile-ip] RE: A Question 
> > > about:draft-ietf-mobileip-aaa-nai-00.txt 
> > > 
> > > 
> > > Hello Ahmad, 
> > > 
> > > Ahmad Muhanna wrote: 
> > > 
> > > 
> > > > I do not think that It is the same!! 
> > > > RFC3012 introduced a new way of authenticating the MN to the FA 
> > > > without violating 
> > > > backward compatibility of RFC2002 or later RFC3220. 
> > > > Mobile Node does not know which way or the standard the 
> > > foreign agent 
> > > > uses to 
> > > > authenticate it. It could be through RADIUS, AAA, Diameter 
> > > who knows. 
> > > 
> > > > 
> > > > The point here is that this draft mandates that every 
> Mobile Node 
> > > > include AAA NAI extension 
> > > > with subtype of 1 whenever it requests static Mobile IP 
> or during 
> > > > Inter-FA handoff. 
> > > > Now: (Standard Compliant RFC3220, RFC3012bis) Legacy Mobile 
> > > Node which 
> > > > exist right now, 
> > > > does not do this. 
> > > > After this draft becomes a standard, according to this 
> > > section, MN is 
> > > > not following the 
> > > > standard by not sending AAA NAI extension in initial 
> Registration 
> > > > Request or during re-authentication.!!! 
> > > > 
> > > > This is not backward compatible!!!! 
> > > 
> > > Okay, so how about adding the following statement to the 
> > introduction: 
> > > 
> > > "The AAA NAI extension MUST only be used with the Diameter Mobile 
> > IPv4 
> > > application and MUST NOT be used with any other AAA protocol." 
> > > 
> > > 
> > > 
> > > /Tony 
> > > 
> > > 
> > > 
> 
>

---

From: "Robert J Marks" <[email-masked]>
Date: Fri, 26 Apr 2002 12:45:31 -0500

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

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.

Tony/Bob, 

section 4. should read: 
" 

section 5. should read: 
" 

   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. 

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

Hello Ahmad, 
  
I'm still not totally comfortable with this new technique and its impact
on bandwidth-constrained links. 

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 
  
-----Original Message----- 

Hi Bob; 
HA. If it visit any FA where it shares a security association with, MN
sends 

MN includes AAA NAI extension and those FA which support diameter 
will use process it and those FA which does not support AAA NAI
(skippable) 
will continue to use either method in 2 or 1. 

Regards; 
Ahmad Muhanna