Subject: Re: ipv6 as an export issue

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 29 Feb 2008 15:47:25 -0500

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
--------------------------------------------------------------------