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