Dan McDonald wrote:
This still leaves asynchrony on the part of IPsec outbound processing. It
can happen one of two ways:
* SADB_ACQUIRE generation, caused be the lack of an outbound IPsec
SA. A successful key-management action will reinject the packet
into IPsec processing and should reinject into IP where an
otherwise successful IPsec process would happen.
* Asynchronous crypto. IPsec can today (with a switch in the
ipsecalgs(1m) command) use the Encryption Framework in asynchronous
mode. Like SADB_ACQUIRE, upon success the packet resumes IPsec
processing.
Part of any IPsec cleanup effore would involve splitting the
before-IPsec-processing and after-IPsec-processing in IP's output path in
such a way that the two asynchronous cases and the synchronous case all end
up in the same place with the same state after IPsec has been applied to the
packet.
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.
Then after that we have some to be defined order of
- the IPsec asynchrony you list above
- IPF asynchrony (something Darrin wants to add for extensibility)
- IPPF/IPQoS asynchrony
- ARP/ND (at the very end I assume)
But all those can operate on a completed IP header, which makes things
easier.
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?
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.
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
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
