Subject: RE: [Mip4] HoA=0.0.0.0 question

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Fri, 17 Jun 2005 04:22:17 -0700

Hi Kuntal.  

Further clarifications on NAI/home address assignment are covered in
draft-paulkandasamy-nai-based-home-address-01.txt.  We'll update that
soon.

I'm aware of the scenario that you've brought up.  Only the first RRQ is
authenticated by the AAA server, and subsequent Re-RRQ's are locally
authenticated by the HA (AAA authentication skipped).  The case you
brought up is covered in #7 in the draft, which states that the HoA in
the mobility binding is returned in the RRP.  But I think the issue is
not about address assignment but really authentication processing.
Since all NEW RRQs are suppose to go to the AAA server, the question
here is who's perspective of "NEW" - HA or MN?  In this case, HA thinks
this is not new since binding exists, but MN obviously thinks it is
sending a new RRQ.  My personal opinion is that since the network (AAA)
has already authenticated the MN before, there's no need to go to AAA
again since the same HoA (session) is still in effect.  The reason this
deployment knob (I call it) was to avoid overloading the AAA server for
the same session (even though MN-AAA AE is in the RRQ).

I agree with folks who said that there's no need to change any drafts
since this is more of an implementation issue.  The skipping of going to
AAA server is an implementation optimization.  This is a issue of that
type of operation.

Now, I'll go and read rest of thread ... :)

Kent

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Chowdhury, Kuntal
> Sent: Thursday, June 16, 2005 3:20 PM
> To: Charles E.Perkins; Avi Lior
> Cc: [email-masked]
> Subject: RE: [Mip4] HoA=0.0.0.0 question
> 
> Hi Charlie,
> 
> It is not my intent to delay anything. I just want to clarify 
> the HA behavior. IMHO, the HA implementations will behave 
> differently if it is not spelt out in any spec that HoA=0 
> should be treated as a new registration request.
> 
> Regards,
> Kuntal
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of 
> > Charles E.Perkins
> > Sent: Thursday, June 16, 2005 3:11 PM
> > To: Avi Lior
> > Cc: [email-masked]
> > Subject: Re: [Mip4] HoA=0.0.0.0 question
> > 
> > 
> > 
> > Hello Avi,
> > 
> > Avi Lior wrote:
> > 
> > > IMO therefore, MIP needs to be more explicit as to what
> > happens eventhough
> > > at the pure MIP context it may not make a difference.
> > 
> > If you want to propose some text, then maybe I would 
> understand what 
> > the problem is.  If it doesn't make any difference in the "pure MIP 
> > context", then I am reluctant to make any further 
> specification for it 
> > within the "pure MIP context" document.
> > 
> > > That is, we need to resolve Kuntal's original question in
> > the MIP context:
> > >  "when the HA receives a RRQ with HoA=0.0.0.0 does it 
> always treat 
> > > that as a NEW registration request even if there is an unexpired 
> > > mobility binding for the same NAI in the HA?"
> > 
> > As far as I can tell from the discussion, a competent 
> engineer could 
> > build an excellent system regardless of whether the registration 
> > request was considered "new" or not.
> > 
> > > We can either require the mobile to use an HoA when
> > re-registering or only
> > > use the NAI to index the binding cache.
> > 
> > Either of these solutions sound overly restrictive to me, of course 
> > depending on the restraints posed by the legacy systems involved.
> > 
> > Regards,
> > Charlie P.
> > 
> > --
> > Mip4 mailing list: [email-masked]
> >     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
> >      Charter page: 
> http://www.ietf.org/html.charters/mip4-charter.html
> > Supplemental site: http://www.mip4.org/
> > 
> 
> -- 
> Mip4 mailing list: [email-masked]
>     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>      Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/
> 

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Pete McCann <[email-masked]>
Date: Mon, 20 Jun 2005 09:31:22 -0500

Hi, Kent,

 > draft-paulkandasamy-nai-based-home-address-01.txt.  We'll update that

I think we agreed to merge the spec in draft-paulkandasamy into a
2794bis which you folks have agreed to edit.  Correct?