On Tue, Mar 11, 2008 at 01:36:36PM -0700, Darren Reed wrote:
> Nicolas Williams wrote:
> >On Tue, Mar 11, 2008 at 01:14:00PM -0700, Darren Reed wrote:
> >>Interesting, the use of ipsecconf to manage TCP MD5.
> >>
> >>Can I specify that my application will use TCP MD5
> >>over an IPsec tunnel, all in the same .conf file?
> >
> >Also, why shouldn't any of the TCP security options not be socket
> >options (or, better, new functions)?
> >
> >Making them system policy options might be a useful fallback, but
> >providing APIs is even better.
> 
> Seemingly the goal of this project is to encourage quick
> adoption of TCP MD5.  Providing the means to specify
> a new system policy that enforces this is a much better
> boost to adoption than requiring people to modify their
> applications.  In addition, it allows applications to
> benefit from the inclusion of this feature where there
> is no chance to use source code.  I can't see why what
> is being offered can't be delivered first and the API
> pieces delivered later.

The problem is that if an application protocol spec says "use TCP MD5"
then how does the application make sure that it's used?  To punt to the
sysadmin and assume that the sysadmin did the right thing is not really
safe.

Remember, we have IP_SEC_OPT (ipsec(7P)).  No, IP_SEC_OPT is not nearly
as useful as we'd all like it to be, but it's a heck of a lot more
useful than not having it at all.

If I were an ARC member I'd derail any fasttrack proposing only an
administrative interface to TCP MD5.  I don't know that I'd find any
members to back me up (and I don't want to be a member either, at least
not yet).  The point is: I think this is extremely important.

Nico
-- 
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to