Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)
On 27/09/16 20:07, Valery Smyslov wrote: > > The attacker can however gain some benefits if he/she waits some time > until the half-open SA is expired on Responder and chooses the same SPI > and nonce for the next connection request. He/she will receive the same > puzzle > if the Responder doesn't change value of secret yet. Note that RFC7296 > recommends > changing secret frequently if under attack (RFC7296, Section 2.6): > > The responder should change the value of frequently, especially > if under attack. > > I think we can add some words to the draft that will recommend > to generate cookie in such a manner, that the cookie is not repeated > even if the same IP, SPI and nonce are used by Initiator. Good one. Yeah I think it'd be fine to add that. All the rest of your and Yoav's responses are good too. Thanks, S. smime.p7s Description: S/MIME Cryptographic Signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)
On 27/09/16 20:21, Yoav Nir wrote: > Looking at the IPR statement you linked to, it does not seem relevant > to me, but IANAL. The proof-of-work scheme described in the patent > ([2]) involves setting a time limit for the client to complete the > puzzle solution. The puzzle in our draft has a set difficulty level, > but no time limit for the Initiator to solve it. FWIW, that sounds reasonable to me. But I've given up pondering what lawyers think about patents so folks can make up their own minds;-) S. smime.p7s Description: S/MIME Cryptographic Signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)
On 27 Sep 2016, at 8:09 PM, Stephen Farrellwrote: > This is a nicely written document... thanks! > > - I vaguely recalled that puzzles and IPR rang a bell. Did > the WG consider [1]? If not, and if it helps, I'm fine with > making a 3rd party declaration on that and last call could be > done again. Or maybe there's a better way to handle it. Or > maybe the WG considered it and are happy enough already that > it's not relevant or about to expire or abandoned or > something. ("Not relevant" would puzzle me:-) > > [1] https://datatracker.ietf.org/ipr/417/ We did not consider this one. We did consider a Sun/Oracle patent but ultimately worked around this by replacing the type of puzzle. The current puzzle is based on the proof-of-work algorithm used in Bitcoins. Looking at the IPR statement you linked to, it does not seem relevant to me, but IANAL. The proof-of-work scheme described in the patent ([2]) involves setting a time limit for the client to complete the puzzle solution. The puzzle in our draft has a set difficulty level, but no time limit for the Initiator to solve it. [2] https://libpatent.com/patents/07197639 > - section 3: "if certificates are involved" - you could note > here that involving certificates can introduce a network > based delay (OCSP, CRLs etc) that's a little different from > CPU consumption. (But it's a nit, and you do note a similar > issue in 4.7.) True. But I think that for most devices used as IKE responders the bottleneck is going to be the amount of CPU they can dedicate to verifying signatures on certificates and CRLs/OCSP responses, not the amount of memory they need to allocate while they’re waiting for a response from whatever servers on the network. IOW if a certain device is capable of verifying the signatures on certificate and CRLs for n initiators per second and there is a total network delay of t to get all the necessary CRLs or OCSP responses and a memory allocation of m for every in-progress IKE Exchange, the same device will be able to allocate much more memory than the m*n*t that is needed to support the n*t concurrent exchanges. > - 4.2: "ratelimits should be done based on either the /48 or > /64" - would it be better to say "something between a /48 and > a /64" maybe? Don't some ISPs assign things in-between? They do. It even says so earlier in the same paragraph. But the Responder does not know what the practices are at the Initiator’s ISP. We know that prefixes longer than /64 are too granular and that prefixes shorter than /48 are too coarse for marking a certain range of addresses as attacking. I suppose the Responder could choose something in between, but I don’t think there’s ever a good justification for say /50 or /58. /48 and /64 seem to make the most sense. > - 4.4: Did you consider making the "4 keys" requirement tied > to the PRF algorithm identifier? That would allow for a > future where e.g. 6 keys are needed for the same PRF, if that > were ever useful. (Without changing current implementations.) > I guess you'd need a separate IANA registry that'd initially > duplicate stuff in that case so maybe not worth doing. (And > could be done later.) Since the level of the puzzle is settable by tweaking the required number of zero-bits, the number of required answers plays no part in the level of difficulty. Rather, it is used to smooth out the puzzle difficulty. See my response to Mirja on this and also https://mailarchive.ietf.org/arch/msg/ipsec/v7PFBEWeaT6ZQCjzCmIaxbRnZ8A > - 7.1.1 - you don't clearly say if the cookie value here can > be a new one or should be the same as one previously used (if > one was previously used). That may just be my ignorance of > IPsec cookies though, but I wondered if there are any cases > where the initiator gets to work away on the puzzle ahead of > time if the same cookie is used for multiple interactions. > There's not much (or zero) of an improvement to the attack > here, though maybe the attacker could more easily offload > puzzle solving to someone else in that case? > I see that while I’m typing this Valery has also replied, so I’ll leave this part to him, as he replied at length. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)
Hi Stephen, -- COMMENT: -- This is a nicely written document... thanks! Thank you! - I vaguely recalled that puzzles and IPR rang a bell. Did the WG consider [1]? If not, and if it helps, I'm fine with making a 3rd party declaration on that and last call could be done again. Or maybe there's a better way to handle it. Or maybe the WG considered it and are happy enough already that it's not relevant or about to expire or abandoned or something. ("Not relevant" would puzzle me:-) [1] https://datatracker.ietf.org/ipr/417/ The WG didn't consider this particular IPR. - section 3: "if certificates are involved" - you could note here that involving certificates can introduce a network based delay (OCSP, CRLs etc) that's a little different from CPU consumption. (But it's a nit, and you do note a similar issue in 4.7.) The network delay does not necessary take place (OCSP is optional, CRL may be cached), while CPU consumption is unavoidable. - 4.2: "ratelimits should be done based on either the /48 or /64" - would it be better to say "something between a /48 and a /64" maybe? Don't some ISPs assign things in-between? This particular sentence was discussed by WG. I think that "either /48 or /64" was chosen for simplicity. - 4.4: Did you consider making the "4 keys" requirement tied to the PRF algorithm identifier? That would allow for a future where e.g. 6 keys are needed for the same PRF, if that were ever useful. (Without changing current implementations.) I guess you'd need a separate IANA registry that'd initially duplicate stuff in that case so maybe not worth doing. (And could be done later.) Several puzzle solutions help reduce volatility of time needed to solve any given puzzle. I don't think it is related to particular PRF, since any "good" PRF must generate pseudorandom result and finding a key for that result would always involve a fortune for the Initiator. The fixed number of keys (4) is a compromise. We considered setting it to larger value, say 16 (and it would make correlation between puzzle difficulty and the time needed to solve it more predictable), but it would increase IKE message size in initial exchange. And it is a bad thing, since it increases the chances that the message exceeds MTU and is fragmented by IP, with all negative consequences. - 7.1.1 - you don't clearly say if the cookie value here can be a new one or should be the same as one previously used (if one was previously used). That may just be my ignorance of IPsec cookies though, but I wondered if there are any cases where the initiator gets to work away on the puzzle ahead of time if the same cookie is used for multiple interactions. There's not much (or zero) of an improvement to the attack here, though maybe the attacker could more easily offload puzzle solving to someone else in that case? In IKEv2 the cookie is usually generated by applying hash function to Initiator's IP, SPI, nonce and some secret maintained by Responder. Since the cookie must be stateless for the Responder, it is not stored on the Responder (except for the secret, which is global and is changed periodically). So, if the Initiator uses the same IP, same SPIi and the same nonce, it will very likely receive the same cookie until the secret is changed. However, it won't much help an attacker. Once the puzzle is solved and the attacker successfully creates half-open SA on the Responder, it cannot use the same combination of IP and SPI to create another one, because all the initial messages with the same IP+SPI will be delivered to that half-open SA and discarded. The attacker can however gain some benefits if he/she waits some time until the half-open SA is expired on Responder and chooses the same SPI and nonce for the next connection request. He/she will receive the same puzzle if the Responder doesn't change value of secret yet. Note that RFC7296 recommends changing secret frequently if under attack (RFC7296, Section 2.6): The responder should change the value of frequently, especially if under attack. I think we can add some words to the draft that will recommend to generate cookie in such a manner, that the cookie is not repeated even if the same IP, SPI and nonce are used by Initiator. Thank you, Valery Smyslov. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-ipsecme-ddos-protection-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ -- COMMENT: -- This is a nicely written document... thanks! - I vaguely recalled that puzzles and IPR rang a bell. Did the WG consider [1]? If not, and if it helps, I'm fine with making a 3rd party declaration on that and last call could be done again. Or maybe there's a better way to handle it. Or maybe the WG considered it and are happy enough already that it's not relevant or about to expire or abandoned or something. ("Not relevant" would puzzle me:-) [1] https://datatracker.ietf.org/ipr/417/ - section 3: "if certificates are involved" - you could note here that involving certificates can introduce a network based delay (OCSP, CRLs etc) that's a little different from CPU consumption. (But it's a nit, and you do note a similar issue in 4.7.) - 4.2: "ratelimits should be done based on either the /48 or /64" - would it be better to say "something between a /48 and a /64" maybe? Don't some ISPs assign things in-between? - 4.4: Did you consider making the "4 keys" requirement tied to the PRF algorithm identifier? That would allow for a future where e.g. 6 keys are needed for the same PRF, if that were ever useful. (Without changing current implementations.) I guess you'd need a separate IANA registry that'd initially duplicate stuff in that case so maybe not worth doing. (And could be done later.) - 7.1.1 - you don't clearly say if the cookie value here can be a new one or should be the same as one previously used (if one was previously used). That may just be my ignorance of IPsec cookies though, but I wondered if there are any cases where the initiator gets to work away on the puzzle ahead of time if the same cookie is used for multiple interactions. There's not much (or zero) of an improvement to the attack here, though maybe the attacker could more easily offload puzzle solving to someone else in that case? ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec