Subject: RE: ipv6 Digest, Vol 46, Issue 33

From: Mike Taylor <[email-masked]>
Date: Wed, 27 Feb 2008 14:36:43 -0800 (PST)

> quick poll - for those opposed to a MUST requirement for IPsec, what
> is your driving objection?
> 
> 1.  the Internet *does not* need a mandatory security mechanism at
> the IP layer
 
True.  My personal feeling is that security at the IP layer is probably
wrong for the majority of systems.  It's great for setting up VPNs
between security gateways with fixed globally routable addresses but
otherwise it just doesn't seem to make a lot of sense.  At least not
if that IP-layer security, like IPsec, has to depend on configuring
packet filters based on IP addresses, protocol numbers, and ports
which as we know are far from permanent entities.
 
It seems to me that the fundamental notion behind IPsec is that
there is something sacred about IP addresses and port numbers, i.e.,
that they provide some form of permanent, trustable identification
of a node.  But of course that just isn't true.  So what's the point, 
in general, of coupling a security mechanism to IP addresses and ports?  
I just personally don't get it, save for the one obvious application 
already notd above for VPN gateways.
 
> 2.  the Internet *does* need a mandatory security mechanism at the IP
> layer, but IPsec is not the right one because it is too heavyweight
> 3.  the Internet *does* need a mandatory security mechanism at the IP
> layer, but IPsec *alone* is insufficient (without IKE, key mgmt, etc)
 
> 4.  I don't care about the architecture of the Internet, because I
> intend to develop devices that are never connected to the global
> Internet (and therefore play no role in defining the Internet
> architecture or adhering to Internet best practices).
> 
 
And that too.  Many of our customers are developing systems for
closed private networks.  We're not sure why they'd want to use IPv6
for that purpose but hey, the customer is always right.  Certainly
they should be able to develop lightweight devices for use on their
private network and if those devices need to access the global internet
they should be able to use a security gateway to accomplish that.
But they wouldn't want to burden those devices with IPsec, even
if IP-layer security made sense.
 
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]
> https://www.ietf.org/mailman/listinfo/ipv6
> 
> 
> End of ipv6 Digest, Vol 46, Issue 33
> ************************************

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

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

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

---

From: Thomas Narten <[email-masked]>
Date: Fri, 29 Feb 2008 15:16:49 -0500

>    that support IPv6, are viewed as encryption items.  Good grief.

This sounds completely bogus to me. I've never heard of this problem
before. Who else has this problem?

Thomas