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

["Kent Leung \(kleung\)" <[e-mail]>]

Hi Ahmad.  Comments below. 

> -----Original Message-----
> From: Ahmad Muhanna [mailto:[e-mail]] 
> Sent: Monday, October 24, 2005 11:53 PM
> To: Milind Kulkarni (mkulkarn)
> Cc: [e-mail]; Alpesh Patel (alpesh); Kent Leung (kleung)
> Subject: RE: [Mip4] I-D 
> ACTION:draft-ietf-mip4-dynamic-assignment-06.txt 
> 
> 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 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

-- 
Mip4 mailing list: [e-mail]
    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/