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

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 19 Aug 2005 14:46:06 -0400

Gen_Art last call review of  Mobile IPv4 Dynamic Home Agent Assignment
     draft-ietf-mip4-dynamic-assignment-05.txt

The General Area Review Team (Gen_Art) serves as a review team for the IETF 
Chair.
We are asked to review documents being considered by the IESG, and where 
possible to provide reviews during or after IETF last call.
The Gen-Art reviewer is selected by a quasi-random process from the team.
I have been selected to review this document.

This is a re-review, following up on a review done of -03.

This draft is almost ready for publication as a Proposed Standard 
RFC.  However, one item that had been noted earlier still leaves room for 
ambiguity about certain fields:

Sections 4.2 and 4.2.1 still do not identify what value is placed in the HA 
Address field of the second registration request, after the redirect has 
been received.  Whatever behavior is intended (put the new HA address in 
the HA Address field, or continue to put ALL-ZERO-ONE-ADDR in the HA 
Address field to allow for further redirection, or either one) should be 
stated.  This was in my earlier comments, and had been acknowledged as 
reasonable.  (Sections 5.1.1 and 5.1.2 note that the new HA address must be 
placed in the Requested HA Extensions, but that does not answer the 
question of what goes in the HA Address field of the packet.)

Nits:
     This document is using an out of date IPR clause.  I don't know if it 
needs to be updated. 

-- 
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: "Kent Leung \(kleung\)" <[email-masked]>
Date: Fri, 19 Aug 2005 15:02:48 -0700

OK, we'll submit rev 06 after fixing the identified issues.  Thanks.

Kent

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]] 
> Sent: Friday, August 19, 2005 2:30 PM
> To: Kent Leung (kleung); [email-masked]; Henrik 
> Levkowetz; Margaret Wasserman
> Cc: Milind Kulkarni (mkulkarn); Alpesh Patel (alpesh); Peter 
> McCann; [email-masked]
> Subject: RE: LC review: draft-ietf-mip4-dynamic-assignment-05.txt
> 
> The proposed replacement for bullet 5 in 4.2.1 works for me.  
> Thank you.
> 
> With regard to the IPR, Henrik's very nice IDnits checker reports:
> 
>      Checking conformance with RFC 3978/3979 boilerplate...
>    * The document seems to lack an RFC 3978 Section 5.5 Disclaimer --
>      however, there's a paragraph with a matching beginning. 
> Boilerplate
>      error?
>    * The document seems to lack an RFC 3979 Section 5, para 1 IPR
>      Disclosure Acknowledgement -- however, there's a paragraph with a
>      matching beginning. Boilerplate error?
>    * The document seems to lack an RFC 3979 Section 5, para 2 IPR
>      Disclosure Acknowledgement -- however, there's a paragraph with a
>      matching beginning. Boilerplate error?
> 
> Yours,
> Joel
> 
> PS: Thank you for the prompt reply.
> At 03:12 PM 8/19/2005, Kent Leung \(kleung\) wrote:
> > > Sections 4.2 and 4.2.1 still do not identify what value 
> is placed in 
> > > the HA Address field of the second registration request, 
> after the 
> > > redirect has been received.  Whatever behavior is 
> intended (put the 
> > > new HA address in the HA Address field, or continue to put 
> > > ALL-ZERO-ONE-ADDR in the HA Address field to allow for further 
> > > redirection, or either
> > > one) should be stated.  This was in my earlier comments, and had 
> > > been acknowledged as reasonable.
> >
> >The HA address field is set to ALL-ZERO-ONE-ADDR to signify 
> that MN is 
> >still registering in dynamic HA assignment mode.  So step 5 
> of 4.2.1 is 
> >same as step 1 in the section.
> >
> >So proposed new text in 4.2.1:
> >
> >5.  If the MN can authenticate the Reply, the MN extracts the HA 
> >address from the Redirected HA Extension.  The MN then sends a 
> >Registration Request to the Redirected HA, unless it has already 
> >received a redirection response from that HA while processing the 
> >Registration Request.  The Home Agent address field in this 
> >Registration Request is set to ALL-ZERO-ONE-ADDR.  The MN 
> may choose to 
> >add Requested HA extension in this new Registration Request.
> >
> >
> > >(Sections 5.1.1 and
> > > 5.1.2 note that the new HA address must be placed in the  
> Requested 
> > >HA Extensions, but that does not answer the  question of 
> what goes in 
> > >the HA Address field of the packet.)
> > >
> >
> >See above.
> >
> >
> > > Nits:
> > >      This document is using an out of date IPR clause.  I 
> don't know 
> > > if it needs to be updated.
> > >
> >
> >Hmm, this seems up to date.  Pls provide some more details so we can 
> >fix this up.
> >
> >Thanks for the review.
> >
> >Kent
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 30 Aug 2005 10:45:19 -0500

Hi Pete,

I agree on the example you just mentioned. However, it seems that we
agree on the concept but differ on the wording. What about if we come up
with something generic to all cases and more specific to others. I will
try by adding the following. Please feel free to comment or modify as
needed.

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 a home 
   domain, it MUST utilize a mechanism that provides secure transmission

   of the registration request to the home agent which is identified to 
   server this registration request. In the case where FA relays the
registration 
   request directly to the home agent, Foreign Agent must have an
existing 
   security association with that home agent.

What do you think?

Regards,
Ahmad

> From: Pete McCann [mailto:[email-masked]] 
> Sent: Tuesday, August 30, 2005 9:27 AM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: Margaret Wasserman; [email-masked]; Alpesh Patel (alpesh); 
> Joel M. Halpern; Kent Leung (kleung); Henrik Levkowetz; 
> Milind Kulkarni (mkulkarn); Khalil, Mohamed [RICH2:2S20:EXCH]
> Subject: RE: [Mip4] Re: LC review: 
> 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
> 
> 
> Ahmad Muhanna writes:
>  > 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
>  > >  > >  > 
>  > >  > >  > 
>  > >  > >  > > 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: 
>  > >  > >  > > 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 
>  > >  > >  > > 
>  > >  > >  > > > 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: 
>  > >  > >  > > > -----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-----
> 
> 
> 
>

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Tue, 30 Aug 2005 08:59:52 -0700

Hi Ahmad and Pete.

I think there there are 2 methods to address the issue, which is
arguably unlikely scenario, IMHO.  The pros and cons of the solution is
restriction of mandatory SA between FA and HA vs. 2 round trips.

1) Use FHAE to protect that FA-HA signaling path. Since not every FA and
HA will have an SA, this is a major limiting factor.

2) Either use a short lifetime value for initial registration reply by
the HA which mitigates any malicious effort to a few seconds or reject
RRQ outright and have MN re-register once more with HA field set.

I personally favor one of the choices in option #2.

Kent

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Tuesday, August 30, 2005 8:45 AM
> To: Pete McCann
> Milind Kulkarni (mkulkarn); Mohamed Khalil
> I agree on the example you just mentioned. However, it seems 
> that we agree on the concept but differ on the wording. What 
> about if we come up with something generic to all cases and 
> more specific to others. I will try by adding the following. 
> Please feel free to comment or modify as needed.
> 
>    server this registration request. In the case where FA 
> relays the registration 
>    request directly to the home agent, Foreign Agent must 
> have an existing 
> > Cc: Margaret Wasserman; [email-masked]; Alpesh Patel 
> (alpesh); Joel M. 
> > Halpern; Kent Leung (kleung); Henrik Levkowetz; Milind Kulkarni 
> > (mkulkarn); Khalil, Mohamed [RICH2:2S20:EXCH]
> > 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
> > 
> > 
> > Ahmad Muhanna writes:
> >  > Hi Pete,
> 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]
> 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]
> 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  > 
> >  > 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.  >  > >  
> > >  > >  > 
> >  > >  > > 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  > > 
> > > 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  > >  > 
> >  > >  > 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  > >  > > 
> >  > >  > 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  > > 
> >  > > 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
> > > > 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)  > >  > >  > > 
> >  > >  > >  > > 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.  >  > 
> >  > >  > >  > 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]
> >  > >  > >  > > 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  > 
> hand, we  > 
> > >  > > do not have the same requirement for establishing 
> the  >  > >  
> > > > binding to start with. Does that make sense?.  >  > >  
> > >  > >  > 
> > > >  > >  > > 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  > >  > 
> >  > >  > >  > 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  > >  > > 
> >  > >  > >  > > > -----Original Message-----  > >  > >  > > > From: 
> > Henrik Levkowetz  > > [mailto:[email-masked]]  > >  > 
> > > Sent: 
> > Saturday,  > > August 20, 2005 6:42 PM  > >  > > > To: 
> Ahmad Muhanna  
> > (kleung);  > >  > >  > > > Milind Kulkarni (mkulkarn); Alpesh Patel 
> > (alpesh); Joel M.  > >  > >  > > > Halpern; Mohamed Khalil  
> > >  > >  
> > > > > Subject: Re: [Mip4] Re: LC review:
> >  > >  > >  > > > -----BEGIN PGP SIGNED MESSAGE-----  > >  > 
> >  > > > 
> > Hash: SHA1  > >  > >  > > >  > >  > >  > > > Hi Ahmad,  > > 
>  > >  > > 
> > >
> >  > >  > >  > > > 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.  > >  > >  > > > >  > 
> >  > >  > 
> >  > >  > >  > > > [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:
> >  > >  > >  > > > > "
> 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.?
> >  > >  > >  > > >
> > > >  > > not include  > >  > >  > > > the requested HA extension.
> >  > >  > >  > > >
> 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.
> >  > >  > >  > > >
> 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-----  > >  > >  > 
> > >  > >  
> > > >  > > >  > >  > > 
> >  > >  > >  > > > 9k8rjzf6t7VTAI/L1rLu8cg=  > >  > >  > > > 
> =Wo9C  > >

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 30 Aug 2005 11:47:11 -0500

Hi Kent,

I would recommend keeping both. 
I mean we could specify that in the case of using one round trip
registration for Dynamic HA, an FHAE is needed to protect the RRQ. On
the other hand, if FA-HA SA is not available, a two round trip RRQ is
required as specified in RFC3344.

If we agree on the concept, then we can come up with some wording.

Regards,
Ahmad

> From: Kent Leung (kleung) [mailto:[email-masked]] 
> Sent: Tuesday, August 30, 2005 11:00 AM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; Pete McCann
> Joel M. Halpern; Henrik Levkowetz; Milind Kulkarni 
> I think there there are 2 methods to address the issue, which 
> is arguably unlikely scenario, IMHO.  The pros and cons of 
> the solution is restriction of mandatory SA between FA and HA 
> vs. 2 round trips.
> 
> 1) Use FHAE to protect that FA-HA signaling path. Since not 
> every FA and HA will have an SA, this is a major limiting factor.
> 
> 2) Either use a short lifetime value for initial registration 
> reply by the HA which mitigates any malicious effort to a few 
> seconds or reject RRQ outright and have MN re-register once 
> more with HA field set.
> 
> > >  > Sorry for the late response. Please see comments inline.  >
> > >  > Regards,
> > >  > Ahmad
> > >  >
> > >  >
> > >  > >
> > >  > > Hi, Ahmad,
> > >  > >
> > >  > > See below.
> > >  > >
> > >  > > Ahmad Muhanna writes:
> > > revocation which requires FA-HA security association.  >  
> > >  > > 
> > > all of these security  > associations and extensions in  
> > > all of
> > > infrastructure  >  > > ala RFC 4004, then there is no issue.  > >
> considerations 
> > > the RRQ to multiple HA's, the most  > > that can  > >  > 
> >  > > go 
> > > succeeded in doing its trick). So, there is not a  > >  > 
> > problem
> > >  > >  > >  > > > > Please let me know what you think of 
> this.  > >  
> > > > >  > > > > Thanks!  > >  > >  > > > >
> > >  > >  > >  > > >
> > > registered with multiple  > >  > > HAs?  > > > >  > >  > 
> >  > > > >