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? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
