Hey folks!
NOTE --> This is more the networking half of IPsec, but I'm Bcc:-ing
security-discuss for IPsec folks who hang out there exclusively.
I put in Darren Moffat's (very sensible) request for local-port flexibility
in IPsec NAT-Traversal (in other words, you can encapsulate ESP-in-UDP with
ports other than 4500).
It took a while to get it right, as well as to get the test environment (some
will-remain-undocumented in.iked changes in usr/closed) right.
I now have a new public webrev:
http://cr.opensolaris.org/~danmcd/detangle/
The *big* questions I have for folks in the audience are:
1.) Could you write your NAT-Traversal IPsec key management
applications now that we have the potentially-public
UDP_NAT_T_ENDPOINT socket option, as well as changes to the
SADB_X_EXT_ADDRESS_NATT_{LOC,REM} PF_KEY extensions to make
them work?
BTW, the PF_KEY usage extension for a local UDP port change is to
specify the SADB_X_EXT_ADDRESS_NATT_LOC with AF_INET/INADDR_ANY
and a non-zero sin_port number.
For remote UDP port change, if you're serving NAT-ted peers, it's
just like before, but if you're *behind* the NAT, you have to add
an SADB_X_EXT_ADDRESS_NATT_REM with both the peer IPv4 address
and the new port.
2.) UDP and IP performance folks --> am I slowing any UDP hotpaths
down? I was looking at using the conn_t's input function pointer
to reroute NAT-T sockets, but it seemed harder than it needed to
be. Maybe I'm missing something, but some of the options
processing happens in ip_fanout_udp_conn() or ip_udp_check() and
it seems I can't really do the zero-SPI stripping after those
functions.
3.) ESP-in-UDP users, I'm seeing larger stack traces when ESP with
NAT-T hits certain points in packet processing. A fix may
involve refactoring esp_send_udp() callers (see lines 2145-2252
of the new ipsecesp.c) to be merely packet-mungers instead of
munge-plus-transmit functions.
What's out on the webrev works, and while I need to run more tests,
FUNCTIONALLY it is complete. I'm still worried about possible usage or
performance problems, thogh.
Thanks,
Dan
_______________________________________________
networking-discuss mailing list
[email protected]
