Up to [cvs.NetBSD.org] / src / sys / netinet6
Request diff between arbitrary revisions
Default branch: MAIN
Current tag: phil-wifi-20190609
Revision 1.74 / (download) - annotate - [select for diffs], Tue May 15 19:16:38 2018 UTC (5 years, 10 months ago) by maxv
Branch: MAIN
CVS Tags: phil-wifi-base,
phil-wifi-20190609,
pgoyette-compat-20190127,
pgoyette-compat-20190118,
pgoyette-compat-1226,
pgoyette-compat-1126,
pgoyette-compat-1020,
pgoyette-compat-0930,
pgoyette-compat-0906,
pgoyette-compat-0728,
pgoyette-compat-0625,
pgoyette-compat-0521,
netbsd-9-base,
netbsd-9-3-RELEASE,
netbsd-9-2-RELEASE,
netbsd-9-1-RELEASE,
netbsd-9-0-RELEASE,
netbsd-9-0-RC2,
netbsd-9-0-RC1,
isaki-audio2-base,
isaki-audio2
Branch point for: phil-wifi,
netbsd-9
Changes since 1.73: +12 -3
lines
Diff to previous 1.73 (colored)
When reassembling IPv4/IPv6 packets, ensure each fragment has been subject to the same IPsec processing. That is to say, that all fragments are ESP, or AH, or AH+ESP, or none. The reassembly mechanism can be used both on the wire and inside an IPsec tunnel, so we need to make sure all fragments of a packet were received on only one side. Even though I haven't tried, I believe there are configurations where it would be possible for an attacker to inject an unencrypted fragment into a legitimate stream of already-decrypted-and-authenticated fragments. Typically on IPsec gateways with ESP tunnels, where we can encapsulate fragments (as opposed to the general case, where we fragment encapsulated data). Note, for the record: a funnier thing, under IPv4, would be to send a zero-sized !MFF fragment at the head of the packet, and manage to trigger an ICMP error; M_DECRYPTED gets lost by the reassembly, and ICMP will reply with the packet in clear (not encrypted).