On Mon, Jan 30, 2006 at 01:44:18PM -0800, Erik Nordmark wrote:
<SNIP!>
> Yes, there will still be some asynchrony, but we should be able to move
> that after all the crafting of the IP header is done.
> Thus any references to the conn_t will be done before any asynchrony.
Outbound IPsec processing always calls the now-misnamed
ipsec_getassocbyconn(). It's misnamed because you are correct - all of the
relevant conn_t information has been cached or used at this point.
The asynch. kEF case is easier - we're well past SA selection and on to other
goodies at this point.
> 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 know what the impact is of tunnel reform is on the above.
> You will add policy (as opposed to routing table) directed tunneling, right?
We decided between 0.8 and 1.0 to rid ourselves of policy-directed tunneling.
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.
> That means that there can be an extra IP header added as part of the
> IPsec processing. Which implies a need to look up a route/arp entry. But
> that isn't any different than IPF doing NAT on the outbound side. So
> having the callout to IPsec and IPF indicate "destination has changed"
> would be a useful way to tell IP to do a new route/arp lookup.
Our decision to forego policy-directed tunnelling *should* make the stack's
life easier, no?
> >Inbound processing shouldn't change all that much - after inbound processing
> >the packet needs to be tagged and re-processed as if it came off the wire
> >w.r.t. checksums and packet contents.
>
> OK
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).
Once Tunnel Reform and one or two other things finish, we're gonna have a lot
to talk about! :)
Dan
_______________________________________________
networking-discuss mailing list
[email protected]
