Hi Vijay, Here's a bunch of comments on the latest draft, some minor, some not so minor.
Thanks,
Yaron
- 1: During during -> during
- 1: Can be also be -> can also be
- 3: I suggest to start this section with an exhaustive list of locations
where the Redirect payload can occur (IKA_SA_INIT response, IKE_AUTH last
response, Informational from gateway).
- 3: "The VPN client indicates support for the IKEv2 redirect mechanism by
including..." -> By including ..., the VPN client indicates that it supports
the IKEv2 redirect mechanism and that it is willing to be redirected.
- 3: "It initiates a new IKE_SA_INIT exchange with the VPN gateway listed in
the REDIRECT payload", add: "provided this is allowed by its IPsec policy".
- 3: The last paragraph (re: MIP6) is out of context here, and I was unable
to understand it. I suggest to clarify and extend it into a separate
section.
- 5: "If the gateway decides to redirect the client during the IKE_AUTH
Exchange..." - this should start a new section.
- Same paragraph: add "The gateway MUST verify the client's AUTH payload
before sending the Redirect payload, and the client MUST verify the
gateway's AUTH payload before acting on the Redirect payload."
- "In case the IKE_AUTH exchange involves EAP authentication" - add: "The
gateway MUST NOT send and the client MUST NOT accept a redirect in any
earlier message."
- 6.2: Now that we've appended the nonce, we should signal the length of the
Identity field explicitly (possibly by stealing 1 octet from the Identity
Type). Even though the client can theoretically compute it using the length
of the expected nonce.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
