Re: [IPsec] IKE fragmentation
Hi Paul, Can't an off-path attacker DoS the gateway if they can guess the SPI values? We never mandated that SPIs should be random (except for RFC 6290, in Sec. 9.3, but this is rarely implemented), so implementations are free to use very small integers for the SPIs. In fact I think we should reconsider mandating random SPIs once again. Thanks, Yaron On 03/14/2013 04:51 PM, Paul Wouters wrote: On Thu, 14 Mar 2013, Tero Kivinen wrote: As earlier explained not doing that allows very wasy DoS attack, which allows IKEv2 to finish by just sending very few packets, i.e. you send one corrupted fragment to the packet and if you do that before responder gets the correct fragment, the responder stores it for reassembly and after it reassembles the packet it will only then notice that the packet is corrupted, and then it needs to throw the whole packet away. It cannot know which of the fragment is corrupted. This means the initiator needs to retransmit whole packet, i.e. all fragments of it, and attacker can do this again. Note that requires an observer that can see your cookies/spi. Which would mean a local attacker, whom could just as easilly send you nonsense forged from the remote endpoint - as they are guaranteed to answer faster. You'd be decrypting thousands of packets to find the needle in the haystack. I wonder what the chances then are that you don't end up dropping teh valid fragment. If the attacker is not local, they need to be in your path to know the spi/cookies, and they can just filter out the valid fragments. But I see your point, it does raise the bar a little bit. Although I'm not convinced it's worth it. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
Paul Wouters writes: > Note that requires an observer that can see your cookies/spi. Yes. > Which would > mean a local attacker, whom could just as easilly send you nonsense > forged from the remote endpoint - as they are guaranteed to answer > faster. You'd be decrypting thousands of packets to find the needle in > the haystack. I wonder what the chances then are that you don't end up > dropping teh valid fragment. My PC has more than enough CPU power to verify MAC on the packets coming in over the wireless link. On the other hand if attacker fills the wireless link with junk packets, it is very easy to find him. If attacker just sends on random packet every 2 seconds, it is much harder to pinpoint who and where he is. The idea of DoS protection is to make the attack more expensive for the attacker, and also make detecting him easier. Adding MAC to fragments does both. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
>> What your draft does, is force the initiator to protect each >> fragment. To protect a fragment in a way that will cause the >> responder to store it, requires running the MAC function, and that >> in turn requires generating the keys (running the PRF), which in >> turn requires completing the D-H calculation. If the initiator fails >> to do any of these things, the fragment will be immediately rejected >> at the responder. Of course, the D-H calculation is not >> per-fragment, and I did not claim that this was the case. > > Initiator must do Diffie-Hellman anyways before it can send IKE_AUTH. True for a legitimate Initiator. At attacker can send fake fragments, and the responder has the option of expanding CPU resources for verifying the ICV, or expanding the memory resources for storing them for a while. There is no difference comparing with usual, non-fragmented IKE_AUTH message - responder still can be forced by attacker to complete DH, calculate keys and try to verify forged message. And fragmentation doesn't make it worse. And even with unprotected fragments it is not a big deal for attacker to send you a set of fragments that you will successfully reassemble to a good-looking message and then you again will have to complete DH, calculate keys and try to verify that garbage. No difference. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
On Thu, 14 Mar 2013, Tero Kivinen wrote: As earlier explained not doing that allows very wasy DoS attack, which allows IKEv2 to finish by just sending very few packets, i.e. you send one corrupted fragment to the packet and if you do that before responder gets the correct fragment, the responder stores it for reassembly and after it reassembles the packet it will only then notice that the packet is corrupted, and then it needs to throw the whole packet away. It cannot know which of the fragment is corrupted. This means the initiator needs to retransmit whole packet, i.e. all fragments of it, and attacker can do this again. Note that requires an observer that can see your cookies/spi. Which would mean a local attacker, whom could just as easilly send you nonsense forged from the remote endpoint - as they are guaranteed to answer faster. You'd be decrypting thousands of packets to find the needle in the haystack. I wonder what the chances then are that you don't end up dropping teh valid fragment. If the attacker is not local, they need to be in your path to know the spi/cookies, and they can just filter out the valid fragments. But I see your point, it does raise the bar a little bit. Although I'm not convinced it's worth it. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
> There is no DH calculating per fragment. DH is calculated once in > IKE_SA_INIT > as in ordinary IKE SA establishment (note, that unprotected messages, > including IKE_SA_INIT > and IKE_SA_RESUME cannot be fragmented). If we do IKEv2 fragments the way everyone does IKEv1 fragments, the initiator can send multiple fragments that don't assemble to a protected packet, causing the responder to allocate memory to store these fragments (at least for a short while). Doing this does not require completing the D-H calculation, and does not require running either an encryption or MAC function. Yes, in our solution only protected messages could be fragmented. This is its limitation. But in IKEv2 all messages except for IKE_SA_INIT, IKE_SA_RESUME and some informational must be protected. What your draft does, is force the initiator to protect each fragment. To protect a fragment in a way that will cause the responder to store it, requires running the MAC function, and that in turn requires generating the keys (running the PRF), which in turn requires completing the D-H calculation. If the initiator fails to do any of these things, the fragment will be immediately rejected at the responder. Yes, but initiator needs to do it in any case. You cannot send protected message (fragmented or not) without calculating DH, SKEYSEED etc. Of course, the D-H calculation is not per-fragment, and I did not claim that this was the case. Sorry I didn't quite catch you. > And you spent absolutetly the same amount of CPU power to > calculate/verify ICV on > fragments as you would spend it on non-fragmented message You spend the same amount only if you require that your ICV verify. This is not needed for creating DoS on the way fragmentation is done in IKEv1. ICV must be verified in any case - fragmented or non-fragmented. > (probably a little bit more, as total length of all fragments of one > message could > be a bit more than the length of original message due to padding, IKE > header and so on, > but the usual difference is few percents). Measurably more, because MAC functions have an initialization part, so running it on a single packet by parts incurs the per-run overhead multiple times. See the differences in the throughput of HMAC based on buffer size (obtained by running "opnessl speed": type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes hmac(md5)17801.04k53527.61k 132966.20k 210528.97k 253873.49k So if the packet is 8000 bytes, and you divided it into 1024 fragments, you would incur a slightly more than 20% penalty. Yes, as I've said there is some penalty. It may differ depending on algorithm and implementation. I don't see a big problem here, as ICV computation must be fast anyway. Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
On Mar 14, 2013, at 10:29 AM, Tero Kivinen wrote: > Yoav Nir writes: >>> There is no DH calculating per fragment. DH is calculated once in >>> IKE_SA_INIT as in ordinary IKE SA establishment (note, that >>> unprotected messages, including IKE_SA_INIT and IKE_SA_RESUME >>> cannot be fragmented). >> >> If we do IKEv2 fragments the way everyone does IKEv1 fragments, the >> initiator can send multiple fragments that don't assemble to a >> protected packet, causing the responder to allocate memory to store >> these fragments (at least for a short while). Doing this does not >> require completing the D-H calculation, and does not require running >> either an encryption or MAC function. > > I would assume all implementations start doing Diffie-Hellman even > before than they even see the first fragment. I.e. when the responder > sends it IKE_SA_INIT reply back it will also start the Diffie-Hellman > calculation on the background so it might be ready when it gets next > packet from the initiator. The initiator must do the Diffie-Hellman > before it can send first IKE_AUTH packet anyways. > > When responder gets IKE_AUTH packet from the initiator, then they will > start Diffie-Hellman calculation if they have not yet done it > previously. My implementation does that. We only calculate the shared key when we need it - when the IKE_AUTH request arrives. >> What your draft does, is force the initiator to protect each >> fragment. To protect a fragment in a way that will cause the >> responder to store it, requires running the MAC function, and that >> in turn requires generating the keys (running the PRF), which in >> turn requires completing the D-H calculation. If the initiator fails >> to do any of these things, the fragment will be immediately rejected >> at the responder. Of course, the D-H calculation is not >> per-fragment, and I did not claim that this was the case. > > Initiator must do Diffie-Hellman anyways before it can send IKE_AUTH. True for a legitimate Initiator. At attacker can send fake fragments, and the responder has the option of expanding CPU resources for verifying the ICV, or expanding the memory resources for storing them for a while. >> Measurably more, because MAC functions have an initialization part, >> so running it on a single packet by parts incurs the per-run >> overhead multiple times. See the differences in the throughput of >> HMAC based on buffer size (obtained by running "opnessl speed": > > We are talking about IKE_AUTH here, and we will do the Diffie-Hellman, > and most likely also public key signature verification and generation > here (fragmentation is most likely only needed if we do have > certificates inside the packet, shared secret authentication should > work without fragmentation). > >> type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes >> hmac(md5)17801.04k53527.61k 132966.20k 210528.97k 253873.49k >> >> So if the packet is 8000 bytes, and you divided it into 1024 >> fragments, you would incur a slightly more than 20% penalty. > > It's actually more useful to compare the speeds from the 1024 bytes > down to 512 bytes and then add Diffie-Hellman over group 14 and RSA > signature verification + generation over 2048 bit key and check the > time difference there. I would expect it to be almost unnoticeable. I agree it's in the noise. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
On Mar 14, 2013, at 10:27 AM, Paul Wouters wrote: > On Thu, 14 Mar 2013, Yoav Nir wrote: > >> Measurably more, because MAC functions have an initialization part, so >> running it on a single packet by parts incurs the per-run overhead multiple >> times. See the differences in the throughput of HMAC based on buffer size >> (obtained by running "opnessl speed": >> >> type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes >> hmac(md5)17801.04k53527.61k 132966.20k 210528.97k >> 253873.49k >> >> So if the packet is 8000 bytes, and you divided it into 1024 fragments, you >> would incur a slightly more than 20% penalty. > > I don't understand this part? Legitimate fragments won't have a > count higher then about 10. Current implementations I've seen cap at > 16 fragments. If you receive a fragment number higher then that, you > discard the whole thing. You could even wait with decrypting until you > got all fragments. True for the way things are done in IKEv1, but Valery's draft has you at least calculating the MAC for each fragment before storing. MAC-ing each fragment is 20% more expensive (for a 8000-byte message) than MAC-ing the whole thing. Not that it matters - it's all in the noise considering that there's also a D-H operation taking place. > I don't see much value in authenticating each fragment. Possibly they > would come in faster then you can decrypt each fragment anyway, so you > need to store them regardless, especially in a DoS where the initiator > does not perform real encryption for sending fragments. > > I would likely implement it to receive all fragments, then run > decryption on all its parts. In that case you don't get the DoS protection offered by this draft. > Furthermore, since we have the cookies/SPI, it is also pretty easy to > ignore bogus fragments, and to require the 6 message echange when > receiving a first-packet for a new exchange when under high load, so > IKE spoofing won't cause us that much of a higher load. > > So I'm not too worried about the DOS, and I'm leaning towards a similar > model to the currently deployed method for IKEv1. Possibly dropping > the useless "fragment id" (not fragment number) It's a tradeoff of memory vs CPU. I'm not sure which is more constrained. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
Yoav Nir writes: > > There is no DH calculating per fragment. DH is calculated once in > > IKE_SA_INIT as in ordinary IKE SA establishment (note, that > > unprotected messages, including IKE_SA_INIT and IKE_SA_RESUME > > cannot be fragmented). > > If we do IKEv2 fragments the way everyone does IKEv1 fragments, the > initiator can send multiple fragments that don't assemble to a > protected packet, causing the responder to allocate memory to store > these fragments (at least for a short while). Doing this does not > require completing the D-H calculation, and does not require running > either an encryption or MAC function. I would assume all implementations start doing Diffie-Hellman even before than they even see the first fragment. I.e. when the responder sends it IKE_SA_INIT reply back it will also start the Diffie-Hellman calculation on the background so it might be ready when it gets next packet from the initiator. The initiator must do the Diffie-Hellman before it can send first IKE_AUTH packet anyways. When responder gets IKE_AUTH packet from the initiator, then they will start Diffie-Hellman calculation if they have not yet done it previously. > What your draft does, is force the initiator to protect each > fragment. To protect a fragment in a way that will cause the > responder to store it, requires running the MAC function, and that > in turn requires generating the keys (running the PRF), which in > turn requires completing the D-H calculation. If the initiator fails > to do any of these things, the fragment will be immediately rejected > at the responder. Of course, the D-H calculation is not > per-fragment, and I did not claim that this was the case. Initiator must do Diffie-Hellman anyways before it can send IKE_AUTH. Responder must do Diffie-Hellman anyways before it can process incoming IKE_AUTH. And as the fragments are not acknowledged separately the responder implementation can store all the encrypted and authenticated fragments wihtout checking and when it all of them, it can do Diffie-Hellman and decrypt + authentication to all of them, just like in the IKEv1 fragment version. So there is no big difference there. The big differences is that smart implementation can check fragments as they come in, thus it can immediately reject bogus fragments, and only store and try reassembly on the valid fragments. As earlier explained not doing that allows very wasy DoS attack, which allows IKEv2 to finish by just sending very few packets, i.e. you send one corrupted fragment to the packet and if you do that before responder gets the correct fragment, the responder stores it for reassembly and after it reassembles the packet it will only then notice that the packet is corrupted, and then it needs to throw the whole packet away. It cannot know which of the fragment is corrupted. This means the initiator needs to retransmit whole packet, i.e. all fragments of it, and attacker can do this again. I think doing authentication per fragment is MUCH better method of doing the fragmentation. > Measurably more, because MAC functions have an initialization part, > so running it on a single packet by parts incurs the per-run > overhead multiple times. See the differences in the throughput of > HMAC based on buffer size (obtained by running "opnessl speed": We are talking about IKE_AUTH here, and we will do the Diffie-Hellman, and most likely also public key signature verification and generation here (fragmentation is most likely only needed if we do have certificates inside the packet, shared secret authentication should work without fragmentation). > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes > hmac(md5)17801.04k53527.61k 132966.20k 210528.97k 253873.49k > > So if the packet is 8000 bytes, and you divided it into 1024 > fragments, you would incur a slightly more than 20% penalty. It's actually more useful to compare the speeds from the 1024 bytes down to 512 bytes and then add Diffie-Hellman over group 14 and RSA signature verification + generation over 2048 bit key and check the time difference there. I would expect it to be almost unnoticeable. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
On Thu, 14 Mar 2013, Yoav Nir wrote: Measurably more, because MAC functions have an initialization part, so running it on a single packet by parts incurs the per-run overhead multiple times. See the differences in the throughput of HMAC based on buffer size (obtained by running "opnessl speed": type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes hmac(md5)17801.04k53527.61k 132966.20k 210528.97k 253873.49k So if the packet is 8000 bytes, and you divided it into 1024 fragments, you would incur a slightly more than 20% penalty. I don't understand this part? Legitimate fragments won't have a count higher then about 10. Current implementations I've seen cap at 16 fragments. If you receive a fragment number higher then that, you discard the whole thing. You could even wait with decrypting until you got all fragments. I don't see much value in authenticating each fragment. Possibly they would come in faster then you can decrypt each fragment anyway, so you need to store them regardless, especially in a DoS where the initiator does not perform real encryption for sending fragments. I would likely implement it to receive all fragments, then run decryption on all its parts. Furthermore, since we have the cookies/SPI, it is also pretty easy to ignore bogus fragments, and to require the 6 message echange when receiving a first-packet for a new exchange when under high load, so IKE spoofing won't cause us that much of a higher load. So I'm not too worried about the DOS, and I'm leaning towards a similar model to the currently deployed method for IKEv1. Possibly dropping the useless "fragment id" (not fragment number) Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
On Mar 14, 2013, at 9:38 AM, Valery Smyslov wrote: > Hi Yoav. > >> > I agree that term "authenticated" is a bit misleading here. >> > The better term would be "integrity protected". >> > In our proposal receiver can be absolutely sure that >> > each fragment comes from the very peer he/she exchanged >> > DH exponents and calculated shared secret with. >> > >> > All fragments which ICV cannot be verified are discarded >> > and don't prevent communication with real peer in any way. >> >> So in order to get the responder to spend memory resources on storing the >> fragment, the initiator needs to expand >> CPU resources on completing the D-H calculation, and calculating integrity >> protection on the fragment. Makes sense. > > Sorry, did you read the draft? Yes. > There is no DH calculating per fragment. DH is calculated once in IKE_SA_INIT > as in ordinary IKE SA establishment (note, that unprotected messages, > including IKE_SA_INIT > and IKE_SA_RESUME cannot be fragmented). If we do IKEv2 fragments the way everyone does IKEv1 fragments, the initiator can send multiple fragments that don't assemble to a protected packet, causing the responder to allocate memory to store these fragments (at least for a short while). Doing this does not require completing the D-H calculation, and does not require running either an encryption or MAC function. What your draft does, is force the initiator to protect each fragment. To protect a fragment in a way that will cause the responder to store it, requires running the MAC function, and that in turn requires generating the keys (running the PRF), which in turn requires completing the D-H calculation. If the initiator fails to do any of these things, the fragment will be immediately rejected at the responder. Of course, the D-H calculation is not per-fragment, and I did not claim that this was the case. > And you spent absolutetly the same amount of CPU power to calculate/verify > ICV on > fragments as you would spend it on non-fragmented message You spend the same amount only if you require that your ICV verify. This is not needed for creating DoS on the way fragmentation is done in IKEv1. > (probably a little bit more, as total length of all fragments of one message > could > be a bit more than the length of original message due to padding, IKE header > and so on, > but the usual difference is few percents). Measurably more, because MAC functions have an initialization part, so running it on a single packet by parts incurs the per-run overhead multiple times. See the differences in the throughput of HMAC based on buffer size (obtained by running "opnessl speed": type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes hmac(md5)17801.04k53527.61k 132966.20k 210528.97k 253873.49k So if the packet is 8000 bytes, and you divided it into 1024 fragments, you would incur a slightly more than 20% penalty. > > Let me emphasize again. > 1. In our proposal sender and receiver spend roughly the same amount of CPU > power > as they would spend on protecting/verifying non-fragmented message. > 2. In our proposal sender and receiver spend roughly the same amount of CPU > power > as they would spend on protecting/verifying fragmented message in Cisco/MS > solution. > 3. In our proposal sender needs to encrypt/protect one message twice only once > per SA establishments and only if he/she tries first to send unfragmented > message and after some retransmits decides to resend it fragmented. > This is avoidable if sender always sends large messages fragmented. > 4. Comparing to Cisco/MS solution our proposal allows receiver to > verify integrity of individual fragment, so forged fragments will not > consume receiver's memory and could not prevent receiver > from getting valid fragments. > >> What do you get when you put together the fragments? a decrypted IKE >> message? Just the list of payloads? > > After you decrypt and verify content of Encrypted Fragment Payload of all > fragments, > get rid of now unnecessary headers and put all together, you get a decrypted > IKE message. Good. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
Hi Yoav. > I agree that term "authenticated" is a bit misleading here. > The better term would be "integrity protected". > In our proposal receiver can be absolutely sure that > each fragment comes from the very peer he/she exchanged > DH exponents and calculated shared secret with. > > All fragments which ICV cannot be verified are discarded > and don't prevent communication with real peer in any way. So in order to get the responder to spend memory resources on storing the fragment, the initiator needs to expand CPU resources on completing the D-H calculation, and calculating integrity protection on the fragment. Makes sense. Sorry, did you read the draft? There is no DH calculating per fragment. DH is calculated once in IKE_SA_INIT as in ordinary IKE SA establishment (note, that unprotected messages, including IKE_SA_INIT and IKE_SA_RESUME cannot be fragmented). And you spent absolutetly the same amount of CPU power to calculate/verify ICV on fragments as you would spend it on non-fragmented message (probably a little bit more, as total length of all fragments of one message could be a bit more than the length of original message due to padding, IKE header and so on, but the usual difference is few percents). Let me emphasize again. 1. In our proposal sender and receiver spend roughly the same amount of CPU power as they would spend on protecting/verifying non-fragmented message. 2. In our proposal sender and receiver spend roughly the same amount of CPU power as they would spend on protecting/verifying fragmented message in Cisco/MS solution. 3. In our proposal sender needs to encrypt/protect one message twice only once per SA establishments and only if he/she tries first to send unfragmented message and after some retransmits decides to resend it fragmented. This is avoidable if sender always sends large messages fragmented. 4. Comparing to Cisco/MS solution our proposal allows receiver to verify integrity of individual fragment, so forged fragments will not consume receiver's memory and could not prevent receiver from getting valid fragments. What do you get when you put together the fragments? a decrypted IKE message? Just the list of payloads? After you decrypt and verify content of Encrypted Fragment Payload of all fragments, get rid of now unnecessary headers and put all together, you get a decrypted IKE message. Yoav= Regards, Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
On Mar 13, 2013, at 10:06 AM, Valery Smyslov wrote: > Hi Yaron, > >> I believe the DoS argument is incorrect, because the message we are most >> worried about (most likely to get fragmented) is IKE_AUTH, and at this point >> both peers are not yet authenticated, of course. So fragments and messages >> can be encrypted but cannot be authenticated. Thus, an attacker can send any >> number of seemingly valid fragments. >> >> Let me know if I'm missing anything. > > I agree that term "authenticated" is a bit misleading here. > The better term would be "integrity protected". > In our proposal receiver can be absolutely sure that > each fragment comes from the very peer he/she exchanged > DH exponents and calculated shared secret with. > > All fragments which ICV cannot be verified are discarded > and don't prevent communication with real peer in any way. So in order to get the responder to spend memory resources on storing the fragment, the initiator needs to expand CPU resources on completing the D-H calculation, and calculating integrity protection on the fragment. Makes sense. What do you get when you put together the fragments? a decrypted IKE message? Just the list of payloads? Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
On Mar 13, 2013, at 10:58 AM, Paul Wouters wrote: > On Wed, 13 Mar 2013, Valery Smyslov wrote: > >> Or are you talking about the fictional IETF document (not yet written) >> describing existing IKEv1 fragmentation? Probably it is better that >> the authors of that solution document it. > > I don't think any IKEv1 documents will ever be written again? :) I think that if we make this a working group document, we should add an Appendix that will be informational and describe what people are doing for IKEv1, including the VendorID and the payload identifier "appropriated" for fragments. When I implemented this I used the source of Wireshark to figure out how the protocol worked. Pretty poor reverse engineering, but it produced something that interoperates. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
Mocana's implementation appears to only support fragmentation for IKEv1, not IKEv2. -derek On Tue, March 12, 2013 3:49 pm, Tero Kivinen wrote: > Actually I verified the fragmentation support from Finland, and they > said it was requested, but it is not in any product yet, and as Paul > Wouters already commented to list that the problem with some > implementations sending fragmentation regardless whether it was > negotiated or not has already been fixed, I requirement to implement > this quickly has gone... > > Anyways, if there is already more implementations doing IKE > framentation, it might be good idea to think whether we should > standardize that. On the other hand I am not sure if they are well > enough documented so that different implementations actually talk each > other... > > Anyways we should most likely act fastly if we want to get this fixed > for IKEv2. > -- > kivi...@iki.fi > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
On Wed, 13 Mar 2013, Valery Smyslov wrote: So does it make sense to say in the document that the first packet must not be fragmented? If you mean draft-smyslov-ipsecme-ikev2-fragmentation, that limitation must be already there. If it is not clear enough, I'll make it more explicit. I have to re-read the draft again, sorry. Or are you talking about the fictional IETF document (not yet written) describing existing IKEv1 fragmentation? Probably it is better that the authors of that solution document it. I don't think any IKEv1 documents will ever be written again? :) Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
Our implementation also does not handle the first packet of an exchange to be fragmented, because we have no state to store the fragments for. In practise this does not matter because the first packet is never large enough to need fragmentation. We do the same. So does it make sense to say in the document that the first packet must not be fragmented? If you mean draft-smyslov-ipsecme-ikev2-fragmentation, that limitation must be already there. If it is not clear enough, I'll make it more explicit. Or are you talking about the fictional IETF document (not yet written) describing existing IKEv1 fragmentation? Probably it is better that the authors of that solution document it. Regards, Valery. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
On Wed, 13 Mar 2013, Valery Smyslov wrote: How is that a DOS attack? In our implementation of the IKEv1 fragmentation, we limit the number of fragments to 16. We will only need to do any crypto when we received the IKE packet marked as "last". Then we do crypto once on the assembled packet and throw it away when crypto fails. If attacker sends you a forged fragment, you cannot determine this untill you get reassembled the whole message. When you determine this you have to discard all received fragments (as you don't know which of them is bogus) and wait for retransmission. For attacker it is enough to send you forged fragments with rather low rate to have a good chance to prevent you from communication with your peer. I think this is kind of DoS attack as Initiator is denied to get desired service (IPsec). But then the attacker has to know the SPI/COOKIES too? So it is an in-path attack. But I see you point. I think that responder should start replying with fragments immediately after it receives first fragmented message from initiator, but not before this event. It is initiator who is responsible for retransmissions and it is his/her responsibility to switch on fragmentation. Yes, this case is different for IKEv2. Our implementation also does not handle the first packet of an exchange to be fragmented, because we have no state to store the fragments for. In practise this does not matter because the first packet is never large enough to need fragmentation. We do the same. So does it make sense to say in the document that the first packet must not be fragmented? Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
Hi Paul, As for IKEv2, I don't know how Cisco is doing fragmentation in this case (it seems to have support for it), but if it is done similarly to IKEv1, than I prefer our own solution - draft-smyslov-ipsecme-ikev2-fragmentation. The main difference is that in Microsoft/Cisco solution (for IKEv1) the whole encrypted ISAKMP message is fragmented, leaving each fragment unauthanticated untill message get reassembled and its authentity could be verivied. This opens door for a very simple DoS attack on receiver. How is that a DOS attack? In our implementation of the IKEv1 fragmentation, we limit the number of fragments to 16. We will only need to do any crypto when we received the IKE packet marked as "last". Then we do crypto once on the assembled packet and throw it away when crypto fails. If attacker sends you a forged fragment, you cannot determine this untill you get reassembled the whole message. When you determine this you have to discard all received fragments (as you don't know which of them is bogus) and wait for retransmission. For attacker it is enough to send you forged fragments with rather low rate to have a good chance to prevent you from communication with your peer. I think this is kind of DoS attack as Initiator is denied to get desired service (IPsec). In our proposal each fragment is encrypted and authenticated individually, that allows receiver to distinguish valid fragments from bogus, thus preventing from abovementioned DoS attack. But I can send lots of small forged fragments and you will do lots of crypto on them for _each_ forged fragment. I think you will end up using a lot more cpu and the attacker needs a lot less bandwidth. ICV check is (must be) very fast, and you cannot avoid this attack even without fragmentation - attacker can send you forged regular messages and you will have to do ICV check for each of them. I don't think fragmentation makes this worse. I actually do like the IKEv1 version. It's very simple. And uses the exact same code path apart from a little buffer where we store some fragments (with sane limits). The only oddness is that fragmentation ID that serves no purpose, as you cannot really have two different packets fragmented in flight for a single exchange. (well you can, but they are going to be identical anyway) While implementing the IKEv1 version, I did wonder about what should trigger fragmentation. For instance, if both parties have send and received the vendorid, and one side sends fragments, should the other side fully indepedantly wait for failure/retransmit before using fragments, or take the hint that if the path is broken one way, it is likely broken in the other way as well? It seems that being a little aggressive here can really help the IPsec SA to establish much faster - especially since our own retransmit time is 20 seconds, which is something we are now consideraing lowering a lot. I think that responder should start replying with fragments immediately after it receives first fragmented message from initiator, but not before this event. It is initiator who is responsible for retransmissions and it is his/her responsibility to switch on fragmentation. Our implementation also does not handle the first packet of an exchange to be fragmented, because we have no state to store the fragments for. In practise this does not matter because the first packet is never large enough to need fragmentation. We do the same. Paul Regards, Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
Hi Yaron, I believe the DoS argument is incorrect, because the message we are most worried about (most likely to get fragmented) is IKE_AUTH, and at this point both peers are not yet authenticated, of course. So fragments and messages can be encrypted but cannot be authenticated. Thus, an attacker can send any number of seemingly valid fragments. Let me know if I'm missing anything. I agree that term "authenticated" is a bit misleading here. The better term would be "integrity protected". In our proposal receiver can be absolutely sure that each fragment comes from the very peer he/she exchanged DH exponents and calculated shared secret with. All fragments which ICV cannot be verified are discarded and don't prevent communication with real peer in any way. Hope this helps. Regards, Valery. Thanks, Yaron On 03/13/2013 03:22 PM, Valery Smyslov wrote: Hi, Anyways, if there is already more implementations doing IKE framentation, it might be good idea to think whether we should standardize that. On the other hand I am not sure if they are well enough documented so that different implementations actually talk each other... We support IKEv1 fragmentation based on documentation found at msdn.microsoft.com. We are able to interoperate with both Microsoft and Cisco. Anyways we should most likely act fastly if we want to get this fixed for IKEv2. As for IKEv2, I don't know how Cisco is doing fragmentation in this case (it seems to have support for it), but if it is done similarly to IKEv1, than I prefer our own solution - draft-smyslov-ipsecme-ikev2-fragmentation. The main difference is that in Microsoft/Cisco solution (for IKEv1) the whole encrypted ISAKMP message is fragmented, leaving each fragment unauthanticated untill message get reassembled and its authentity could be verivied. This opens door for a very simple DoS attack on receiver. In our proposal each fragment is encrypted and authenticated individually, that allows receiver to distinguish valid fragments from bogus, thus preventing from abovementioned DoS attack. And, of course, we have implemented this solution in our products. And, of course, we are intersted in doing IKEv2 fragmentation in standard, interoperable way (based either on our proposal or smth else). Regards, Valery Smyslov. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
On Wed, 13 Mar 2013, Valery Smyslov wrote: As for IKEv2, I don't know how Cisco is doing fragmentation in this case (it seems to have support for it), but if it is done similarly to IKEv1, than I prefer our own solution - draft-smyslov-ipsecme-ikev2-fragmentation. The main difference is that in Microsoft/Cisco solution (for IKEv1) the whole encrypted ISAKMP message is fragmented, leaving each fragment unauthanticated untill message get reassembled and its authentity could be verivied. This opens door for a very simple DoS attack on receiver. How is that a DOS attack? In our implementation of the IKEv1 fragmentation, we limit the number of fragments to 16. We will only need to do any crypto when we received the IKE packet marked as "last". Then we do crypto once on the assembled packet and throw it away when crypto fails. In our proposal each fragment is encrypted and authenticated individually, that allows receiver to distinguish valid fragments from bogus, thus preventing from abovementioned DoS attack. But I can send lots of small forged fragments and you will do lots of crypto on them for _each_ forged fragment. I think you will end up using a lot more cpu and the attacker needs a lot less bandwidth. I actually do like the IKEv1 version. It's very simple. And uses the exact same code path apart from a little buffer where we store some fragments (with sane limits). The only oddness is that fragmentation ID that serves no purpose, as you cannot really have two different packets fragmented in flight for a single exchange. (well you can, but they are going to be identical anyway) While implementing the IKEv1 version, I did wonder about what should trigger fragmentation. For instance, if both parties have send and received the vendorid, and one side sends fragments, should the other side fully indepedantly wait for failure/retransmit before using fragments, or take the hint that if the path is broken one way, it is likely broken in the other way as well? It seems that being a little aggressive here can really help the IPsec SA to establish much faster - especially since our own retransmit time is 20 seconds, which is something we are now consideraing lowering a lot. Our implementation also does not handle the first packet of an exchange to be fragmented, because we have no state to store the fragments for. In practise this does not matter because the first packet is never large enough to need fragmentation. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
Hi Valery, I believe the DoS argument is incorrect, because the message we are most worried about (most likely to get fragmented) is IKE_AUTH, and at this point both peers are not yet authenticated, of course. So fragments and messages can be encrypted but cannot be authenticated. Thus, an attacker can send any number of seemingly valid fragments. Let me know if I'm missing anything. Thanks, Yaron On 03/13/2013 03:22 PM, Valery Smyslov wrote: Hi, Anyways, if there is already more implementations doing IKE framentation, it might be good idea to think whether we should standardize that. On the other hand I am not sure if they are well enough documented so that different implementations actually talk each other... We support IKEv1 fragmentation based on documentation found at msdn.microsoft.com. We are able to interoperate with both Microsoft and Cisco. Anyways we should most likely act fastly if we want to get this fixed for IKEv2. As for IKEv2, I don't know how Cisco is doing fragmentation in this case (it seems to have support for it), but if it is done similarly to IKEv1, than I prefer our own solution - draft-smyslov-ipsecme-ikev2-fragmentation. The main difference is that in Microsoft/Cisco solution (for IKEv1) the whole encrypted ISAKMP message is fragmented, leaving each fragment unauthanticated untill message get reassembled and its authentity could be verivied. This opens door for a very simple DoS attack on receiver. In our proposal each fragment is encrypted and authenticated individually, that allows receiver to distinguish valid fragments from bogus, thus preventing from abovementioned DoS attack. And, of course, we have implemented this solution in our products. And, of course, we are intersted in doing IKEv2 fragmentation in standard, interoperable way (based either on our proposal or smth else). Regards, Valery Smyslov. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE fragmentation
Hi, Anyways, if there is already more implementations doing IKE framentation, it might be good idea to think whether we should standardize that. On the other hand I am not sure if they are well enough documented so that different implementations actually talk each other... We support IKEv1 fragmentation based on documentation found at msdn.microsoft.com. We are able to interoperate with both Microsoft and Cisco. Anyways we should most likely act fastly if we want to get this fixed for IKEv2. As for IKEv2, I don't know how Cisco is doing fragmentation in this case (it seems to have support for it), but if it is done similarly to IKEv1, than I prefer our own solution - draft-smyslov-ipsecme-ikev2-fragmentation. The main difference is that in Microsoft/Cisco solution (for IKEv1) the whole encrypted ISAKMP message is fragmented, leaving each fragment unauthanticated untill message get reassembled and its authentity could be verivied. This opens door for a very simple DoS attack on receiver. In our proposal each fragment is encrypted and authenticated individually, that allows receiver to distinguish valid fragments from bogus, thus preventing from abovementioned DoS attack. And, of course, we have implemented this solution in our products. And, of course, we are intersted in doing IKEv2 fragmentation in standard, interoperable way (based either on our proposal or smth else). Regards, Valery Smyslov. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
