Vishwas Manral wrote:
> Hi Brian/ Jinmei,
>
> What about the case of having such malicious packets tunnelled inside
> unicast packets?
The multicast address and the victim source address still need to be
known along with the multicast tree topology in order to make the attack
work. It may help
Hi Brian/ Jinmei,
What about the case of having such malicious packets tunnelled inside
unicast packets?
> that case the returned ICMPv6 messages will most likely be forwarded
> by the attacking router
I feel two points are totally missed in the argument here. Forwarding
traffic is generally d
JINMEI Tatuya / 神明達哉 wrote:
> At Wed, 30 May 2007 10:48:49 -0700,
> "Vishwas Manral" <[EMAIL PROTECTED]> wrote:
>
However this still leaves room for attacks upstream from any router
downstream in the Multicast tree.
>>> I simply don't understand how this can effectively be done...
>> M
At Wed, 30 May 2007 10:48:49 -0700,
"Vishwas Manral" <[EMAIL PROTECTED]> wrote:
> > > However this still leaves room for attacks upstream from any router
> > > downstream in the Multicast tree.
> >
> > I simply don't understand how this can effectively be done...
>
> May be I am missing the point
Hi Jinmei,
> However this still leaves room for attacks upstream from any router
> downstream in the Multicast tree.
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
At Wed, 30 May 2007 09:32:58 -0700,
"Vishwas Manral" <[EMAIL PROTECTED]> wrote:
> However this still leaves room for attacks upstream from any router
> downstream in the Multicast tree.
I simply don't understand how this can effectively be done...
> Also I am unsure, but if we
> can tunnel such
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
At Tue, 29 May 2007 17:40:31 -0700,
"Vishwas Manral" <[EMAIL PROTECTED]> wrote:
> I guess we understand the issues well. Do we think it is important
> 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
Pekka Savola 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
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 t
At Tue, 29 May 2007 10:54:30 -0700,
"Vishwas Manral" <[EMAIL PROTECTED]> wrote:
> 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).
I think Pekka is correct.
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 PROTECTED]> wrote:
Hi Pekka,
> Yes RPF only checks that it comes from the
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, re
On Mon, 28 May 2007, Vishwas Manral wrote:
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
grou
group.
Cheers
Suresh
-Original Message-
From: Vishwas Manral [mailto:[EMAIL PROTECTED]
Sent: May 28, 2007 3:59 PM
To: Pekka Savola
Cc: [EMAIL PROTECTED]; ipv6@ietf.org
Subject: Re: Destination options attack
Hi Pekka,
I am not sure if RPF can catch it all.
Its not the same as bombarding
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.
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
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 o
18 matches
Mail list logo
