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

From: "Milind Kulkarni \(mkulkarn\)" <[email-masked]>
Date: Fri, 9 Sep 2005 12:14:55 -0700

Thanks Henrik. Text below incorporates your suggestions. Will wait few
days for any more comments, before publishing next version of the draft.

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.  A
Mobile Node SHOULD minimize the risk of this scenario by sending
deregistrations to the HA from which the additional registration replies
are received after a successful registration."

Milind 

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

Hi Milind,

On 2005-09-09 00:06 Milind Kulkarni (mkulkarn) said the following:

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

Good as far as it goes, but I'd prefer to also add a SHOULD regarding MN
de-registration of additional replies earlier in the document, where MN
behaviour is discussed.

	Henrik

-- 
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, 09 Sep 2005 22:28:45 +0200

Hi Milind

> days for any more comments, before publishing next version of the draft.

Right, thanks - except I believe it should be in section 5.1.2, as part
of the Mobile Node considerations.  Adding required or recommended behaviour
in the Security Considerations isn't so good, it should all be in the
protocol description part of the draft.

Regards,

	Henrik

---

From: Pete McCann <[email-masked]>
Date: Fri, 9 Sep 2005 15:47:10 -0500

Do we need some additional text that requires the FA to relay the
spurious Registration Replies to the MN for the case of FA-located
CoA?

-Pete

Henrik Levkowetz writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > Hi Milind
 > 
 > -----BEGIN PGP SIGNATURE-----
 > 
 > iD8DBQFDIfB9eVhrtTJkXCMRAlgLAJ92szzVziBQs8ObADiVs2ETD17soQCffb6P
 > 5Nu1VUwJG3y95Fl/QzKNzyc=
 > =yWLY
 > -----END PGP SIGNATURE-----

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 09 Sep 2005 23:21:43 +0200

> spurious Registration Replies to the MN for the case of FA-located

Yes, I think that would be good, too.  Of course, we can't in any way
rely on an FA doing so, as legacy FA's won't have any clue about this,
but for new compliant FAs this would be the right thing to do, I believe.

	Henrik