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: [email protected] > 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 > > > > > [email protected] <mailto:[email protected]> > > > > > https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > > > > > > > > > > End of ipv6 Digest, Vol 46, Issue 33 > > > > > ************************************ > > > > ------------------------------------------------------------------------ > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [email protected] <mailto:[email protected]> > > 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 [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
