Re: [RFC] Ethernet Cheap Cryptography

[stephen@dino.dnsalias.com (Stephen J. Bevan)]

Pawel Foremski writes:
 > Consider such an example: our task is to bridge two LANs managed by a
 > third-party ISP over a wireless link, with the highest performance possible
 > for such medium. The ISP has its clients on one LAN and a PPPoE
 > concentrator on the second one.  Because the ISP doesn't trust us
 > or is not aware of our bridge, it uses MPPE to secure PPP. We
 > cannot enforce any changes to the way the ISP provides services to
 > its end users.  
 > 
 > In ASCII art, that would be:
 > 
 > [PPPoE server]---[Linux#1]--ccrypt--[dumb WiFi bridge] )))  \/
 >                                                             ||
 > [PPPoE client]---[Linux#2]--ccrypt--[dumb WiFi bridge] ((( <=/
 > 
 > Obviously, the dumb WiFi bridge cannot speak anything other than 1500-byte,
 > plain (not encrypted) Ethernet.

Since there was no mention of bridging in the ccrypt documentation or
previously in the email thread I (incorrectly) assumed that PPPoE was
terminating on the Linux box.  Thus the IP traffic would be visible
and hence IPsec could be used.  Clearly if the Linux box is bridging
PPPoE as you note above then IPsec is not viable.  Thus the addition
of the above scenario to the ccrypt documentation help would avoid
getting questions about why you can't use IPsec :-)

However, in the above you note that MPPE is being used.  I take this
to mean that all the PPP traffic between the PPPoE client and PPPoE
server is encrypted.  However, if that's the case then I don't
understand why there is a need to use ccrypt for the wireless link
between the two Linux boxes.  Thus perhaps I misunderstood where MPPE
is being used?  Or perhaps you meant this is only one example and in
other scenarios MPPE is not used and so in that case the wireless
traffic does need encrypting?