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? >> > > If the system doesn't have the keys configured, then you can't > meaningfully turn it "on." The only thing you can do is fail if it > isn't available. > > If the system does have keys, and is configured to use TCP-MD5, then > allowing the application to turn it off seems silly to me. > 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).
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. > I don't see a real point to an on/off switch. > > >> 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. > > 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? ~Girish _______________________________________________ networking-discuss mailing list [email protected]
