Subject: [Mip4] I-D ACTION:draft-ietf-mip4-dynamic-assignment-06.txt

From: [email-masked]
Date: Wed, 12 Oct 2005 15:50:01 -0400

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		: Mobile IPv4 Dynamic Home Agent Assignment
	Author(s)	: M. Kulkarni, et al.
	Filename	: draft-ietf-mip4-dynamic-assignment-06.txt
	Pages		: 24
	Date		: 2005-10-12
	
Mobile IPv4 [1] uses the Home Agent (HA) to anchor sessions of a 
   roaming Mobile Node (MN).  This draft proposes a messaging mechanism 
   for dynamic home agent assignment and HA redirection.  The goal is to 
   provide a mechanism to assign an optimal HA for a Mobile IP session 
   while allowing any suitable method for HA selection.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mip4-dynamic-assignment-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] 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-dynamic-assignment-06.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mip4-dynamic-assignment-06.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.
-- 
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: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 25 Oct 2005 01:52:47 -0500

Hi Milind,
My apology for not responding earlier.

security consideration section:
"
   There is a possibility of more than one HA create a mobility 
   binding entry for a given MN, if a man in the middle captures the 
   Registration Request with HA field set to ALL-ZERO-ONE-ADDR and 
   forwards it to other HAs.  This scenario assumes that the rogue node 
   can find out the addresses of the HAs which are able to authenticate 
   the Registration Request.  It also assumes that the rogue node has 
   the capability to store, duplicate, and send packets to the other HAs

   within the limited time of the replay window. Otherwise these HAs 
   will reject the Registration Requests anyway. In addition, this type 
   of attack is only possible when the Requested HA Extension is not 
   included in the registration message.  The Mobile Node can minimize 
   the duration of this condition by using a short lifetime (e.g. 5 
   seconds) in the Registration Request.
"

My only concern is with the recommendation of setting the lifetime to 5
seconds. Basically we are recommending a 2 round trip registration. Do
you agree?

If we are ok with 2 round trip DHA registration, then I would argue that
we let the HA reject the first registration using an appropriate code
e.g. 136. This much better because in the case of 5 second registration,
It is more expensive since HAs needs to allocate resources including the
IP addresses and then releasing them.
On the other hand, 5 seconds is too short that it could interfere with
the retransmission mechanism due to a lost registration request.

The other issue:
I believe it resolves the security issue for MN with co-located acre of
address without any complication.

Since the MN with co-located care of address always acquire the
requested HA address via other means as documented in section 6.0 of the
draft, why not then allow the MN to use the HA IP address in the HA
field of the RRQ. Just like regular MIPv4. unless I am missing something
here, I think this scenario becomes just like a regular Mobile IP
registration.
On the other hand, in case that it is required for the MN to set the HA
field to ALL-ZERO-ONE-ADDR, then why not mandate on the MN to always add
the Requested HA extension.

Thanks and sorry for the delay.

Regards,
Ahmad

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Tue, 25 Oct 2005 10:42:32 -0700

Hi Ahmad.  Comments below. 

> -----Original Message-----
> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Monday, October 24, 2005 11:53 PM
> To: Milind Kulkarni (mkulkarn)
> Cc: [email-masked]; Alpesh Patel (alpesh); Kent Leung (kleung)
> Subject: RE: [Mip4] I-D 
> ACTION:draft-ietf-mip4-dynamic-assignment-06.txt 
> 
> Hi Milind,
> My only concern is with the recommendation of setting the 
> lifetime to 5 seconds. Basically we are recommending a 2 
> round trip registration. Do you agree?
> 
> If we are ok with 2 round trip DHA registration, then I would 
> argue that we let the HA reject the first registration using 
> an appropriate code e.g. 136. This much better because in the 
> case of 5 second registration, It is more expensive since HAs 
> needs to allocate resources including the IP addresses and 
> then releasing them.
> On the other hand, 5 seconds is too short that it could 
> interfere with the retransmission mechanism due to a lost 
> registration request.
> 
> 

The 5 secs is an example only.  It's an arbitrary small value dictated
by MN implementation or configuration.  There are a few benefits of this
scheme.  First, no changes to MN or HA operation needed using a small
lifetime.  For some networks such as cdma2000, this type of issue
doesn't happen, IMHO.  So the MN can use regular lifetime value and such
registration is optimized for working scenario (without the need for 2
registration exchanges).  Maybe for WLAN which may not L2 encrypted, the
MN uses the small registration lifetime for this type of roaming
interface to overcome the possibility of such an attack.  In summary,
the scheme is optimized for networks where this issue doesn't exist and
mitigate the attack where there may be a possibility.  Both ways, it's
the same normal registration exchange and MN/HA operation.

> The other issue:
> I believe it resolves the security issue for MN with 
> co-located acre of address without any complication.
> 
> Since the MN with co-located care of address always acquire 
> the requested HA address via other means as documented in 
> section 6.0 of the draft, why not then allow the MN to use 
> the HA IP address in the HA field of the RRQ. Just like 
> regular MIPv4. unless I am missing something here, I think 
> this scenario becomes just like a regular Mobile IP registration.
> On the other hand, in case that it is required for the MN to 
> set the HA field to ALL-ZERO-ONE-ADDR, then why not mandate 
> on the MN to always add the Requested HA extension.
> 

The HA is already checking the HA address in the extension against the
destination IP address for CCoA mode.  The ALL-ZERO-ONE-ADDR in the HA
field indicates dynamic HA assignment.  

Section 5.1.2:

   If the Registration Request contains the Requested HA Extension, the
   HA address in that extension MUST match the destination IP of the
   Request.

The reason it's a "SHOULD" instead of "MUST" is that for some access
networks (e.g. GPRS/UMTS), this type of issue doesn't exists.  So, for
cellular networks, MN doesn't need to add the extension to avoid
consuming bandwidth unnecessarily.  For WLAN, MN can add the extension
for protect against this type of attack.

Section 5.1.2:

   In some cases, for the first Registration Request the MN may want to
   hint to the network to be anchored at a specific HA.  The MN SHOULD
   put that address in the HA address of the Requested HA Extension.

> Thanks and sorry for the delay.

No problem and thanks for your inputs.  

Kent

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 25 Oct 2005 13:43:02 -0500

Hi Kent,
Comments inline.

Regards,
Ahmad

> The 5 secs is an example only.  It's an arbitrary small value 
> dictated by MN implementation or configuration.  There are a 
> few benefits of this scheme.  First, no changes to MN or HA 
> operation needed using a small lifetime.  For some networks 
> such as cdma2000, this type of issue doesn't happen, IMHO.  
> So the MN can use regular lifetime value and such 
> registration is optimized for working scenario (without the 
> need for 2 registration exchanges).  Maybe for WLAN which may 
> not L2 encrypted, the MN uses the small registration lifetime 
> for this type of roaming interface to overcome the 
> possibility of such an attack.  In summary, the scheme is 
> optimized for networks where this issue doesn't exist and 
> mitigate the attack where there may be a possibility.  Both 
> ways, it's the same normal registration exchange and MN/HA operation.

[Ahmad]
The same argument can be made about the other option, allowing the HA to
reject the first registration, and that is an existing HA functionality
anyway. However, I am ok with whatever you guys pick.

> for protect against this type of attack.

[Ahmad]
Makes sense. Thanks.