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

From: Pete McCann <[email-masked]>
Date: Thu, 25 Aug 2005 10:57:50 -0500

Hi,

[back on the mailing list now]

This thread concerns the possibility of having more than one HA create
a binding for a given MN.  It seems true that the RRQ created by the
MN, if delivered to multiple HAs, could potentially create state on
each of those HAs.  However, I think we are making too much out of the
possibility.  An attacker that has the power to duplicate packets
(changing the destination IP address) and drop selected packets can
pretty much prevent a mobile IP registration from taking place.

Rather, I think we should focus on the correctness of the protocol in
the absence of attackers: there is a requirement for a unicast
destination address on the packet so only one HA will receive it in a
normal protocol run.  I do not think we need to add special mechanisms
like the infinite/short lifetime that is being proposed or the
requirement for an FA-HA MSA.  I think these requirements would
unfairly limit the deployment possibilities.

It seems to me that it should suffice to put in some text in the
security considerations about this issue.  We might also consider
adding text that says if the MN gets RRPs from more than one HA it
must immediately de-register the extra unwanted bindings.

-Pete

Ahmad Muhanna writes:
 > Aplesh,
 > 
 > Comments inline.
 > 
 > Regards,
 > Ahmad
 > 
 > 
 > > -----Original Message-----
 > > From: Alpesh Patel (alpesh) [mailto:[email-masked]] 
 > > Sent: Wednesday, August 24, 2005 8:44 PM
 > > To: Henrik Levkowetz; Muhanna, Ahmad [RICH2:2Q30:EXCH]
 > > Cc: Peter McCann; Margaret Wasserman; Kent Leung (kleung); 
 > > Milind Kulkarni (mkulkarn); Joel M. Halpern; Khalil, Mohamed 
 > > [RICH2:2S20:EXCH]; Alpesh Patel (alpesh)
 > > Subject: RE: [Mip4] Re: LC review: 
 > > draft-ietf-mip4-dynamic-assignment-05.txt
 > > 
 > > 
 > > Henrik:
 > > 
 > > In regards to Ahmad's original comment, we have one suggestion:
 > > 
 > > If the rogue node changes the destination address enroute to 
 > > the HA and sends the RRQ to multiple HA's, the most that can 
 > > go wrong is multiple HA's creating a binding for the MN.
 > > 
 > [Ahmad]
 > I believe that is a big deal. It means that multiple resources will be
 > allocated for the same MN, including IP address which is very precious
 > in MIPv4. It also could have impact on billing at the HA.
 > 
 > > The rogue has to first figure out all the HA's addresses - 
 > > this may not be trivial.
 > 
 > [Ahmad]
 > Well, I do not want to debate this but the fact it is possible then it
 > is an issue.
 > 
 > > 
 > > Also, a good MN implementation will deregister when it 
 > > receives multiple Registration Replies (if the rogue 
 > > succeeded in doing its trick). So, there is not a problem here.
 > 
 > [Ahmad]
 > Where is that documented? Can you please give a reference to this. 
 > 
 > > 
 > > Also, the rogue cannot mount a "store and replay" attack - 
 > > this window of vulnerability is limited only within the 
 > > replay window - otherwise the HA's will reject the 
 > > Reigstration Replies anyway.
 > 
 > [Ahmad]
 > I agree that this attack is limited to the replay window. However, it is
 > very simple and can happen.
 > 
 > > 
 > > How about adding text to the following effect:
 > > 
 > > When requesting dynamic HA assignment, MN SHOULD not set the 
 > > lifetime field to infinity (0xffff). If lifetime requested is 
 > > infinite, HA MUST set it to a low value and send a 
 > > Registration Reply. (This will mitigate the risk of lingering 
 > > binding entries at HA's - in case the Registration Reply from 
 > > other HAs' are lost).
 > 
 > [Ahmad]
 > Let us assume that the MN ends up registering at multiple HA's. As per
 > the RFC3543 "Registration Revocation", we need a security association
 > between the FA and the HA in order to revoke this false binding. On the
 > other hand, we do not have the same requirement for establishing the
 > binding to start with. Does that make sense?.
 > 
 > > 
 > > Subsequent registration requests with the HA where MN is 
 > > anchored can have default behavior.
 > > 
 > > So, if the rogue is succesful in mounting this type of 
 > > attack, it will be short lived (limited to lifetime).
 >  
 > [Ahmad]
 > Basically you agree to publish a standard with a security vulnerability
 > as long as it is short lived?
 > I understand that there is a limited audience on this thread, but I
 > guess some carriers may not like that limitation.
 > 
 > Also, 
 > > this attack will be successful only if the Reply from the 
 > > HAs' do not reach the MN. 
 > 
 > [Ahmad]
 > I disagree, same comment as above. Is that documented anywhere?.
 > 
 > Finally, I have no issue to publish the draft (as is) as long as you
 > document the security vulnerability as per your statement below.
 > " So, if the rogue is succesful in mounting this type of attack, it will
 > be short lived (limited to lifetime)"
 > 
 > Another alternative: we can add this under section 5.2 Foreign Agent
 > Considerations: 
 >    During the registration process, if the foreign agent wishes to
 >    participate in dynamic home agent allocation process with the home
 > domain, 
 >    it MUST have an existing security association with the home agent 
 >    that has been identified to serve the registration request.
 > > 
 > > Comments/Suggestions?
 > > Alpesh 
 > > 
 > > > -----Original Message-----
 > > > From: Henrik Levkowetz [mailto:[email-masked]]
 > > > Sent: Saturday, August 20, 2005 6:42 PM
 > > > To: Ahmad Muhanna
 > > > Cc: Peter McCann; Margaret Wasserman; Kent Leung (kleung); 
 > > > Milind Kulkarni (mkulkarn); Alpesh Patel (alpesh); Joel M. 
 > > > Halpern; Mohamed Khalil
 > > > Subject: Re: [Mip4] Re: LC review: 
 > > > draft-ietf-mip4-dynamic-assignment-05.txt
 > > > 
 > > > -----BEGIN PGP SIGNED MESSAGE-----
 > > > Hash: SHA1
 > > > 
 > > > Hi Ahmad,
 > > > 
 > > >     Comments below.  Milind, Alpesh, Kent - would you check
 > > > this, please?
 > > > 
 > > > 
 > > > On 2005-08-20 23:23 Ahmad Muhanna said the following:
 > > > > Hi Pete/Henrick,
 > > > > 
 > > > > 
 > > > > As chairs for the Mip4 working group, I would like to get your
 > > > > feedback on the security issue identified in my posting dated 
 > > > > 6/22/205. email attached. In that posting I identified a security 
 > > > > issue which could cause a MN to register with multiple 
 > > HAs. No one 
 > > > > apparently showed interest in this issue including the authors. 
 > > > > However, I believe that the group needs to conclude if it 
 > > > is an issue
 > > > > or not before this draft becomes a standard.
 > > > > 
 > > > > This email is not posted to the mip4 list.
 > > > > 
 > > > > Please let me know what you think of this.
 > > > > Thanks!
 > > > > 
 > > > 
 > > > [snip copy of later mail from Joel Halpern]
 > > > 
 > > > > Hello all,
 > > > > 
 > > > > My apologies in advance if this issue has been discussed 
 > > before. If
 > > > > that is true, can someone let me know of the conclusion. Thanks!
 > > > > 
 > > > > As per section 5.3.1 Assigned Home Agent Considerations, 
 > > I find the
 > > > > following paragraph:
 > > > > "
 > > > > As per the messaging proposed here, the mobile node (or 
 > > the foreign
 > > > > agent) sends the Registration Request to the Requested HA 
 > > address, 
 > > > > which is a unicast address. Therefore, this document does 
 > > > not specify
 > > > > any new behavior for the case where the HA receives a
 > > > subnet directed
 > > > > broadcast Registration Request as specified in section
 > > > 3.8.2.1 of the
 > > > > Mobile IPv4 specification [1]. Although the Home Agent 
 > > field in the
 > > > > Registration Request is not a unicast address, the destination IP 
 > > > > address is a unicast address. This avoids the problem 
 > > > associated with
 > > > > subnet-directed broadcast destination IP address that may 
 > > result in
 > > > > multiple HAs responding. Thus, there is no need to deny the 
 > > > > registration as stated in Mobile IPv4 [1] section 3.8.3.2."
 > > > > 
 > > > > My question here is how by setting the destination IP
 > > > address of the
 > > > > IP packet to the HA unicast IP address guarantee that MN 
 > > will avoid
 > > > > the possibility of being registered with multiple HAs?
 > > > > 
 > > > > What I have in mind here, is the possibility of someone
 > > > listening on
 > > > > that link and all what is needed is to include the RRQ in
 > > > an IP packet
 > > > > with the destination IP address is set to a different HA. In other
 > > > > words, any HA receives this RRQ can process this RRQ and send a 
 > > > > confirmation reply to the MN and MN ends up registering 
 > > > with multiple
 > > > > HAs.?
 > > > 
 > > > This would be the case when an MN registers directly with a
 > > > HA, with a co-located care-of address, and does not include 
 > > > the requested HA extension.
 > > > 
 > > > I believe you are right that there is a possibility of a bad
 > > > guy causing a registration with more than one HA in this 
 > > > case.  This would result in the MN receiving registration 
 > > > replies from multiple HAs, if more than one HA would decide 
 > > > to accept the registration.
 > > > 
 > > > The solution could be to specify that the inclusion of a
 > > > Requested HA extension would be a MUST in all cases, with the 
 > > > HA being required to verify that the HA address in the 
 > > > Requested HA extension matches its own address.
 > > > 
 > > > 
 > > > 	Henrik
 > > > -----BEGIN PGP SIGNATURE-----
 > > > 
 > > > iD8DBQFDB9vjeVhrtTJkXCMRAhxDAKCAVB5dw98q6fNcHe/r7qmbLd9vJQCg4oLd
 > > > 9k8rjzf6t7VTAI/L1rLu8cg=
 > > > =Wo9C
 > > > -----END PGP SIGNATURE-----
 > > > 
 > > 
 > > 

-- 
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: Thu, 25 Aug 2005 22:42:55 +0200

> must immediately de-register the extra unwanted bindings.

Certainly makes sense to me.

	Henrik