Flooding Attacks and MIP6 (was RE: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04)

Hi Christian,
Thanks for taking the time to respond. It is extremely refreshing to be
having a technical discussion! Also, apologies for the delayed response
- last week turned out to be very busy. 

I want to separate the topics out, since these are long discussions.
I'll start separate threads on a couple of other related topics after
this. 

Summarizing the means by which flooding attacks can be realized: 

1. Directly flooding the victim by sending traffic to the victim - as
you pointed out, this requires reasonable amount of effort on the
attacker's part. 

2. Subscribing for bogus sessions using a victim's IP address (TCP has
some behavior that can help here, for e.g., slowing down if proper acks
aren't received, but it is possible to subscribe to UDP/RTP sessions).
This would allow the attacker to amplify the attack without too much
direct resource involvement. 

3. Using MIP6 home subscription to redirect traffic to the victim. Of
course, the risk here is that of authenticated nodes registering the
victim's IP address as its CoA. 

4. Using MIP6 RO to redirect traffic to the victim. If there is a HoA
test, here too, the risk is that of authenticated nodes registering the
victim's IP address as its CoA. The HoA test cannot pass unless there is
a valid binding for that node at the HA. When the HoA is created with
CGAs, this situation has full equivalence with the home subscription.
Note that I'm still not saying the MN-HA authenticated state has any
meaning to the CN. 

If I understand correctly, you are saying that MIP6 can be used to
amplify flooding attacks. Even though I think in practice, 2 above can
be used to amplify flooding attacks, if that is the intention, I can buy
the argument that if say, 2 is solved by other means, you will still be
left with the possibility of amplification via 3 and 4. 

However, the point I struggle with is this - as I've said above, I think
there is equivalence in the attack that is possible with 3 and 4,
assuming that the HoA is based on CGAs and a HoA test is done. So, if we
say RR for CoA is needed, it is equally needed for 3 and 4. I don't see
why it is needed for 4 alone in this case. 

Thoughts? 

Vidya

> -----Original Message-----
> From: Christian Vogt [mailto:chvogt@tm.uka.de] 
> Sent: Tuesday, August 08, 2006 9:37 AM
> To: Narayanan, Vidya
> Cc: mipshop@ietf.org; Jari Arkko; Wassim Haddad
> Subject: Re: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04
> 
> Hi Vidya,
> 
> thanks for reviewing this document!  I'll respond in-line.
> 
> > Summary: ---------
> > Overall, I do believe that MIP6 RO needs to be revised for better 
> > security and optimization. I think using CGAs to generate HoAs is a 
> > good step towards that. From that perspective, this draft 
> is good. I 
> > do, however, think that we don't need any CoA tests (more 
> on that in 
> > the details below). By using CGAs and signed proof to 
> verify HoAs and 
> > an initial HoA test, the CN gets the same assurance about the 
> > addresses of an MN as the HA. That alone is sufficient to 
> generate a 
> > binding and optionally exchange a symmetric key. Hence, I think the 
> > "cga" part of the draft is useful, while the "cba" part is 
> > non-essential.
> 
> You are touching two points here:  (i) whether or not MIPv6 
> could be useful for flooding, and (ii) whether or not a CoA 
> test is necessary in the presence of a home address ownership 
> proof and a proof of home agent registration.  Let me address 
> these points separately.
> 
> (i)  From an attacker's perspective, the advantage of 
> MIPv6-based flooding (or redirection-based flooding) over 
> "classic" flooding techniques (ignore DDos for the moment) is 
> that it can provide much higher amplification:  The attacker 
> won't need to send as much packets to the correspondent node 
> as the correspondent node will send to the victim.  
> Amplification makes the big difference between classic 
> flooding and redirection-based flooding.
> 
> By "classic" flooding, I here refer to direct flooding 
> attacks (where the attacker itself simply sends packets to 
> the victim), or reflection attacks like TCP-SYN or Smurf 
> attacks.  Direct flooding attacks obviously don't provide any 
> amplification.  TCP-SYN and Smurf attacks usually don't amply 
> much either, provided that network administrators follow CERT 
> advisories.
> 
> Of course, in addition to these classic flooding strategies, 
> there are DDoS attacks, which /do/ provide amplification.  
> But DDoS attacks are different from classic or 
> redirection-based flooding attacks in the sense that they 
> typically exploit vulnerabilities in operating systems rather 
> than vulnerabilities in Internet protocols.  OS developers 
> are doing their part to avoid amplified flooding in that they 
> patch flaws in their software.  We in IETF should contribute 
> our part to avoid vulnerabilities in the protocols we develop.
> 
> As a side note, DDoS and redirection-based flooding could also be
> combined:  Why not command zombies to redirect a CN's packets 
> to the victim instead of having the zombies send the flooding 
> packets themselves?  Many zombies are probably private home 
> computers, which may have limited upstream connectivity.  So 
> they may not be able to generate that many flooding packets, 
> but they can certainly trick better-provisioned CNs into 
> sending packets to a victim.
> 
> The issue of redirection has long been taken care of in the 
> non-mobile Internet, where transport protocols perform an 
> initial reachability verification upon connection 
> establishment.  E.g., a TCP responder sends an unguessable 
> sequence number to the TCP initiator.  Without knowing the 
> sequence number, the initiator won't receive any data.  DCCP 
> and SCTP do similar tricks in order to verify an initiator's 
> IP address initially.  Now, mobility protocols (and also 
> multi-homing protocols) can be used to change the IP address 
> a posteriori, which means that the reachability verification 
> must be done again.  This is the purpose of the CoA test.
> 
> And this brings me to the second point...
> 
> (ii)  ...which is whether a home address ownership proof, 
> combined with a proof of home agent registration, would allow 
> a CN to omit reachability verification for a new CoA.
> 
> First of all, a home address ownership proof does not 
> increase the trustworthiness of a MN from the perspective of 
> a CN.  The home address does not even have to be a permanent 
> one.  An attacker could just configure a CBA-based HoA with a 
> network prefix from its current link, use the same or a 
> different IP address from that prefix as its CoA, and start 
> registering with the CN.  There does not even have to be a HA.
> This issue is the very same in RFC 3775 as in the proposed 
> CGA-CBA protocol.  While the CGA-based home address ownership 
> verification makes impersonation attacks much harder (which 
> is why we use it), it does not change the practicability or 
> likelihood of redirection-based flooding.
> 
> For the same reason, the CN cannot trust that there really is 
> a HA with which the MN has registered.  The HA may be 
> cooperating with the attacker, it there may be no HA at all.  
> After all, the CN never sees an authenticated message from 
> the HA.  The home registration is really irrelevant for the 
> correspondent registration from a security perspective 
> (except that you could otherwise use the IPsec-protected 
> tunnel between the HA and the MN).
> 
> Second, you mention that in standard MIPv6, an attacker would 
> have to be on two paths---between the HA and the CN as well 
> as between the MN and the CN---in order to break the return 
> routability procedure.  This is actually not the case; 
> sitting on the HA-CN path is sufficient.  The attacker would 
> use the victim's HoA, but it's own CoA.  It can thus exchange 
> both HoTI/HoT and CoTI/CoT with the CN on behalf of the victim.
>  Note, however, that this would be an impersonation attack.  
> Flooding can be combined with impersonation, but also a 
> correctly authenticated (possibly compromised) MN may wage a 
> flooding attack.
> 
> It is true that RFC 3775 does not include a CoA test for home 
> registrations.  But the motivation for this was not that the 
> HA can securely verify the MN's home address ownership, or 
> that the home registration is IPsec-protected.  The 
> motivation rather was that, first, the HA can trust the MNs 
> that they use the right CoA and, second, that there is an 
> administrative relationship between the HA and the MN so that 
> a MN can always be tracked down if it still behaves 
> maliciously (e.g., when the MN was compromised).
> 
> The same rationale was used in Charlie's RFC 4449 (Securing 
> Mobile IPv6 Route Optimization Using a Static Shared Key):  
> It assumes that, first, MNs and CNs are under a common 
> administration and, second, that they trust each other.  
> There was an extensive debate in the MIP6 working group on 
> whether this assumption would limit the applicability of the 
> technique too much.  But in the end, the assumption was 
> written down as such.  (It's in section 2 of RFC 4449 in case 
> you want to take a look.)
> 
> Given that the envisioned CGA-CBA protocol should not be 
> limited to MNs and CN with a-priori relationships, we need to 
> avoid the assumptions made in RFC 4449.  This in turn means 
> that we have to do the CoA test.
> And we want to optimize them.
> 
> > Having said that, I think it would be best if this document 
> actually 
> > takes a two-step process, going through experimental track first.
> > That would give us the opportunity to mature the concept and have a 
> > solid proposal for MIP6 RO. I don't think we should target 
> a proposed 
> > standard right away - I think in this case, going to an 
> experimental 
> > RFC first is useful (as we've done before with mobility 
> optimizations 
> > such as FMIP and HMIP).
> 
> Vidya, the introduction of a new OSI layer for a host 
> identifier as well as the architecture required for localized 
> mobility optimizations are certainly more tricky than a proof 
> of IP address ownership or some byte counting during 
> concurrent reachability verification.
> 
> Also, AFAICT, one of the reasons for making FMIP and HMIP 
> experimental in the first round was lack of a sufficient 
> security mechanism in both cases.  Mipshop is now taking care of this.
> 
> > Detailed comments -----------------
> > 
> > (I've limited these to sections 1 to 3, since that captures the
> > concept)
> > 
> > Major: ------
> > 
> > 1. After some thought, I think we don't need CoA tests (and 
> > consequently, CBA) at all here. In MIP6, CoA test makes 
> sense, since 
> > an attacker has to be present both on the link between the 
> MN and the 
> > CN and on the link between the MN and HA to successfully 
> arrive at the 
> > Kbm. Without the HoTi/HoT or CoTi/CoT, this becomes easier for the 
> > attacker, since presence is required only on one link. 
> However, if the 
> > MN's HoA can be cryptographically verified and the initial HoA test 
> > can be done to (indirectly) prove the existence of a valid 
> > registration at the HA, there should be no need for CoTi/CoT. For 
> > e.g., the HA today does not do a CoA verification - it goes to the 
> > same point as in 1 above that if the MN wants to flood 
> another node by 
> > claiming a wrong CoA, it can do that anyway by other means.
> 
> Please see my comments above wrt. both, why it is sufficient 
> for an attacker to only be on the HA-CN path, as well as why 
> we still require the CoA test.
> 
> > 2. The text under "Initial home address tests" in section 3 is 
> > confusing. I'm not sure I understand the flooding attack as 
> described. 
> > If the goal is to flood any network, as I said in my first point 
> > above, it doesn't need to be done with MIP6. What is more 
> important is 
> > ensuring that an MN that does not have a binding with its 
> HA doesn't 
> > end up creating a binding with a random CN. The fact that 
> the MN has a 
> > valid binding with its HA implies a couple of things - that it has 
> > been authenticated and authorized for MIP6 use and that it is not 
> > claiming another node's HoA.
> 
> Again, see my comments above wrt. to the value of a home 
> registration from the CN's perspective.
> 
> However, I will certainly take a look at section 3 and 
> clarify the text.
> 
> > Given that, the initial home address test will achieve this - it is 
> > just that the motivation seems to differ in my mind.
> > 
> > Not-so-major (not-so-minor :)) ------------------------------
> > 
> > 3. Section 2.2 talks about redirection of an MN's 
> communications to a  
> > third party, thereby flooding the victim (2nd bullet). In my view, 
> > this is not a threat that MIP6 brings. If a malicious node 
> has a goal 
> > of flooding a given node, it doesn't need MIP6 to achieve 
> that. It can 
> > send packets to that IP address and those will do. There 
> isn't a real 
> > need to set up a bogus MIP6 binding to realize that attack. So, I 
> > think that paragraph should be removed.
> > 
> > 4. Also, the point about DoS attacks may stay - but, it is probably 
> > worth mentioning that DoS attacks are achieved by a variety 
> of other 
> > means, some of them, much simpler than engaging in expensive 
> > computations.
> 
> You are right; I will add this.
> 
> > 5. Section 3 talks about cryptographically generated home addresses 
> > providing authentication - CGAs provide address ownership 
> validation,  
> > but not really authentication. In order to authenticate a 
> node (i.e., 
> > to verify the node is "who" it claims to be), a verification of its 
> > identity needs to occur - which implies a shared key or a 
> > public/private key pair endorsed by a certificate. I'm 
> assuming this 
> > section meant to really talk about HoA ownership validation?
> 
> Absolutely right.  Need to clarify that.
> 
> Thanks again!
> 
> Best,
> - Christian
> 
> --
> Christian Vogt, Institute of Telematics, Universitaet 
> Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/
> 
> "Everything should be made as simple as possible, but not simpler."
> (Albert Einstein)
> 
> 
> Narayanan, Vidya wrote:
> > Summary: --------- Overall, I do believe that MIP6 RO needs to be 
> > revised for better security and optimization. I think using CGAs to 
> > generate HoAs is a good step towards that. From that 
> perspective, this 
> > draft is good. I do, however, think that we don't need any 
> CoA tests 
> > (more on that in the details below). By using CGAs and 
> signed proof to 
> > verify HoAs and an initial HoA test, the CN gets the same assurance 
> > about the addresses of an MN as the HA. That alone is sufficient to 
> > generate a binding and optionally exchange a symmetric key. 
> Hence, I 
> > think the "cga" part of the draft is useful, while the 
> "cba" part is 
> > non-essential.
> > 
> > Having said that, I think it would be best if this document 
> actually 
> > takes a two-step process, going through experimental track first.
> > That would give us the opportunity to mature the concept and have a 
> > solid proposal for MIP6 RO. I don't think we should target 
> a proposed 
> > standard right away - I think in this case, going to an 
> experimental 
> > RFC first is useful (as we've done before with mobility 
> optimizations 
> > such as FMIP and HMIP).
> > 
> > Detailed comments -----------------
> > 
> > (I've limited these to sections 1 to 3, since that captures the
> > concept)
> > 
> > Major: ------
> > 
> > 1. After some thought, I think we don't need CoA tests (and 
> > consequently, CBA) at all here. In MIP6, CoA test makes 
> sense, since 
> > an attacker has to be present both on the link between the 
> MN and the 
> > CN and on the link between the MN and HA to successfully 
> arrive at the 
> > Kbm. Without the HoTi/HoT or CoTi/CoT, this becomes easier for the 
> > attacker, since presence is required only on one link. 
> However, if the 
> > MN's HoA can be cryptographically verified and the initial HoA test 
> > can be done to (indirectly) prove the existence of a valid 
> > registration at the HA, there should be no need for CoTi/CoT. For 
> > e.g., the HA today does not do a CoA verification - it goes to the 
> > same point as in 1 above that if the MN wants to flood 
> another node by 
> > claiming a wrong CoA, it can do that anyway by other means.
> > 
> > 2. The text under "Initial home address tests" in section 3 is 
> > confusing. I'm not sure I understand the flooding attack as 
> described. 
> > If the goal is to flood any network, as I said in my first point 
> > above, it doesn't need to be done with MIP6. What is more 
> important is 
> > ensuring that an MN that does not have a binding with its 
> HA doesn't 
> > end up creating a binding with a random CN. The fact that 
> the MN has a 
> > valid binding with its HA implies a couple of things - that it has 
> > been authenticated and authorized for MIP6 use and that it is not 
> > claiming another node's HoA.
> > 
> > Given that, the initial home address test will achieve this - it is 
> > just that the motivation seems to differ in my mind.
> > 
> > Not-so-major (not-so-minor :)) ------------------------------
> > 
> > 3. Section 2.2 talks about redirection of an MN's 
> communications to a  
> > third party, thereby flooding the victim (2nd bullet). In my view, 
> > this is not a threat that MIP6 brings. If a malicious node 
> has a goal 
> > of flooding a given node, it doesn't need MIP6 to achieve 
> that. It can 
> > send packets to that IP address and those will do. There 
> isn't a real 
> > need to set up a bogus MIP6 binding to realize that attack. So, I 
> > think that paragraph should be removed.
> > 
> > 4. Also, the point about DoS attacks may stay - but, it is probably 
> > worth mentioning that DoS attacks are achieved by a variety 
> of other 
> > means, some of them, much simpler than engaging in expensive 
> > computations.
> > 
> > 5. Section 3 talks about cryptographically generated home addresses 
> > providing authentication - CGAs provide address ownership 
> validation,  
> > but not really authentication. In order to authenticate a 
> node (i.e., 
> > to verify the node is "who" it claims to be), a verification of its 
> > identity needs to occur - which implies a shared key or a 
> > public/private key pair endorsed by a certificate. I'm 
> assuming this 
> > section meant to really talk about HoA ownership validation?
> > 
> > 
> > Vidya
> 
> 
> 
> 
> 
> 

_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop