svn commit: r218794 - in head: . sys/netipsec

[Bjoern A. Zeeb]

On Mon, 21 Feb 2011, Pawel Jakub Dawidek wrote:

Hi,

> On Mon, Feb 21, 2011 at 09:40:25AM +0100, VANHULLEBUS Yvan wrote:
>>> Second of all I really think that an UPDATING entry is not enough.
>>> We should at least provide sysctl to change it back
>>
>> I sent a mail on freebsd-net@ at the beginning of january, to ask some
>> feedback from users, and got NO response at all.
>> So I considered implementing such a sysctl would be just time waste.
>> And it is also a quite bad solution, as it does not solves situations
>> where you want to do IPsec using HMAC_SHA2 with two peers, one which
>> is RFC4868 compliant, and the other which uses the old round-96 bits
>> draft for it's implementation....
>
> You can't talk to two such peers with sysctl or without anyway. I assume
> that if someone already has tunnels configured and they work, they work,
> because the other end uses 96 bits hashes. Once he upgrades there is no
> way to get old behaviour back quickly.
>
> You are changing on-the-wire protocol in the middle of stable branch. Am
> I alone in thinking that this is bad idea?
>
> I'm not saying using larger hash is wrong. Quite the opposite.
> I actually implemented this for a customer, but never got around merging
> it to FreeBSD, because of the on-the-wire protocol change.
>
> Imagine a situation where someone does upgrade from 8.2 to 8.3 one of
> his IPsec machines. Tunnels stop to work. How can he tell what went
> wrong? We don't even log hash mismatches, we only bump some counter.
> This is not user-friendly. Situations like that make people angry and
> make them want to use FreeBSD a little bit less.

So let me hijack this one.

I am not sure about merging it either but frankly it doesn't matter
much if you go from 8.2->8.3 with your custom kernels (you have to
build them anyway as IPSEC is not in GENERIC) and the UPDATING note
is in place so you have the heads up, or eventually going from 7.x or
8.x to 9.x and hit the same problem.

The fact that we still need to do it now rather than doing years ago
is the real problem and we have lots of similar issues in other areas
where we have excellent state of the art draft code but not final or
updated RFC updates and we'll see these kinds of situations a lot more
in the future also for GENERIC features.

That said doing the full hash and if it fails checking the truncated
is what I consider (by design) bad magic in security and as Yvan had
pointed out doesn't help if you are the initiator but only if you are
the responder (not even thinking about possible security implications
yet).

I think the counter is actually the right thing rather than spitting
log() messages per packet on the console for those kinds of things.
netstat -s is un underutilized debugging tool unfortunately.
Educating users is what needs to be done (in addition to fixing more
counters).

The longer we are going to stay on the earlier version though the more
likely we will run into interop problems with other stacks no matter
what.  Having been through this pros and cons before during the review
I convinced myself that we'll eventually have to bite the bullet -- so
rather now than later.

That said if you can come up with a clean solution that will work in
all cases I am happy to hear that.

Adding a single global sysctl or compile time option to avoid POLA
problems for the MFC is probably the thing I could be talked into
with clear mentioning in NOTES/man page that it'll be gone from 9.
That said a sysctl is probably the most user friendly given that they
can update all kernels and then switch the sysctls with all peers,
flush and be done w/o reboot or anything.


/bz

-- 
Bjoern A. Zeeb                                 You have to have visions!
          Stop bit received. Insert coin for new address family.