The design looks fine to me. My question is about the original direction of using IPsec artifacts to implement this. From protocol point of view, nothing seems to mandate having the use of new SA and SPD types (tcpsig). The SPI-less SA for example is a little odd, along with the special treatment for the various ipseckey verbs to skip tcpsig SAs.
An alternative design could've been the use of pfhooks. The callback function of the hook can implement an interceptor that selectively gets TCP packets on both directions, make a policy decision with possibly rewriting a packet or injecting newly generated ones as needed by the protocol. Darren Reed can jump in and say more here, in particular about the interaction with other hooks when defined, and about the availability of interfaces to configure the hooks. Kais. Girish Moodalbail wrote: > Hello all, > > Please find the design document for providing TCP MD5 signature option at > > http://opensolaris.org/os/community/networking/files/tcp_md5.pdf > > I am looking for folks to review this. > > The document captures the design of providing TCP MD5 signature option as > described in RFC 2385. When this feature is enabled between two > communicating > end points, MD5 signature is added on outgoing packets and MD5 signature is > verified on the incoming packets. > > I have done a prototype code based on this design and it seems to work > fine :) > > Thanks in advance! > ~Girish > _______________________________________________ > networking-discuss mailing list > [email protected] > > _______________________________________________ networking-discuss mailing list [email protected]
