Thor Lancelot Simon writes:

>If the code can't be changed to actually encrypt the packets, it should
>at least blackhole them on output -- always.  If it can't be changed to
>blackhole them, it should be changed to refuse to allow such security
>policy rules to be loaded, to emit a loud, obvious warning when a kernel
>is so configured, and to emit a loud, obvious warning when such a kernel
>is booted.
>
>Silently emitting unencrypted traffic that the user expected to be
>encrypted is *really* bad.

Thor,

Yeah, that was in the back of my mind when I asked about the pullup.
A few points, though:

0. The intended audience of this patch is users who want
hardware-accelerated IPsec for IPv4 traffic, who use FAST_IPSEC, and
who want *some* support for IPv6 traffic. The intended audience 
explicitly *ex*cludes those who want IPv6 traffic to be IPsec'ed.

That was known to not work: the prior behaviour was an immediate
panic. (telnet ::1 triggered a panic, irrespective of presence of
absence of SPDs, and whether they matched IPv4 or IPv6).


1.  I was under the misapprehension that options(4) listed the
combination of FAST_IPSEC and INET6 as non-working, undefined,
and generally, "caveat emptor".  (As does the FreeBSD documentation 
for FreeBSD's FAST_IPSEC, as quoted here recently w.r.t. TCP-MD5).
It turns out that options(4) says nothing about FAST_IPSEC or its
limitations. That's a bug that should definitely be fixed.

2.  Yes, this issue was in the back of my mind when I asked about the
pullup. As far as I can ascertain, our FAST_IPSEC code currently
black-holes input v6 packets if either:

	i) The packets match a rule requiring IPsec, and the packets
	   are in clear text
	ii) The received packets are in fact IPsec'ed.

	    (we may panic in that case, I don't have the legacy
	     infrastructure to test it).

I'm not sure about output. the code may in fact emit packets that are
suppose to be IPsec'ed as cleartext. I agree its better to black-hole
this traffic, if the kernel is configured to apply IPsec to v6 traffic.

Again, the assumption is that anyone using this understands that
FAST_IPSEC *doesn't* *work* with IPv6.  Turning on both FAST_IPSEC and
INET6 puts you into territory that should be marked `experimental'.
If you think its worth explicitly black-holing v6 packets that have a
matching SPD, even with that caveat, then I can make it so.

Of the other options, I'd prefer the loud, obvious warning on boot.