Subject: [IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

From: "Alexey Melnikov" <[email-masked]>
Date: Tue, 27 Sep 2016 03:15:36 -0700

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

I tempted to ballot Yes on on the document. I hope it will get widespread
deployment.

Please excuse my ignorance: Puzzle Solution Payload format - I don't see
the new payload type specified in the diagram. Where is it included?

---

From: Valery Smyslov <[email-masked]>
Date: Tue, 27 Sep 2016 14:42:26 +0300

Hi Alexey,

payload type for the Puzzle Solution Payload is specified in the last sentence
of Section 8.2:

   The payload type for the Puzzle Solution payload is <TBA by IANA>.

It is not included in the diagram in this section since the "Next Payload" field in generic 
payload header contains the type of the following payload, not the type of payload 
the diagram depicts.

There is also an IANA Considerations Section which also specifies the
payload type for the Puzzle Solution payload.

Thank you,
Valery Smyslov.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 27 Sep 2016 14:48:21 +0300

> On 27 Sep 2016, at 2:42 PM, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Alexey,
> 
> It is not included in the diagram in this section since the "Next Payload" field in generic payload header contains the type of the following payload, not the type of payload the diagram depicts.

But it is depicted in sections 7.1.2 and 7.2.2. In both cases denoted as PS (=puzzle solution):

From 7.1.2:
   If the Initiator supports puzzles and is ready to solve them, then it
   tries to solve the given puzzle.  After the puzzle is solved the
   Initiator restarts the request and returns back to the Responder the
   puzzle solution in a new payload called a Puzzle Solution payload
   (denoted as PS, see Section 8.2) along with the received COOKIE
   notification.

   HDR, N(COOKIE), [PS,] SA, KE, Ni, [V+][N+]   —>

From 7.2.2:
   If the IKE_SA_INIT response message contains the PUZZLE notification
   and the Initiator supports puzzles, it MUST solve the puzzle.  Note,
   that puzzle construction in the IKE_AUTH exchange differs from the
   puzzle construction in the IKE_SA_INIT exchange and is described in
   Section 7.2.3.  Once the puzzle is solved the Initiator sends the
   IKE_AUTH request message, containing the Puzzle Solution payload.

   HDR, PS, SK {IDi, [CERT,] [CERTREQ,]
               [IDr,] AUTH, SA, TSi, TSr}   -->

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Sep 2016 23:43:08 +0100

Hi Valery,

> On 27 Sep 2016, at 12:42, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Alexey,
> 

Ok, this is what I missed. I just wanted to make sure that whoever parses a response can figure out where a puzzle solution starts and whether it is present.

Thank you,
Alexey