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

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 2 Sep 2005 17:04:30 -0500

Hi Alpesh,

Please see my comments inline.

Regards,
Ahmad

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

[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

   During the registration process, if the foreign agent wishes to
   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. 
.......
"

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

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

[Ahmad]
I am not sure if this is a valid scenario that we need to worry about.
Can you please elaborate more?

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

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

> 
> 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: Henrik Levkowetz <[email-masked]>
Date: Sat, 03 Sep 2005 00:41:02 +0200

Hi Ahmad, all,

<hat type="just another guy">

>    (defined in Section 3.2.) to it. 

Requiring a mandatory FHAE leaves the dynamic HA assignment mechanism
dead in the water, in order to mitigate a threat which nobody so far
has managed to convince me is in any way more than a minor nuisance.

> I respect your personal opinion. But in reality it is a real issue.

I've seen no convincing data on this, only your repeated assertion
that this is major.  I don't see that at all.

>> stating that the MN Must deregister if it receives multiple replies.

This, on the other hand, seems to me to be a response appropriate
to the threat.  

> is mandated. Please see comment above.

</hat>

<hat type="chair">

Ok. Discuss the issues here.  Expressing amazement at how people use
the language is not helping us to focus on the technical issue, so
let's assume that first sentence isn't there.

</hat>

<hat type="just another guy">

If you want to REQUIRE the existence of an FA/HA security association
in some or all deployments of MIPv4, that is a major change to the
whole protocol, and I think the best course would be to write it up
in a draft.

For this particular case, it seems to me that the only thing you
might accomplish is to totally shoot down any use of the dynamic
HA assignment mechanism with arbitrary FAs at all, and that doesn't
make sense to me.

</hat>