Re: Destination options attack

["Vishwas Manral" <vishwas.ietf at gmail.com>]

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 <msa at burp.tkv.asdf.org> wrote:
> > > On Mon, 28 May 2007, Vishwas Manral 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).
> > > >
> > > > 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
>
> 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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------