On Fri, Feb 03, 2006 at 10:53:50AM -0800, Erik Nordmark wrote:
> Dan McDonald wrote:
> >
> >Only here do we really no longer need conn_t information.
>
> I don't think IPF and IPPF needs the conn_t.
That's cool.
> 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).
It's hard to latch for an unconnected UDP socket where we're uttering
sendto(3SOCKET) to different peers.
You're right in that what we actually need is the outbound policy action for
the datagram in question. Only then can we obtain an SA, or form an ACQUIRE
if there is none.
> 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.)
Works for me.
> 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).
You're correct.
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.
> 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.
Please tell me if you discover anything interesting on the receive side.
<Re: Packet metadata...>
> 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.
I think we can. Lemme think it out loud later in this note.
> 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.
Yep.
> 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.
Yep and yep.
And like there's no ARP/ND on receive, there's no ACQUIRE/KM either. (KM is
to IPsec as routing/ARP/ND is to IP...)
> So is it only our current code structure in the IP receive paths that
> make it look like we have asynchrony?
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).
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.
Dan
_______________________________________________
networking-discuss mailing list
[email protected]
