>>>>>> The ping pong attack is mitigated in RFC4443. >>>>> >>>>> I must be missing something.. what does RFC4443 have to do with >>>>> this? A ping pong attack does not require the attack packets to >>>>> be ICMPv6 echo requests... >>>> >>>> https://tools.ietf.org/html/rfc4443#section-3.1 One specific case >>>> in which a Destination Unreachable message is sent with a code 3 >>>> is in response to a packet received by a router from a >>>> point-to-point link, destined to an address within a subnet >>>> assigned to that same link (other than one of the receiving >>>> router's own addresses). In such a case, the packet MUST NOT be >>>> forwarded back onto the arrival link. >>>> >>>> Most implementations I'm aware of now implement this. >>> >>> Why wouldn't an attacker send *any* packet meant for the p2p link, >>> but that not correspond to the address of any of the two >>> endpoints? >>> >>> i.e., I don't see the need to focus on a specific kind of packet... >>> I guess I'm missing something? >> >> Yes, you are missing something. RFC4443 specifies what behaviour >> should be if a router receives a packet on a point to point link that >> would end up being forwarded back out the same link. The specified >> behaviour is drop and send destination unreachable. That solves the >> problem for any packet obviously. And any prefix length assigned to >> the link. > > How could RFC4443 possibly address this for all packets without formally > updating RFC2460? > > P.S.: For a specification pov, this shouldn't be buried in RFC4443, and, > as noted, no matter where this "patch" is specified, such doc should > certainly update RFC2460.
You will probably save everyone a lot of energy if you just admit you had missed it, and moved on. Ole
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
