[merging two different replies back into one] On 2014-08-19 18:33, Fernando Gont wrote: > Hello, Jeroen, > > On 08/19/2014 10:18 AM, Jeroen Massar wrote: >> Hence we should formulate text a bit like: >> >> 8<------------------------ >> When forwarding or receiving an ICMP error packet: >> - The IP destination of the packet MUST match the source address >> represented in the ICMP error packet. >> >> - The ICMP error packet's destination address must qualify uRPF rules >> for the same interface as the source address.[1] >> >> As the verified packets are ICMP errors, when the verification fails the >> packet MUST be dropped, logging is recommended. >> >> Due to the checking inside the ICMP portion of a packet: >> Access-routers, firewalls and hosts MUST perform these checks. >> Core-routers SHOULD perform these checks >> >> [1] When ICMP-dst address matches IP-src the check should already have >> been performed by the standard uRPF check. >> ------------------------>8 > > Should we include something alng this lines to the countermeasures > listed in draft-gont-v6ops-ipv6-ehs-in-real-world, or were you thinking > about something else?
While it kind-of has a place there, (ipv6-ehs-in-real-world) is a "current state of the Internet" regarding this problem, it thus introduces the problem. Hence, a short, separate document which updates ICMPv4 + ICMPv6 referencing that draft would be more appropriate IMHO. Especially as then it is quicker for implementers to see what they need to get done to solve the issue. Hence, a short intro with "this is the problem: ....; for more detail see draft-X + RFC5927" + "do this in your ICMPv4/v6 stacks" would be a good start. Then we might be able to get it quickly into at least Linux and BSD kernels which is what most access-router/firewalls are being built upon. On 2014-08-19 18:25, Fernando Gont wrote: > On 08/19/2014 01:17 PM, Jeroen Massar wrote: >> >> While that specific fragmented attack won't work, one can still spoof >> return ICMPs and give wrong answers. >> >> Anyone remember Rotorouter[1] ? :) >> >> Hence, why it is a good idea to do the same checks for IPv4 too >> and why I avoid mentioning what kind of attack it was solving. >> It is just good hygiene to check validity of things. > > FWIW, I had posted this thingy a while ago: > <http://www.gont.com.ar/papers/filtering-of-icmp-error-messages.pdf> > -- essentially BCP38 on the ICMPv4 payload.. aka RFC 5927, though only informational even though it went through WG review it seems. That indeed touches upon the subject quite a bit too, and would be a good thing to reference from a draft dubbed: "ICMPv4 + ICMPv6 Address Verification" Greets, Jeroen _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
