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

Hi Vidya.

> I don't quite agree that the above situation is any different for
> home registration vs. RO. Here's why - in both cases, let's assume
> that the victim is some random node in the internet that does not
> have any relationship with the home domain of the MN (attacker). In
> both cases, the packets arriving at the victim has the CN IP address,
> the HoA and the CoA (the victim's IP address, in this case) available
> to it. The victim additionally has the HA IP address available to it
> in the HA routed case. However, considering that the victim is a
> random node with no relationship to the home domain, it needs to
> deduce the home domain from the IP addresses and then complain. It
> can do this in both cases. In both cases, deniability is also equally
> possible, since the home domain could claim that the attacker is the
> CN in both cases.

I'll try to explain why I think the HA and CN registrations are
different wrt. how a victim could react to flooding.  At a glance:

- Deniability can, as you mention, happen in both cases.  But I don't
think it's very relevant in the HA registration case.

- Assuming that the attacker/MN and the HA do not cooperate, the victim
always has someone to send a complaint to if bidirectional tunneling is
used for flooding.  But there may not be anybody to complain at in the
RO case.

Addressing cooperations between the MN and the HA...

If the HA denies involvement in the flooding attack and assigns the
blame to the CN, then the attacker/MN and the HA cooperate.  This can
happen; there are actually 3 cases:

(1)  A "real" HA accepts the attacker's/MN's incorrect CoA during the
home registration.  The attacker/MN uses bidirectional tunneling (BT) to
flood the victim.

(2)  A "real" HA accepts the attacker's/MN's incorrect CoA during the
home registration.  The attacker/MN uses RO to flood the victim.

(3)  There is no real HA or home domain.  The attacker plays the role of
the HA during the HoA test (so the pseudo-HA and the attacker obviously
cooperate).  The flooding attack happens via RO.

I guess the point is that, in (1), the amplification is with the HA.
(The CN is also an amplifier, but that's irrelevant here.)  Since the HA
is cooperating with the MN, it may be willing to spend the effort.  But
there is not really a motivation for such an attack because there are
easier attacks with the same effect.  E.g., the HA could simply send
packets directly to the victim.

Furthermore, given the possibility of case (3), I don't see a big need
for case (2), in particular for a cooperation between the MN and the HA.
 OTOH, case (3) is really attractive because the amplification is with
the CN, and there is no need for the attacker to cooperate with a third
party.

I'd conclude that a cooperation between an attacker/MN and the HA is not
so relevant.  So let's assume for now that there is no such cooperation...

Of course, case (1) may also happen when the attacker/MN and the HA do
/not/ cooperate.  The attacker/MN then wouldn't really care about the
effort that the HA spends.  But in this case, it is in the HA's (or the
MSP's) best interest that a MN's CoA is correct, and it would certainly
disable a misbehaving MN upon complaint of a victim.

Also note that in this case, the victim has some assurance that there
really is a HA/MSP to which it can attend, because it sees the HA's IP
address in the flooding packets.

This leaves cases (2) and (3).  Case (2) is actually not the critical
one:  A victim can complain with the attacker's MSP just as it can in
case (3), even though it does not know the IP address of a HA.  More
critical is case (3), because there is no MSP to which the victim could
attend.

I think case (3) is the scenario that should concern us most, hence the
need to do the CoA test.

In summary, whether or not a MN is registered with in a "real" HA, and
howsoever secure the home registration is, is transparent to a CN.  So
the threat is that a victim may not be able to complain to anyone if the
flooding attack is based on RO, but it would be able to do so if the
attack is based on BT.  Exactly this is the reason why we have to
protect the home and correspondent registrations independently.

> Given that a "complaint" has to take the form of an email or a phone
> call or something tangible, this is equally feasible (or not, actually,
> in my mind!) in both cases. The added availability of the HA IP address
> really doesn't mean anything as far as I can see. 

Here is where Jari's point comes in:  a CoA test is a proactive measure,
whereas sending a complaint is only a reactive one.  The attack may long
be over when such a complaint is eventually handled.  The good thing
with the CoA test is that it /prevents/ an attack in the first place.

IMO, it would actually be good if also the HA did a CoA test.  But the
fact that the HA trusts in the CoA without a test doesn't mean that this
is very secure and should be transferred to CN registrations.

> The whole admin thing being some level of protection here is quite
> bizzarre to me  :)  [...]

You name it. ;-)  However, that was the assumption made in RFC3775---and
the requirement for omitting the CoA in the home registration case.  See
also section 15.3 in RFC3775 and section 1.3.2 in RFC4225.

> - but, even if I made the leap to embrace that, I
> still feel there is equivalence as I've described above. What am I
> missing? 

Hope the text above could help a bit.

Bye,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

Narayanan, Vidya wrote:
> Hi Jari,
> 
> <snip>
> 
>>> 
>>> 
>> Yes -- but I believe for TCP this is hard, because it would imply
>> being able to guess the sequence numbers. Otherwise the session
>> won't even start. There are ways to guess the sequence numbers, but
>> at least some of those ways involve additional cost for the
>> attacker.
>> 
> 
> I'd somewhat buy that :) I think spoofing the acks can be done, but
> it does involve some cost.
> 
> <snip>
> 
>> That is the crux of the matter. Whatever arrangement exists between
>> the MN and its HA is invisible to the CN (under the assumption of
>> talking to a random Internet host). What the CN sees with a home
>> test is that the MN appears to be in control of receiving traffic
>> at the home address. This is sufficient for agreeing to route
>> traffic relating to that address differently, but it does not say
>> anything about the existence of the node at the care of address.
>> 
>> Of course, if there's a problem, the CN can go and complain to the
>> home network's admin. The admin may be able to find out the
>> offending node and turn it off. But the victim network admin needs
>> to talk to both the CN network and then indirectly the home network
>> to get this started; during the design of the original RR
>> mechanisms it was felt that its better to provide a mechanism that
>> helps prevent these situations -- even if the network admin and
>> authorities could sort out the situation later.
>> 
> 
> I don't quite agree that the above situation is any different for
> home registration vs. RO. Here's why - in both cases, let's assume
> that the victim is some random node in the internet that does not
> have any relationship with the home domain of the MN (attacker). In
> both cases, the packets arriving at the victim has the CN IP address,
> the HoA and the CoA (the victim's IP address, in this case) available
> to it. The victim additionally has the HA IP address available to it
> in the HA routed case. However, considering that the victim is a
> random node with no relationship to the home domain, it needs to
> deduce the home domain from the IP addresses and then complain. It
> can do this in both cases. In both cases, deniability is also equally
> possible, since the home domain could claim that the attacker is the
> CN in both cases.
> 
> Given that a "complaint" has to take the form of an email or a phone 
> call or something tangible, this is equally feasible (or not,
> actually, in my mind!) in both cases. The added availability of the
> HA IP address really doesn't mean anything as far as I can see.
> 
> 
> <snip>
> 
>>> 
>>> 
>> Let me first state that if I could redesign RFC 3775 today, I would
>> probably NOT include an administrative security association
>> relationship for the MN - HA. This would have made deployment much
>> easier (e.g. DHCP assigned home agents without any of the
>> bootstrapping complexity). And it would have gotten us rid of
>> problem #3.
>> 
>> We have occasionally talked about this change, though not very
>> seriously -- and I would not hold it as a precondition for doing RO
>> enhancements. In any case, in the current deployment model of
>> Mobile IPv6 there is an administrative relationship which can be
>> used to shut down misbehaving nodes or even send the authorities to
>> catch the guilty. I still like to have a stronger flooding
>> amplification protection for the MN - CN relationship --
>> particularly if it does not have a cost in communications latency.
>> 
> 
> The whole admin thing being some level of protection here is quite 
> bizzarre to me :) - but, even if I made the leap to embrace that, I 
> still feel there is equivalence as I've described above. What am I 
> missing?
> 
> Vidya

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