>>>> 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
	address this.

itojun

---
	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.
	also
	- it becomes difficult to distinguish gif + ipsec transport mode and
	  ipsec tunnel mode (this is a problem markus@openbsd is attacking
	  right now)

	the right thing to happen for the transport mode IPsec packet is
	to go into protosw logic directly, with offset argument for pr_input
	properly set.