On 08/19/2014 11:37 AM, Philip Homburg wrote: >> >>> - The ICMP error packet's destination address must qualify uRPF rules for= >> the same interface as the source address.[1] >> >> Should this language be limited to uRPF, or should it include other >> anti-spoofing >> mechanisms, as well? > > At least for TCP it is relatively easy for the host to check whether the > sequence > numbers make sense. If they don't, discard the error ICMP.
mmm.. not really... check this (from <http://www.ietf.org/id/draft-gont-6man-deprecate-atomfrag-generation-00.txt>): o Many implementations fail to perform validation checks on the received ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and documented in [RFC5927]. It should be noted that in some cases, such as when an ICMPv6 error message has (supposedly) been elicited by a connection-less transport protocol (or some other connection-less protocol being encapsulated in IPv6), it may be virtually impossible to perform validation checks on the received ICMPv6 error messages. And, because of IPv6 extension headers, the ICMPv6 payload might not even contain any useful information on which to perform validation checks. o Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big" error messages, the Destination Cache [RFC4861] is usually updated to reflect that any subsequent packets to such destination should include a Fragment Header. This means that a single ICMPv6 "Packet Too Big" error message might affect multiple communication instances (e.g., TCP connections) with such destination. Cheers, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
