Hi Andy, thank you, please see inline.
> 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. Actually, while PPK_ID looks like occupying exactly 8 bytes on the figure, the side lines of the box around it have tildes (~) in the middle to indicate that the actual size can vary. I do not know how to better indicate the variability of the field length on the figure. If you have any ideas how to do it (preserving the clarity of the figure) I'll be happy to use them. > ## 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 This sentence has already been changed based on Gorry comments to: At the time this extension was being developed, the consensus in the IPsecME WG was that the IPsec traffic was more important to be protected than the IKE traffic. > ### 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 > +-----------+-------------+--------+-----------+--------------------+ Actually, "*" here means "Does not matter", and not "Not Applicable". The reason asterisks are used is that this document is closely related to RFC 8784 (in fact, it was developed to overcome the RFC 8784 limitations) and RFC 8784 has an identical table (modulo slightly different conditions) where asterisk are used. We inherited its syntax here, since nobody complained before. I'd rather to keep asterisks here unless you strongly prefer something else (and "Does not matter" is a bit long to fit into cells, so something different is needed). > ### 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. Your understanding is correct. Perhaps (to emphasize that it is initial IKE SA that is not quantum secure in RFC 8784 and we make it such here): Unlike using PPKs in IKE_AUTH, this specification makes even initial IKE SA quantum secure. If you are OK with this, I'll make the change. Regards, Valery. _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
