-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: > Joe, > >> ... >> >> Whatever BTNS is _now_ motivated by, it WAS motivated by the need for >> transport protection in the absence of a-priori keys (infrastructure or >> predeployed). > > I agree that was your motivation, and you explained that clearly. But we > now have a WG with a broader set of goals, and thus the original > motivation you cite is not the only one. Steve, AOK; it'd be useful clarify the broader set since it relates to the P&AS. >> As to the reasons you cited in your original quote: >> 1- performance >> 2- security of the software system >> 3- lower layer can be done elsewhere in the system >> 3- using BTNS as a place to explore split-layer security >> >> For which of these would SSL address a BTNS use case? > > There are a number of outboard, SSL accelerator products that clearly > support #1 above. The use of such outboard accelerators could improve > crypto security relative to the application layer, although that depends > on the crypto options available to the application. The fact that these > accelerators are analogous to BITW IPsec implementations also allows > them to avoid some of the OS security pitfalls that accrue to an > application running on the most popular OS, which also supports #2 > above. Although it is an awful protocol layering violation, outboard > accelerators for SSL are regularly placed as intermediate systems, just > like IPsec SG, consistent with (the first) #3 above. The second bullet > #3 above is NOT something I cited as a motivation for layer 3 security, > so it seems out of place on your list. It wasn't my list; it was a summary of yours (with my misnumbering): (note that the 4th one, the second #3 above, was listed in the negative in your list): - -- quoted from original mail, "*" inserted to highlight the items above: There are multiple motivations for imposing security controls at layer 3. *Performance* may be important in some instances, as you suggest, but more often the motivations have to do with assurance and management. Lower layer controls can be *more secure* that higher later controls, given the unfortunate state of OS and application security. Lower layer controls *can be imposed (cleanly) at points other than end systems*, which simplifies management and also may improve assurance. None of this says that application layer security is redundant. However, it also does not suggest that *trying to split security services* between layer 3 and layer 7, as some BTNS use cases require, will necessarily work well. - -- None of these are solved by SSL; SSL has corresponding solutions for the first three, but in no case does it protect the transport connection. I.e., what is the motivation for BTNS that does not include - if not focus - on transport protection? >> > Also, SSL/TLS now is defined to support UDP, so the traditional >> argument >>> about needing to use IPsec to accommodate other than TCP is no longer >>> valid. >> >> There are more transport protocols than just TCP and UDP. See >> http://www.iana.org/assignments/protocol-numbers for a complete list ;-) > > The vast majority of the protocols on that list are rarely used or > obsolete (a limiting case of rarely used). For example, when do you > think the last packet radio measurement packet (#21) was sent :-)? This > is not a very relevant list for purposes of our discussion, although I > admit there are transport protocols other than TCP and UDP. The relevant > question is which ones are of interest to the potential set of BTNS users. RTP is used for VoIP, which is becoming more common, as we hope will be DCCP and SCTP. Then there are infrastructure protocols, like ISIS-over-IP. i.e., not all of these are as likely to be used as others, but there are more than 2. However, SSL/TLS is a red-herring here anyway; it doesn't protect the transport layer. TCP/MD5 is the comparable protocol for potential BTNS users; there is no equivalent for UDP, and we'd need to reinvent it for every other transport protocol in use (at least the handful above) as well. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD/Os4E5f5cImnZrsRAovAAJ99sYd/xB+OhZBq4tj5cyYGBh+BpQCgma0h JW6Vm0ouTCoinrZKZTb0l9s= =vFdq -----END PGP SIGNATURE-----
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.