I used to follow export issues in 1997/1998 at which time any 'hard- to crack' encryption was not exportable [hence all sorts of implementations using 40 bit keys]......yet any crypto used solely for authentication purposes was exempt. This has changed over the years and of course different countries have different regulations.
This wiki is actually pretty good in terms of a synopsis on the history in US: http://en.wikipedia.org/wiki/Export_of_cryptography Any vendor shipping IPsec (or any other technology utilizing cryptographic algorithms) since mid 1990's will be familiar with the export rules (and their permutations). All companies shipping products with encryption [or thinking of doing so] need to look at http://www.bis.doc.gov/encryption/default.htm ..... and http:// www.bis.doc.gov/encryption/lechart1.htm I guess the Bureau of Industry and Security may need some re- education since in practice not all IPv6 implementations support IPsec with encryption capability (some initial implementations that did IPsec as a checkmark only shipped IPsec AH). To me it also seems an education process for new vendors that deal with v6 and have no prior export issue experience.......while it seems ridiculous to fill out paperwork with N/A in all fields........well............whatever it takes to get the right license. - merike On Feb 29, 2008, at 12:47 PM, Ed Jankiewicz wrote: > wow. I've never heard of the Bureau of Industry and Security. > I'll do > a little digging, hopefully can get an opinion from someone at > NSA. It > seems like an overly simplistic assumption that all IPv6 products are > encryption items. I'll post anything I discover that is "approved for > public release" to the list. > > [EMAIL PROTECTED] wrote: >> Hello Ed, >> >> We have been fighting this battle directly with government personal >> at the Bureau of Industry and Security >> (http://www.bis.doc.gov/about/index.htm) >> both by email and by phone. It has been going on for months. We >> finally >> had a phone conversation with a higher level manager at BIS just the >> other day and as I expected by then we were told basically that if >> IPv6 >> is mentioned anywhere in our product's documentation (even for socket >> layer protocols like FTP or Telnet that happen to be able to run over >> IPv6 sockets) that we MUST submit these products as encryption items >> and fill out Supplement No. 6 to Part 742—Guidelines for Submitting >> Review Requests >> for Encryption Items and that they will have to go to the NSA and >> others for review. >> The mistake we made before is that we tried to submit these items as >> if they did >> not include any encryption capabilities, which of course they do not, >> but this manager >> informed us that in that case the review is done by lower level >> people >> who absolutely are >> trained that if it says IPv6 then it is an encryption item >> because, as >> this manager told us >> repeatedly, IPv6 by definition includes security so any products that >> support IPv6 are >> by definition encryption items and must be reviewed by BIS as such. >> And this >> review is done by different people than the ones who review non- >> encryption >> items. We tried to explain again to him that technically it simply >> wasn't true that >> IPv6 really has built-in security but as I expected it wasn't any >> use. >> >> He assured us that so long as we explained in supplement 6 that in so >> many words >> the products were "passive" with regard to security, i.e, had no >> means >> of influencing >> whether or not any security was applied to the application data, then >> it would not >> be a lengthy process and we should get them through pretty easily. >> But he also >> explained that the goverment doesn't care where the actual security >> operations >> get carried out in the code. That is, the fact that it is all >> done by >> a separate >> IPsec module and that we can sell our IPv6 code without IPsec is >> irrelevant. >> The issue as best we can tell seems to be whether the product >> provides >> an API >> by which a user of the product could influence/configure the use of >> security. Of >> course none of our socket-layer products have such an API, and in >> fact >> our IPv6 >> stack doesn't even have such an API. Only the IPsec product itself >> has such >> an API. >> >> So once we explained this to him he acknowledged that probably we >> will >> in the >> end be able to export the IPv6 products, without IPsec, under a >> lesser >> export >> license (I forget the number) than an actual encryption item such as >> IPsec itself. >> However, the products MUST still go to the correct people for review >> and thus >> MUST be submitted with Supplement 6 as potential encryption items >> or they >> will never get through. The laughable part is that every single part >> of Supplement >> 6 will end up being filled out as N/A since this form asks you to >> supply the >> details, like supported maximum encryption key lengths, for the >> supposed >> encryption item. It's like some episode of MASH. >> >> So it really aggravates us that because this misguided notion has >> been >> propagated >> that IPv6 somehow has "built-in" security we must now go through this >> lengthier and >> more involved process than we otherwise would have. Especially >> since, >> as we all know, >> IPv6 has does not have built-in security any more than does IPv4 and >> yet apparently >> because of the IPv6 node requirements document mandating that IPv6 >> nodes must >> support IPsec the goverment has been lead to believe that IPv6 by >> definition has >> built-in security. >> >> Regards, >> >> Mike Taylor >> >> >> ----- Original Message ---- >> From: Ed Jankiewicz <[EMAIL PROTECTED]> >> To: Mike Taylor <[EMAIL PROTECTED]> >> Cc: ipv6@ietf.org >> Sent: Friday, February 29, 2008 10:22:47 AM >> Subject: Re: ipv6 Digest, Vol 46, Issue 33 >> >> Can you provide a citation to some authority for export >> restrictions on >> IPv6? I have not heard that before and find it surprising (though >> not >> impossible). That would be troubling, because IPsec in and of itself >> (and by association IPv6) does not necessarily contain any >> cryptographic >> code, although an implementation might. Also, not all algorithms >> would >> be subject to export control. Nothing in IPv6 or IPsec compels an >> implementor to include any restricted cryptographic code. >> >> I am definitely not a cryptography expert, nor am I an authority >> on US >> export regulations. However, in my day job I deal with IPv6 >> standards >> for US DoD and interact with a lot of vendors. I don't recall this >> coming up with any vendors, but if there is a chance this will be an >> issue, I need to do some homework. In particular, for DoD use we may >> require more advanced algorithms (see RFC 4869 and >> http://www.nsa.gov/ia/industry/crypto_suite_b.cfm) and I don't >> know what >> the restrictions on export of that code would be. >> >> Ed J. >> >> Mike Taylor wrote: >>> >>> 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. >>> >>> >>> >>> Regards, >>> >>> >>> >>> Mike Taylor >>> >>> >>> >>>> R, >>> >>>> Dow >>> >>>> >>> >>>> >>> >>>> ------------------------------ >>> >>>> >>> >>>> _______________________________________________ >>> >>>> ipv6 mailing list >>> >>>> ipv6@ietf.org <mailto:ipv6@ietf.org> >>> >>>> https://www.ietf.org/mailman/listinfo/ipv6 >>> >>>> >>> >>>> >>> >>>> End of ipv6 Digest, Vol 46, Issue 33 >>> >>>> ************************************ >>> >>> -------------------------------------------------------------------- >>> ---- >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org <mailto:ipv6@ietf.org> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >> > > -- > Ed Jankiewicz - SRI International > Fort Monmouth Branch Office - IPv6 Research > Supporting DISA Standards Engineering Branch > 732-389-1003 or [EMAIL PROTECTED] > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
