Subject: RE: [Mip4] HoA=0.0.0.0 question

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 16 Jun 2005 18:19:58 -0400

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/

---

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

"draft-paulkandasamy-nai-based-home-address-01.txt" does not exist for me to look at.

-Kuntal

> 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
> 
> > 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
> > 
> > > From: [email-masked] 
> > [mailto:[email-masked]]On Behalf Of 
> > > Charles E.Perkins
> > 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.
> > > 
> > > >  "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?"
> > > 
> > engineer could 
> > > build an excellent system regardless of whether the registration 
> > > request was considered "new" or not.
> > > 
> > > Either of these solutions sound overly restrictive to me, 
> of course 
> > > depending on the restraints posed by the legacy systems involved.
> > > 
> > > Regards,
> > > Charlie P.
> > > 
> > > --
> > >      Charter page: 
> > http://www.ietf.org/html.charters/mip4-charter.html
> >      Charter page: 
http://www.ietf.org/html.charters/mip4-charter.html

---

From: Avi Lior <[email-masked]>
Date: Sat, 18 Jun 2005 01:21:54 -0400

Hi Henrik,

See comments inline.  Also perhaps the scenario I presented in another email
will help.

> From: Henrik Levkowetz [mailto:[email-masked]] 
> Sent: Thursday, June 16, 2005 4:51 PM
> To: Avi Lior
> Cc: 'Charles E. Perkins'; Chowdhury, Kuntal; [email-masked]
> Hi Avi,
> On 2005-06-16 21:34 Avi Lior said the following:
> > Hi Charlie,
> > 
> > Actually I am not sure it's a AAA problem either.  The original 
> > scenario Kuntal raises can happen with or without the presence of a 
> > AAA function right?
> > 
> > The side-effect (Kuntal's explaination) is what can happen 
> with a AAA.
> > 
> > IMO therefore, MIP needs to be more explicit as to what happens 
> > eventhough at the pure MIP context it may not make a difference.
> 
> I think here we're at the crux of the matter: Not only 
> doesn't it make a difference, there really isn't a difference 
> at the MIP level, I believe.

Well its not clear to me that this is the case. Unless I missed something
the scenario I presented does show that there is an issue with MIP protocol.
A tighter protocol would solve the problem.

Again if I am correct MIP group could say that this is a corner case and we
don't care.  But that is a different matter entirely.

> > 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 
> Well, since there really isn't any difference between 
> "re-registration" and "new registration" in MIP4, there 
> really isn't a distinction, protocol-wise...

But as you can see (again look at the scenario I presented) there is a real
world difference.

> re-registering or 
> > only use the NAI to index the binding cache.
> 
> This seems to argue for creating a distinction, based on the 
> value of the HoA field, between some "new registrations" and 
> other "re-registrations".

So I actually now belive that the HOA could solve the problem but only in
certain cases, that is, when the Home Network is setting the IP address.
 
> I'm not convinced that this is wise, and I'm not convinced it 
> is necessary.
> 
> Possibly it could be argued that it would be advantageous to 
> add to the specification that:
> 
> "If there exists an active binding for the MN when a 
> registration request with the Home Address field set to 
> 0.0.0.0 is received by the HA, the HA SHOULD return the same 
> Home Address as for the already existing binding."

That helps in one particular case. As well, it may be helpful to also state
that during re-registration a mobile node MUST set the HOA address to the
one assigned during the initial registration and during registration
revocation.  But that may already be stated.
 
> But that is maybe a different matter ?
> 
> (As some background to this discussion, I coded the HA side 
> of dynamic address assignment some 2-3 years ago.  I found 
> that since the HA can never know whether the MN has been 
> turned on and off between registrations, and the MN really 
> can't assume that the HA hasn't had a power outage, 
> malfunction, or what-not, it turned out that you really have 
> to find a way to handle a lot of different combinations of 
> existing and non-existing active bindings, 0.0.0.0 requests, 
> and requests with old, timed-out HoAs.
> 
> Any attempt at specifying that the MN "must" use an assigned 
> HoA when "re-registering" ran smack into the realities of 
> things which said that there were no way of guaranteeing that 
> behaviour, in the face of everything that might happen with 
> the MN, the HA, and the link between them ...
> 
> Or to put it in a completely different way - the randomness 
> and unpredictability of changing wireless links makes it a 
> strong protocol feature that there indeed is no difference 
> between "new registration" and
> "re-registration".)

Well, I think a tighter specification can help in this situation.  For
example, if we had explicit commands for Registration, Re-registration, hen
I don't see how that would have hurt.  It at least helps reduce the
guesswork at the HA as to the state of the MN.
 
> 	Henrik
> >> From: Charles E. Perkins [mailto:[email-masked]]
> >> Sent: Thursday, June 16, 2005 1:31 PM
> >> To: Chowdhury, Kuntal
> >> Cc: [email-masked]
> >> Hello Kuntal,
> >> Based on your example, I do not believe that the distinction
> >> would case any change to the base Mobile IPv4 specification. 
> >> Would this be a new document within the aaa working group?
> >> 
> >> Regards,
> >> Charlie P.
> 
>

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Mon, 20 Jun 2005 14:41:35 -0700

Hi Pete.  Yes, we're working on that.

Kent

> From: Pete McCann [mailto:[email-masked]] 
> Sent: Monday, June 20, 2005 7:31 AM
> To: Kent Leung (kleung)
> Cc: Chowdhury, Kuntal; Charles E.Perkins; Avi Lior; [email-masked]
> Hi, Kent,
> Kent Leung \(kleung\) writes:
>  > 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 think we agreed to merge the spec in draft-paulkandasamy 
> into a 2794bis which you folks have agreed to edit.  Correct?
>

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Mon, 20 Jun 2005 22:57:54 -0700

Thanks Avi for clarifying the billing context.

Pete's issue about trusting the MN for billing comes to my mind as well.

I see the following implications of HoA = 0 in RRQ:

1) Address assignment
	HoA is set to address in existing binding, IMHO

2) Authentication
	HA may or may not go to AAA for authentication.  Pros and cons
of each method.  Maybe up to operator to decide.  No interoperability
issue between HA and AAA server either way.

3) Accounting
	HA generate AAA accounting record which includes the HoA=0
value.  One possible solution is to calculate the time difference
between this RRQ and last time traffic was accounted for this MN.  The
reason is that charging is based on usage, which is indicated by traffic
to/from MN, independent of registration timers.

Note that I would still set HoA=0 for every RRQ on the MN to save some $
for time-based billing.  :)  

So maybe a better scheme to deal with this is using RFC 3543?  When MN
is truly disconnected, FA sends revocation to the HA to remove the
binding.  Then it's always clear when there is a NEW session since old
bindings don't hang around long.

Kent 

> Behalf Of Pete McCann
> Sent: Monday, June 20, 2005 7:36 AM
> To: Avi Lior
> Cc: [email-masked]; Chowdhury, Kuntal; Henrik Levkowetz; 
> Charles E.Perkins
> Avi,
> One comment below:
> Avi Lior writes:
>  > Charlie and All,
>  > Here is an example of the problem (as I understand it) 
> Kuntal or others may  > correct me or add to this.
>  >
>  > Consider the case where customers are billed based on time.
>  >
>  > Now consider what happens when a mobile deregisters but 
> the  deregistration  > is lost; the binding cache in the HA 
> will become stale.  In order not to  > overbill the user, the 
> HA -- everytime a binding update goes stale could  > then 
> attempt to determine when the session actually terminated by 
> looking at  > other indicators to determine the last activity 
> time.  Note this operation  > is expensive but it is 
> important for accurate billing of customers and hence  > 
> important to operators.
>  >
>  > If however, the same mobile preforms a new registration 
> before the lifetime  > of the previous registration expires, 
> then the HA will see this new  > registration as a 
> re-registration.  The HA will then NOT attempt to  > 
> re-compute the real session time and the user will be billed 
> for that time.
>  >
>  > In some environments such as wirelss this could happen 
> relatively frequently  > and operators are concerned about 
> these issues and want to make sure that  > they do everything 
> possible to bill appropriately.
>  >
>  > One solution to this problem is as Kuntal suggested.  In 
> his particular case  > where the HOA is allocated by the home 
> network then if the mobile always  > sends an HOA with 
> 0.0.0.0 in new registration then we can then deferentiate  > 
> between new registration and a re-registration.
>  >
>  > However, when the MN is assigned a static HOA then that 
> "hint" is no longer  > available. We need something else.  
> What that something else is I am not  > sure.  But it seems 
> to me that we should have explicitly indicated whether a  > 
> registration is a new registration or a re-registration. This 
> would make the  > protcol more robust.
> 
> Let's say we add a flag to indicate a "new registration" and 
> then users won't be billed for time between the last 
> registration and a "new registration".  What is to prevent me 
> from setting this flag in every single registration?  Let's 
> say the MN is set up to be a seldom-used server so you can't 
> really tell from traffic flow whether the MN is still out 
> there listening.  Then I won't be billed for any time at all, 
> but the MN is still available to receive packets from the HA 
> at any time.
> 
> I think we do need a more detailed case analysis of the 
> address assignment implications when the HoA = 0.0.0.0 and 
> this should be in a
> 2794 bis document.  This is planned to be completed by the 
> working group.  However, we need to consider carefully 
> whether this kind of a billing requirement needs to be addressed.
> 
>  > Another solution is to reduce the lifetime of a 
> registration.  This may be  > workable in fixed wireline 
> mobile ip application but it is not a good idea  > for 
> wireless mobile ip applications due to the expensive over the 
> air  > resources.
> 
> As long as there is a binding in the HA the MN is getting 
> some kind of service from the HA (the HA is available to 
> forward packets).
> 
> -Pete
> 
>  > Perhaps I should ask this question from those who know 
> this subject far  > better than me, is there a reliable way 
> for the HA to reliably deferentiate  > between a 
> Re-registration, a new Re-gistration?
>  >
>  > > From: Charles E.Perkins [mailto:[email-masked]] 
>  > > Sent: Thursday, June 16, 2005 6:43 PM  > > To: 
> Chowdhury, Kuntal  > > Cc: [email-masked]; Henrik Levkowetz  > 
> > Subject: Re: [Mip4] HoA=0.0.0.0 question  > >  > >  > >  > 
> > Hello Kuntal,  > >  > > "Chowdhury, Kuntal" wrote:
>  > >
>  > > > What I understand from your responses is that HoA=0 
> should  > > be treated  > > > by the HA as a new registration 
> request (since an HoA assignment is  > > > involved here). Is 
> this a correct understanding?
>  > >
>  > > I'd rather not modify the specification about how the  > 
> > home agent might distinguish this as a new Request.
>  > > Just from memory, without perusing the document,  > > I 
> believe that the concept of "new registration"
>  > > in the base specification is tied closely to the  > > 
> use of the same "Identification" field within the  > > 
> Registration Request, and I would not want to disturb  > > 
> the meaning of that term.
>  > >
>  > > Moreover, I don't yet fully understand the need, even  > 
> > in the context of AAA protocols.
>  > >
>  > > Regards,
>  > > Charlie P.
>  > >
>  > > --
>  > > Supplemental site: http://www.mip4.org/  > >  >  > --  >

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 21 Jun 2005 11:21:32 -0400

> bindings don't hang around long.

As always, there are holes in every proposal. What if the revocation message is lost (never reached the HA)? 

> for time-based billing.  :)  

Yes, you can...but if you do that you run the risk of getting a different address (HoA) every time you send an RRQ. This is because, the HAs may treat the HoA=0 as a new registration, therefore tear down the old binding and admit a new binding and assign a new HoA. This may break your applications/sessions. To save a few cents you will cause yourself more pain in that case. Besides, it does not take too much time for the operators to figure out revenue leaks.

Ideally, what MIP4 WG should do, IMHO:

a. Define a reliable way to distinguish registrations from re-registrations.
b. Define a reliable way to distinguish registrations from retransmitted registrations when Timestamp based ID is used. (In some situations, the network nodes (FA, HA, AAA) get pounded due to too frequent retransmissions of RRQs.

-Kuntal

> Sent: Tuesday, June 21, 2005 12:58 AM
> To: Pete McCann; Avi Lior
> Cc: [email-masked]; Chowdhury, Kuntal; Henrik Levkowetz; Charles
> E.Perkins

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Tue, 21 Jun 2005 09:12:15 -0700

> From: Chowdhury, Kuntal [mailto:[email-masked]] 
> Sent: Tuesday, June 21, 2005 8:22 AM
> To: Kent Leung (kleung); Pete McCann; Avi Lior
> Cc: [email-masked]; Henrik Levkowetz; Charles E.Perkins
> As always, there are holes in every proposal. What if the 
> revocation message is lost (never reached the HA)? 
> 

The messages support ack/retransmissions.

> > Note that I would still set HoA=0 for every RRQ on the MN 
> to save some 
> > $ for time-based billing.  :)
> 
> Yes, you can...but if you do that you run the risk of getting 
> a different address (HoA) every time you send an RRQ. This is 
> because, the HAs may treat the HoA=0 as a new registration, 
> therefore tear down the old binding and admit a new binding 
> and assign a new HoA. This may break your 
> applications/sessions. To save a few cents you will cause 
> yourself more pain in that case. Besides, it does not take 
> too much time for the operators to figure out revenue leaks.
> 

But since the MN knows the reg lifetime, it can send RRQ with HoA=0
before expiration so the chance is good that mobility binding exists if
HA is functioning properly.  And HA has to consider the case when MN
moves to a black-out area and provide the same HoA to MN whenever
possible - the benefits of same HoA.

Kent

> b. Define a reliable way to distinguish registrations from 
> retransmitted registrations when Timestamp based ID is used. 
> (In some situations, the network nodes (FA, HA, AAA) get 
> pounded due to too frequent retransmissions of RRQs.
> 
> -Kuntal
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 22 Jun 2005 02:00:31 -0400

Hello Charlie,

"Chowdhury, Kuntal" wrote:

>> IMHO, HAs can assign the same HoA to the MN even if the HAs don't do
>> address management via DHCP. The idea of posting the question in the 
>> first place was to clarify the behavior with MIP4 experts. After past 
>> few days discussion, I think I got my answer: i.e. leave it upto the 
>> implementation.

> I didn't exactly see anyone else make that statement.

You probably missed what Kent said. At least he clearly said it is
implementation specific:

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

Regards,
Ahmad

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Tue, 21 Jun 2005 23:49:52 -0700

Hi Ahmad.
 
I would like to clarify the context of my statement quoted below.  It
was in response to the example given for differentiating new and
re-registrations was:
"Based on local policy the HA may have to process a new RRQ differently
than a re-registration. For example, the local policy may not require
the HA to perform AAA auth (i.e. process MN-AAA) every time the MN
performs re-registration ..."

There are _no_ standards specification on this authentication
optimization.  It is an implementation policy that exists today.
Standards specifies that MN-AAA AE is authenticated by the AAA server,
not subjectively ignored.  But I don't have any problem with this method
since it's a usage policy that's interoperable between HA and AAA using
standards mapping of RRQ fields to RADIUS AVPs.  So what triggers RADIUS
messages can remain a user's knob, ranging from each registration to
only when new binding is created, with steps in between.
 
Anyways, I agree with Charlie that the WG is always open to ideas on
solving practical problems.  Don't let a few comments dissuade you from
writing an I-D to clarify the issues and potential solution.  Maybe some
of us are missing a few pieces of info (Avi's accounting perspective was
good input).  Henrik and Pete provided some good feedbacks which can
generate some explanatory text in the doc.  
 
Kent

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ahmad Muhanna
	Sent: Tuesday, June 21, 2005 11:01 PM
	To: 'Charles E.Perkins'; 'Chowdhury, Kuntal'
	Cc: [email-masked]'; Ahmad Muhanna
	Subject: RE: [Mip4] HoA=0.0.0.0 question

	Hello Charlie, 

	> I didn't exactly see anyone else make that statement. 

	You probably missed what Kent said. At least he clearly said it
is implementation specific: 

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

	Regards, 
	Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 22 Jun 2005 03:14:08 -0400

Thanks Kent for the clarification.
 
I thought that was the context of Kuntal's initial question.

Regards, 
Ahmad 

-----Original Message-----
From: Kent Leung (kleung) [mailto:[email-masked]] 
Sent: Wednesday, June 22, 2005 1:50 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; Charles E.Perkins; Chowdhury, Kuntal
Cc: [email-masked]
Subject: RE: [Mip4] HoA=0.0.0.0 question

Hi Ahmad.
 
I would like to clarify the context of my statement quoted below.  It was in
response to the example given for differentiating new and re-registrations
was:
"Based on local policy the HA may have to process a new RRQ differently than
a re-registration. For example, the local policy may not require the HA to
perform AAA auth (i.e. process MN-AAA) every time the MN performs
re-registration ..."

There are _no_ standards specification on this authentication optimization.
It is an implementation policy that exists today.  Standards specifies that
MN-AAA AE is authenticated by the AAA server, not subjectively ignored.  But
I don't have any problem with this method since it's a usage policy that's
interoperable between HA and AAA using standards mapping of RRQ fields to
RADIUS AVPs.  So what triggers RADIUS messages can remain a user's knob,
ranging from each registration to only when new binding is created, with
steps in between.
 
Anyways, I agree with Charlie that the WG is always open to ideas on solving
practical problems.  Don't let a few comments dissuade you from writing an
I-D to clarify the issues and potential solution.  Maybe some of us are
missing a few pieces of info (Avi's accounting perspective was good input).
Henrik and Pete provided some good feedbacks which can generate some
explanatory text in the doc.  
 
Kent

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ahmad Muhanna

Hello Charlie, 

Regards, 
Ahmad

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 23 Jun 2005 10:27:53 -0500

As far as authentication and interaction with AAA goes: The way I look at it, the MN uses MN-HA-AE if it has an MSA with the HA, if not it uses MN-AAA-AE. These MSAs are specified through SPIs, not through IP addresses (unless I missed something). So whether or not the HoA is zero or not, does not change anything. The main point is whether the MSA is still alive or not. We can also debate on how we can tie the MSA life time to the RRQ life time, but seeing all this discussion, maybe it is good to keep the possibility of "these two lifetimes being independent" open.

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kent Leung \(kleung\)
Sent: Wednesday, June 22, 2005 1:50 AM
To: Ahmad Muhanna; Charles E.Perkins; Chowdhury, Kuntal
Cc: [email-masked]
Subject: RE: [Mip4] HoA=0.0.0.0 question

Hi Ahmad.

I would like to clarify the context of my statement quoted below.  It was in response to the example given for differentiating new and re-registrations was:

"Based on local policy the HA may have to process a new RRQ differently than a re-registration. For example, the local policy may not require the HA to perform AAA auth (i.e. process MN-AAA) every time the MN performs re-registration ..."

There are _no_ standards specification on this authentication optimization.  It is an implementation policy that exists today.  Standards specifies that MN-AAA AE is authenticated by the AAA server, not subjectively ignored.  But I don't have any problem with this method since it's a usage policy that's interoperable between HA and AAA using standards mapping of RRQ fields to RADIUS AVPs.  So what triggers RADIUS messages can remain a user's knob, ranging from each registration to only when new binding is created, with steps in between.

Anyways, I agree with Charlie that the WG is always open to ideas on solving practical problems.  Don't let a few comments dissuade you from writing an I-D to clarify the issues and potential solution.  Maybe some of us are missing a few pieces of info (Avi's accounting perspective was good input).  Henrik and Pete provided some good feedbacks which can generate some explanatory text in the doc.  

Kent

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ahmad Muhanna

Hello Charlie, 

> I didn't exactly see anyone else make that statement. 

You probably missed what Kent said. At least he clearly said it is implementation specific: 

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

Regards, 
Ahmad