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
>
> > https://www.ietf.org/mailman/listinfo/ipv6
>
> >
>
> >
>
> > End of ipv6 Digest, Vol 46, Issue 33
>
> > ************************************
>
> ------------------------------------------------------------------------
>
> --------------------------------------------------------------------
> 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
--------------------------------------------------------------------
