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

From: "Alpesh Patel \(alpesh\)" <[email-masked]>
Date: Fri, 2 Sep 2005 12:41:45 -0700

Ahmad:

I am not convinced that having FHAE is required. There is no FHAE 
deployment today and mandating one as part of this draft is an
overburden.

If you look back at the threat models I mentioned in one of the previous
emails, FHAE comes in handy if there is a rouge between FA and HA
changing the destination IP and forwarding the RRQ to multiple HAs'.
This
I think is not the threat model that we should be too much concerned
about.

The valid threat model is when a rogue on the MN/FA link changes the dst
IP
And forwards to multiple HAs. In that case, the MN will receive multiple

replies (since the FA had multiple outstanding RRQs that the rogue
generated).

In this case, we can put text in Security Considerations stating that
the MN
Must deregister if it receives multiple replies.

If we are really paranoid about the first scenario, we can highlight
this in
Security Considerations and put text that one way to mitigate is by
reducing
the lifetime of initial RRQ.

Wondering what the co-chairs/ADs are thinking. Maybe they can be the 
tie-breaker in this scenario :)

-a 

> -----Original Message-----
> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Tuesday, August 30, 2005 9:47 AM
> To: Kent Leung (kleung); Pete McCann
> Cc: Margaret Wasserman; [email-masked]; Alpesh Patel (alpesh); 
> Joel M. Halpern; Henrik Levkowetz; Milind Kulkarni 
> (mkulkarn); Mohamed Khalil
> Subject: RE: [Mip4] Re: LC review: 
> draft-ietf-mip4-dynamic-assignment-05.txt
> 
> 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
> 
> 
> > -----Original Message-----
> > From: Kent Leung (kleung) [mailto:[email-masked]]
> > Sent: Tuesday, August 30, 2005 11:00 AM
> > To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; Pete McCann
> > Cc: Margaret Wasserman; [email-masked]; Alpesh Patel 
> (alpesh); Joel M. 
> > Halpern; Henrik Levkowetz; Milind Kulkarni (mkulkarn); 
> Khalil, Mohamed 
> > [RICH2:2S20:EXCH]
> > Subject: RE: [Mip4] Re: LC review: 
> > draft-ietf-mip4-dynamic-assignment-05.txt
> > 
> > 
> > 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
> > 
> > > -----Original Message-----
> > > From: Ahmad Muhanna [mailto:[email-masked]]
> > > Sent: Tuesday, August 30, 2005 8:45 AM
> > > To: Pete McCann
> > > Cc: Margaret Wasserman; [email-masked]; Alpesh Patel 
> (alpesh); Joel 
> > > M. Halpern; Kent Leung (kleung); Henrik Levkowetz; Milind 
> Kulkarni 
> > > (mkulkarn); Mohamed Khalil
> > > Subject: RE: [Mip4] Re: LC review: 
> > > draft-ietf-mip4-dynamic-assignment-05.txt
> > > 
> > > 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
> > > 
> > > 
> > > > -----Original Message-----
> > > > 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: 
> > > > draft-ietf-mip4-dynamic-assignment-05.txt
> > > > 
> > > > 
> > > > 
> > > > 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
> > > >  > >  > >  >
> > > >  > >  > >  >
> > > >  > >  > >  > > -----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: "Alpesh Patel \(alpesh\)" <[email-masked]>
Date: Fri, 2 Sep 2005 15:23:11 -0700

Ahmad:

Please see line ... 

> Sent: Friday, September 02, 2005 3:05 PM
> To: Alpesh Patel (alpesh); Kent Leung (kleung); Pete McCann
> Cc: Margaret Wasserman; [email-masked]; Joel M. Halpern; 
> Henrik Levkowetz; Milind Kulkarni (mkulkarn); Mohamed Khalil
> Hi Alpesh,
> Please see my comments inline.
> 
> Regards,
> Ahmad
> 
> > 
> > 
> > Ahmad:
> > 
> I was trying to address the comment that was raised by Kent. 
> However, my preference is to mandate a security association 
> between the FA and the HA which could be through FHAE, IPSec, 
> etc. I believe this is a valid requirement and it is already 
> mandated by RFC3543, registration revocation under section 4.2.1:
> "
> 4.2.1.  Negotiation of Revocation Support
> 
>    participate in revocation messages with the home domain, 
> it MUST have
>    an existing security association with the home agent identified in
>    the registration request, and append a revocation support extension
>    (defined in Section 3.2.) to it. 
> .......
> "

ASP>> I am not doubting the existence of FHAE and it certainly is needed
For RFC3543 - note that it is an explicit signalling between FA and HA.

> 
> > If you look back at the threat models I mentioned in one of the 
> > previous emails, FHAE comes in handy if there is a rouge between FA 
> > and HA changing the destination IP and forwarding the RRQ 
> to multiple 
> > HAs'. This I think is not the threat model that we should 
> be too much 
> > concerned about.
> 
> [Ahmad]
> I respect your personal opinion. But in reality it is a real issue.
> 

ASP>> Ahmad, can you show me how it is a real issue. I am trying to 
understand the network environment where this is really feasible. Maybe
that will help me clarify the issue you are raising. 

> > 
> > The valid threat model is when a rogue on the MN/FA link 
> changes the 
> > dst IP And forwards to multiple HAs. In that case, the MN 
> will receive 
> > multiple
> > 
> I am not sure if this is a valid scenario that we need to worry about.
> Can you please elaborate more?
> 

ASP>> On the link connecting the MN to the FA - for example a
Open wifi link, a rogue can intercept the RRQ and then keep
Forwarding the RRQ to multiple HA's (in the HAs domain) by changing
the destination IP. My thinking is that this is a feasible attack -
should
Say more feasible than doing so on the FA/HA path (but maybe your
Clarification to the above help me).

> > the MN Must deregister if it receives multiple replies.
> > 
> > 
> > this in Security Considerations and put text that one way 
> to mitigate 
> > is by reducing the lifetime of initial RRQ.
> 
> [Ahmad]
> I am not sure what do you mean by paranoid here. I am really 
> amazed that you still using this word. Anyway, It is probably 
> more beneficial to stay focused on the technical issue than 
> the feelings. Once more, this is not the first time that a 
> security association between the FA and HA is mandated. 
> Please see comment above.
> 

ASP>> My apologies, there was no intention to express or stir 
feelings and it was not directed to you - I am in it too - please see
the "we".

Ofcourse, as mentioned at the beginning, I am not doubting
FHAE - will wait for the scenario where this is realistic. 

-a

> > > M. Halpern; Henrik Levkowetz; Milind Kulkarni (mkulkarn); Mohamed 
> > > Khalil
> > > 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.
> > > 
> > > > > > resources of IP  > addresses. It could be a real
> > problem.  > >
> > > > > >  > >  > Is that a MIPv4 WG mandate or just your 
> opinion?  > >  
> > > > > >  > >  > > there is a requirement  > >  > > for a unicast 
> > > > > > destination address on the packet
> > > > > so only one
> > > > > > mailing list has a  > consensus, I have no problem at
> > all.  > >
> > > > > > >
> > > > > > Patel (alpesh) [mailto:[email-masked]]  > >  > >  
> > > Sent: 
> > > > > > > >  > > [RICH2:2S20:EXCH]; Alpesh Patel (alpesh)  >
> > >  > >  > >
> > > > > > reject the  > >  > >  > > Reigstration Replies
> > anyway.  > >  > >
> > > > > > >  > >  > >  > [Ahmad]
> > > > > > following:  > >  > > > > Hi Pete/Henrick,  > >  > > 
> > >  >  > 
> > > > > > >  > >
> > > > > > before this draft becomes a standard.  > >  > >  > >
> > > >  >  > >
> > > > > > >
> > > > > > document does  > >  > >  > > > not specify  > >  > >
> > > > > any
> > > > > > new behavior for the case where the HA receives  > 
> >  > > a  >
> > > > > > > subnet
> > > > > > Mobile IPv4 specification [1]. Although the Home
> > Agent  > >  > >
> > > > > > > field
> > > > > > multiple HAs responding. Thus, there is no need  > >
> > to deny the
> > > > > > >  > >  > >
> > > > > > > > registration as stated in Mobile IPv4 [1] section
> >  > >  > >
> > > > > > to include the RRQ in  > > > an IP packet  > > >  > >
> >  > > with
> > > > > > the destination IP address is set to a different HA.
> > > > > > reply to the MN and MN ends up registering  > >  > >
> > > > > with
> > > > > > multiple  > >  > >  > > > > HAs.?  > >  > >  > > >  
> > >  > >

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sun, 4 Sep 2005 22:53:24 -0500

Absolutely.

Regards,
Ahmad

> Sent: Sunday, September 04, 2005 10:19 AM
> Henrik Levkowetz; Milind Kulkarni (mkulkarn); Khalil, Mohamed 
> [RICH2:2S20:EXCH]; Pete McCann; Alpesh Patel (alpesh)
> Let me clarify my position.
> 
> I had summarized the solution options which were discussed.  
> This does not mean that I think this problem is really a big 
> issue.  Actually, I think it's just a nit.  
> 
> I don't think FHAE is needed in the solution.  Having this 
> requirement is too restrictive.  We should not go down this path.
> 
> So if someone can offer a solution that doesn't need FHAE 
> _and_ doesn't require 2 round trips to establish the dynamic 
> HA session, would you agree to go with that?
> 
> Kent
> 
>  
> 
> Think about 
> > > > > > > the MIP4 Diameter application where the
> > > security is
> > > > > > > to  > participate in  > > registration revocation?  > >
> > > > > > > de-register the extra  > >  > > unwanted bindings.  > >  >
> > > > > > >  > >  > [Ahmad]
> > > > > > > case when FA is  > present in the call path. Thanks.  > >
> > > > > > > > > >  > >  > >  > > > > Hello all,  > >  > >  > 
> > > > > > > specified in section  > > > 3.8.2.1 of the  > > > 
>  > >  > >
> > > > > > > > listening on  > > > > that link and all what  > 
> >  > > is
> > > > > > needed is
> > > > > > > the destination IP address is set to a different 
> HA.  > >  > 
> > > > > > >  > >  > >  > > > -----BEGIN PGP SIGNATURE-----  > 
> >  > >  >
> > > > > > > >  > >
> > > > > > > > >  > > >  > >  > >
> > > > > > >

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 5 Sep 2005 12:35:15 -0500

Comments inline.

Ahmad
 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> on 2005-09-05 17:09 Ahmad Muhanna said the following:
> [...]
> > Section 5.1.1., add new para. 4:
> > 
> >    "Even if a successful Registration Reply is received, the MN must
> >    continue to listen for successful Registration Replies.
> > If any further
> >    successful Registration Reply is received, the MN must 
> immediately
> >    send a deregistration (Registration Request with the Registration
> >    Lifetime field set to 0) in response to an additional 
> Registration
> >    Reply which is a response to a Registration Request to which a
> >    successful Registration Request has already been received.
> > 
> >    The reason is to terminate any inappropriate resource usage which
> >    might result from an attacker duplicating the 
> Registration Request
> >    to multiple legitimate HAs, rather than letting it go only to the
> >    intended recipient as intended by the requesting MN, as described
> >    in Section x.x, Security Considerations."
> > 
> > 
> >> [Ahmad]
> >> This solution does not work. check earlier discussion on 
> this thread.
> 
> Thanks for the pointer.  In that case, unless anybody can 
> propose a mitigation, I'd propose that we document this in 
> the security considerations and leave it at that.

[Ahmad]
I am ok if there is a consensus on this.
> 
> > 
> > 
> > Section 5.1.2., add new para. 4:
> > 
> >    "Even if a successful Registration Reply is received, the MN must
> >    continue to listen for successful Registration Replies.
> > If any further
> >    successful Registration Reply is received, the MN must 
> immediately
> >    send a deregistration (Registration Request with the Registration
> >    Lifetime field set to 0) in response to an additional 
> Registration
> >    Reply which is a response to a Registration Request to which a
> >    successful Registration Request has already been received.
> > 
> >    The reason is to terminate any inappropriate resource usage which
> >    might result from an attacker duplicating the 
> Registration Request
> >    to multiple legitimate HAs, rather than letting it go only to the
> >    intended recipient as intended by the requesting MN, as described
> >    in Section x.x, Security Considerations."
> > 
> > 
> >> [Ahmad]
> >> In the case of the MN with co-located is registered with 
> an FA, the 
> >> proposed solution does not work. see comments above for section 
> >> 5.1.1.
> 
> I believe you're mistaken here, if you're talking about an MN 
> with a co-located address which is sending its registration 
> request through an FA.

[Ahmad]
I very possibly could be. But could you please explain to me why. May be
I need to understand the difference (in this respect) between a MN using
an FA care-of-Address and a MN using co-located care of address but
registering via FA. I thought the RRQ in both cases is relayed to HA via
the FA.

> 
> >> On the other hand, for the case of MN with co-located but not 
> >> registered with FA, IMO the proposed solution is not 
> definitive. My 
> >> understanding is that MN stops listening to MIP UDP in one of the 
> >> following
> >> conditions:
> >> 1. When MN registration times out and no longer interested in
> >> registering.
> 
> If the registration times out on the MN, it has timed out on 
> the HA too, so we don't have a problem any more, no?

[Ahmad]
I was trying to explain when the MN quits listening to MIP UDP messages.
Yes, this is not related to the issue at hand.

> 
> >> 2. When MN receives a successful RRP. (make sense why to keep 
> >> listening)
> 
> No, there's no such requirement that I know of, and anyway, 
> we are now specifying what we require of an MN which is using 
> dynamic HA assignment, so we can very well specify that it 
> should listen for this.

[Ahmad]
I agree that there is no such requirement but there is MN's out there
that we need to consider for backward compatibility.
I have no issue if this get mandated on MN's. 

> 
> >> 3. may be there is others?
> > 
> >> IMO it is a burden and a waste of resources at the MN side.
> 
> Well, I guess we have different viewpoints here, then.
> 
> >> Now here are some questions:
> >> 1. How long the MN needs to continue listening?
> 
> I see no reason why the MN has to start and stop listening.  
> As long as it is maintaining a registration, it could be 
> alert to spurious registration replies with verifiable HA-MN 
> auth ext, and de-register as needed.  Making it start and 
> stop just complicates things, I'd say...
> 
> >> 2. What happens if the RRP coming from one or several HA's 
> got lost? 
> >> We still have the same problem.
> 
> In that case, the additional registration will have to time out.

[Ahmad]
I think if we need to accept that, we probably need to document it
somewhere.

On the other hand, Since the MN with co-located care of address always
acquire the requested HA address via other means as documented in
section 6.0 of the draft, we may get away with this scenario by letting
the MN to always set the requested HA address in the HA address field of
the RRQ (the draft mandates it in case of MN registering with legacy
FA). We still can accomplish everything this section of the draft is
trying to accomplish by addressing the issue at the HA.

For example, in case that HA can not serve any MN (for any reason, load
balancing, etc..) HA always can reject the RRQ with RRP using code
REDIRECTED-HA-REQ and include Redirected HA extension which contains the
redirected HA address, this is similar to what the draft is proposing in
such scenario. If HA can serve the MN, it send a successful RRP.

This is mostly inline with RFC3344 and will serve the purpose of what
the draft is trying to achieve. Unless there is a strong reason to have
the MN to set the HA address field to ALL-ZERO-ONE-ADDR. No?

> 
> 
> 	Henrik
> -----BEGIN PGP SIGNATURE-----
> 
> iD8DBQFDHG1leVhrtTJkXCMRAhAnAJ0aAVIMp2bOZg8f+7LnmReskFg5WQCgoEzh
> QFXf7vu2cIbGwz61hsKxw8w=
> =1BEq
>6

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 12 Sep 2005 07:53:36 -0500

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 15 Sep 2005 17:37:53 -0500

Hi, Henrik/Pete,

Please see a question inline.

Regards,
Ahmad

> on 2005-09-16 00:08 [email-masked] said the following: [...]
> > 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?
> 
> 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.

[Ahmad]
Could you please (Henrik or Pete) explain to me how by mandating (MUST
or SHOULD) the FA to forward additional replies would resolve the issue
or even work. i.e. can we do that?
Thanks.
> > Thanks again,