Dan McDonald wrote:
Then after that we have some to be defined order of
- the IPsec asynchrony you list above
Which is packet-transforming - something I hope doesn't interfere with the
following:
- IPF asynchrony (something Darrin wants to add for extensibility)
- IPPF/IPQoS asynchrony
...otherwise we'll *still* need to carry the cached baggage along for the
ride.
I don't mind ordering things in this manner, but if IPF and/or QoS want to
know what was deep inside that packet, we're still going to need metadata
following the packet around.
- ARP/ND (at the very end I assume)
Only here do we really no longer need conn_t information.
I don't think IPF and IPPF needs the conn_t.
And IPsec wouldn't need the conn_t, but on transmit it needs the policy
(which we hopefully can latch for udp as well as tcp, basically move
most of that up to the transports), and then need the result of the
policy (a reference to the SA or whatever it is).
If we can extract the information from the conn_t and result of the
policy, then we can pass that as function arguments down the stack to
IPsec. (Since the ARP/ND asynchrony is below IPsec in this model, there
is no need to save it in an M_CTL *above* IPsec.)
We still need to save things *across* IPsec when it is async, such as
the information that ip_xmit_v* needs (outbound ill and IP nexthop),
that is relatively simple. And we don't need to carry an M_CTL for this
in the case when IPsec can do things inline (without asynchrony).
Tunnel Reform changes current behavior by:
- Having IPSEC_{IN,OUT} going upstream to the tun module. Tun is now
active in IPsec policy enforcement. Each tunnel has a IPsec policy
database structure, keyed by inner-packet contents, as opposed to
the instance used for global policy, set by ipsecconf(1m).
- Fortunately, when Clearview tunnelling happens, this isn't so
bad, becoming only as mildly annoying as what happens in the
post-FireEngine TCP (which is not very annoying at all)!
None of that will cause the pain of IPsec inserting a new IP header.
ok
FWIW I haven't thought enough about asynchrony on the receive side, but
we might be able to move away from a M_CTL to having the attributes in
function call arguments (e.g., we already carry ill_t on the receive
side; makes sense to look at a ip_rcv_attributes_t as an argument with
other things like "was encrypted with SA x". But need to stare at the
receive side a bit more.
Our decision to forego policy-directed tunnelling *should* make the stack's
life easier, no?
A bit, but we still need the "re-evaluate because the IP header changed"
due to IP Filter I think.
But we still need that metadata because of the separation of mechanism (early
in packet processing) and policy (enforcement of which can only meaningfully
happen after locating a conn_t, or even later in the case of tunnelled
packets).
Yes, but the question in my head is whether this can be carried as
arguments on the receive side, and avoid carrying around an M_CTL.
What are the potential sources of asynchrony on the receive side?
IP Filter might be extended to allow upcalls to user land. But that
would happen before IPsec decrypt.
And the resource control mechanisms to slow down on the receive side are
planned to be below IP (the squeue stops draining a receive ring in the
NIC).
No ARP/ND async on the receive side.
So is it only our current code structure in the IP receive paths that
make it look like we have asynchrony?
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
