Subject: Destination options attack

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 28 May 2007 11:39:46 -0700

Hi,

I noticed one more security issue like the Destination options header
attack. A packet is sent by using a destination header as a Multicast
Group address, and source address of the machine to be attacked. A
random Option type is added to the destination Options header, which
has the highest order two bits as 10 (send ICMP Reply to the source).

The above would cause ICMP packets to be sent to the source address
from all members of the multicast group to the source. This could very
eaily overwhelm the source

I think the use of the Option-Type with highest order two bits as 10,
should be deprecated. Let me hear the views. I would also want to hear
the views reflected by Elwyn, Suresh and I regarding the Tiny
Fragments issues. We would wnat to add that to the standard too.

I have also posted a draft for checks to be added to the IPv6 header
Routing header, to minimize and raise the barrier of an amplification
attack.

Thanks,
Vishwas

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 May 2007 22:44:35 +0300 (EEST)

> eaily overwhelm the source

AFAICS, I don't see how this attack would be very effective. 
Multicast forwarding algorithms check (for loop prevention) that a 
packet destined to a multicast address comes from a topologically 
RPF-wise correct direction.  So unless you assume a router has been 
compromised (and all bets are off) basically you can only spoof an 
address inside the subnet where the attacker is, but I don't see this 
as a very useful attack myself because it'd be more effective to 
attack directly.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 28 May 2007 12:59:24 -0700

Hi Pekka,

I am not sure if RPF can catch it all.

Its not the same as bombarding the source itself. With the attack I
mention, we can actually send one packet (which goes to all members of
the multicast group). This will cause all the members of the multicast
group to send a reply to one source.

So the amplification factor is the number of multicast members in a
group. For large groups this number may be huge. Do let me know what I
am missing?

Thanks,
Vishwas

---

From: "Suresh Krishnan \(QB/EMC\)" <[email-masked]>
Date: Mon, 28 May 2007 16:09:02 -0400

Hi Vishwas,
	The multicast RPF algorithm allows a multicast router to accept
a multicast datagram only on the interface where it would send a unicast
datagram to the source of that datagram. The first multicast router
receiving this specific spoofed source datagram will notice that the
packet is not coming in the interface it is supposed to come in from,
and it will drop it. That said, this attack is possible if you are
trying to attack somebody in the same network as you. But you might as
well directly attack the source with as many packets as the number of
members in a multicast group.

Cheers
Suresh 

-----Original Message-----
From: Vishwas Manral [mailto:[email-masked]] 
Sent: May 28, 2007 3:59 PM
To: Pekka Savola
Cc: [email-masked]; [email-masked]
Subject: Re: Destination options attack

Hi Pekka,

Thanks,
Vishwas

On 5/28/07, Pekka Savola <[email-masked]> wrote:
> > I noticed one more security issue like the Destination options 
> > header attack. A packet is sent by using a destination header as a 
> > Multicast Group address, and source address of the machine to be 
> > attacked. A random Option type is added to the destination Options 
> > header, which has the highest order two bits as 10 (send ICMP Reply
to the source).
> > from all members of the multicast group to the source. This could 
> > very eaily overwhelm the source
>

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 May 2007 23:09:10 +0300 (EEST)

> group. For large groups this number may be huge. Do let me know what I

Sure, there is an amplification factor, but AFAICS, if the attacker's 
real source address if 2001:db8:1:2::F00/64, (s)he can only (for 
practical purposes) target an address under 2001:db8:1:2::/64. I don't 
see how this attack is more effective than just sending packets to 
that on-link address yourself at a higher rate and potentially spoofed 
source addresses.

So, the only thing (IMHO) worth considering is the increase in PPS 
along the return path from the receivers to the target (the ICMP 
amplification responses).  Yet given that generating these errors is 
rate-limited, so you'd need a huge number of receivers in order to 
cause even a 10000pps increase; most networks are not worried about 
attacks of that caliber as O(100Kpps) and O(1Mpps) attacks are already 
commonplace with existing methods.

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 28 May 2007 13:41:46 -0700

Hi Markku,

The following is a quote RFC2460.

   The Option Type identifiers are internally encoded such that their
   highest-order two bits specify the action that must be taken if the
   processing IPv6 node does not recognize the Option Type:

    O
    O
    O

      10 - discard the packet and, regardless of whether or not the
           packet's Destination Address was a multicast address, send an
           ICMP Parameter Problem, Code 2, message to the packet's
           Source Address, pointing to the unrecognized Option Type.
   O
   O
   O

Thanks,
Vishwas

On 5/28/07, Markku Savela <[email-masked]> wrote:
> No. Stack is not supposed to send ICMP error report, if the destination
> of the triggering packet was sent to a multicast or any kind of
> broadcast address (including broadcast MAC).
>
> --
> Markku Savela
>

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 29 May 2007 10:54:30 -0700

Hi Jinmei/ Itojun,

What do you think about this issue? I think this is serious enough to
warrant deprecation ght Option Type (10 value bits as the higher order
2 bits).

Thanks,
Vishwas

On 5/28/07, Vishwas Manral <[email-masked]> wrote:
> Hi Pekka,
>
> > Yes RPF only checks that it comes from the right downstream direction,
> > but because each hop uses RPF, a compromised router (i.e.: one that
> > doesn't conform to the RPF rule) will be required in the tree if you
> > would want to attack an IP not in the same subnet as an attacker.
> > Depending on where the attacker is in the tree (edge versus core) you
> > might likely require a large number of such compromised routers.
> I agree. However for an attack we have to think of the worst case and
> not the best case scenario. So even with one upstream router we could
> cause a problem.
>
> That said, I wanted to know are we considering the case where such a
> doctored packet is actually tunnelled to a router in the network, from
> where it travels downstream using normal multicast routing.
>
> Thanks,
> Vishwas
>
> > > RPF, can result in an attack upstream of a tree from any node
> > > downstream (not necessarily on the same network). Like Pekka said
> > > there is rate limiting of ICMP (so the affects can be mitigated), but
> > > I truly thing it is a dangerous feature to have and we should
> > > deprecate the same.
> >
> > Yes RPF only checks that it comes from the right downstream direction,
> > but because each hop uses RPF, a compromised router (i.e.: one that
> > doesn't conform to the RPF rule) will be required in the tree if you
> > would want to attack an IP not in the same subnet as an attacker.
> > Depending on where the attacker is in the tree (edge versus core) you
> > might likely require a large number of such compromised routers.
> >
> > >>  Ooops, ok.. I should have read the text before posting. I
> > >>  misremembered that the multicast "ban" was global for any message.
> > >>
> > >>  However, as said, the replies should come only from nodes that are
> > >>  listening the multicast..
> > >>
> > >
> > >
> >
> > --

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 30 May 2007 07:43:06 +0900

At Tue, 29 May 2007 10:54:30 -0700,

> warrant deprecation ght Option Type (10 value bits as the higher order

I think Pekka is correct.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 29 May 2007 17:40:31 -0700

Hi,

I guess we understand the issues well. Do we think it is important
enough to deprecate the option or not?

In my view this issue is just as important as the routing header
issue, if not more. I think the option needs to be depracated. Do let
me know about the same? I will put in a draft for the same too.

Thanks,
Vishwas

---

From: Brian Haberman <[email-masked]>
Date: Wed, 30 May 2007 07:48:51 -0400

Pekka Savola wrote:
> AFAICS, I don't see how this attack would be very effective. Multicast
> forwarding algorithms check (for loop prevention) that a packet destined
> to a multicast address comes from a topologically RPF-wise correct
> direction.  So unless you assume a router has been compromised (and all
> bets are off) basically you can only spoof an address inside the subnet
> where the attacker is, but I don't see this as a very useful attack
> myself because it'd be more effective to attack directly.

I completely agree with Pekka on this one.  Multicast forwarding is
driven by the RPF check.  If you try to spoof the source address of a
multicast packet, you would have to be on the same subnet as your
victim.  So I don't see the vulnerability here.

Regards,
Brian

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 30 May 2007 23:30:01 +0900

At Tue, 29 May 2007 17:40:31 -0700,

> enough to deprecate the option or not?

No.  If you really understood what Pekka pointed out, I don't simply
understand in which point you thought it is "important".  Could you
describe exactly how this causes a problem even if routers perform the
RPF check correctly (which I believe can be reasonable assumed)?

					JINMEI, Tatuya

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 30 May 2007 09:32:58 -0700

Hi Jinmei,

I agree the RPF check mitigates a few issues (as the IP source address
should be upsteam on the same port from which a multicast packet came
in).

However this still leaves room for attacks upstream from any router
downstream in the Multicast tree. However the amplification factor
that can be got from such an attack can be multiple times more than
the routing header amplification attack. Also I am unsure, but if we
can tunnel such multicast packets, then we get over the whole factor
of RPF, by being able to send a packet from anywhere on the internet.

However if the concensus is that the issue is not very practical in
live networks then I will just drop the discussion here.

Thanks,
Vishwas

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 31 May 2007 02:36:47 +0900

At Wed, 30 May 2007 09:32:58 -0700,
"Vishwas Manral" <[email-masked]> wrote:

> downstream in the Multicast tree.

I simply don't understand how this can effectively be done...

> Also I am unsure, but if we

Sorry, but I don't buy the argument of "if we could do something very
powerful which is actually impossible it would cause a very bad
thing."  What I wanted to see is a realistic attack scenario.

> live networks then I will just drop the discussion here.

I don't know if that's the consensus of the wg; I simply stated my
opinion in response to a question to myself.  But at least I've not
been convinced about what you explained so far.

					JINMEI, Tatuya

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 30 May 2007 10:48:49 -0700

Hi Jinmei,

> I simply don't understand how this can effectively be done...

May be I am missing the point then. A router can set the source
address as any of the upstream address, whether in the multicast tree
or not. As the address is upstream according to the RPF check the
check does not fail. All downstream hosts, that process the packet,
actually send an ICMP packet to the spoofed source address. This
source can then get overwhelmed. Another case as pointed out was if
the IP address was in the same network.

Is there something I am missing in the whole argument here?

Thanks,
Vishwas

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 31 May 2007 13:44:55 +0900

At Wed, 30 May 2007 10:48:49 -0700,

> the IP address was in the same network.

Okay I understand what you mean, but it still doesn't convince me.  In
that case the returned ICMPv6 messages will most likely be forwarded
by the attacking router, so the router would simply be able to attack
the victim node directly with the "amplified" volume of traffic.  I
don't see why the router would bother to trigger the errors in the
first place.  In fact, the essential point is the same as the case
where an attacking node is located in the same subnet as the victim.
Pekka already pointed out that it's not a useful attack.  Since I
already agreed with him, this example naturally isn't convincing to
me.

					JINMEI, Tatuya

---

From: Brian Haberman <[email-masked]>
Date: Thu, 31 May 2007 11:14:53 -0400

> already agreed with him, this example naturally isn't convincing to

More to the point, how would the attacker know it is on the multicast
tree?  That node would have to have knowledge of the multicast routing
state in the network.  If that is the case, I can think of much more
sinister attacks that could be launched.

Regards,
Brian

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 31 May 2007 10:49:02 -0700

Hi Brian/ Jinmei,

What about the case of having such malicious packets tunnelled inside
unicast packets?

> > by the attacking router
I feel two points are totally missed in the argument here. Forwarding
traffic is generally done in the hardware by ASIC's while thats not
the case of packets that need to be processed. So any router in the
middle will not process the packet so will not be overwhelmed.

The second more interesting case is again, a malicious device can
attack any router upstream of a router in its same network too.

Thanks,
Vishwas