[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ipsec questions/bugs/fixes (PF_KEY/PF_ENCAP)




In message <19990302134623.A18309@folly.informatik.uni-erlangen.de>, Markus Fri
edl writes:
>
>I have been playing with the new ipsec code and tried to establish
>AH/ESP connections between machines (i386 w/ current) running PF_KEY
>and PF_ENCAP kernels.
>
>So far, I can only get AH work. ESP fails to decode the messages.
>The decoded packet contains garbage (bad port numbers, TCP flags,
>etc, test-scripts are attached).
>
>Has anyone tried this successfully?

Yes, I did test between a SPARC running a PF_ENCAP kernel and an i386 running
a PF_KEY kernel, using all algorithms (that's how I found out the Blowfish
problem).

In your ESP tests, the packets do pass encryption/authentication and all
the sanity tests in ip_esp_new.c/esp_new_input() ? 

>Additionally, after removing all my SAs (on the PF_KEY machine)
>with 'ipsecadm -delspi' I cannot remove the flows that where using
>these SAs:

>If a SADB_DELETE message is sent on a PF_KEY socket pfkeyv2_send()
>calls tdb_delete() which in turn calls delete_flow() for every flow
>using this SA.
>
>Isn't it necessary to delete the entries in the routing table with
>rtrequest(RTM_DELETE, ...)? Is every 'struct flow' linked to exactly
>one routing entry? Am I wrong?

You should use "ipsecadm flow -delete ..." before you "ipsecadm delspi ...",
otherwise the routing entries are not deleted. There is a number of reasons
for maintaining this behaviour (multiple SAs using the same flow/routing table 
entry, dynamic VPN). delete_flow() is tdb_delete() is just freeing the memory.

I suppose this should be documented (use flow -delete before delspi).

>There is a little bug in pfkeyv2.c (pfkeyv2.c misses an $OpenBSD$ tag):
>According to RFC 2367 a SADB_UPDATE message should return ESRCH
>(and not EEXIST) if no matching SA is found. The same applies to
>other message types. A patch is attached.
>
>ipsecadm.8 speaks about SPIs when it should speak about SAs. A patch is
>attached. The example is fixed, too.

You are right, thanks!
-Angelos