Subject: Re: ipv6 as an export issue

From: "Eric Klein" <[email-masked]>
Date: Sun, 2 Mar 2008 13:54:55 +0200

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

---

From: Merike Kaeo <[email-masked]>
Date: Mon, 3 Mar 2008 19:51:00 -0800

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:

>> review is done by different people than the ones who review non- 
>> encryption
>> MUST be submitted with Supplement 6 as potential encryption items  
>> or they
>>>    is sold separately.  But we can't convince them otherwise  
>>> because it
>>>
>>> ----

---

From: [email-masked]
Date: Fri, 29 Feb 2008 12:34:24 -0800 (PST)

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-masked]>
To: Mike Taylor <[email-masked]>
Cc: [email-masked]
Sent: Friday, February 29, 2008 10:22:47 AM
Subject: Re: ipv6 Digest, Vol 46, Issue 33

Ed J.

Mike Taylor wrote:
>    is sold separately.  But we can't convince them otherwise because it
>
>    lines of interface code that are #ifdef'd out when IPsec isn't present
>