link-layer encryptors for Ethernet?

John Denker jsd at av8n.com
Wed Feb 9 12:02:21 EST 2005


Steven M. Bellovin wrote:
> Are there any commercial link-layer encryptors for Ethernet available?  
> I know that Xerox used to make them, way back when, but are there any 
> current ones, able to deal with current speeds (and connectors)?

Several people have made suggestions involving IPsec,
which were not immediately accepted.

Let me try to kick the discussion downfield a little ways.

I don't know what application Steve has in mind, but
there exists a wide range of applications for which I
would seriously consider the following approach:
   GRE over IPsec transport.

This would not in the narrowest sense be encrypting the
layer-2 traffic, but it would look like that to the
applications.

To say the same thing in more detail:  As you know, the
IPsec RFC covers two main subjects:
  A) the layout of the packets, and
  B) the SPDB (security policy database)

If we temporarily neglect part (B), to a decent approximation
we can describe IPsec tunnel mode in terms of IPsec transport
mode, as follows:
   IPIP over IPsec transport.

The analogy to GRE over IPsec transport should now be clear.
You can call it GREsec or L2sec.

The SPDB issues can now be stirred back in.  In the
implementation of IPsec that I am most famililar with
(OpenS/WAN, descended from FreeS/WAN) the SPDB was
   a) never 100% implemented, but
   b) what was implemented was pretty much orthogonal
    to the packet-formatting business,
so you don't AFAICT lose anything important by using GRE
instead of IPIP encapsulation.

=============

I would argue that for most applications, GREsec is better
than genuine strict link-layer encryption, because it
can, if you want, be transported across routers, whereas
anything at the genuine link layer cannot.

I realize that there remain some issues that I have not
addressed, notably processes that live in the gray area
between layer two and layer three, such as arp, dhcp,
and neighbor discovery.

=============================

If this is barking up the wrong tree, please explain why.
Please tell us the real requirements in more detail.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list