On Tue, Mar 11, 2008 at 06:44:04PM -0400, Girish Moodalbail wrote: > James Carlson wrote: > >Girish Moodalbail writes: > > > >>Are we talking of providing a socket option to turn on/off the feature. > >>Basically a flag. So that there is a way to override the weaker system > >>policy?
Yes. > [...] > I meant, if the system is not configured to use TCP-MD5 and the > application wants to use TCP-MD5 then this flag will be useful (Case > of overriding a weaker system policy). Which IP_SEC_OPT already sets precedent for. > On the other hand, as you said, if the system does have keys, and is > configured to use TCP-MD5 then the application should be disallowed > from overriding the stronger system policy. Same as with IP_SEC_OPT. > >I don't see a real point to an on/off switch. Right, me either. > >>Are we talking of providing a socket option to push the password/keys to > >>be used for computing MD5 digest? > > > >Yes, I think that's what they're asking for, but that gets the client > >into the tricky business of handling sensitive key material (including > >all the configuration file problems this causes), and doesn't seem to > >be necessary. But TCP-MD5 isn't exactly a great protocol (no automatic keying, no re-keying, ...) so I don't feel bad about this. Also, the password could be in a token and the API could simply take a reference to it, rather than the actual password. The main reason to say no to my proposal is that only BGP should be using this and we don't want to encourage any other use. > Well, if this is what is being asked for, then the application could > as well use the PF_KEY(7P) socket to push the keys to kernel using > SADB messages. Why do we need a separate set of API's? IP_SEC_OPT is easy to use in an application. PF_KEY is not (unless you're a KE application, which is not simple anyways). _______________________________________________ networking-discuss mailing list [email protected]
