Subject: RE: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt

From: [email-masked]
Date: Thu, 15 Sep 2005 15:08:52 -0700

Hello Ahmad,

Your suggested text changes look good to me. I am reproducing your text
here for reference again:

9. Security Considerations 

"There is a possibility of having more than one HA creating a mobility
binding entry for a given MN, if a man in the middle captures the RRQ
and forwards it to other HAs in the network.  However, this scenario
assumes that the rogue node can find out addresses of those HAs in the
network. It also assumes that the rogue Mobile 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 some cases, a Mobile Node may receive
additional successful registration replies from these HAs and the Mobile
Node may choose to minimize the risk of this scenario by sending
deregistrations to these HAs."

Question for Henrik: 
The last line of above paragraph doesn't say "the Mobile Node SHOULD
...". Is that ok? I am reluctant to add the text "the Mobile Node SHOULD
minimize the risk of this scenario..." in the MN Considerations Section,
because we will have to add this scenario there again or at least
reference it. Is that ok?

Thanks again,
Milind

-----Original Message-----
From: Ahmad Muhanna [mailto:[email-masked]] 
Sent: Monday, September 12, 2005 5:54 AM
To: Milind Kulkarni (mkulkarn); Henrik Levkowetz
Cc: Kent Leung (kleung); Joel M. Halpern; Pete McCann; [email-masked];
Margaret Wasserman; Alpesh Patel (alpesh); Mohamed Khalil
Subject: RE: [Mip4] Re: LC review:
draft-ietf-mip4-dynamic-assignment-05.txt

Hi Milind,
If this approach gets consensus over other proposed solutions, I believe
it, in general, captures the security limitation and concern. 
However, a couple of minor comments inline and a proposed modification..

Regards,
Ahmad

> ----- End Original Message-----
> 
> Hello all,
> 
> In order to make progress on this issue, I am proposing following 
> additional text. Please provide your comments/suggestions.
> 
> 
> 9. Security Considerations
> 
> "There is a possibility of having more than one HA creating a mobility

> binding entry for a given MN, if a man in the middle captures the RRQ 
> and forwards it to different Has in the network.  However, this 
> scenario assumes that the rogue node has the capability to store and 
> duplicate packets, and can find out addresses of the HAs in the 
> network. Time window of this scenario is limited to only within the 
> replay window - otherwise the HAs will reject the Registration 
> Requests anyway.
 
[Ahmad]
It gives the impression that the rogue node needs to find out the HA's
addresses within the replay window, which is not necessary.

> A Mobile Node may choose to minimize the risk of this scenario by 
> sending deregistrations to the HA from which the additional 
> registration replies are received after a successful registration."
> 
[Ahmad]
This also gives the impression that the Mobile Node always receives
additional replies which is not true in the case when FA is in the call
path.

I would like to suggest a slight modification as follows or any similar
text:

9. Security Considerations 

"There is a possibility of having more than one HA creating a mobility
binding entry for a given MN, if a man in the middle captures the RRQ
and forwards it to other HAs in the network.  However, this scenario
assumes that the rogue node can find out addresses of those HAs in the
network. It also assumes that the rogue Mobile 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 some cases, a Mobile Node may receive
additional successful registration replies from these HAs and the Mobile
Node may choose to minimize the risk of this scenario by sending
deregistrations to these HAs.
"
> Thanks,
> Milind

-- 
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: Henrik Levkowetz <[email-masked]>
Date: Fri, 16 Sep 2005 00:28:33 +0200

Hi Milind,

on 2005-09-16 00:08 [email-masked] said the following:
[...]
> reference it. Is that ok?

I believe a SHOULD in the MN considerations section is appropriate, and
also, following Pete's comment, a SHOULD or MUST in the FA considerations
(i.e., an FA must forward additional registration replies so that an MN
 can de-register them - see Pete's earlier comment for details).  Leaving
the needed text out of the MN and FA considerations section doesn't seem
like a good way to go.

	Henrik