On 27 Sep 2016, at 8:09 PM, Stephen Farrell <[email protected]> wrote:
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
