Nicolas Williams writes: > But TCP-MD5 isn't exactly a great protocol (no automatic keying, no > re-keying, ...)
Agreed; it's not. It's there for compatibility reasons. (Read: "cisco") > 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. That seems to me to get more complicated. Why should we apply more implementation effort to something that is intentionally narrow use. > 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. That's it. It's BGP, LDP, and related routing protocols that use this. As a practical matter, it'd be quite difficult for anyone else to use it -- mostly because there'd be nobody at the other end speaking the same protocol. Sure, someone could deliberately ignore our advice, and do something weird. As vendors, we're in the rope selling business. > > 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). Perhaps it could even be useful one day (though I doubt it), but I see no reason for it now, no matter how easy it is to use. We're not talking about ad-hoc connections where the application might have "preferences" regarding the kind of protection provided. Instead, these are effectively nailed-up connections that are explicitly configured between specially configured routing daemons. The option just doesn't make sense to me. The only one that could make some sense is PF_KEY, as a full Cisco-like command line interface would potentially allow the user to specify the key from within the application (as distasteful and insecure as that may be). But I know of no use that looks like IP_SEC_OPT. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
