Thomas Narten wrote: > Mike Taylor <[EMAIL PROTECTED]> writes: > >> And while it isn't a surmountable problem >> >> 5. We are being forced to treat all of our IPv6 enabled protocols >> such as FTP as encryption items by the U.S. export authorities >> because the U.S. government thinks they must be since IPv6 >> "includes security". It's just plain silly since our IPv6 is no >> different than our IPv4 - both get all their security from our >> IPsec which is sold separately. But we can't convince them >> otherwise because it has been mandated that all IPv6 nodes shall >> support IPsec. We can sell our IPv6 code without any trace of IPsec >> save for a few lines of interface code that are #ifdef'd out when >> IPsec isn't present and yet our IPv6 stack and worse yet, all of >> the socket-layer apps that support IPv6, are viewed as encryption >> items. Good grief. > > This sounds completely bogus to me. I've never heard of this problem > before. Who else has this problem?
Sorry, I've not followed the complete thread, I just follow on this message snippet. A while ago, when planning for implementing an IPv6 stack, we faced some regulating issues. Namely that because 3des, sha-1 and md-5 were necessary parts for ESP and AH, necessary parts of IPv6, and because this code was clearly under US export control regulations at that time, and because we were in a country different than the one controlling its export, and because in that country use of encryption software was regulated differently - we decided to write our own implementations of these algorithms and submit it to different regulators in a way we wanted to. The goal was not to circumvent these controls, which are really the law, but to have control about how to be controlled, if I can say so. This was successful to a certain degree, but also faced many hurdles to get through. Remark that similar worries circulated when linux kernels started including IPsec features by default (from freeswan was that?). I'm not sure where is it now, but I think linux 2.6 kernels are widely deployed and include this security code. Remark also that, for example, SHA-1 code wasn't available in an RFC except until recently. I'm not sure IETF faces these RFCs to the different export regulations of different countries. Just some thoughts, and and I'd like to stress the various local regulations on security code are far from approaching any level of bogusness and can backfire very nasty - one should learn the different governments' requirements and act responsibly. Alex > > Thomas > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
