Re: [RFC] Ethernet Cheap Cryptography
On Sun, 15 Oct 2006, Dawid Ciezarkiewicz wrote: > Hi, > I'd be thankful for your opinions about that idea. Please forgive me any > nuances that I didn't know about. This limits the system to only talking to one other system on the same link. I guess you could have per-MAC keys and associate the crypto info with neighbor cache entries. Likely need a cryptographer to review the protocol -- blindly using the first block of every encrypted packet as the IV smells problematic, for example. - James -- James Morris <[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
On Sunday, 15 October 2006 23:35, you wrote: > > Hi, > > I'd be thankful for your opinions about that idea. Please forgive me any > > nuances that I didn't know about. > > This limits the system to only talking to one other system on the same > link. I guess you could have per-MAC keys and associate the crypto info > with neighbor cache entries. The idea is to use vlan and macvlan devices to separate encrypted traffic - as you can just encrypt vlan device. Other than that - yes ccrypt was considered as solution for point-to-point links. > Likely need a cryptographer to review the protocol -- blindly using the > first block of every encrypted packet as the IV smells problematic, for > example. Cryptographic part needs attention. I'm not a cryptographer and no cryptographer have checked the idea or code. And yes - this is little problematic, but I think the solution is good enough - there is little chance to inject valid upper level packet, and even if such event occur - there is no chance that can carry valid hostile information. The magic function is is_decoded_buffer_valid, which - using upper level info - will just drop packets that weren't encrypted correctly. There are little chances that spoofed frame after decryption will look like good packet - for IPv4 I estimate them to be much less than 1 to 256 * 256 * 32 (2097152) and this can be rather easily improved. Injected packets that will not pass such validation will not change stored IV, so transmition will not be affected. And even when such frame will pass - it will probable consist of garbages - the only effect will be using bad IV in the next encryption - so next good frame will be dropped. If ccrypt will be considered reasonable I was thinking about kernel warnings on spoofing tries detection, using simple bad frames counters. - 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
From: [EMAIL PROTECTED] (Stephen J. Bevan) Date: Tue, 17 Oct 2006 20:21:46 -0700 > * You write "frames will be delivered in order, so on the other side > IV can be always in sync." In fact, in addition to your comments, Linux can reorder packets locally within the system even within traffic for the same link. Any technology which absolutely requires in order packet delivery isn't going to work very well. - 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
On Wednesday, 18 October 2006 05:21, you wrote: > Dawid Ciezarkiewicz writes: > > I'd be thankful for your opinions about that idea. Please forgive me any > > nuances that I didn't know about. > > * I suggest extending the documentation with some motivating examples > of why someone would want to use this rather than IPsec for IP > and/or in what scenarios you'd envisage someone wanting to encrypt > ARP, PPPoE, ... etc. Perhaps, you can somehow mesh it with 802.1x > to provide link-level encryption to augment 802.1x link-level > authentication? You're right. I'll add such documentation. For now - short version: as a company dealing with wifi regularly we often come to a problem - using wifi bridges with strengths like price, "CE included", easy integration, good bandwidth, distance etc. - that those devices regularly have max eth mtu 1500, not much cpu power and are often so feature-less that there are many problems with good traffic security. 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. We think that solution like ccrypt will be far more secure and simple - and allows to maximize bandwidth and packet per second rate. > * Your implementation allows the key to be changed but not in a way > that allows both sides to do so without disrupting traffic i.e. you > don't have something akin to IKE phase2 re-keying. Without that > then if someone can sniff the traffic long enough they are going to > get a big sample of data to try and crack the keys with. Well - ccrypt allows to change keys without disrupting traffic. It works like this: first new ccrypt_rx alg:key pair is added. After that ccrypt_rx will still use old alg:key, but all unmatched frames will be challenged against new one too. Then as soon as possible ccrypt_tx should have that new alg:key pair added. When ccrypt_rx gets new frame sent by new alg:key it will not match old alg:key, but will match new one. Receiver will switch then and from now on it will use only new pair. 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. As device ccrypt_rx and tx are independent traffic encryption can use independent keys in both traffic directions. And because they use pairs of alg:key, in each change: algorithm, key and key length can be changed at once. AFAIK attacker have no way to tell where such change occurs nor what are parameters of current alg:key. The idea is to change keys regularly on both sides with userspace tools - like ssh on separate vlan, or even simpler static key rotation algorithms or something like it. This should allow secure alg:key switching with about any frequency. I hope this will make cracking keys hard enough for attacker that it will not even try. Integrity security is more difficult (and possibly weaker) part of ccrypt. > * You write "frames will be delivered in order, so on the other side > IV can be always in sync." If any switches between the two linux > boxes are running any kind of link aggregation then you can't > guarantee that the frames will be delivered in order. IEEE 802.3ad > requires that packets belonging to the same session travel down the > same port to avoid re-ordering but implementations vary as to > whether they actually guarantee it or not since most higher level > protcols can survive some re-ordering. 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. > * Given your desire not to change the size of the payload you have no > space for MAC. This makes it easier (but by no means easy) to alter > the payload in such a way that it is still decrypted and considered > valid. Could you explain it more? I don't understand. You mean MAC as ... ? > * For the same reason as above you don't have a sequence number. This > combined with the lack of MAC weakens the defense against replay > attacks i.e. where third party captures a packet and then re-sends > it at a later time. The fact that IVs must be in sync for the > packet to be accepted makes it harder for an attacker but since they > know how the IV is calculated they know what message to look for > before replaying a packet. Maybe because of previous one I don't clearly understand the mechanisms. Please - if you could explain it more - that knowledge would be very useful, and I could put it into the docs too. > * A variation of the above is that the attacker doesn't care about > injecting packets per se, rather they use the above to cause packet > loss by causing the receiver to update its IV based on a replaye
Re: [RFC] Ethernet Cheap Cryptography
On Wednesday, 18 October 2006 05:25, David Miller wrote: > From: [EMAIL PROTECTED] (Stephen J. Bevan) > Date: Tue, 17 Oct 2006 20:21:46 -0700 > > > * You write "frames will be delivered in order, so on the other side > > IV can be always in sync." > > In fact, in addition to your comments, Linux can reorder packets > locally within the system even within traffic for the same link. > > Any technology which absolutely requires in order packet delivery > isn't going to work very well. I've tried to put ccrypt handlers as close to hardware xmit and recv as possible so local reorder doesn't matter. Medium doesn't reorder frames and switches, bridges shouldn't do that neither (but as Stephen J. Bevan said this may not be always true). - 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
From: Dawid Ciezarkiewicz <[EMAIL PROTECTED]> Date: Wed, 18 Oct 2006 11:51:46 +0200 > I've tried to put ccrypt handlers as close to hardware xmit and recv as > possible so local reorder doesn't matter. Medium doesn't reorder frames and > switches, bridges shouldn't do that neither (but as Stephen J. Bevan said > this may not be always true). You can put it all the way in netif_receive_skb() and you still can see reordering of receive packets on an SMP system. - 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
On Wednesday, 18 October 2006 12:16, David Miller wrote: > From: Dawid Ciezarkiewicz <[EMAIL PROTECTED]> > Date: Wed, 18 Oct 2006 11:51:46 +0200 > > > I've tried to put ccrypt handlers as close to hardware xmit and recv as > > possible so local reorder doesn't matter. Medium doesn't reorder frames and > > switches, bridges shouldn't do that neither (but as Stephen J. Bevan said > > this may not be always true). > > You can put it all the way in netif_receive_skb() and you still > can see reordering of receive packets on an SMP system. Thanks for pointing that out. As every frame reorder will cost "only" one real frame to by lost I need to investigate this issue and get more real testing in such environments. - 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
On Wednesday, 18 October 2006 11:15, Dawid Ciezarkiewicz wrote: > > * Given your desire not to change the size of the payload you have no > > space for MAC. This makes it easier (but by no means easy) to alter > > the payload in such a way that it is still decrypted and considered > > valid. > > Could you explain it more? I don't understand. You mean MAC as ... ? Oh. Sorry. You mean message authentication code. Well - ccrypt have to live without it. From the start I knew that integrity will be the weakest point of ccrypt. - 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
Dawid Ciezarkiewicz writes: > You're right. I'll add such documentation. For now - short version: as a > company dealing with wifi regularly we often come to a problem - using wifi > bridges with strengths like price, "CE included", easy integration, good > bandwidth, distance etc. - that those devices regularly have max eth mtu > 1500, not much cpu power and are often so feature-less that there are many > problems with good traffic security. So far so good. > 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. DNS&SIP) and applications should try to avoid it. Thus the argument for ccrypt should say :- a) why IPsec is not suitable for securing IP traffic in WIFI scenarios. b) what traffic other than IP traffic needs to be encrypted. > Well - ccrypt allows to change keys without disrupting traffic. It > works like this: first new ccrypt_rx alg:key pair is added. After > that ccrypt_rx will still use old alg:key, but all unmatched frames > will be challenged against new one too. Then as soon as possible > ccrypt_tx should have that new alg:key pair added. When ccrypt_rx > gets new frame sent by new alg:key it will not match old alg:key, > but will match new one. Receiver will switch then and from now on > it will use only new pair. And if the packets come out of order i.e. you get a packet with a new key followed by a packet with the old key? > 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. > As device ccrypt_rx and tx are independent traffic encryption can use > independent keys in both traffic directions. And because they use pairs of > alg:key, in each change: algorithm, key and key length can be changed at > once. AFAIK attacker have no way to tell where such change occurs nor what > are parameters of current alg:key. > > The idea is to change keys regularly on both sides with userspace > tools - like ssh on separate vlan, or even simpler static key > rotation algorithms or something like it. This should allow secure > alg:key switching with about any frequency. 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. > 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. - 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. DNS&SIP) 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: [RFC] Ethernet Cheap Cryptography
Pawel Foremski writes: > First, ccrypts task is to secure Ethernet, not IP. Understood, but the vast majority of traffic running over Ethernet that a user cares about is IP and so IPsec does the job. Obviously IPsec cannot handle non-IP traffic but the question is what non-IP traffic do users want encrypted? > 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. > > b) what traffic other than IP traffic needs to be encrypted. > > PPPoE; Ethernet in general. PPPoE carrying IP can be handled by IPsec as noted above. That leaves Ethernet in general. > > 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. 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. > > 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). 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? 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/public&preivate 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. - 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
From: [EMAIL PROTECTED] (Stephen J. Bevan) Date: Thu, 19 Oct 2006 19:18:41 -0700 > 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. Linux will for local TCP connections over IPSEC transports since it knows the path MTU, for IPSEC gateways the source system will adjust the MSS after it notes via path-MTU what the decreased MTU is. I think this is just a big list of excuses for not using IPSEC as the solution for whatever problem is trying to be solved. - 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
On Thursday, 19 October 2006 05:57, Stephen J. Bevan wrote: > And if the packets come out of order i.e. you get a packet with a new > key followed by a packet with the old key? As IV from invalid frames are saved ccrypt will synchronize anyway, but I was wrong in one aspect - in current implementation each reorder will cost two frames, not one. This could be possibly reduced to only one, but I must find a time to investigate that more. > 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. Simple random delay should do the trick. > 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 Looks like a good reason to change frame type field so it does not look like IP packet. > * will re-order frames due to redundancy, load-balancing, > spanning-tree changes ... etc. In summary - using ccrypt with switches may lead to problems. - 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/public&preivate 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
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
Re: [RFC] Ethernet Cheap Cryptography
David Miller writes: > From: [EMAIL PROTECTED] (Stephen J. Bevan) > Date: Thu, 19 Oct 2006 19:18:41 -0700 > > > 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. > > Linux will for local TCP connections over IPSEC transports since it > knows the path MTU, for IPSEC gateways the source system will adjust > the MSS after it notes via path-MTU what the decreased MTU is. path-MTU gets interesting[1] in the context of an an IPsec gateway (i.e. tunnel mode IPsec) and there is definitely variability as to how reliably an ICMP will be returned in the case that the MTU is exceeded somewhere between the two endpoints. Throw in port/protocol based selectors[2] or IPv4(IPv6) traffic encrypted with an IPv6(IPv4) header[3] and the chances of success go down. Users ussually don't tend to care whose IPsec is at fault, they just want things to work. Thus, having tunnel mode IPsec alter the MSS (of non-local traffic) to take account of the encryption (or PPPoE, ... etc.) overhead smooths over most fragmentation issues. -- [1] as detailed in the length Appendix B of RFC 2401. [2] some IPsec implementation won't correctly match an ICMP up against port/protocol based selectors and so the ICMP is lost. [3] mapping the DF bit is left to implementations, some reset the DF bit and so just fragment. - 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
From: [EMAIL PROTECTED] (Stephen J. Bevan) Date: Fri, 20 Oct 2006 19:17:42 -0700 > path-MTU gets interesting[1] in the context of an an IPsec gateway > (i.e. tunnel mode IPsec) and there is definitely variability as to how > reliably an ICMP will be returned in the case that the MTU is exceeded > somewhere between the two endpoints. Throw in port/protocol based > selectors[2] or IPv4(IPv6) traffic encrypted with an IPv6(IPv4) > header[3] and the chances of success go down. Yes, this has been discussed to death here previosly. It can be made more reliable, the fact that most of the implementations suck (to some extent including Linux's) should not deter us trying to make it work as reliably as possible. I just think that this ethernet level crypto talk is a complete waste of time, there are much better things to concentrate on in my opinion. :-) - 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
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. - 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: > 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
Pawel Foremski writes: > 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. Given the same problem (securely bridging PPPoE over WiFi) I would gone with an approach that peeked inside to see if there was MPPE and in that case done nothing and if there was no MPPE adjusted the MSS of any TCP traffic and wrapped it in another layer of IPsec+GRE. The latter eats up another 40-60 bytes of MTU/MSS but on the positive side has known security properties and has no reordering issues. However, given that the code would be rather ugly (lots of layering violations) I wouldn't have a high expectation of that code being accepted into a major Linux tree unless bridged PPPoE over WiFi was something that lots of users were clamouring for. Hopefully PPPoE will die out and make the issue moot. - 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
