Subject: Re: FYI: this time, really about to import crypto framework
To: Sam Leffler <email@example.com>
From: None <firstname.lastname@example.org>
Date: 07/23/2003 12:56:31
>>>> This is assuming there's still a consensus to move towards a
>>>> continuation-passing crypto framework for IPsec in general (which is a
>>>> pre-requisite for taking advantage of crypto accelerator cards) and to
>>>> Fast-IPsec (finishing adding Ipv6) in particular.
>>> I think that's a good direction to move.
> Sam's code re-injects ESP-decoded packet (and others) to ipintrq,
> just like openbsd (Sam commented that he wouldn't do it but from
> freebsd code, he did). it causes a big problem on transport mode case.
maybe my memory wrt communication w/ Sam on this matter is incorrect.
anyways, the following text describes the problem. i believe Sam will
at the end ofsys/netipsec/ipsec_input.c:ipsec4_common_input_cb(),
mbuf after ESP decryption/AH authentication is re-injected into
ipintrq. because of this, for transport-mode IPsec packet, we will
experience problems like follows:
- IP options will be evaluated again
(in IPv6 case, all extension headers prior to ESP/AH will be evaluated
again - this is a violation of RFC2460 page 6, last 4 lines)
- IP stat counters will be increased twice
- IP header checksum computed twice
and there may be more.
- it becomes difficult to distinguish gif + ipsec transport mode and
ipsec tunnel mode (this is a problem markus@openbsd is attacking
the right thing to happen for the transport mode IPsec packet is
to go into protosw logic directly, with offset argument for pr_input