Hi Tommy,
thank you for your comments.
I tend to agree with Paul that I find it unlikely, from an implementor’s standpoint, that many Initiators will
choose
to implement the puzzle logic, especially ones that are running on mobile devices. It is unlikely that the phones
will be able
to solve the puzzles quickly enough to beat out botnets, and it would be hard to justify the battery consumption
necessary.
That being said, the document does a very good job of explaining the problem space, and the other parts of its
solution
(rate-limiting and suggesting session resumption) make good sense. Perhaps there can be more focus on how a
responder
can best protect itself if indeed the majority of its clients do not support
puzzles?
Sections 4 - 6 describe measures other than puzzles that the responder can use
to defend itself against DDoS attack.
Do you think it is not enough? Puzzles are a new thing, that's why more text is
needed to explain how they are fit
into the protocol. However the draft is not solely about puzzles, and I think it covers other defending techniques in
sufficient details.
One question on section 7.1.2:
If the received message contains a PUZZLE notification and doesn't
contain a COOKIE notification, then this message is malformed because
it requests to solve the puzzle, but doesn't provide enough
information to do it. In this case the Initiator SHOULD resend
IKE_SA_INIT request. If this situation repeats several times, then
it means that something is wrong and the IKE SA cannot be
established.
I am concerned that the suggestion for the initiator reacting to malformed IKE_SA_INIT packets is to send more
traffic to the responder.
The responder should not legitimately send a PUZZLE notification without a COOKIE notification, since this would be
invalid.
If the initiator sees this, it can either assume that (a) the responder’s implementation is out of spec, or (b) some
malicious third party
is deliberately modifying the unencrypted packet. In the first case, trying to send the IKE_SA_INIT again would be
in vain;
in the second case, we have provided a way for a third party to cause initiators to send more traffic to the
responder,
thus providing an attack vector. What are your thoughts on this?
A proper responder would not send a malformed packet. An attacker could send a
malformed response immediately
after the initiator sends the request. By the time the initiator gets the real responder’s response, it has lost
state.
That is why it is always a good idea (not just in this context) for the initiator to ignore malformed responses until
the timeout is reached.
That makes sense. The wording, however, could imply that the Initiator should resend the request as if in response to
the malformed packet.
Based on your comment, the Initiator should wait for the usual amount of time before retrying, rather than immediately
retrying the packet.
It may be useful to clarify this in the text.
You are right that the Initiator should wait for the retransission timer to
expire before resending message.
I agree that the wording is ambiguous about that. How about the following?
If the received message contains a PUZZLE notification and doesn't
contain a COOKIE notification, then this message is malformed because
it requests to solve the puzzle, but doesn't provide enough
information to do it. In this case the Initiator MUST ignore
the received message and continue to wait until either the valid one
is received or the retransmission timer fires. If it fails to receive the
valid
message after several retransmissions of IKE_SA_INIT request, then
it means that something is wrong and the IKE SA cannot be established.
Regards,
Valery.
Thanks,
Tommy
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
