Andy Newton has entered the following ballot position for draft-ietf-ipsecme-ikev2-qr-alt-08: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-qr-alt/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Andy Newton, ART AD, comments for draft-ietf-ipsecme-ikev2-qr-alt-08 CC @anewton1998 * line numbers: - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-qr-alt-08.txt&submitcheck=True * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments Thanks for writing this draft. The following are just comments to use as you see fit. ### Variable PKK_ID Given the figure and the description of PKK_ID below, is there a mismatch on the length. The description says "(variable)" but the figure seems to indicate a rigid 8 octets. 204 1 2 3 205 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | | 208 ~ PPK_ID ~ 209 | | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | | 212 + PPK Confirmation + 213 | | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 Figure 1: PPK_IDENTITY_KEY Notification Data Format 218 Where: 220 * PPK_ID (variable) -- PPK_ID as defined in Section 5.1 of 221 [RFC8784]. The receiver can determine the length of PPK_ID by 222 subtracting 8 (the length of PPK Confirmation) from the 223 Notification Data length. 225 * PPK Confirmation (8 octets) -- value, which allows the responder 226 to check whether it has the same PPK as the initiator for a given 227 PPK_ID. This field contains the first 8 octets of a string 228 computed as prf( PPK, Ni | Nr | SPIi | SPIr ), where prf is the 229 negotiated PRF; PPK is the key value for a specified PPK_ID; Ni, 230 Nr, SPIi, SPIr -- nonces and IKE SPIs for the SA being 231 established. ## Nits ### Remove "the one" I think "the one" can be removed from the end of line 91. I would also remove the word "mostly", but that's just me. 90 calculation. At the time this extension was being developed, it was 91 a consensus in the IPsecME WG that it is the IPsec traffic the one 92 that mostly needs to be protected. It was believed that information ### Not Applicable Cells My first reaction to looking at this table is that "*" was a reference to a foot note or aside. Maybe putting "n/a" for "not applicable" is better if your intention is to say neither "Yes" nor "No" but something is needed. 295 Table 1 summarizes the above logic for the responder: 297 +===========+=============+========+===========+====================+ 298 |Received | Supports |Has one | PPK is | Action | 299 |USE_PPK_INT| USE_PPK_INT |of | mandatory | | 300 | | |proposed| for | | 301 | | |PPKs | initial | | 302 | | | | IKE SA | | 303 +===========+=============+========+===========+====================+ 304 |No | * |* | No | [RFC8784] (if | 305 | | | | | proposed) or | 306 | | | | | standard IKEv2 | 307 | | | | | protocol | 308 +-----------+-------------+--------+-----------+--------------------+ 309 |No | Yes |* | Yes | Send | 310 | | | | | NO_PROPOSAL_CHOSEN | 311 +-----------+-------------+--------+-----------+--------------------+ 312 |Yes | Yes |Yes | * | Section 3.1, | 313 | | | | | Paragraph 16, Item | 314 | | | | | 1 (use this | 315 | | | | | extension) | 316 +-----------+-------------+--------+-----------+--------------------+ 317 |Yes | Yes |No | Yes | Section 3.1, | 318 | | | | | Paragraph 16, Item | 319 | | | | | 2 (abort | 320 | | | | | negotiation) | 321 +-----------+-------------+--------+-----------+--------------------+ 322 |Yes | Yes |No | No | Section 3.1, | 323 | | | | | Paragraph 16, Item | 324 | | | | | 3 (standard IKEv2 | 325 | | | | | protocol) | 326 +-----------+-------------+--------+-----------+--------------------+ ### Comparison to IKE_AUTH 457 IKEv2 protocol are discussed in [RFC8784]. Compared to use PPKs in 458 IKE_AUTH this specification makes even initial IKE SA quantum secure. Just a suggestion (if I understood correct): Unlike PPKs in IKE_AUTH, this specification makes initial IKE SA quantum secure. _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
