Subject: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Fri, 23 Sep 2016 12:11:39 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-ipsecme-ddos-protection-09: No Objection

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:
----------------------------------------------------------------------

Some questions:

1) sec 7.1.2: If there is a puzzle but no cookie, maybe the initiator
should ignore it and try to send reply without the puzzle solution, as
there might be still a change to get served…? If it then received another
packet with puzzle it can still solve it and reply.

2) sec 7.1.4: Does „the Responder MUST verify the puzzle solution“? Maybe
there are cases where the burden for the initiator is high enough by
requesting the solution that there is already an effect even if the
responder decides to not verify it…? 

3) also sec 7.1.4: Does the following sentence really makes sense? How
doe the responser know? Maybe just remove it?
	„The more time the Initiator spent solving the puzzles, the higher
priority it should receive.“
	
4) sec 7.2.1.1 says „the Responder would be able to estimate the
computational power of the Initiator and select the difficulty level
accordingly.“ How would it estimate the computational power? Based on the
reply time? Wouldn’t it also need to know the RTT and current congestion
level then?

5) sec 7.2.2 says „If the IKE_SA_INIT response message contains the
PUZZLE notification and the Initiator supports puzzles, it MUST solve the
puzzle.“
	Should this be „IKE_SA_AUTH“ here instead of „IKE_SA_INIT“? 
	Otherwise it contradicts sec 7.1.2 („The Initiator MAY ignore the PUZZLE
notification…“)

Two general comments/questions:

1) What’s about the additional cpu load of the responder to calculate the
puzzle. Can that be a problem? Are there any strategies to keep that low
(recalculation/caching/reuse)? How long should things be cached/used?
Maybe add a few sentences in the Operational Considerations section!

2) Would it make sense to also give a field to change the number of
requested keys to scale load? Or why was it decided to use a fixed number
of 4 here?

---

From: Yoav Nir <[email-masked]>
Date: Fri, 23 Sep 2016 23:06:05 +0300

Hi.

See responses below

> On 23 Sep 2016, at 10:11 PM, Mirja Kuehlewind <[email-masked]> wrote:

A response that contains neither COOKIE nor INVALID_KE_PAYLOAD nor the regular payloads like SA is invalid according to RFC 7296. That is one reason why we chose to keep the COOKIE notification and add a PUZZLE notification rather than put both pieces of data in the new notification. A response with only PUZZLE and no COOKIE is invalid and should be treated as such. So after some (not specified anywhere) time, the Initiator should start a new IKE_SA_INIT exchange, hoping that this time the Responder returns a valid response.

> responder decides to not verify it…? 

There was a suggestion discussed that the Responder MAY choose not to check the solution or randomly check just one of the four solutions. The WG didn’t like that as it makes the protocol non-deterministic and makes things harder to test. So consensus was to make the verification mandatory. Of course, this doesn’t affect interoperability, so we can’t force a responder to check everything.

> priority it should receive.“

The Responder cannot know. It can only assume based on the expected number of steps in finding a solution with a certain number of trailing zero bits.

> reply time? Wouldn’t it also need to know the RTT and current congestion

The only estimate that the responder has is based on what the initiator solved during the IKE_SA_INIT exchange. If the Initiator solved a level-15 puzzle (15 trailing zeros in each of the four solutions) then it stands to reason that it *can* solve a level-15 puzzle. Maybe the word “estimate” is misleading here.

> 	Otherwise it contradicts sec 7.1.2 („The Initiator MAY ignore the PUZZLE

Sure. Seems to be a typo.

> Maybe add a few sentences in the Operational Considerations section!

Verifying a puzzle solution involves 4 invocation of a MAC function on a few tens of bytes. This is very low considering that (1) IKE initiation involves at least one and typically two PK operations, and (2) IKE is for generating key material which is then used to MAC millions or billions of packets.

> requested keys to scale load? Or why was it decided to use a fixed number

You scale the load by changing the difficulty (number of requested trailing zero bits).  The reason we are asking for 4 solutions rather than 1 is to make the amount of work more predictable. We could make it even more predictable with 16 solutions, but that makes the packet bigger and runs the risk of requiring packet fragmentation. So we chose 4 as a reasonable compromise.  See this mail about it:
https://mailarchive.ietf.org/arch/msg/ipsec/v7PFBEWeaT6ZQCjzCmIaxbRnZ8A

Yoav

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sat, 24 Sep 2016 00:37:09 +0200

Hi Yoav,

okay. I guess some of the reasoning you gave could go into the draft…

Thanks!
Mirja

> Am 23.09.2016 um 22:06 schrieb Yoav Nir <[email-masked]>:
> 
> Hi.
> 
> See responses below
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Sun, 25 Sep 2016 23:20:12 +0300

Hi Mirja, Yoav,

I agree with Yoav's answers, just want to clarify a few things. See below
(I removed the comments where I have nothing to add to Yoav's answers).

> A response that contains neither COOKIE nor INVALID_KE_PAYLOAD nor the regular payloads like SA is invalid according 
> to RFC 7296.
> That is one reason why we chose to keep the COOKIE notification and add a PUZZLE notification rather than put both 
> pieces of
> data in the new notification. A response with only PUZZLE and no COOKIE is invalid and should be treated as such.
> So after some (not specified anywhere) time, the Initiator should start a new IKE_SA_INIT exchange, hoping that this 
> time the
> Responder returns a valid response.

Actually, the Initiator sends requests, not responses. So, if the Initiator ignores
invalid response from the Responder, then the only thing it can do is to wait
some time and sends another request (or just retransmit the sent request in hope
that invalid response was from an attacker who wants to break IKE SA establishment).
If the situation doesn't improve (the Initiator continues to receive invalid responses),
then the Initator has nothing to do but give up.

I just want to emphasise that Mirja's suggestion (ignore invalid response) is exactly
what the draft suggests to do in this case, as Yoav correctly outlined. Isn't it clear enough from the
document? Should we add more clarifications?

> certain number of trailing zero bits.

The Responder can also measure the time between the puzzle request and
the reception of puzzle solution (and the Responder can do this in a stateless manner).
Sure this measurment cannot be accurate, because it includes RTT, but it
can be used as additional input to the prioritizing algorithm (along
with puzzle difficulty and the number of times the puzzle was requested).
But in general the prioritizing algorithm is a local matter of Responder
and the draft doesn't mandatae it in any way.

> Sure. Seems to be a typo.

No, that's not a typo. Note, that unlike IKE_SA_INIT exchange the IKE_AUTH exchange
cannot be restarted. So, if we want the puzzle solution to be in IKE_AUTH request
(that is sent by the Initiator), the puzzle must be given to the Initiator earlier,
i.e. in the preceding response from the Responder, i.e. in the IKE_SA_INIT response.
So the text is correct.

However, I understand Mirja's source of confusion - in IKEv2 there are
three different kinds of IKE_SA_INIT responses ("regular", COOKIE and
INVALID_KE_PAYLOAD) and unfortunately RFC7296 doesn't give them distinct
names - they all are IKE_SA_INIT response. So, there is no contradiction with
7.1.2, because 7.1.2 tells about IKE_SA_INIT response that contain COOKIE request
(and PUZZLE request), while 7.2.2 tells about "regular" IKE_SA_INIT response,
i.e. that contains SA, KE, NONCE payloads etc. So, while in the first case
the Initiator can ignore puzzle request (if PUZZLE is present in a response containing COOKIE)
and still have a chance to be served, in the second case it cannot ignore puzzle request
(when PUZZLE is present in a "regular" IKE_SA_INIT response).

Do you think it is not clear enough and more clarifications are needed?

Regards,
Valery.