Re: [IPsec] Fragmentation causing IKE to fail
Valery Smyslov writes: * Find ways of making the packets smaller: move to PSK, fiddle with trust anchors so that only one cert is needed, avoid sending CRLs, hash-and-URL, etc. These are not always successful, and often require more configuration than we would like. Not an option either. Corporate PKI has plenty of requirements to deal with and the requirement to make certificates smaller is the least. Hash-and-URL is a nice feature, but it requires an additional infrastructure that not every customer is willing to deploy. Hash-and-URL do require customer to deploy www-server. I admit that for some enterprices that might be burden to deploy, but quite a lot of other enterprices do already have working deployed www-server they can use... The url can be static, the certificate stored on that url can be static, new certificates needs to be pushed to www-server only and only when the new certiticate is enrolled. The url can be something like http://certs.example.com/ca-short-name/hash-of-cert. Hash-and-URL should make the packets small enough that fragmentation is not needed (especially if network supports 1280 byte packets). * Build a fragmentation layer within IKE, so IKE messages are broken into several packets that get reassembled at the destination. This is the path taken by one of our competitors [1]. This means that IKE has segmentation in addition to other TCP-like features such as retransmission. I like this approach, but as far as I know this is done for IKEv1 only. This also requires finding pmtu and so on which means this whole protocol gets quite complicated. * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is already allocated to ISAKMP. We have had IKE running over TCP for several years for remote access clients. This was done because remote access clients connect from behind some very dodgy NAT devices, and some of those do drop fragments. Getting this behavior at the ISP is novel. IKE over TCP has its drawbacks. It eliminates the ability of IKE to be stateless (with COOKIE), thus considerably increasing its vulnerability to DoS attack. Switching between UDP and TCP (especially in the middle of exchange) considerably complicates protocol that is already complex in that part (remember switching to port 4500 on the fly). If mechanisms already defined in the IKEv2 (Hash-and-URL etc) are not enough, then I think IKE over TCP is the way to go. Most likely it would be better to do it similarly we do NAT-T, i.e. instead of switching to UDP port 4500 we would switch to TCP port 4500 for the IKE_AUTH packets. Nothing prevents starting the creation of the TCP connection while sending the first IKE_SA_INIT packet over UDP. As with NAT-T we can either start over TCP port 4500 immediately from the beginning, if we like (i.e. we know from previous experience or from configuration that we should do that). As with NAT-T we can use either UDP or TCP port 4500 at will, regardless whether NAT was detected or not. Also either end can send requests either over UDP or TCP and reply would come back over same channel. In some cases we might want to send packet first with UDP, and if we do not get any replies back for our requests, we might want to fall back to TCP. In the other hand there is no point of sending retransmissions to TCP connection, i.e. we always only send one copy there (unless the TCP connection is reset, and we recreate it). Anyways it is possible for both initiator and responder to see same packet coming both over TCP and UDP, so normal windowing and duplicate packet detection needs to be done (and resending of replies if needed etc) Using TCP port 4500 instead of TCP port 500 has the benefit that it might bypass those filters someone was complaining about. If we want to support ESP over that TCP channel too, then we need to add some kind of framing which will tell the simulated UDP packet length, i.e. similar what DNS does (prefix the packet with two byte length field). On other hand we might want to add also non-IKE marker somewhere too. Adding one notification to the IKE_SA_INIT to indicate the support of this feature would be need. Note, that if we run IKE_SA_INIT over UDP, then we can still support stateless cookies, and for packets requiring fragmentation there is no stateless processing anyways (whether the state is in the system reassembly system, new IKEv2 reassembly system, or in the TCP does not really matter). One open issue is how this fits with MOBIKE. I.e. if we get address updates over UDP, do we immediately also create matching TCP connection, and what do we do if that TCP connection creation fails, even when the UDP worked etc. I'm in favor of developing standard way of fragmenting big packets in IKEv2. I beleive there might be relatively simple solutions not breaking core protocol implementation. I think TCP is better approach. It has already solved most of the hard problems, and we can use
Re: [IPsec] Fragmentation causing IKE to fail
Hi Valery, This is not a different problem, because whatever solution we choose, we must ensure the whole system is functional: both IKE and IPsec. Routers that drop IKE fragments will not hesitate to drop ESP/UDP fragments, too. Thanks for pointing out Sec. 8 to me. I suppose you are right about the behavior of implementations in the case of ESP-in-UDP, but from a formalistic point of view, note that: - RFC 4301, Sec. 8 says nothing about NAT traversal (ESP-in-UDP). - RFC 3948 (IPsec-in-UDP) says nothing about fragmentation... So we have a hole here. By the way, I'm not sure that UDP packets are still typically small. There's more and more video on the Internet, and I'm sure some of it is NOT on Skype. Thanks, Yaron On 06/11/2012 08:37 AM, Valery Smyslov wrote: Hi Yaron, I think this is a different problem from dropping UDP fragments, and, from my point of view, less important. For most of UDP traffic this is not an issue, because packets are small. For TCP traffic IPsec gateway usually copies Don't Fragment Bit to outer IP header, and usually this bit is set. If some intermediate router has smaller MTU, it should drop packet and send ICMP Destination Unreachable. Having received it IPsec gateway may store needed MTU value in SA and then report this value to any host in protected network that tries to send bigger TCP packet. This behavior is irrespective to whether ESP-in-UDP employed or just plain ESP, and is documented in RFC4301 section 8. Regards, Valery Smyslov. Hi Valery, There's something I'm missing here. Let's say we go for a solution where we fragment IKE packets into pieces of 576 bytes, at the application level. Now, how do we determine the length of the ESP-over-UDP packets? Are you suggesting we fix them at 576 too, or do we need to have a (proprietary) path MTU discovery for this to *really* work? Thanks, Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
Hi Yaron IPsec usually reduces the effective PMTU by 50-100 bytes. There are ways to overcome this: - the encrypting gateway can send ICMP fragmentation needed packets to the origin of the packet - the encrypting gateway can fiddle with the MSS on TCP SYN and SYN-ACK to reduce the size of TCP packets - the encrypting gateway can fragment before encrypting, thus making the ESP (with or without UDP) small enough and apparently not fragmented. Yoav -Original Message- From: Yaron Sheffer [mailto:yaronf.i...@gmail.com] Sent: 11 June 2012 09:54 To: Valery Smyslov Cc: Tero Kivinen; ipsec@ietf.org; Yoav Nir Subject: Re: [IPsec] Fragmentation causing IKE to fail Hi Valery, This is not a different problem, because whatever solution we choose, we must ensure the whole system is functional: both IKE and IPsec. Routers that drop IKE fragments will not hesitate to drop ESP/UDP fragments, too. Thanks for pointing out Sec. 8 to me. I suppose you are right about the behavior of implementations in the case of ESP-in-UDP, but from a formalistic point of view, note that: - RFC 4301, Sec. 8 says nothing about NAT traversal (ESP-in-UDP). - RFC 3948 (IPsec-in-UDP) says nothing about fragmentation... So we have a hole here. By the way, I'm not sure that UDP packets are still typically small. There's more and more video on the Internet, and I'm sure some of it is NOT on Skype. Thanks, Yaron On 06/11/2012 08:37 AM, Valery Smyslov wrote: Hi Yaron, I think this is a different problem from dropping UDP fragments, and, from my point of view, less important. For most of UDP traffic this is not an issue, because packets are small. For TCP traffic IPsec gateway usually copies Don't Fragment Bit to outer IP header, and usually this bit is set. If some intermediate router has smaller MTU, it should drop packet and send ICMP Destination Unreachable. Having received it IPsec gateway may store needed MTU value in SA and then report this value to any host in protected network that tries to send bigger TCP packet. This behavior is irrespective to whether ESP-in-UDP employed or just plain ESP, and is documented in RFC4301 section 8. Regards, Valery Smyslov. Hi Valery, There's something I'm missing here. Let's say we go for a solution where we fragment IKE packets into pieces of 576 bytes, at the application level. Now, how do we determine the length of the ESP-over-UDP packets? Are you suggesting we fix them at 576 too, or do we need to have a (proprietary) path MTU discovery for this to *really* work? Thanks, Yaron Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
Yaron == Yaron Sheffer yaronf.i...@gmail.com writes: Yaron There's something I'm missing here. Let's say we go for a Yaron solution where we Yaron fragment IKE packets into pieces of 576 bytes, at the Yaron application level. We need to know what problem we are in fact facing. It seems to me that the routers causing the problems are in fact CGN, and therefore NAT is likely involved, and so ESP-over-UDP. If we have a network where 576 byte ESP packets are required, then regardless of IKE fragmentation (or not), we have a problem to deal with at the IPsec level. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. pgpYXU4jIawbV.pgp Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
Hi Yaron, I think this is a different problem from dropping UDP fragments, and, from my point of view, less important. For most of UDP traffic this is not an issue, because packets are small. For TCP traffic IPsec gateway usually copies Don't Fragment Bit to outer IP header, and usually this bit is set. If some intermediate router has smaller MTU, it should drop packet and send ICMP Destination Unreachable. Having received it IPsec gateway may store needed MTU value in SA and then report this value to any host in protected network that tries to send bigger TCP packet. This behavior is irrespective to whether ESP-in-UDP employed or just plain ESP, and is documented in RFC4301 section 8. Regards, Valery Smyslov. Hi Valery, There's something I'm missing here. Let's say we go for a solution where we fragment IKE packets into pieces of 576 bytes, at the application level. Now, how do we determine the length of the ESP-over-UDP packets? Are you suggesting we fix them at 576 too, or do we need to have a (proprietary) path MTU discovery for this to *really* work? Thanks, Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
Hi, Hash-and-URL do require customer to deploy www-server. I admit that for some enterprices that might be burden to deploy, but quite a lot of other enterprices do already have working deployed www-server they can use... The url can be static, the certificate stored on that url can be static, new certificates needs to be pushed to www-server only and only when the new certiticate is enrolled. The url can be something like http://certs.example.com/ca-short-name/hash-of-cert. Hash-and-URL should make the packets small enough that fragmentation is not needed (especially if network supports 1280 byte packets). * Build a fragmentation layer within IKE, so IKE messages are broken into several packets that get reassembled at the destination. This is the path taken by one of our competitors [1]. This means that IKE has segmentation in addition to other TCP-like features such as retransmission. I like this approach, but as far as I know this is done for IKEv1 only. This also requires finding pmtu and so on which means this whole protocol gets quite complicated. Not necessary. For the sake of simplicity you may always fragment to the smallest packets guaranteed to pass through (576 bytes for IP4). IKE is not bulk transfer protocol, so performance is not an issue here. If mechanisms already defined in the IKEv2 (Hash-and-URL etc) are not enough, then I think IKE over TCP is the way to go. Most likely it would be better to do it similarly we do NAT-T, i.e. instead of switching to UDP port 4500 we would switch to TCP port 4500 for the IKE_AUTH packets. Nothing prevents starting the creation of the TCP connection while sending the first IKE_SA_INIT packet over UDP. As with NAT-T we can either start over TCP port 4500 immediately from the beginning, if we like (i.e. we know from previous experience or from configuration that we should do that). As with NAT-T we can use either UDP or TCP port 4500 at will, regardless whether NAT was detected or not. Also either end can send requests either over UDP or TCP and reply would come back over same channel. In some cases we might want to send packet first with UDP, and if we do not get any replies back for our requests, we might want to fall back to TCP. In the other hand there is no point of sending retransmissions to TCP connection, i.e. we always only send one copy there (unless the TCP connection is reset, and we recreate it). Anyways it is possible for both initiator and responder to see same packet coming both over TCP and UDP, so normal windowing and duplicate packet detection needs to be done (and resending of replies if needed etc) Using TCP port 4500 instead of TCP port 500 has the benefit that it might bypass those filters someone was complaining about. If we want to support ESP over that TCP channel too, then we need to add some kind of framing which will tell the simulated UDP packet length, i.e. similar what DNS does (prefix the packet with two byte length field). On other hand we might want to add also non-IKE marker somewhere too. Don't you think it looks too complicated? Two different transport each with two ports, special framing etc... Adding one notification to the IKE_SA_INIT to indicate the support of this feature would be need. Note, that if we run IKE_SA_INIT over UDP, then we can still support stateless cookies, Successful COOKIE exchange make you sure that peer is real entity, but in case of TCP this information can't help TCP/IP stack to distinguith between bad and good boys. Or you have to constantly update firewall rules enabling and disabling incoming TCP connections from different addresses depending on success/failure of COOKIE exchange. and for packets requiring fragmentation there is no stateless processing anyways (whether the state is in the system reassembly system, new IKEv2 reassembly system, or in the TCP does not really matter). Any IKE exchange after COOKIE request is already statefull, so I don't see any problem here. One open issue is how this fits with MOBIKE. I.e. if we get address updates over UDP, do we immediately also create matching TCP connection, and what do we do if that TCP connection creation fails, even when the UDP worked etc. Yes, It will become more and more complex. The ESP over TCP do cause some problems, as some implementations do capture those packets already in the kernel without ever giving them to the userland, and doing that from the TCP stream is bit harder and requires bit more code. Oh... ESP over TCP is very problematic... And if the transports are different for IKE and ESP, we will catch all kinds of problems when IKE goes smoothly, but following ESP doesn't work at all. Regards, Smyslov Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
Hi Valery, There's something I'm missing here. Let's say we go for a solution where we fragment IKE packets into pieces of 576 bytes, at the application level. Now, how do we determine the length of the ESP-over-UDP packets? Are you suggesting we fix them at 576 too, or do we need to have a (proprietary) path MTU discovery for this to *really* work? Thanks, Yaron On 06/09/2012 08:40 AM, Valery Smyslov wrote: Hi, Hash-and-URL do require customer to deploy www-server. I admit that for some enterprices that might be burden to deploy, but quite a lot of other enterprices do already have working deployed www-server they can use... The url can be static, the certificate stored on that url can be static, new certificates needs to be pushed to www-server only and only when the new certiticate is enrolled. The url can be something like http://certs.example.com/ca-short-name/hash-of-cert. Hash-and-URL should make the packets small enough that fragmentation is not needed (especially if network supports 1280 byte packets). * Build a fragmentation layer within IKE, so IKE messages are broken into several packets that get reassembled at the destination. This is the path taken by one of our competitors [1]. This means that IKE has segmentation in addition to other TCP-like features such as retransmission. I like this approach, but as far as I know this is done for IKEv1 only. This also requires finding pmtu and so on which means this whole protocol gets quite complicated. Not necessary. For the sake of simplicity you may always fragment to the smallest packets guaranteed to pass through (576 bytes for IP4). IKE is not bulk transfer protocol, so performance is not an issue here. If mechanisms already defined in the IKEv2 (Hash-and-URL etc) are not enough, then I think IKE over TCP is the way to go. Most likely it would be better to do it similarly we do NAT-T, i.e. instead of switching to UDP port 4500 we would switch to TCP port 4500 for the IKE_AUTH packets. Nothing prevents starting the creation of the TCP connection while sending the first IKE_SA_INIT packet over UDP. As with NAT-T we can either start over TCP port 4500 immediately from the beginning, if we like (i.e. we know from previous experience or from configuration that we should do that). As with NAT-T we can use either UDP or TCP port 4500 at will, regardless whether NAT was detected or not. Also either end can send requests either over UDP or TCP and reply would come back over same channel. In some cases we might want to send packet first with UDP, and if we do not get any replies back for our requests, we might want to fall back to TCP. In the other hand there is no point of sending retransmissions to TCP connection, i.e. we always only send one copy there (unless the TCP connection is reset, and we recreate it). Anyways it is possible for both initiator and responder to see same packet coming both over TCP and UDP, so normal windowing and duplicate packet detection needs to be done (and resending of replies if needed etc) Using TCP port 4500 instead of TCP port 500 has the benefit that it might bypass those filters someone was complaining about. If we want to support ESP over that TCP channel too, then we need to add some kind of framing which will tell the simulated UDP packet length, i.e. similar what DNS does (prefix the packet with two byte length field). On other hand we might want to add also non-IKE marker somewhere too. Don't you think it looks too complicated? Two different transport each with two ports, special framing etc... Adding one notification to the IKE_SA_INIT to indicate the support of this feature would be need. Note, that if we run IKE_SA_INIT over UDP, then we can still support stateless cookies, Successful COOKIE exchange make you sure that peer is real entity, but in case of TCP this information can't help TCP/IP stack to distinguith between bad and good boys. Or you have to constantly update firewall rules enabling and disabling incoming TCP connections from different addresses depending on success/failure of COOKIE exchange. and for packets requiring fragmentation there is no stateless processing anyways (whether the state is in the system reassembly system, new IKEv2 reassembly system, or in the TCP does not really matter). Any IKE exchange after COOKIE request is already statefull, so I don't see any problem here. One open issue is how this fits with MOBIKE. I.e. if we get address updates over UDP, do we immediately also create matching TCP connection, and what do we do if that TCP connection creation fails, even when the UDP worked etc. Yes, It will become more and more complex. The ESP over TCP do cause some problems, as some implementations do capture those packets already in the kernel without ever giving them to the userland, and doing that from the TCP stream is bit harder and requires bit more code. Oh... ESP over TCP is very problematic... And if the transports
Re: [IPsec] Fragmentation causing IKE to fail
On Jun 7, 2012, at 8:20 AM, Yoav Nir wrote: Trying to think up ways to deal with this, I can think of some: * Get all ISPs to stop dropping fragments. This would be great, but as the saying goes, you are so not in charge. * Find ways of making the packets smaller: move to PSK, fiddle with trust anchors so that only one cert is needed, avoid sending CRLs, hash-and-URL, etc. These are not always successful, and often require more configuration than we would like. * Build a fragmentation layer within IKE, so IKE messages are broken into several packets that get reassembled at the destination. This is the path taken by one of our competitors [1]. This means that IKE has segmentation in addition to other TCP-like features such as retransmission. * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is already allocated to ISAKMP. We have had IKE running over TCP for several years for remote access clients. This was done because remote access clients connect from behind some very dodgy NAT devices, and some of those do drop fragments. Getting this behavior at the ISP is novel. * Use IKE over TCP only after IKE over UDP fails during transmission of a packet 512 bytes. That would be interoperable with current deployments (although they would not see the second attempt, of course), it costs little, and is trivial to implement. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
On Thu, 7 Jun 2012, Paul Hoffman wrote: * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is already allocated to ISAKMP. We have had IKE running over TCP for several years for remote access clients. This was done because remote access clients connect from behind some very dodgy NAT devices, and some of those do drop fragments. Getting this behavior at the ISP is novel. * Use IKE over TCP only after IKE over UDP fails during transmission of a packet 512 bytes. That would be interoperable with current deployments (although they would not see the second attempt, of course), it costs little, and is trivial to implement. Is that compatible with some vendor's tcp port 1 implementation? Also, if we are doing this, I'd prefer to be able to signal which tcp port to use, to make it more flexible to bypass port 500 blocks (which is part of the tcp 1 implementation I believe) Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
On Jun 7, 2012, at 9:43 AM, Paul Wouters wrote: On Thu, 7 Jun 2012, Paul Hoffman wrote: * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is already allocated to ISAKMP. We have had IKE running over TCP for several years for remote access clients. This was done because remote access clients connect from behind some very dodgy NAT devices, and some of those do drop fragments. Getting this behavior at the ISP is novel. * Use IKE over TCP only after IKE over UDP fails during transmission of a packet 512 bytes. That would be interoperable with current deployments (although they would not see the second attempt, of course), it costs little, and is trivial to implement. Is that compatible with some vendor's tcp port 1 implementation? Why should I care about that completely non-standard use? Seriously. Also, if we are doing this, I'd prefer to be able to signal which tcp port to use, to make it more flexible to bypass port 500 blocks (which is part of the tcp 1 implementation I believe) That seems fine to me. However, assuming that a firewall that blocks TCP/500 will not block TCP/somerandomnewnumber is not wise. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
On Thu, Jun 7, 2012 at 11:54 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Jun 7, 2012, at 9:43 AM, Paul Wouters wrote: Also, if we are doing this, I'd prefer to be able to signal which tcp port to use, to make it more flexible to bypass port 500 blocks (which is part of the tcp 1 implementation I believe) That seems fine to me. However, assuming that a firewall that blocks TCP/500 will not block TCP/somerandomnewnumber is not wise. Use port 80. (I'm being half facetious, half sarcastic, and half serious with this.) Nico -- ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
On Jun 7, 2012, at 10:26 AM, Nico Williams wrote: On Thu, Jun 7, 2012 at 11:54 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Jun 7, 2012, at 9:43 AM, Paul Wouters wrote: Also, if we are doing this, I'd prefer to be able to signal which tcp port to use, to make it more flexible to bypass port 500 blocks (which is part of the tcp 1 implementation I believe) That seems fine to me. However, assuming that a firewall that blocks TCP/500 will not block TCP/somerandomnewnumber is not wise. Use port 80. (I'm being half facetious, half sarcastic, and half serious with this.) Being non-all-of-the-above: that won't work. Many firewalls that are blocking UDP fragments do deep packet inspection on port 80 and will throw away traffic that doesn't look like HTTP. (Don't get me started on look like...) --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
On Thu, Jun 7, 2012 at 12:40 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Jun 7, 2012, at 10:26 AM, Nico Williams wrote: Use port 80. (I'm being half facetious, half sarcastic, and half serious with this.) Being non-all-of-the-above: that won't work. Many firewalls that are blocking UDP fragments do deep packet inspection on port 80 and will throw away traffic that doesn't look like HTTP. (Don't get me started on look like...) To be closer to 100% serious I'd have to advocate an HTTP mapping of IKE and/or use of port 443. I'm not sure that I want to go there, but really, if you want to get past deep inspection nowadays then your best bet seems to be port 443. Which, of course, would not be enough. You'd find that ESP (encapsulated in UDP or not) also gets filtered, so you'd have to start sending ESP over HTTPS. And that's all kinds of not fun. At some point though one has to give up and declare the ISP useless. If you're a dissident in Iran, well, you're not using IPsec anyways, and Tor and all things port 443 are really your only friends, and if in the end the great firewalls get good enough, well, what can we do as far as *standards*? Not much. But I don't think Yoav was talking about this case, just a lousy ISP case, and for that I suspect deep packet inspection is not really the problem. For Yoav I suspect that IKE over TCP + UDP encapsulation of ESP is the way to go; worst case scenario: ESP over TCP. Nico -- ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
Yoav == Yoav Nir y...@checkpoint.com writes: Yoav Trying to think up ways to deal with this, I can think of some: Yoav * Get all ISPs to stop dropping fragments. This would be Yoav great, but as the saying goes, you are so not in charge. 1) better diagnostics would help the end users point the finger properly. I wish the POSIX/BSD APIs would give the application an error when a fragment assembly times out.. Yoav * Build a fragmentation layer within IKE, so IKE messages are Yoav broken into several packets that get reassembled at the Yoav destination. This is the path taken by one of our competitors Yoav [1]. This means that IKE has segmentation in addition to other Yoav TCP-like features such as retransmission. I proposed this for IKEv2 awhile ago. I twould be worthwhile for people who like certificates. Yoav * Use IKE over TCP. Looking at the IANA registry ([2]) TCP Yoav port 500 is already allocated to ISAKMP. We have had IKE Yoav running over TCP for several years for remote access Yoav clients. This was done because remote access clients connect Yoav from behind some very dodgy NAT devices, and some of those do Yoav drop fragments. Getting this behavior at the ISP is novel. And ESP over TCP on port 4500? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
On Jun 7, 2012, at 7:15 PM, Paul Hoffman wrote: * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is already allocated to ISAKMP. We have had IKE running over TCP for several years for remote access clients. This was done because remote access clients connect from behind some very dodgy NAT devices, and some of those do drop fragments. Getting this behavior at the ISP is novel. * Use IKE over TCP only after IKE over UDP fails during transmission of a packet 512 bytes. That would be interoperable with current deployments (although they would not see the second attempt, of course), it costs little, and is trivial to implement. This is possible, but since UDP is not reliable, you'd have to retransmit several times before giving up on UDP. Even if we shorten the at least a dozen times over a period of at least several minutes, it's still long enough for users to feel - get the connection with Exchange lost message in Outlook, for example. You could begin both UDP (first IKE message) and TCP's 3-way handshake at the same time. If the 3-way handshake completed in time, the larger packets would go over that connection. If not, they would go over TCP. But all this is implementation-specific details. I'm more interested in hearing whether others are seeing this (I would guess yes, otherwise Cisco would not have developed the IKE fragments), and on whether there is interest in the group in an IKE-over-TCP draft. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
On Jun 7, 2012, at 2:53 PM, Yoav Nir wrote: On Jun 7, 2012, at 7:15 PM, Paul Hoffman wrote: * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is already allocated to ISAKMP. We have had IKE running over TCP for several years for remote access clients. This was done because remote access clients connect from behind some very dodgy NAT devices, and some of those do drop fragments. Getting this behavior at the ISP is novel. * Use IKE over TCP only after IKE over UDP fails during transmission of a packet 512 bytes. That would be interoperable with current deployments (although they would not see the second attempt, of course), it costs little, and is trivial to implement. This is possible, but since UDP is not reliable, you'd have to retransmit several times before giving up on UDP. Even if we shorten the at least a dozen times over a period of at least several minutes, it's still long enough for users to feel - get the connection with Exchange lost message in Outlook, for example. Good point. You could begin both UDP (first IKE message) and TCP's 3-way handshake at the same time. If the 3-way handshake completed in time, the larger packets would go over that connection. If not, they would go over TCP. Yuck. But possibly the right answer. But all this is implementation-specific details. I'm more interested in hearing whether others are seeing this (I would guess yes, otherwise Cisco would not have developed the IKE fragments), and on whether there is interest in the group in an IKE-over-TCP draft. Please consider IKE-with-TCP-and-UDP before IKE-over-TCP. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
On Jun 7, 2012, at 8:26 PM, Nico Williams wrote: On Thu, Jun 7, 2012 at 11:54 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Jun 7, 2012, at 9:43 AM, Paul Wouters wrote: Also, if we are doing this, I'd prefer to be able to signal which tcp port to use, to make it more flexible to bypass port 500 blocks (which is part of the tcp 1 implementation I believe) That seems fine to me. However, assuming that a firewall that blocks TCP/500 will not block TCP/somerandomnewnumber is not wise. Use port 80. Well, we came up with IKE-over-TCP for clients in 2002. That worked OK with broken routers and NAT devices, but not with firewalls. So in 2003 we came up with sending both IKE and IPsec over port 443 (because at the time few firewalls other than ours validated that what goes on port 443 looks like SSL). Finally in 2005 we came out with a client that actually uses SSL for traffic, so that firewalls have to either be SSL proxies or do traffic flow analysis to recognize non-HTTPS. But this arms race between tunneling clients and firewalls is not the issue here. Without getting into the whole net neutrality controversy, ISPs are not supposed to, nor are they trying to block the creation of tunnels. What they are doing is saving themselves the need to keep state on received fragments, which allows better scale and better performance with the same hardware. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
On Fri, 8 Jun 2012, Yoav Nir wrote: But all this is implementation-specific details. I'm more interested in hearing whether others are seeing this (I would guess yes, otherwise Cisco would not have developed the IKE fragments), and on whether there is interest in the group in an IKE-over-TCP draft. Yes we have seen this in the past with openswan, though people affected would usually use 2048 bit RSA keys instead of 1024 bit RSA keys. And usually in combination with a CAcert without intermediary CAs. We would advise them to use 1024 and the IKE fragemntation problem would go away. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
On Jun 8, 2012, at 1:01 AM, Paul Hoffman wrote: On Jun 7, 2012, at 2:53 PM, Yoav Nir wrote: On Jun 7, 2012, at 7:15 PM, Paul Hoffman wrote: * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is already allocated to ISAKMP. We have had IKE running over TCP for several years for remote access clients. This was done because remote access clients connect from behind some very dodgy NAT devices, and some of those do drop fragments. Getting this behavior at the ISP is novel. * Use IKE over TCP only after IKE over UDP fails during transmission of a packet 512 bytes. That would be interoperable with current deployments (although they would not see the second attempt, of course), it costs little, and is trivial to implement. This is possible, but since UDP is not reliable, you'd have to retransmit several times before giving up on UDP. Even if we shorten the at least a dozen times over a period of at least several minutes, it's still long enough for users to feel - get the connection with Exchange lost message in Outlook, for example. Good point. You could begin both UDP (first IKE message) and TCP's 3-way handshake at the same time. If the 3-way handshake completed in time, the larger packets would go over that connection. If not, they would go over TCP. Yuck. But possibly the right answer. But all this is implementation-specific details. I'm more interested in hearing whether others are seeing this (I would guess yes, otherwise Cisco would not have developed the IKE fragments), and on whether there is interest in the group in an IKE-over-TCP draft. Please consider IKE-with-TCP-and-UDP before IKE-over-TCP. I think we can accommodate different implementations by requiring: - that initiator MAY switch back and forth between TCP and UDP - that responder MUST respond in the same transport where the request arrived - that responder must not depend on all requests for a particular flow coming through the same transport. For example, it's perfectly acceptable for the first request of Main Mode to come over UDP, while the next two come over TCP. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
Hi, we've being running into this issue constantly. I think it is serious problem for road warriers, who have to deal with all kinds of buggy or crippled SOHO routers installed in hotels etc. Many our customers complain that they are unable to connect to main office while being on business trip and most offen the reason is inability (or unwilling) of some intermediate router(s) to pass UDP fragments. Trying to think up ways to deal with this, I can think of some: * Get all ISPs to stop dropping fragments. This would be great, but as the saying goes, you are so not in charge. No an option. * Find ways of making the packets smaller: move to PSK, fiddle with trust anchors so that only one cert is needed, avoid sending CRLs, hash-and-URL, etc. These are not always successful, and often require more configuration than we would like. Not an option either. Corporate PKI has plenty of requirements to deal with and the requirement to make certificates smaller is the least. Hash-and-URL is a nice feature, but it requires an additional infrastructure that not every customer is willing to deploy. * Build a fragmentation layer within IKE, so IKE messages are broken into several packets that get reassembled at the destination. This is the path taken by one of our competitors [1]. This means that IKE has segmentation in addition to other TCP-like features such as retransmission. I like this approach, but as far as I know this is done for IKEv1 only. * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is already allocated to ISAKMP. We have had IKE running over TCP for several years for remote access clients. This was done because remote access clients connect from behind some very dodgy NAT devices, and some of those do drop fragments. Getting this behavior at the ISP is novel. IKE over TCP has its drawbacks. It eliminates the ability of IKE to be stateless (with COOKIE), thus considerably increasing its vulnerability to DoS attack. Switching between UDP and TCP (especially in the middle of exchange) considerably complicates protocol that is already complex in that part (remember switching to port 4500 on the fly). Have others on this list run into this issue? Yoav I'm in favor of developing standard way of fragmenting big packets in IKEv2. I beleive there might be relatively simple solutions not breaking core protocol implementation. Regards, Smyslov Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
