Subject: RE: [Mip4] HoA=0.0.0.0 question

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 17 Jun 2005 10:21:03 -0400

Okay...what I sense is that the description of the HoA=0.0.0.0 behavior for an existing MIP binding does not belong in MIP and it also does not belong in AAA. But, all I know is that new registration vs. re-registration determination has significant practical deployment implication. I am wondering whether such a thing should be defined or left open for interpretation.

BTW, I thought MIP4 WG was chartered to take care of Mobile IPv4 deployment issues!

"
Besides the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns such as optimization, security, extensions, AAA support, and deployment issues.
"

-Kuntal

> -----Original Message-----
> From: Kent Leung (kleung) [mailto:[email-masked]]
> Sent: Friday, June 17, 2005 6:22 AM
> To: Chowdhury, Kuntal; Charles E.Perkins; Avi Lior
> Cc: [email-masked]
> Subject: RE: [Mip4] HoA=0.0.0.0 question
> 
> 
> 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: "Charles E. Perkins" <[email-masked]>
Date: Sun, 19 Jun 2005 09:11:45 -0700

Hello Kuntal,

Chowdhury, Kuntal wrote:

 >Okay...what I sense is that the description of the HoA=0.0.0.0 
behavior for an existing
 > MIP binding does not belong in MIP and it also does not belong in 
AAA. But, all I know
 > is that new registration vs. re-registration determination has 
significant practical
 > deployment implication. I am wondering whether such a thing should be 
defined or left
 > open for interpretation.

It depends on whether one vendor's HA should need to work with another
vendor's AAA box(es).

 >BTW, I thought MIP4 WG was chartered to take care of Mobile IPv4 
deployment issues!

I guess this was meant to be provocative.

Of course, it is chartered for that reason.  I do not think the 
specification you
seelk belongs in the base specification.  I didn't say the work would be
incompatible with [mip4] working group.  That would be up to the working
group to say.  I could see the decision going either way.

Regards,
Charlie P.