Does this mean that Microsoft went and got approval for every Windows PC since XP came out? Or that every PC manufacture (including hand helds and Windows Mobile cell phones) had to do register too?
Seems a bit extreme to me. Eric On 2/29/08, Ed Jankiewicz <[EMAIL PROTECTED]> 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 --------------------------------------------------------------------
