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 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 On 5/28/07, Pekka Savola <[EMAIL PROTECTED]> wrote: > On Mon, 28 May 2007, Vishwas Manral wrote: > > 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. > > > On 5/28/07, Markku Savela <[EMAIL PROTECTED]> wrote: > >> > >> > > >> > 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 > >> > >> 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.. > >> > > > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
