Subject: [Dime] Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 7 Aug 2007 10:38:52 -0500

All,
During DIME meeting at IETF-69, Pete raised the point that when RADIUS
relay the re-transmitted RRQ without going to AAA, Pete thinks that
there possibly a security concern.

I would like to start this thread but I would like to let Pete summarize
his concern and we then can discuss it.

Hi Pete,

Could you please summarize the security concern that you raised during
DIME meeting?
Many thanks in advance.
 
Regards,
Ahmad

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Wednesday, August 01, 2007 4:06 AM
> To: [email-masked]
> Cc: Muhanna, Ahmad (RICH1:2H10)
> Subject: MIPv4 Authentication Performance Using RADIUS and Diameter 
> MIPv4
> 
> Hi Ahmad,
> 
> you raised some interesting discussions during the DIME working group 
> meeting. Unfortunately, there was not enough time to address all 
> questions.
> 
> I would be great if you could
> * summarize your presentation, and
> * address some of the raised questions on the mailing list.
> 
> Ciao
> Hannes
> 
> 

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 7 Aug 2007 16:45:48 -0400

Hi, Ahmad,

Maybe this is not so big an issue, but one thing that might
happen is that the MN can use a different HA address in the
re-transmitted RRQ.  If there is network policy in place
that only allows registering on specific HAs, this policy
might be skirted by the retransmission unless the HA address
is sent to the RADIUS/Diameter server with every RRQ.

I am also concerned about increasing the overall registration
time by going from one round-trip to two round-trips.  The
nice thing about the existing Diameter application is that
it can do both authentication/authorization and MIP registration
in one round-trip to the home network.

One question: why couldn't we fix the problem by adjusting
the retransmission timers upwards?  If we know that AAA adds
some additional delay, we could wait a bit longer before
retransmitting the request.  This seems to fix the problem. 

-Pete

Ahmad Muhanna wrote:
> All,
> During DIME meeting at IETF-69, Pete raised the point that when
> RADIUS relay the re-transmitted RRQ without going to AAA, Pete thinks
> that there possibly a security concern.  
> 
> I would like to start this thread but I would like to let Pete
> summarize his concern and we then can discuss it. 
> 
> Hi Pete,
> 
> Could you please summarize the security concern that you raised
> during DIME meeting? 
> Many thanks in advance.
> 
> Regards,
> Ahmad
> 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 7 Aug 2007 17:02:04 -0500

Hi Pete,
Please see response inline.

Regards,
Ahmad

> From: McCann Peter-A001034 [mailto:[email-masked]] 
> Sent: Tuesday, August 07, 2007 3:46 PM
> To: Muhanna, Ahmad (RICH1:2H10); [email-masked]
> Cc: [email-masked]; Hannes Tschofenig
> Subject: RE: Issue 2: Security Concern in RADIUS Mode: MIPv4 
> Auth Performance Using RADIUS and Diameter MIPv4 Application draft
> 
> Hi, Ahmad,
> 
> re-transmitted RRQ. If there is network policy in place that 
> only allows registering on specific HAs, this policy might be 
> skirted by the retransmission unless the HA address is sent 
> to the RADIUS/Diameter server with every RRQ.

[Ahmad]
We can look at this special case later, but for the sake of this simple
analysis, we need to address the most common simple scenario first. With
the following in mind: "What would the impact be when using Diameter
MIPv4 Application in place of RADIUS model."

Also, usually the MN does not try to register with another HA until the
registration process is timeout. In our case, we are focusing on the
first retransmitted RRQ which usually done after one second.

> nice thing about the existing Diameter application is that it 
> can do both authentication/authorization and MIP registration 

[Ahmad]
I am sorry I missed this point here. Could you please elaborate a little
further.

> retransmitting the request.  This seems to fix the problem. 

[Ahmad]
I agree with you here. It is anticipated that Diameter MIPv4 Application
will take a longer time to complete MIPv4 initial registration. Two
questions: 

1. Why the MN and possibly the network configurations need to change
just for using Diameter MIPv4 Application in place of RADIUS.
2. On the other hand, even if we increase the initial timer a little, we
still do not solve the issue, all what we do is delaying it.

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 8 Aug 2007 10:18:16 -0400

Hi, Ahmad,

Ahmad Muhanna wrote:
>> Maybe this is not so big an issue, but one thing that might happen is
>> that the MN can use a different HA address in the re-transmitted RRQ.
>> If there is network policy in place that only allows registering on
>> specific HAs, this policy might be skirted by the retransmission
>> unless the HA address is sent to the RADIUS/Diameter server with
>> every RRQ.
> 
> [Ahmad]
> We can look at this special case later, but for the sake of this
> simple analysis, we need to address the most common simple scenario
> first. With the following in mind: "What would the impact be when
> using Diameter MIPv4 Application in place of RADIUS model."  

I think the main impact would be a shorter overall registration
time, because the AMR/AMA can carry the registration along with
the authentication credentials, which means only one round-trip
to the home network instead of 2.
 
> Also, usually the MN does not try to register with another HA until
> the registration process is timeout. In our case, we are focusing on
> the first retransmitted RRQ which usually done after one second.  

Why can't we just increase the recommended timeout value?

>> I am also concerned about increasing the overall registration time by
>> going from one round-trip to two round-trips.  The nice thing about
>> the existing Diameter application is that it can do both
>> authentication/authorization and MIP registration in one round-trip
>> to the home network.
> 
> [Ahmad]
> I am sorry I missed this point here. Could you please elaborate a
> little further. 

The Diameter MIP4 application was designed to minimize the number
of round-trips needed to complete the authentication and registration
process.  Because the RRQ is carried inside the AMR, there is only
one round trip to carry out the two operations: authentication and
registration.

>> One question: why couldn't we fix the problem by adjusting the
>> retransmission timers upwards?  If we know that AAA adds some
>> additional delay, we could wait a bit longer before retransmitting
>> the request.  This seems to fix the problem.
> 
> [Ahmad]
> I agree with you here. It is anticipated that Diameter MIPv4
> Application will take a longer time to complete MIPv4 initial
> registration. 

On the contrary, I think it will be faster.

> Two  

If we have encountered deployment situations in which a 1 second
retransmission is too fast, then we should adjust the recommended
minimum value of the timer.
 
> 2. On the other hand, even if we increase the initial timer a little,
> we still do not solve the issue, all what we do is delaying it. 

If we can increase the timer so that 99% of the time the registration
completes (or fails) within the new timeout value, then we will have
the initial RRP back to the MN before it retransmits (or, in the case
of failure, the retransmission will be really necessary).  This seems to
solve the issue.  I don't think we should go re-architecting the MIP4
Diameter application because of a mismatched timeout value.

-Pete

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 8 Aug 2007 09:31:49 -0500

Hi Pete,

>From this discussion, it is apparent that there is no security issue
that you are concerned with. Please confirm?
If that is true, then we can change the subject of this thread to the
performance issue and continue discussion.

Is that acceptable?

Regards,
Ahmad
 
> I think the main impact would be a shorter overall 
> registration time, because the AMR/AMA can carry the 
> registration along with the authentication credentials, which 
> means only one round-trip to the home network instead of 2.

> The Diameter MIP4 application was designed to minimize the 
> number of round-trips needed to complete the authentication 
> and registration process.  Because the RRQ is carried inside 
> the AMR, there is only one round trip to carry out the two 
> operations: authentication and registration.
> 
> If we have encountered deployment situations in which a 1 
> second retransmission is too fast, then we should adjust the 
> recommended minimum value of the timer.
>  
> If we can increase the timer so that 99% of the time the 
> registration completes (or fails) within the new timeout 
> value, then we will have the initial RRP back to the MN 
> before it retransmits (or, in the case of failure, the 
> retransmission will be really necessary).  This seems to 
> solve the issue.  I don't think we should go re-architecting 
> the MIP4 Diameter application because of a mismatched timeout value.
> 
> -Pete
>

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 8 Aug 2007 11:24:15 -0400

Hi, Ahmad,

I would say there is a minor security issue that may or may not
be important in some deployments.

It is fine with me if you want to change the subject line.

-Pete

Ahmad Muhanna wrote:
> that you are concerned with. Please confirm? If that is true, then we
> can change the subject of this thread to the performance issue and
> continue discussion.  
> 
> Is that acceptable?
> 
> Regards,
> Ahmad
> 
>> 
>> Hi, Ahmad,
>> 
>> Ahmad Muhanna wrote:
>>>> Maybe this is not so big an issue, but one thing that might happen
>>>> is that the MN can use a different HA address in the
>>>> re-transmitted RRQ. If there is network policy in place that only
>>>> allows registering on specific HAs, this policy might be skirted
>>>> by the retransmission unless the HA address is sent to the
>>>> RADIUS/Diameter server with every RRQ.
>>> 
>>> [Ahmad]
>> I think the main impact would be a shorter overall registration time,
>> because the AMR/AMA can carry the registration along with the
>> authentication credentials, which means only one round-trip to the
>> home network instead of 2.
> 
>> 
>>>> I am also concerned about increasing the overall registration time
>>>> by going from one round-trip to two round-trips.  The nice thing
>>>> about the existing Diameter application is that it can do both
>> The Diameter MIP4 application was designed to minimize the number of
>> round-trips needed to complete the authentication and registration
>> one round trip to carry out the two
>>> 2. On the other hand, even if we increase the initial timer a
>>> little, we still do not solve the issue, all what we do is delaying
>>> it. 
>> 
>> of failure, the retransmission will be really necessary).  This seems
>> to solve the issue.  I don't think we should go re-architecting the
>> MIP4 Diameter application because of a mismatched timeout value.
>> 
>> -Pete

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 8 Aug 2007 10:29:05 -0500

Thanks Pete.
Just a minor note; I have not been able to see what was the minor
security issue you are referring to but as you said, we can go ahead and
start the new thread.

Will follow Performance discussion on the new thread.

Regards,
Ahmad

> Sent: Wednesday, August 08, 2007 10:24 AM
> I would say there is a minor security issue that may or may 
> not be important in some deployments.
> 
> re-transmitted 
> >>>> RRQ. If there is network policy in place that only allows 
> >>>> registering on specific HAs, this policy might be skirted by the 
> >>>> retransmission unless the HA address is sent to the 
> RADIUS/Diameter 
> >>>> server with every RRQ.
> >>> 
> >>> [Ahmad]
> registration time, 
> number of 
> registration

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 9 Aug 2007 12:15:44 -0500

Hi Pete,
My apologies, I almost forgot about opening this thread. However, May I
focus on one portion of your reply, specifically your proposals to
address the issue.

> recommended minimum value of the timer.

[Ahmad]
This is a proposal for increasing the initial RRQ retransmission timer.
Please see below.

> the MIP4 Diameter application because of a mismatched timeout value.

[Ahmad]
Ok, I think this is an important step. I think what you are trying to
say is that you agree with the analysis that the draft presented and you
are trying to propose solutions for the issue without any change to the
Diameter Mobile IPv4 Application, RFC4004. Is that a fair statement?

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 9 Aug 2007 13:51:48 -0400

Hi, Ahmad,

Ahmad Muhanna wrote:
> say is that you agree with the analysis that the draft presented and
> you are trying to propose solutions for the issue without any change
> to the Diameter Mobile IPv4 Application, RFC4004. Is that a fair
> statement?    

I agree that if the Diameter infrastructure takes too long to
respond to the MN before it retransmits, this would potentially
put a second, uneccessary AMR into the network, causing more
traffic.  The registration process itself would be delayed a
bit because the MN would be waiting for a response to its most
recently transmitted RRQ.  However, RFC3344 specifies an
exponentially increasing timeout value so eventually the MN
would get registered.

I think that summarizes the problem you raised; it could have
been sent to the list in that form rather than writing an
entire draft with call flows comparing RADIUS to Diameter.

I agree that a Diameter (or RADIUS, for that matter) infrastructure
might take more than 1 second to respond to an AMR or an Access-Request.
It seems that the solution is to recommend a longer timeout value
for the initial retransmission.  Another solution would be to allow
the MN to complete its registration successfully by receiving an
RRP matching a previous RRQ (not just the most recently retransmitted
one).

I don't think we should turn the MIP4 Diameter application into a
2-round-trips protocol.  The goal of RFC4004 is to provide MIP
registration in one round-trip.

-Pete

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 9 Aug 2007 13:43:16 -0500

Hi Pete,

> respond to the MN before it retransmits, this would 
> potentially put a second, uneccessary AMR into the network, 
> causing more traffic.  The registration process itself would 
> be delayed a bit because the MN would be waiting for a 
> response to its most recently transmitted RRQ.  However, 
> RFC3344 specifies an exponentially increasing timeout value 
> so eventually the MN would get registered.
> 

[Ahmad]
I assume you are talking here with MIPv4 chair hat-off, there is no
restrictions about writing drafts in IETF and getting two wg to agree to
present the idea and generate discussion inside the meeting and on the
mailing lists or you are suggesting a new IETF rule here?

Having said that, I guess the least which can be said about what you
just mentioned is over simplification of what the draft is trying to
present. The idea the draft was to highlight and present, IMO and many
others, a valid weakness about D-MIPv4 architecture. The draft is trying
to compare the performance of the current RADIUS deployment to what to
be Diameter Mobile IPv4 Application deployment. Let me try to explain
what the draft is trying to highlight one more time:

1. Currently there are certain deployment configuration parameters and
the operator probably would like to get better performance in case
Diameter is used in place of RADIUS without further studies and analysis
to how to tweak the network in order to optimize the expected D-MIP4
performance issue.

2. The point here is not about Diameter as an AAA protocol, however, it
is about the concept of coupling the MIPv4 control signaling to AAA
signaling. Which many people do not think it is a good idea and believe
that it is a deviation from RFC3344 initial MIPv4 registration
procedure. Do not you agree?

3. Of course, RFC3344 have a retransmission mechanism, which in most
cases should get the MN eventually registered. On the other hand,
RFC4004 proposes a Diameter Application and impeded MIPv4 control
signaling inside AAA control signaling and the draft never assumed that
there could be an impact on the MIPv4 signaling retransmission mechanism
or performance. Not to mention coupling of MIPv4 signaling
retransmission with AAA signaling retransmission.

4. If the AAA infrastructure have the same load in case of RADIUS and
D-MIP4 and the MN had to retransmit the initial MIPv4 RRQ, there is a
much much greater chance that D-MIPv4 will cause another round of
UNNECESSARY AAA signaling that does not happen in the case of RADIUS.

5. If the AAA infrastructure is slightly loaded and cause a MN to
retransmit its MIPv4 initial RRQ, D-MIPv4 as per RFC4004 makes the
situation much WORSE by injecting, at least, DOUBLE the number of AAA
(Diameter) signaling messages. In the case of RADIUS this is not there.

6. Actually, we are going to publish a new revision of this draft and
address the scenario of allocating a HA in the visited network. Have you
looked into the difference between the RADIUS and D-MIP4 performance in
this scenario and what will happen if the MN happened to retransmit?

7. Finally, I guess all of the above worth writing a draft in order to
provide heads up for the industry of what to expect in case D-MIPv4,
RFC4004, is deployed in place of RADIUS.

> 
> I agree that a Diameter (or RADIUS, for that matter) 
> infrastructure might take more than 1 second to respond to an 
> AMR or an Access-Request.
> It seems that the solution is to recommend a longer timeout 
> value for the initial retransmission.  Another solution would 
> be to allow the MN to complete its registration successfully 
> by receiving an RRP matching a previous RRQ (not just the 
> most recently retransmitted one).
> 
> I don't think we should turn the MIP4 Diameter application 
> into a 2-round-trips protocol.  The goal of RFC4004 is to 
> provide MIP registration in one round-trip.
> 
> -Pete
>

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 9 Aug 2007 15:02:12 -0400

Hi, Ahmad,

Ahmad Muhanna wrote:
> 2. The point here is not about Diameter as an AAA protocol, however,
> it is about the concept of coupling the MIPv4 control signaling to
> AAA signaling. Which many people do not think it is a good idea and
> believe that it is a deviation from RFC3344 initial MIPv4
> registration procedure. Do not you agree?    

No, I don't.  Putting the Registration Request in the AMR is a feature.
It allows the registration to happen in one round-trip.
 
> address the scenario of allocating a HA in the visited network. Have
> you looked into the difference between the RADIUS and D-MIP4
> performance in this scenario and what will happen if the MN happened
> to retransmit?    

Obviously this scenario takes longer to process the RRQ and so the
chance of hitting a retransmission is greater.
 
>> might take more than 1 second to respond to an AMR or an
>> Access-Request. It seems that the solution is to recommend a longer
>> timeout value for the initial retransmission.  Another solution
>> would be to allow the MN to complete its registration successfully
>> by receiving an RRP matching a previous RRQ (not just the most
>> recently retransmitted one). 
>> 

-Pete

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 9 Aug 2007 14:30:55 -0500

Hi Pete,

> > it is about the concept of coupling the MIPv4 control 
> signaling to AAA 
> > signaling. Which many people do not think it is a good idea and 

[Ahmad]
Well, I do not understand what you mean by a feature. Initial RRQ/RRP is
coupled with AMR/AMA, as a matter of fact they are carried in
attributes. In other words, we can not relay initial RRQ/RRP outside
AMR/AMA as per RFC3344. Even if you want to call it a feature, that
feature makes D-MIP4 architecture different from RADIUS and at the same
time makes AAA infrastructure more vulnerable.

> Obviously this scenario takes longer to process the RRQ and 
> so the chance of hitting a retransmission is greater.

[Ahmad]
Okay.. Then that is bad and has bad consequences on the AAA
infrastructure and on the current MIPv4 deployment. Operators, expects
the current network infrastructure to work, at least, better when
upgrading AAA to Diameter not to degrade their network performance and
start spending moneys on studies and tweaking mechanisms here and there
to compromise for the D-MIPv4 feature. IMO, that is not a bad feature
and we need to fix it.

> infrastructure 
> >> timeout value for the initial retransmission.  Another 
> solution would 
> >> be to allow the MN to complete its registration successfully by 
> >> receiving an RRP matching a previous RRQ (not just the 
> most recently 
> >> retransmitted one).
> >>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 9 Aug 2007 14:34:18 -0500

Sorry one correction:)

> compromise for the D-MIPv4 feature. IMO, that is **not** a bad 
> feature and we need to fix it.

I meant to say: IMO, that is a bad feature and we need to fix it.

Regards,
Ahmad

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 11 Aug 2007 02:00:07 +0300

Pete,

> It allows the registration to happen in one round-trip.

Obviously it is a feature. But don't you think it is a bit of a hack? I
mean, tunneling one protocol inside another for the sake of saving
round-trips? For example, we could further reduce the round-trips by
tunneling MIP4 inside EAP of network access authentication.

I also understand that having to go to HAAA twice for each MIP RegReq is
bothersome. But then, maybe we should re-consider the necessity of MN-FA
authentication. Given that HA is going to authenticate the MN, does FA also
need to do the same?

Alper

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Mon, 13 Aug 2007 11:14:50 -0400

Alper Yegin wrote:
> Pete,
>> No, I don't.  Putting the Registration Request in the AMR is a
>> feature. It allows the registration to happen in one round-trip.
> 
> Obviously it is a feature. But don't you think it is a bit of a hack?
> I mean, tunneling one protocol inside another for the sake of saving

I don't think it's a hack.  When we have Mobile IP being used
for access authentication I think it makes sense to carry the
RRQ in a Diameter application.  EAP is a different case because
then we have a separate protocol doing access authentication.

> I also understand that having to go to HAAA twice for each MIP RegReq
> is bothersome. But then, maybe we should re-consider the necessity of
> MN-FA authentication. Given that HA is going to authenticate the MN,
> does FA also need to do the same?   

The FA and HA might be part of different administrative domains.
I think the FA has just as much reason to authenticate the MN as
the HA.

-Pete

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 13 Aug 2007 23:09:12 +0300

Pete,

> then we have a separate protocol doing access authentication.

Using a mobility protocol's AAA for network access AAA is another hack,
IMHO. These are two separate services. That may explain why one protocol is
tunneled inside another, but it does not justify.
 
I understand these are all driven by performance improvements.

> I think the FA has just as much reason to authenticate the MN as

MN is authenticated by the same entity (HAAA) whether requested by the FA or
the HA. If HA and FA has some trust relationship (e.g., using FA-HA AE, or
IPsec), then I believe letting the HA authenticate the MN is sufficient. 

Alper

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Mon, 13 Aug 2007 16:32:23 -0400

Alper Yegin wrote:
> Pete,
>>
>> I don't think it's a hack.  When we have Mobile IP being used for
>> access authentication I think it makes sense to carry the RRQ in a
>> Diameter application.  EAP is a different case because then we have a
>> separate protocol doing access authentication.
> 
> Using a mobility protocol's AAA for network access AAA is another
> hack, IMHO. These are two separate services. That may explain why one
> protocol is tunneled inside another, but it does not justify.  

Well, this is the road we went down back in 1998.  There is at
least one SDO that is heavily dependent on the MN-NAI and MN-AAA
extensions.
 
> I understand these are all driven by performance improvements.

Yes.
 
>> I think the FA has just as much reason to authenticate the MN as the
>> HA.
> 
> MN is authenticated by the same entity (HAAA) whether requested by
> the FA or the HA. If HA and FA has some trust relationship (e.g.,
> using FA-HA AE, or IPsec), then I believe letting the HA authenticate
> the MN is sufficient.   

There is no scalable way to maintain trust relationships between
all pairs of (FA, HA).  One of the main purposes of the Diameter
MIPv4 application is to distribute keys for those (FA, HA)
relationships that are necessary based on the MNs that are
roaming to a given FA.  The FA needs to make sure that the
visited resources will be paid for, which is why it needs 
authorization from the AAA infrastructure.

-Pete

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 14 Aug 2007 01:58:32 +0300

> authorization from the AAA infrastructure.

FA-HA security association can also be dynamically created during the
network access authentication procedure. 

Alper

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 14 Aug 2007 09:59:11 -0400

Alper Yegin wrote:
>> There is no scalable way to maintain trust relationships between all
>> pairs of (FA, HA).  One of the main purposes of the Diameter
>> relationships that are necessary based on the MNs that are roaming to
>> a given FA.  The FA needs to make sure that the visited resources
>> will be paid for, which is why it needs authorization from the AAA
>> infrastructure.
> 

That's exactly what the Diameter-MIPv4 application does.

-Pete

---

From: Tom Taylor <[email-masked]>
Date: Wed, 15 Aug 2007 13:27:14 -0400

Isn't this what HOKEY is all about?

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 15 Aug 2007 23:32:15 +0300

Yes, HOKEY has relevance to that.

Alper 

> From: Tom Taylor [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2007 8:27 PM
> To: Alper Yegin
> Cc: 'McCann Peter-A001034'; 'Ahmad Muhanna'; [email-masked]; [email-masked]
> Subject: Re: [Dime] RE: Issue 3: Diameter MIP4 Application vs.
> RADIUSArchitecture
>

---

From: "Tsirtsis, George" <[email-masked]>
Date: Thu, 16 Aug 2007 04:34:59 -0700

Sorry I have not followed this fully but I also think that sending RRQs
encapsulated in DIAMETER messages is not always desirable. In fact it
links two protocols in a way that is somewhat undesirable. The HA for
example, has to be able to accept MIP registrations from two different
protocols now (i.e., MIP and DIAMETER). The RADIUS way of doing this is
a bit cleaner, but more importantly is widely deployed and current
deployments are unlikely to change their model just because they want to
upgrade to DIAMETER.

My 2c
George

-----Original Message-----
From: McCann Peter-A001034 [mailto:[email-masked]] 
Sent: Tuesday, August 14, 2007 2:59 PM
To: Alper Yegin; Ahmad Muhanna; [email-masked]
Cc: [email-masked]
Subject: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application
vs.RADIUSArchitecture

-Pete

-- 
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: "Hesham Soliman" <[email-masked]>
Date: Thu, 16 Aug 2007 22:01:32 +1000

> I understand these are all driven by performance improvements.

=> I agree with Alper about this. I do think we should avoid this type of
"performance improvement" :). I don't think it's a good idea for the RRQ or
other MIP messages to be encapsulated in Diameter and I actually think the
performance benefits are negligible.

Hesham

 >      Charter page: 
 > http://www.ietf.org/html.charters/mip4-charter.html

---

From: <[email-masked]>
Date: Thu, 30 Aug 2007 15:05:12 +0300

Hi all,

Sorry for jumping in the thread but I fail to understand why we'd need
to
alter a MIPv4 initial retransmission timer due to a certain deployment
model.
If MIPv4 is deployed in such a way that the initial retransmission timer
would
need to be doubled, tripled,... then I'd say it is up to the service
provider
to provide such parameters. This is how 3GPP2 operators have solved it.

Cheers,
Markku 

>From: ext McCann Peter-A001034 [mailto:[email-masked]] 
>Sent: 09 August, 2007 22:02
>To: Ahmad Muhanna; [email-masked]
>Subject: [Mip4] RE: Issue 3: Diameter MIP4 Application vs. 
>RADIUSArchitecture
>
>Hi, Ahmad,
>
>Ahmad Muhanna wrote:
>Obviously this scenario takes longer to process the RRQ and so 
>the chance of hitting a retransmission is greater.
> 
>>> receiving an RRP matching a previous RRQ (not just the most 
>recently 
>>> retransmitted one).
>>>