Re: [RFC] Ethernet Cheap Cryptography
Stephen J. Bevan wrote: 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? For example because MPPE is optional and some sessions may be encrypted and some not. As I mentioned, we cannot influence the ISP in topic. More generally, I wanted to present an example of a layer-2 encapsulation that Linux does not know or (as in this case) can't modify the data in it, thus it cannot fix the TCP MSS value. -- Pawel Foremski [EMAIL PROTECTED] - 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
Re: [RFC] Ethernet Cheap Cryptography
Stephen Hemminger wrote: Ethernet encrypted bridging is old stuff: http://kerneltrap.org/node/167 http://www.arnor.net/encryptingbridge/ It never got accepted, mostly for the same reasons this proposal is a dead end. From what I can see in the brief description is that ccrypt is more general as it is not limited to ethernet bridging code, UDP and AES. Unfortunately I cannot find any replies to the announcement you've mentioned and thus I am and was not aware of the objections to the encrypted bridging idea. I knew the encrypted bridging project before starting to think about ccrypt, BTW. -- Pawel Foremski [EMAIL PROTECTED] - 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
Re: [RFC] Ethernet Cheap Cryptography
Stephen J. Bevan wrote: Pawel Foremski writes: Secondly, IPsec won't decrease MSS in TCP encapsulated in PPPoE traffic, for example. Various, commercial, IPsec products decrease the MSS for TCP encapsulated in PPPoE. I've not checked the Linux 2.6 IPsec code to see if it does or if it can easily be made to. 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. IMHO it's quite probable to come up with another example. Only if the rekeying traffic is the only being transmitted. IMHO a border case. Unless you mask the size of your (re-)keying traffic by randomly padding the packets then they can be detected even in the middle of other traffic. Yeah, you're right, forgot about padding. Sure, but that's IMHO little bit off-topic in regard to ccrypt, which is just an encryption back-end (eventually the rekeying daemon will sit in the userspace). Sure. However, there has to be a user-kernel API and the question is whether what you have now is sufficient when a daemon is added or whether it will need to change? If it does need to change it will need to be backwards compatible or need to be a separate API? Ah, so you were asking about API. Then, Dawid should probably answer that question as he's implemented the whole ccrypt. The sysfs API may not always be available for userspace tools, good point. Also at least for IPsec, the kernel knows something about IKE in that generally IKE traffic is not encrypted by IPsec. Instead IKE has its own encryption which it bootstraps using shared-secrets/certificates/publicpreivate key pairs. In the case of ccrypt either the ccryptKE protocol would need to bypass ccrypt or you need to way to start off with known keys, but not the same keys every time or that can be exploited. I think in case of ccrypt it could be administrators task to ensure that the ccrypt key exchange traffic won't be encrypted by it. Dawid mentioned using vlans or macvlans, but I guess it wouldn't be much complicated to add another possibilities in future, if required. P.S. Please excuse me not CCing this post to all interested people, but temporarily I'm using gmane gateway through knode (real pain ... ;-) -- Pawel Foremski [EMAIL PROTECTED] - 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
Re: [RFC] Ethernet Cheap Cryptography
Stephen J. Bevan wrote: Dawid Ciezarkiewicz writes: It enforces to use upper level encryption with internal fragmentation which is problem because of more more frames that those bridges have to handle, bigger traffic etc. Where did the fragmentation come from? If you are sending TCP over IPsec then the ESP/AH code should decrease the TCP MSS as it goes through to take acount of the extra space that IPsec will take up. Thus neither end-point will ever send a frame on that session that will require fragmentation. Granted you can still have a problem if someone sends a UDP packet that is close to the 1500 MTU, but RFCs recommend against it (e.g. DNSSIP) and applications should try to avoid it. First, ccrypts task is to secure Ethernet, not IP. Secondly, IPsec won't decrease MSS in TCP encapsulated in PPPoE traffic, for example. Thus the argument for ccrypt should say :- a) why IPsec is not suitable for securing IP traffic in WIFI scenarios. It's suitable. But for IP. b) what traffic other than IP traffic needs to be encrypted. PPPoE; Ethernet in general. This allows key switching without loosing any frames. It should be done quickly, since when in key transition state all invalid/spoofed frames have double cpu impact on receiver. Shouldn't be a problem because attacker should have no clue about when key is being switched. If the keying is done manually an attacker won't know when the keys are changed. However, if keying is coordinated over the same link via a protocol (as is done with IKE for IPsec) then the attacker can see (or at least guess) the packets carrying the keying protcol thus know re-keying is going to occur. Only if the rekeying traffic is the only being transmitted. IMHO a border case. Indeed, in IPsec, the equivalent of ccrypt is ESP and that's rather straighforward. The complicated part is IKE, the userspace component that handles keying. It is certainly possible to create something simpler than IKE (e.g. IKEv2 is somewhat simpler) but the devil is in the details. Sure, but that's IMHO little bit off-topic in regard to ccrypt, which is just an encryption back-end (eventually the rekeying daemon will sit in the userspace). Oh, and of course I agree IKE (v1) is too complicated :-). I was not aware of that. Thanks. I will add this info to documentation. There is nothing actually I can do about that in the form that ccrypt is mean to be now. For completness there are also switches that :- * take notice of the TOS/DiffServ bits in an IP header and will re-order based on them * will re-order frames due to redundancy, load-balancing, spanning-tree changes ... etc. I'll only add to what Dawid has said that ccrypt has been designed for direct P2P links, with single path (and no such switches on it's way). Later it turned out to be applicable for eg. small (simple) LANs or wireless ad-hoc networks. Thanks for your remarks! Bye, -- Pawel Foremski [EMAIL PROTECTED] - 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
Re: [PATCH 6/7] bonding: Add priv_flag to avoid event mishandling
Jay Vosburgh wrote: Add priv_flag to specifically identify bonding-involved devices. Needed because IFF_MASTER is an unreliable identifier (vlan interfaces above bonding will inherit IFF_MASTER). Misidentification of devices would cause notifier events for other devices to be erroneously processed by bonding, causing various havoc. Just wanted to report that this patch solves a kernel oops on 2.6.17.11 while trying to change name of a VLAN device created on top of a bonding one. Thanks, -- Pawel Foremski [EMAIL PROTECTED] -- VGER BF report: U 0.687767 - 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
