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

From: "Ahmad Muhanna"<[email-masked]>
Date: Mon, 22 Apr 2002 16:37:52 -0500

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: Tue, 23 Apr 2002 17:48:21 -0500

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; 

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. 

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

---

From: "Fredrik Johansson" <[email-masked]>
Date: Wed, 24 Apr 2002 11:37:17 +0200

MessageBob,
  -----Original Message-----
  From: Robert J Marks [mailto:[email-masked]]
  Sent: den 24 april 2002 00:48
  To: 'Ahmad Muhanna'; '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 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.
  [->]
  Well, since the extensions are received in the registration reply, the MN should
send them in registration requests. However, it's only necessary to send them when
it's probable that the FA need to go through the AAA mechanism to authenticate.
I.e. there is no need to send them when just doing a tunnel update, but when ,for
example, requesting new session keys or when changing point of attachment it has
to send the nai extensions.

  Is this good enough to not waste to much on bandwidth constrained links?

  /Fredrik

  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;

  for example:

  Regards;
  Ahmad Muhanna