Subject: [Mip4] 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
> 
> 

-- 
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: "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: Sri Gundavelli <[email-masked]>
Date: Thu, 9 Aug 2007 22:25:12 -0700 (PDT)

I've reviewed this document. It is in a good shape. Few
comments on the final version. May want to add some
clarifying text.

Sri

---------------------------------------------------------
Section 2.3 Implicit and Explicit Modes

   "In this mode of operation all traffic to and from
    the IPv6 prefixes MUST be encapsulated over the IPv4 tunnel between
    the mobile node's IPv4 home address and the IPv4 address of the home
    agent, and as such it is transparent to any foreign agent in the
    path."

The above text is not clear on what the supported encap modes are. The
text seems to say the encap mode is I(b) or II(b). Should allow I(a) and 
II(a) ?
If transparency to FA is desired for IPv6 traffic in implicit mode, I(b)
must be enforced. But, in CCOA mode, I(b) is an overhead.

I). FA-COA Mode:

    HA========FA-----MN

Encapsulation modes for IPv6 traffic:

    a.) HA-FACOA{IPv6-Pak}

    b.) HA-FACOA{HA-MNHoA{IPv6-Pak}}

II). MN-COA Mode:

    HA================MN

Encapsulation modes for IPv6 traffic:

    a.) HA-MNCOA{IPv6-Pak}

    b.) HA-MNCOA{HA-MNHOA{IPv6-PAK}}

As well for the explicit mode, the document talks about "tunneling
to HoA or CoA". But, its not implicit, if this introduces a new
encap modes I(b) or II(b). Because, 3344, uses this style of
delivery for broadcast or multicast packets. Few more lines of
text will help.

===================================================

Section 3.2 IPv6 Code Extension

> A new skippable extension to the Mobile IPv4 header

Should this be a non-skippable extension ? Its a reply and
MN cant ignore this. It is present, because MN asked for it
and it understands the format. Is it for supporting older
FA's in path and when the packets are tunneled to HoA ?

====================================================

Section 3.2  Code Values

> 10 registration rejected, not home subnet

> 11 registration rejected, Duplicate Address Detection failed

Some of these code values require some explanation. Some are
relevant only when the requested address is a prefix and some
when the address is a IPv6-HoA. Its not specified where exactly
each error code can be used. I understand, it may be implicit,
but, few lines will help.

========================================================
Section 4.3

"If the IPv6 home address included in a IPv6 prefix request extension"

You mean "IPv6 prefix extension" ?. Its in other places as well...

=========================================================
Section 4.3.1.  IPv6 Packet Processing

Should be mentioned that Proxy ND is required only when the requested
IPv6 address is a HoA and not a IPv6 prefix.

=========================================================

Section 4.3.2:

    "Even if the tunnel for IPv4 traffic terminates at a different point
    than the tunnel for IPv6 traffic (mobile node's CoA vs HoA), both
    tunnels MUST use the tunneling mechanism negotiated by the Mobile IP
    header as defined in MIPv4 [RFC3344].  When IPinIP encapsulation is
    negotiated IPv6 is tunneled over IPv4 according to [RFC4213].  GRE
    and Minimal Encapsulation techniques also allow tunneling of IPv6
    packet by setting the Protocol Type [RFC1701] and Protocol [RFC2004]
    fields to appropriate payload type defined for IPv6 by IANA."

When the packets are tunneled to the HoA, the inner capsulation
should be just IPv6-over-IPv4. I wonder, what is the value of using
GRE for the inner packets ? This alligns better with the delivery
style for broadcast and multicast packets, IMO.

============================================================
Section 4.3.2

" Packets addressed to the mobile node's IPv6 link-local address MUST
    NOT be tunneled to the mobile node.  Instead, these packets MUST be
    discarded and the home agent SHOULD return an ICMPv6 Destination
    Unreachable, Code 3, message to the packet's Source Address (unless
    this Source Address is a multicast address)."

The HA will probably never know the link-local address of the
mobile node ? The document does not specify the operation of the
mobile node using a IPv6 HoA on its home interface and also
there is no "Link-Local Address Compatibility (L)" flag to tell the
HA that the identifier for IPv6-HoA and the Link-local address is
the same.
==============================================================

"IPv6 packets received from the mobile client"

It should be "mobile node". Some places the MN is referred to as
mobile client. This should be consistent with 3344 terminology.

==============================================================
Section 4.8: Registration with a private CoA

You probably need a new type value for carrrying IPv6 packets in
UDP. MIP Tunnel Data Message [3519, Section 3.3]. Or just mention
that the IPv6 protocol number should be set when carrying IPv6
packets.

===============================================================

Tsirtsis, George wrote:
> Hi Peter,
>
> Kent sent me his comments offline and I have incorporated them in the
> draft. His main comment was about clarifying that implicit mode is
> entirely transparent to the FA, which I did.
>
> He is now, I think, on vacation so I could not check the changes with
> him. In any case I am sure he will check the document next week when
> he will be back.
>
> Regards
> George
>
>
> From: McCann Peter-A001034 [mailto:pete.mccann at motorola.com]
> Sent: Tuesday, August 07, 2007 3:52 PM
> To: mip4 at ietf.org; kleung at cisco.com
> Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt
>
> Thanks George for submitting the updated version.
>
> Kent, you said during the meeting that you had some comments on this
> draft.  Could you send them to the list, so that we can move ahead
> with this document?
>
> Thanks,
>
> -Pete
>
> Internet-Drafts at ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Mobility for IPv4
>> Working Group of the IETF.
>>
>> 	Title		: Dual Stack Mobile IPv4
>> 	Author(s)	: G. Tsirtsis, et al.
>> 	Filename	: draft-ietf-mip4-dsmipv4-03.txt
>> 	Pages		: 25
>> 	Date		: 2007-8-7
>>
>> This specification provides IPv6 extensions to the Mobile IPv4
>>    protocol.  The extensions allow a dual stack node to use IPv4 and
>>    IPv6 home addresses as well as to move between IPv4 and dual
>> stack    network infrastructures.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-03.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> i-d-announce-request at ietf.org with the word unsubscribe in the body
>> of the message. You can also visit
>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your
>> subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then "get
>> draft-ietf-mip4-dsmipv4-03.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>> 	mailserv at ietf.org.
>> In the body type:
>> 	"FILE /internet-drafts/draft-ietf-mip4-dsmipv4-03.txt".
>>
>> NOTE:	The mail server at ietf.org can return the document in
>> 	MIME-encoded form by using the "mpack" utility.  To use this
>> 	feature, insert the command "ENCODING mime" before the "FILE"
>> 	command.  To decode the response(s), you will need "munpack" or
>> 	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
>> 	exhibit different behavior, especially when dealing with
>> 	"multipart" MIME messages (i.e. documents which have been split
>> 	up into multiple messages), so check your local documentation on
>> 	how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.

---

From: "Tsirtsis, George" <[email-masked]>
Date: Fri, 10 Aug 2007 03:21:00 -0700

Hi Sri, Thanks for you comments. Please see comments inline...

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Friday, August 10, 2007 6:25 AM
To: McCann Peter-A001034
Cc: [email-masked]
Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt 

Sri

II(a) ?

GT> Sri, I(b) and II(b), keep things simple. To allow for I(a) we must
be confident that the HA can distinguish between CoA and CCoA
registrations in all cases. Are we sure HA implementations can always do
that? In other words, in the absence of an FA-HA authenticator is it
always possible for an HA to know whether a RRQ is coming from the MN or
the FA?

I). FA-COA Mode:

    HA========FA-----MN

    a.) HA-FACOA{IPv6-Pak}

II). MN-COA Mode:

    HA================MN

    a.) HA-MNCOA{IPv6-Pak}

GT> I am not sure what you call "a new encap mode"? what kind of
clarification would you think is necessary for I(b) and II(b)? I would
appreciate it if you could provide proposed text.

GT> I see your point but I think the extension works as skippable too.
The defined behavior for the mobile not receiving this extension is to
assume encapsulation of IPv6 over the HA-HoA tunnel, which is not
harmful (just less efficient). Its existence allows for encapsulation to
the MN's CoA but one can always encapsulate on the HA-HoA tunnel. Also
by keeping it skippable we save on code space (i.e., use of one
skippable code for all DSMIP extensions) which I assume is somewhat
limited? 

Section 3.2  Code Values

GT> Maybe you missed it but use of these codes is I think well defined
in the Home Consideration section 4.3 paragraph 3 and 4. Could you take
another look and let me know if it is sufficient?

GT> Ah yes, thanks. It in 6 places, I will correct it.

GT> Hmmm, yes maybe. Is that simple statement sufficient or should we
say anything more?

Section 4.3.2:

GT> Yes you are right. Should I then say that when IPv6 is encapsulated
over the HA-HoA tunnel, RFC4213 should always be used? How is the
following?:

"When IPv6 traffic is encapsulated over the tunnel between the HA and
the mobile node's care-off address, the tunneling mechanism used should
be the same with the mechanism negotiated by the Mobile IP header as
defined in MIPv4 [RFC3344]. In that case, when IPinIP encapsulation is
negotiated, IPv6 is tunneled over IPv4 according to [RFC4213]. GRE and
Minimal Encapsulation techniques also allow tunneling of IPv6 packet by
setting the Protocol Type [RFC1701] and Protocol [RFC2004] fields to
appropriate payload type defined for IPv6 by IANA. When, however, IPv6
traffic is encapsulated over the tunnel between the HA and the mobile
node's home address, IPv6 is always tunneled over IPv4 according to
[RFC4213], no matter what tunneling mechanism is negotiated in MIPv4
signaling. "

GT> Actually I am strangling to remember why or when we wrote this.
Should I just remove it or is there something else we should say?

GT> ok, thanks.

GT> OK, good point. So would the following text work?:

" 4.8.  Registration with a private CoA

If the care-of address is a private address then Mobile IP NAT Traversal
as [RFC3519] MAY be used in combination with the extensions described in
this specification. In that case the next header field of the Mobile
Tunnel Data message header [RFC3519] MUST be set to the value for IPv6."

Thanks
George

readers

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 10 Aug 2007 22:44:15 +1000

=> Basically we need to say that the HA will defed the IPv6 address by
sending a proxy Neighbour Advertisement message. RFC 3775 talks about
resending the message once for reliability. You could  refer to that
behaviour. 

 > Should I just remove it or is there something else we should say?

=> I can't remember why we wrote this either. Looks like a bug, but I'm
wondering whether we should have the L-flag equivalent here at all. It'd be
interesting to see if anyone cares about link-local traffic, e.g. DHCPv6,
MLD...etc. 

Hesham

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 12 Aug 2007 21:43:11 -0700

Hi George,

Inline ... 

> From: Tsirtsis, George [mailto:[email-masked]] 
> Sent: Friday, August 10, 2007 3:21 AM
> To: Sri Gundavelli; McCann Peter-A001034
> Cc: [email-masked]

Why will this be an issue just in implicit mode. If the "IPv6
Tunneling Mode Extension" is present, HA can send the IPv6 packets
in I(a)/II(a) mode i.e to a care-of address and not to the home
address. Now, if the CoA is FA-COA or a CCOA, will that be
important ? HA simply wraps the IPv6 packets with the tunnel
header. If the packets are received at the FA, it simply forwards
them as in for the explicit mode. Also, the presence of "D" bit in
the RRQ, specifies if its FA-COA or a CCOA mode of operation. 

I'm ok either way. I was not sure, why in implicit mode, IPv6
packets cant be sent in I(a)/II(a) modes.

> appreciate it if you could provide proposed text.

Typical view of a MIP tunnel, is between FA-COA/CCOA to HAA and
there is just one tunnel. Tunneling to HoA introduces some what
a new tunnel i.e to the HA-MNCOA{HA-MNHOA{IPv6-PAK}}.
I was just saying, few more line of text might be good, that the
packet needs to be wrapped first in HAA-HoA and then HAA-COA 
wrappers. The text from 3344 on how broadcast/multicast packets
are sent, can be used here.

Ok.

Ok.

Fine.

This is fine.

Ok.

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 12 Aug 2007 22:19:21 -0700

> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Friday, August 10, 2007 5:44 AM
> To: 'Tsirtsis, George'; 'Sri Gundavelli'; 'McCann Peter-A001034'
> Cc: [email-masked]

I meant for the case, when the MN requests a prefix. HA need not
do any IPv6 ND operations. A simple route for the prefix over the
tunnel should be sufficient.

> interesting to see if anyone cares about link-local traffic, 

The draft did not talk about of the use of IPv6 home address on the
home link. If the MN is on a virtual link or never at home, there
is no need for the HA to defend the mobile node's link-local address.
But, there is no such assumption mentioned in the spec. If the mobile
node operates as a normal MIPv6 node on the home link, we need to make
sure that address is defended by the HA, else it might loose it. MN
might use a link-local source address for DHCPv6 requests.

Sri

---

From: "Tsirtsis, George" <[email-masked]>
Date: Mon, 13 Aug 2007 03:05:22 -0700

inline

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Monday, August 13, 2007 6:19 AM
To: 'Hesham Soliman'; Tsirtsis, George; 'McCann Peter-A001034'
Cc: [email-masked]
Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt 

GT> Yes, I agree. I am going to edit the text in section 4.3. as
follows:
" When the IPv6 prefix extension contains a /128 IPv6 address
and unless this home agent already has a binding for the
given IPv6 address indicated, the home agent MUST perform
Duplicate Address Detection <xref target="RFC2462"/> on the
mobile node's home IPv6 link before returning a registration
reply. This ensures that no other node on the home link is
using the IPv6 home address. Duplicate address detection is
not required when the IPv6 prefix extension contains a
prefix."

GT> I guess the fundamental question is whether the case of MN "at home"
is of interest to the group. I do not see a strong need for this since
MIPv4 in the field is typically deployed in "virtual link" mode. If
people feel strongly about support for home link operation we have to
add some more language around that, otherwise I will just state that
this is not supported at this point.

 Thoughts?
George

---

From: "Tsirtsis, George" <[email-masked]>
Date: Mon, 13 Aug 2007 03:07:27 -0700

Hi Sri, thanks...some more comments inline...

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Monday, August 13, 2007 5:43 AM
To: Tsirtsis, George; 'McCann Peter-A001034'
Cc: [email-masked]
Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt 

Hi George,

Inline ... 

important ? 

GT> It is actually important. The MN can only send the "IPv6
Tunneling Mode Extension" if it works in CCoA mode. See the following
quote from section 4.5:
"The mobile node SHOULD include exactly one IPv6 tunneling mode
   extension if it uses the co-located care-of address model and it
   wants to request that IPv6 packets are tunneled to its co-located
   care-of address.  If the mobile node uses the co-located care-of
   address model but it does not include the IPv6 tunneling mode
   extension the home agent will tunnel IPv6 traffic to the mobile
   client's home address.  The mobile node MUST NOT include an IPv6
   tunneling mode extension if it uses the care-of address mode of
   operation.  Note that if the mobile includes an IPv6 tunneling mode
   extension in this case, IPv6 packets could be tunneled to the FA by
   the HA.  The FA is then likely to drop them since it may not have
   appropriate state to process them."

HA simply wraps the IPv6 packets with the tunnel
header. If the packets are received at the FA, it simply forwards
them as in for the explicit mode. Also, the presence of "D" bit in
the RRQ, specifies if its FA-COA or a CCOA mode of operation. 

GT> The problem is that if the HA tunnels IPv6 packets to the FA and the
FA does not support IPv6, the packets will be dropped on the floor. In
implicit mode (i.e., the absence of an IPv6 tunneling Mode extension),
there is no way for the HA to know if the FA supports IPv6 or the
behaviors defined in this draft, so tunneling to the MN's IPv4 HoA is
always safer.

GT> OK, I see. I will modify the appropriate part of section 4.3.2 as
follows, based on corresponding text in 3344, so tell me if it works:
"   1) Registration request is received with one or more IPv6 prefix
   extensions.  An IPv6 tunneling mode extension is not included.

All IPv6 packets destined to the registered IPv6
prefix(es) MUST be tunneled by the home agent to
the registered IPv4 home address of the mobile.

===start of new text=======
The home agent first encapsulates the IPv6
packet addressed to the mobile node's IPv4 home
address, and then tunnels this encapsulated
datagram to the foreign agent. This extra level
of encapsulation is required so that IPv6
routing remains transparent to a foreign agent
that does not support IPv6. When received by the
foreign agent, the unicast encapsulated packet is
detunneled and delivered to the mobile node in
the same way as any other datagram. The mobile
node must decapsulate the received IPv4 packet
it receives in order to recover the original
IPv6 packet. 
======end of new text========
Additionally, the home agent MUST
be prepared to accept reverse tunneled packets
from the IPv4 home address of the mobile
encapsulating IPv6 packets sent by that mobile."

Ok.

Ok.

Fine.

This is fine.

Ok.

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 13 Aug 2007 03:17:20 -0700

Hi George,

> encapsulating IPv6 packets sent by that mobile."

This is good.

Thanks
Sri

---

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
> round-trips? For example, we could further reduce the round-trips by
> tunneling MIP4 inside EAP of network access authentication.   

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.

> Alper

-Pete

---

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: 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: "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 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: "Alper Yegin" <[email-masked]>
Date: Sat, 11 Aug 2007 02:00:07 +0300

Pete,

Alper

---

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

Pete,

 

Alper

---

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: "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
> 
> Isn't this what HOKEY is all about?
> 
> Alper Yegin wrote:
> > _______________________________________________
> > DiME mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/dime
> >
> >

---

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

---

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: Tom Taylor <[email-masked]>
Date: Wed, 15 Aug 2007 13:27:14 -0400

---

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