This document discusses improving IPsec security association resolution. It outlines problems with the current approach, where applications often get errors when no SA exists. The proposed solution is to have connect(), sendmsg(), and other calls return status to indicate resolution is in progress, and queue or retry packets as needed. Ongoing work includes handling all use cases and determining the full scope of the problem to address. Key challenges include different needs for opportunistic encryption versus large scale deployments.

1. Better IPSec
Security Association Resolution
Netconf 2006
Tokyo
James Morris
jmorris@namei.org

2. Problem
a) Outbound packet
b) Security policy db entry match
c) No security association in kernel
●
Most of the time, we return EAGAIN to app or
drop packet if forwarding.
●
We kick the key manager, and usually have an
SA available for next packet.

3. Problem...
●
It actually kind of works for one case: blocking
sendmsg() of datagrams.
●
Process is scheduled in a loop until SA
resolved. See xfrm_lookup().
●
Does not work for connect(2), so ping and
many UDP apps just get EAGAIN.

4. Solution
●
General solution for all protocols and contexts:
– connect(2)
– sendmsg(2)
– forwarding path (tunnel endpoint)
– various kernel-generated packets
– blocking and non-blocking modes

5. Solution...
●
Ideally, we'd like connect(2) to follow Posix
semantics, for non-blocking this is:
– Return EINPROGESS first
– Return EALREADY until SA resolved
●
For non-blocking sockets in general, it'd be nice
to make sure poll(2) works as expected.
– even for datagram protocols, as IPSec adds a kind
of session underneath.

6. Solution...
●
sendmsg(2) should return EAGAIN for non-
blocking case
●
For tunnel end point, we probably need to
queue packets in a resolution queue.
●
This may also be useful for non-blocking socket
case.
●
Herbert has suggested larval dst to go with
larval SA.

7. Status
●
Current patch contains a lot of instrumentation
and some initial changes:
– Make connect(2) work for the blocking case,
hooking into ip_route_connect()
– Propagate new flags down to xfrm_lookup() to
control behavior:
●
Kick the key manager?
●
Sleep until resolved?

8. Ongoing work
●
Continue to develop code to handle all cases
and protocols
●
Probably involve some code consolidation
●
Determine how much of the problem to solve

9. Issues
●
Not clear on all of the use-cases for this:
– Opportunistic encryption
– Complex/large scale policy where pro-active SA
negotiation overhead would be too high
– Others?