Hello everyone!

One thing I'd like to get rid of in OpenSolaris is "nattymod".  It implements
some of the ESP-in-UDP functionality for IPsec NAT-Traversal (see RFC 3948).
It designed pre-FireEngine, and more importantly, pre-Yosemite.

The way it works today is that a participating Key Management daemon
(in.iked) does an elaborate dance involving I_PUSH of nattymod, plus a couple
of putmsg() calls to prime the pump, and then NAT-T can start.

I'd like to reduce this dance to a privileged socket option, and in-line
nattymod's functionality inside the post-Yosemite UDP stack.

It LOOKS like on the responder-side, I can do this at approx. line 4661 of
udp.c:

        /*
         * IP inspected the UDP header thus all of it must be in the mblk.
         * UDP length check is performed for IPv6 packets and IPv4 packets
         * without options to check if the size of the packet as specified
         * by the header is the same as the physical size of the packet.
         */
        udpha = (udpha_t *)(rptr + (hdr_length - UDPH_SIZE));
        if ((MBLKL(mp) < hdr_length) ||
            (mp_len != (ntohs(udpha->uha_length) + hdr_length - UDPH_SIZE))) {
                goto tossit;
        }

----->  /* XXX KEBE SAYS PUT NAT-T CODE HERE... */

        /* Walk past the headers. */
        if (!udp->udp_rcvhdr) {
                mp->b_rptr = rptr + hdr_length;
                mp_len -= hdr_length;
        }

I have two questions for the UDP wizards in the audience:

        1.) Am I right about where inbound NAT-T packets would get
            chewed-up and shunted off to IPsec's ESP?

        2.) Let's say ESP is protecting an outbound packet.  Is there a very
            clean entry point to UDP where I can send a well-formed UDP
            packet and it does the HW-checksum setup, etc. etc.?

            Right now, that happens in ip_wput_ipsec_out(), and I think we
            can do better (even before an overhaul of IP that eliminates
            ip_newroute() and the dain-bramage it causes).

Thanks,
Dan
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to