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

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 29 Aug 2005 22:56:51 -0500

Hi Pete,
Sorry for the late response. Please see comments inline.

Regards,
Ahmad

> 
> Hi, Ahmad,
> 
> See below.
> 
> Ahmad Muhanna writes:
>  > Thanks Pete for bringing the discussion to the mailing list.  > 
> Please see comments inline.  >  > Regards,
>  > Ahmad
>  > 
>  > > 
>  > > 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. 
>  >  
>  > [Ahmad]
>  > Since you agree that this attack is valid and possible and 
> if this  > attack is successful with a single MN, then it is 
> possible for almost  > every MN requesting Dynamic HA on the 
> compromised FA-HA link. That could  > be devastating to the 
> HA domain. I hope you agree.
> 
> I wouldn't use the word "devastating."  If the HAs are on different 
> subnets, it creates some extra state that has no effect on the overall

> operation of the system and which will timeout after the first 
> Lifetime.

[Ahmad]
In the case where HA's assign IP addresses from local pools, this means
a waste of IP addresses. Now, if this attack is possible for one MN, it
can be possible for many MN's and probably drain HA resources of IP
addresses. It could be a real problem.

> 
> If the HAs are on the same subnet, however, it will create a 
> competition for the gratuitous/proxy ARP which would have an effect on

> the reliability of the traffic, so I can see your point of view here.
> 
>  > > 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
>  > 
>  > [Ahmad]
>  > If we think along this line, we probably do not need any 
> security  > measures in MIPv4 protocol to start with. On the 
> other hand, why RFC  > (3543) mandates the FA to have a 
> security association with the HA to  > participate in 
> registration revocation?
> 
> I am not saying we don't need security, just that we need to consider 
> the big picture.  If you think about the most likely deployment 
> scenarios for this draft, there will be a single AAA server that is 
> responsible for allocating a home agent address and for distributing 
> security associations.
> Inserting requests into a secure AAA infrastructure is a lot 
> harder than inserting a duplicate (destination address 
> modified) packet.

[Ahmad]
I am not sure about the concept of a single AAA server. Anyway, you are
basically proving my point here. You just highlighted that the reason
that we do not need to worry about this issue when the deployment uses
AAA infrastructure is that AAA infrastructure is a SECURE one. On the
other hand, you seem not to agree to make the FA-HA link a secure one
for the other deployment. Why don't we agree to make that link secure
too. It is nothing new, already existing FA and HA most probably support
registration revocation which requires FA-HA security association.

> 
> Even if the Registration Request is sent directly to an HA, it will 
> most likely be protected by an MN-AAA authentication extension, and 
> the central AAA server can prevent duplicate sessions.

[Ahmad]
You are assuming a SINGLE statefull AAA server in this one.

> 
>  > > can
>  > > pretty much prevent a mobile IP registration from taking
> place.  > 
>  > [Ahmad]
>  > Of course, that is true. That is why we need to make sure 
> that we have a  > secure solution (protocol) to prevent such 
> attacks.  > 
>  > > 
>  > > Rather, I think we should focus on the correctness of the 
>  > > protocol in the absence of attackers: 
>  > 
>  > [Ahmad]
>  > Is that a MIPv4 WG mandate or just your opinion?
> 
> Sorry, chair hat off for now.
> 
>  > > there is a requirement
>  > > for a unicast destination address on the packet so only one
>  > > HA will receive it in a normal protocol run.  
>  > 
>  > [Ahmad]
>  > Thinking of normal protocol run; If all what we are 
> looking for is just  > normal protocol run, then why do we 
> have all of these security  > associations and extensions in 
> all of the RFCs related to MIPv4  > protocol.  > 
>  > > 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.
>  > 
>  > [Ahmad]
>  > I respectfully disagree. If such attack happens, service 
> providers may  > not be able to serve their own legitimate 
> customers. It will cost them a  > lot of money.  > 
>  > > 
>  > > It seems to me that it should suffice to put in some text in 
>  > > the security considerations about this issue.  
>  > 
>  > [Ahmad]
>  > If we clearly highlight the security issue and this 
> mailing list has a  > consensus, I have no problem at all.  > 
>  > 
>  > > 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.
>  > 
>  > [Ahmad]
>  > Could you please explain to me how this is possible in a 
> case when FA is  > present in the call path. Thanks.
> 
> You are right I think - the FA would drop the extra RRPs because it 
> would be looking for a response from the unicast HA to which it sent 
> the message.  Of course, if the RRQ was sent to the AAA infrastructure

> ala RFC 4004, then there is no issue.
> 
> Perhaps what we need is a note in the security considerations that 
> mentions the possibility of multiple HAs on the same subnet getting 
> the registration request and independently authenticating it.  This 
> will be possible in some deployments and impossible (e.g., centralized

> AAA server validating MN-AAA auth extension) in others.  If it is 
> possible, then maybe we need to return a successful binding with 
> Lifetime=0 which will indicate to the MN that it needs to immediately
> re-register with the assigned HA.

[Ahmad]
I do not agree that this belongs to the security consideration section.
IMO it is more serious than that and it should be considered under the
FA consideration section. On the other hand, your suggestion (lifetime =
0) defeats the basic principle of Dynamic HA being established in a
single round trip registration. If we need to use 2 round trip
registration, I believe what RFC(3344) already has makes more sense. HA
reject the RRQ with code (136) Unknown HA Address and inserts its own
unicast IP address in the HA field of the RRP. Then MN sends RRQ using
the HA unicast IP address as per the HA address in RRP. 
> 
> -Pete
> 
> 
>  > > -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/
> 
> 
> 

-- 
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: Pete McCann <[email-masked]>
Date: Tue, 30 Aug 2005 09:26:40 -0500

Hi, Ahmad,

I think I see your point now, but I still disagree that we need to
mandate FA-HA security association in all cases.  Think about the MIP4
Diameter application where the security is hop-by-hop: the RRQ arrives
at the HA via the AAA server and the HAs can be configured to accept
initial RRQs only from this interface.  I don't think we need to
require the FA/HA MSA in this case; it is provided indirectly via the
hop-by-hop AAA security.

-Pete