Subject: Re: [MOBILE-IP] [tsgp] Re: Comments on PN-4732 -- MN-AAA Extension and FAC Draft

From: Gopal Dommety <[email-masked]>
Date: Mon, 22 May 2000 18:45:28 -0700

Pat,

The reason I am concerned is that the optional MN-HA Authentication might work for DIAMETER
but might not work for RADIUS. In fact, I would appreciate if you could provide clarification as to how
it would work.

Thanks
Gopal

At 05:43 PM 22/05/00 -0700, [email-masked] wrote:
>I would seriously caution this group to make sure that Mobile behaviour is
>consistent regardless of the AAA protocol used. So, always assume that the
>MN-HA is NOT present when MN-AAA is present. The MN-HA MUST be present in the
>corresponding response.
>
>PatC
>>
>> >... and since the AAAH and the HA inherently trust each other, I don't see
>> the >problem. If the AAAH tells the HA "take this here packet and process
>> it. Trust >me, I've checked it, and you can make sure that I am the AAAH by
>> checking >these bits".
>>
>> The case we are looking at is with RADIUS SPI and RADIUS processing. In this
>> case the AAAH does not tell the HA anything. We are debating if having MN-HA
>> AE optional with MN_AAA with  RADIUS SPI
>>
>> Thanks
>> Gopal
>>
>>
>> >
>> >Let's remember that one of the main reasons for the AAA is to reduce the
>> >amount of administration that would otherwise be necessary on the HA, and
>> even >allow for HAs to be allocated within a Foreign Domain. Now how would a
>> Mobile >Node create a MN-HA, if: 1. The HA is unknown, and
>> >2. The MN has no long lived security association with the (potentially)
>> >unknown HA.
>> >
>> >>
>> >> 3.   The FAC draft does not specify what the PDSN has to do with the
>> MN-AAA >>      extension.  Some implementations may want to send the MN-AAA
>> to the AAA  >>      infrastructure and the MN-HA to the HA.
>> >Well, as I stated above, I see no need for both the MN-AAA and the MN-HA. By
>> >doing so, this eliminates all of the benefits of the MN-AAA, and the FAC
>> draft >as well. The FAC draft doesn't state what to do with the AAA data,
>> because >this is a AAA protocol thing, and has nothing to do with the FAC
>> draft. In >fact, an older version of the FAC and NAI draft had some
>> examples, which the >IESG requested that we remove for no real good reason
>> (as far as the >co-authors can see).
>> >
>> >
>> >>
>> >> 4.   We would like to reiterate the possibility that the AAA server may
>> not >>      have the key for HA authentication, especially in the case where
>> >>      the HA is outside the operator's network.
>> >
>> >And I would like to re-iterate, that one such AAA protocol actually defines
>> in >quite a bit of detail how the HA is allocated in a foreign network, and
>> even >what the payload looks like.
>> >
>> >Let us not forget that the MObile IP WG cannot document what the AAA
>> protocol >looks like, because this belongs to another WG. Therefore, we need
>> to also >look at the AAA protocol details.
>> >
>> >Hopefully this clarifies the issue.
>> >
>> >PatC
>> >>
>> >> Regards,
>> >> Anda Farcasanu and Dorothy Gellert
>> >>
>> >>
>> >> > X-Sender: [email-masked]
>> >> > Date: Mon, 22 May 2000 14:38:51 -0700
>> >> > To: [email-masked]
>> >> > From: Gopal Dommety <[email-masked]>
>> >> > Subject: [tsgp] Re: Comments on PN-4732 -- MN-AAA Extension and FAC
>> >Draft >> > Cc: [email-masked], [email-masked], [email-masked]
>> >> > Mime-Version: 1.0
>> >> > List-Unsubscribe: <mailto:[email-masked]>
>> >> >
>> >> > At 11:14 AM 22/05/00 -0700, Raymond Hsu wrote:
>> >> > >Hi Gopal:
>> >> > >
>> >> > >IS-835 has filled the blank in Section 6.3.4.  Basically, the HA
>> performs >> > >similarly to how PDSN handle MN-AAA authentication
>> information. >> > >Specifically, when the HA recevies the MN-AAA Extension,
>> the HA will >> > >communicate the MN-AAA authentication information to the
>> local RADIUS >> > >server in a RADIUS Access-Request.
>> >> >
>> >> > Couple of points:
>> >> >
>> >> > 1. Going a bit further in your line of thought (althoguh this is not
>> >> specified/mentioned).
>> >> > If the HA uses the authentication infrastructure and the registration
>> >fails
>> >> the
>> >> > authentication due to lifetime mismatch, how is the HA going to handel
>> >this
>> >> case.
>> >> >
>> >> > 2. You are assuming that the Local RADIUS to the HA has the Key, which
>> >might
>> >> not be true. In which
>> >> > case how will be handel it.
>> >> >
>> >> > 3. The FAC draft states that the MN-AAA can be removed then what
>> happens  >then?
>> >> >
>> >> > In my opinion the FAC draft is not clear when the MN-HA is optional.
>> And I  >> believe that
>> >> > statement has been in there with a different operational model than
>> what  >we
>> >> have in PN-4732.
>> >> >
>> >> >  MY REQUEST:
>> >> > It might be a good idea to remove the optionality of MN-HA in the
>> PN-4732  >> until we are clear on how it will work.
>> >> >
>> >> > Thanks
>> >> > Gopal
>> >> >
>> >> >
>> >> > >
>> >> > >Regards,
>> >> > >
>> >> > >Raymond
>> >> > >
>> >> > >At 11:04 AM 5/22/00 -0700, Gopal Dommety wrote:
>> >> > >>At 10:35 AM 22/05/00 -0700, Raymond Hsu wrote:
>> >> > >>>Hi Rajesh:
>> >> > >>>
>> >> > >>>According to the FAC draft, if MN-AAA Extension is included in the
>> >RRQ, the
>> >> > >>>MN-HA Authentication Extension is optional.  Since IS-835 has
>> required >> > >>>MN-AAA Extension already, this is why MN-HA Authentication
>> Extension is >> > >>>optional in IS-835, which is consistent with the FAC
>> draft. >> > >>
>> >> > >>FAC draft does not specify how the HA is supposed to authenticate if
>> >HA gets
>> >> > >>only the MN-AAA.
>> >> > >>
>> >> > >>Any thoughts on how this should be done?
>> >> > >>
>> >> > >>-Gopal
>> >> > >>
>> >> > >>
>> >> > >>>
>> >> > >>>Regards,
>> >> > >>>
>> >> > >>>Raymond
>> >> > >>>
>> >> > >>>At 12:04 AM 5/21/00 -0700, Rajesh Bhalla wrote:
>> >> > >>>>Ray, Mark, et al
>> >> > >>>>
>> >> > >>>>  I have a question related to the following text that has been
>> >added to
>> >> > >>>>  section 6.5.2.3.  (lines 8-9, page 33, clean-PDF version)
>> >> > >>>>  "The mobile station may include the MN-HA Authentication
>> Extension  >> > >>>>  [RFC 2002]."
>> >> > >>>>
>> >> > >>>>   The question is: MN-HA Authentication Extension is now optional
>> at >> > >>>>   the mobile; and if the mobile does not include the MN-HA
>> >Authentication
>> >> > >>>>   Extension, what should the mobile expect from the HA in the RRP
>> -   >> > >>>>   a MN-HA Authentication Extension or MN-AAA Extension ??
>> >> > >>>>
>> >> > >>>>  Both the FAC draft and IS-835 are quite on this for HA behaviour.
>> >> > >>>>
>> >> > >>>>  Do we need to add text to IS-835 to address this ambiguity !!
>> >> > >>>>
>> >> > >>>>Thanks
>> >> > >>>>Rajesh
>> >> > >>>>
>> >> > >>>>At 11:54 AM 5/9/00 -0700, Raymond Hsu wrote:
>> >> > >>>>>Mark:
>> >> > >>>>>
>> >> > >>>>>Adding new text to remove technical inconsistency should be OK,
>> >because
>> >> we
>> >> > >>>>>don't want our document to contradict itself.  One example is the
>> >> > >following:
>> >> > >>>>>
>> >> > >>>>>During the last meeting, we agreed in Section 6.5.2.3 to add the
>> >sentence
>> >> > >>>>>"The mobile station may include the MN-HA Authentication Extension
>> >[RFC >> > >>>>>2002]." (lines 8-9, page 33, clean-PDF version).  Because of
>> this >> > >>>>>agreement, the sentence stated on lines 14-16 needs to be
>> changed as  >> > >>follows:
>> >> > >>>>>
>> >> > >>>>>"If the MN-HA Authentication Extension is included in the MIP RRQ,
>> the >> > >>>>>mobile station shall compute the MN-HA Authentication
>> Extension,  >> according
>> >> > >>>>>to [RFC 2002], based on the shared secret the mobile station has
>> >with the
>> >> > >>>HA."
>> >> > >>>>>
>> >> > >>>>>The new text is the beginning clause, and the rest of the sentence
>> is  >> same
>> >> > >>>>>as before.  This new text is necessary, because without it the
>> >sentence
>> >> on
>> >> > >>>>>lines 14-16 contradicts the sentence on lines 8-9 in Section
>> 6.5.2.3. >> > >>>>>
>> >> > >>>>>Thanks,
>> >> > >>>>>
>> >> > >>>>>Raymond
>> >> > >>>>>
>> >> > >>>>>At 02:19 PM 5/9/00 -0400, Munson, Mark A. wrote:
>> >> > >>>>>>Ray,
>> >> > >>>>>>
>> >> > >>>>>>Inasmuch as the document was approved by the committee at the end
>> >of the >> > >>>>>>meeting, I don't plan to spend more meeting time
>> reviewing editorial >> > >>>>>>corrections - the editor and I will just put
>> them in before we  >send it
>> >> in
>> >> > >>>>>>for publication.  If I am not comfortable that the change is
>> >editorial,
>> >> > >>then
>> >> > >>>>>>it won't get in.  Cleaning up things in the accounting tables
>> such  >as
>> >> > >>making
>> >> > >>>>>>sure the values are consistent and defined is editorial.  Adding
>> new  >> text
>> >> > >>>>>>isn't.  Let me point out that this isn't like a last call
>> process.  > As
>> >> for
>> >> > >>>>>>when it gets submitted - that's a problem with the FAC as you
>> >pointed
>> >> out.
>> >> > >>>>>>I still haven't heard from Tom/Pete on its status.
>> >> > >>>>>>
>> >> > >>>>>>Regards,
>> >> > >>>>>>Mark
>> >> > >>>>>>
>> >> > >>>>>>> ----------
>> >> > >>>>>>> From:   Raymond Hsu[SMTP:[email-masked]]
>> >> > >>>>>>> Reply To:       Raymond Hsu
>> >> > >>>>>>> Sent:   Tuesday, May 09, 2000 1:38 PM
>> >> > >>>>>>> To:     [email-masked]
>> >> > >>>>>>> Subject:        [tsgp] Re: Conference Call Tomorrow -- Comments on
>> >> PN-4732
>> >> > >>>>>>>
>> >> > >>>>>>> Hi:
>> >> > >>>>>>>
>> >> > >>>>>>> My notes show that tomorrow's conference call is to resolve
>> ballot >> > >>>>>>> comments
>> >> > >>>>>>> on PN-4286-A, not PN-4732.
>> >> > >>>>>>>
>> >> > >>>>>>> Since our last face-to-face meeting, there were several e-mails
>> >> > >>requesting >> > >>>>>>> editorial changes for PN-4732.  What is the
>> status of these >> > >requests?  Do
>> >> > >>>>>>> we need a separate conference call to review these editorial
>> >> > >comments?  I
>> >> > >>>>>>> like to re-emphasize that we should not accept anymore
>> technical  >> ballot
>> >> > >>>>>>> comments for PN-4732 at this point; however, we should flush
>> out  >> > >>editorial
>> >> > >>>>>>> inconsistency and mistakes from PN-4732.
>> >> > >>>>>>>
>> >> > >>>>>>> Regards,
>> >> > >>>>>>>
>> >> > >>>>>>> Raymond
>> >> > >>>>>>>
>> >> > >>>>>>> At 10:10 AM 5/9/00 -0700, Rajesh Bhalla wrote:
>> >> > >>>>>>> >Content-Type: text/plain; charset="us-ascii"
>> >> > >>>>>>> >X-MIME-Autoconverted: from 8bit to quoted-printable by
>> >> > >>>>>>> >sj-msg-core-2.cisco.com id KAA00480
>> >> > >>>>>>> >
>> >> > >>>>>>> >Hello All,
>> >> > >>>>>>> >
>> >> > >>>>>>> >  From further implementation experience, we stumbled on
>> another  >> 'typo'
>> >> > >>>>>>> in
>> >> > >>>>>>> >  PN-4732. The typo results in a conflict in the assignment of
>> >the  >> > >>'Type'
>> >> > >>>>>>> value
>> >> > >>>>>>> >
>> >> > >>>>>>> >  to one of the Airlink Record Specific Parameters in the
>> >horizontal
>> >> > >>>>>>> Table-5
>> >> > >>>>>>> >  in Section 9.4. This typo is in addition to two other
>> >comments that
>> >> I
>> >> > >>>>>>> had
>> >> > >>>>>>> >  forwarded to the group earlier on May 2nd.
>> >> > >>>>>>> >
>> >> > >>>>>>> >  Below is the consolidated list of the THREE comments with the
>> >> > >request  >> > >>>>>>> >  that these be addressed at the upcoming
>> conference call  >tomorrow.
>> >> > >>>>>>> >
>> >> > >>>>>>> >  1.  'y1  Airlink Record Type' has been assigned a value of
>> >'26/40'.
>> >> > >>>>>>> Value
>> >> > >>>>>>> >'26/40'
>> >> > >>>>>>> >     is already used for parameter 'C2  Correlation ID'. The
>> >> > >proposal is
>> >> > >>>>>>> to
>> >> > >>>>>>> >assign
>> >> > >>>>>>> >     value of '26/44'(or some other non-conflicting value) to
>> the >> > >>>>>>> parameter
>> >> > >>>>>>> >'y1'.
>> >> > >>>>>>> >
>> >> > >>>>>>> >  2.  The second comment relates to some typos regards the
>> 'y1'  >type
>> >> > >>>>>>> airlink
>> >> > >>>>>>> >      parameters. Table 5, section 9.4  specifies the
>> enumerated >> > >values
>> >> > >>>>>>> >      for various airlink events as:
>> >> > >>>>>>> >
>> >> > >>>>>>> >          y1=  1 (Connection Setup)
>> >> > >>>>>>> >          y1= 2 (Active Start)
>> >> > >>>>>>> >          y1= 3 (Active Stop)
>> >> > >>>>>>> >          y1= 4 (SDB Record)
>> >> > >>>>>>> >
>> >> > >>>>>>> >        We need to modify the Airlink Record Types in the
>> >tables in
>> >> > >>>>>>> sections
>> >> > >>>>>>> >        9.2.2, 9.2.3 and 9.2.4 also to account for the removal
>> >of   >> the
>> >> > >>>>>>> >Connection
>> >> > >>>>>>> >        Release type airlink record.
>> >> > >>>>>>> >
>> >> > >>>>>>> >   3. The third comment relates to the need for address some
>> >details
>> >> on
>> >> > >>>>>>> >       the SDB Airlink Record. Attached is a proposal that
>> >contains
>> >> two
>> >> > >>>>>>> options
>> >> > >>>>>>> >
>> >> > >>>>>>> >       for addressing the changes. Though two options are
>> >included,
>> >> we
>> >> > >>>>>>> prefer
>> >> > >>>>>>> >       Option-1 as it uses fewer airlink parameters..
>> >> > >>>>>>> >
>> >> > >>>>>>> >    Again, we would appreciate that these comments be
>> addressed  >at
>> >> the
>> >> > >>>>>>> >    conference call tomorrow.
>> >> > >>>>>>> >
>> >> > >>>>>>> >Thanks
>> >> > >>>>>>> >Rajesh Bhalla
>> >> > >>>>>>> >Cisco Systems Inc.
>> >> > >>>>>>> >
>> >> > >>>>>>> >
>> >> > >>>>>>> >
>> >> > >>>>>>>
>> >> > >>>>>>>
>> >> > >>>>>>> ---
>> >> > >>>>>>> You are currently subscribed to tsgp as:
>> [email-masked] >> > >>>>>>>
>> >> > >>>>>>
>> >> > >>>>>>---
>> >> > >>>>>>You are currently subscribed to tsgp as: [email-masked]
>> >> > >>>>>>
>> >> > >>>>>
>> >> > >>>>>
>> >> > >>>>>---
>> >> > >>>>>You are currently subscribed to tsgp as: [email-masked]
>> >> > >>>>>
>> >> > >>>>
>> >> > >>>>
>> >> > >>>>---
>> >> > >>>>You are currently subscribed to tsgp as: [email-masked]
>> >> > >>>>
>> >> > >>>
>> >> > >>>
>> >> > >>>---
>> >> > >>>You are currently subscribed to tsgp as: [email-masked]
>> >> > >>>
>> >> > >>>
>> >> > >>
>> >> > >>
>> >> > >>---
>> >> > >>You are currently subscribed to tsgp as: [email-masked]
>> >> > >>
>> >> > >
>> >> > >
>> >> > >---
>> >> > >You are currently subscribed to tsgp as: [email-masked]
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >> > ---
>> >> > You are currently subscribed to tsgp as: [email-masked]
>> >>
>> >>
>> >> ---
>> >> You are currently subscribed to tsgp as: [email-masked]
>> >>
>> >
>> >
>> >
>> >---
>> >You are currently subscribed to tsgp as: [email-masked]
>> >
>> >
>>
>
>
>
>---
>You are currently subscribed to tsgp as: [email-masked]
>
>

---

From: Glen Zorn <[email-masked]>
Date: Wed, 24 May 2000 14:18:11 -0700

Gopal Dommety [mailto://[email-masked]] writes:

> but might not work for RADIUS.

RADIUS is dead.

> In fact, I would appreciate if you
> could provide clarification as to how
> it would work.
>
> Thanks
> Gopal
>
>
>

---

From: David Mitton <[email-masked]>
Date: Thu, 25 May 2000 09:49:51 -0400

> > but might not work for RADIUS.

         It's not dead yet. <sorry couldn't resist>

In fact several "new" RADIUS RFCs should emerge from the Editor's queue any
day now.  (they are only several years old)

...which says something sorry about this process.  While it's sometimes
suggested that RADIUS be advanced to "Historic", RADIUS will not be dead
until something _else_ prys it out of the ISPs fingers.
At the moment, I'm not aware of a commercial Diameter server.

Now that I've sent a message to this list, I have a question being new here;
         Has anyone written a draft on supporting Mobile-IP with RADIUS??
I have several non-ID proposals on the subject, but I haven't seen a
public, practices documents.

         Dave.

---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
Carrier Packet Solutions, IP Mobility         978-288-3030 FAX
Billerica, MA 01821                    [email-masked]