Dan McDonald wrote:
It's hard to latch for an unconnected UDP socket where we're uttering
sendto(3SOCKET) to different peers.
Yes, but for UDP performance we want to handle the case when a socket is
repeatedly sending to the same destination differently, for instance by
caching the IRE and the source address that was selected. If/when we
fully do this, we can also latch the policy lookup.
We can either do this in the udp and icmp=rawip transport code, or we
can have a generic ip_output_conn(conn_t *, mblk_t *) which uses fields
in the conn for the caching.
One thing that was always a concern was:
- What if the answers for ip_xmit_v* change between the start and
finish of asynchronous processing?
I see two approaches:
1.) "Stick to your guns" - once we're in outbound SA lookup, we stick
with outbound ill and IP nexthop even if the values for the
datagram got changed.
2.) "Try again" - re-lookup this data after IPsec asynchrony.
I feel #1 is simpler, and since it's IP if we lose a single datagram due to a
configuration change it's no big deal. I can be convinced otherwise,
however.
#1 still requires to verify that the ill still exists, e.g., by using an
ifindex.
#2 requires carrying a lot more information across IPsec, since we need
all the input that went into doing the IRE lookup (which includes the
SO_DONTROUTE setting, zoneid, IP_MULTICAST_IF, IP_BOUND_IF, etc etc
option settings).
So I think #1 is sufficient. If the ill has disappeared we just drop the
packet.
Inbound IPsec processing is as follows:
- getassocbyspi()
- Perform inbound ops (POSSIBLY ASYNC!!!)
- With decrypted and/or verified packet, strip headers and carry
along knowlege that we decrypted and/or verified.
So if we have asynch. crypto on the inbound side, it *might* be a problem.
If we have AH *and* ESP, we get up to two asynch events (EF allows dual-ops
for ESP, so that's not a problem).
Yes, we need to be able to carry things *across* IPsec in the async
case. And we need to determine what information this is (at least the
ill; perhaps IP_RECVLLA information as well.)
But once IPsec is done, we don't have any other sources of async, thus
the IPsec results (which SA etc was used for the decrypt) can be carried
as function arguments.
We can chose not to use asynch. crypto, especially if you can schedule-by-SPI
on to different processors the way we do with schedule-by-ports today (given
they live in the same offset, it wouldn't be rocket science).
We can carry the inbound SA pointer(s) as an argument, as that's contains all
of the information we need to feed into an inbound policy check.
Good.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
