On Tue, 2013-11-05 at 17:53 -0800, Christian Huitema wrote: > Encrypting the links that transport lots of private data to faraway > places look like a reasonable practice. But it is one of many possible > solutions. It may well be more practical to use a form of end-to-end > encryption between the components of the data centers. See classic > debate on end-to-end versus link-by-link, in which end-to-end tends to > win most of the time.
If the applications and the complexity of adding end-to-end encryption to them is low in the DC interconnect case, it may be the easiest approach. Also, defense-in-depth. However, with MAC PHY's already available with 802.1AE - MacSEC, doing AES-128 or AES-256 (switches available today!), it's also quite low-hanging-fruit for the data link layer. And this applies for all traffic on a link, and some links are obviously more interesting than others. If for example ISPs renting trans-oceanic wavelengths from cable system operators were to encrypt their router-to-router links, the defensive surface against pervasive surveillance would drastically grow in terms of number of organizations to engage with secret laws. This does make tapping much more complex, and expensive, and really is quite low hanging fruit. Decreasing pervasive surveillance is not an all-or-nothing project. However, before ISPs could begin encrypting their backbone links, there would have to be a business case for doing it, e.g. customers demanding it. What would help, I believe, is some form of standard on how operators do the encryption, that could be included as a MUST in RFQs. This could very well be an RFC. It would also definitely help to get this going that a couple of really large networking enterprises made vendors create/expand products. These would be IEEE, and I wonder if 802.1AE is sufficient already? /M
signature.asc
Description: This is a digitally signed message part
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
