I've finished my read through the draft. Note that I didn't give much
scrutiny to the Config or EAP payloads, but I've read over everything
else. A few more comments:
1) There are excessive spaces on the second lines of these list items in
section 2.23:
- If the server is behind a NAT, substitute the IP address in the
TSr entries with the remote address of the IKE SA.
^
- If the client is behind a NAT, substitute the IP address in the
TSi entries with the local address of the IKE SA.
^
2) In section 3.3, this sentence: "If an algorithm that combines
encryption and integrity protection is proposed, it MUST be proposed as an
encryption algorithm and an integrity protection algorithm MUST NOT be
proposed." seems to apply to all protocols, including IKE, and it is more
strict than what we'd agreed to for ticket #122. It is also more strict
than the "MAY" in section 3.3.3. Speaking of ticket #122, the updated
text for that ticket is somehow missing in this draft.
3) In section 3.6: "Certificate payloads SHOULD be included in an exchange
if certificates are available to the sender unless the peer has indicated
an ability to retrieve this information from elsewhere using an
HTTP_CERT_LOOKUP_SUPPORTED Notify payload." This sentence is incoherent
-- I think if the HTTP_... notify was sent you'd still include a
certificate payload, it just wouldn't hold a certificate. I'm probably
not the best person to suggest alternative wording, but perhaps something
like "Certificate payloads SHOULD be used to send entire certificates if
they are ..."
4) Section 3.10.1 -- we should remember to remove "{{ Demoted the SHOULD
}}" before publication.
5) Section 3.13.1, extraneous capitalization:
o Selector Length - Specifies the length of this Traffic Selector
Substructure including the header.
^
6) Section 3.13.1, could probably use a little tweaking to replace
references to "ICMP" with "ICMP, ICMPv6 and MIPv6". Also, the paragraph
containing "This document does not specify how to represent the 'MH Type'
field ..." actually goes on to specify just that.
7) Section 3.14, "The Encrypted Payload, if present in a message, MUST be
the last payload in the message. Often, it is the only payload in the
message." Out of curiosity, do we know of any cases where this payload is
not the only payload in the message? It strikes me as odd to allow for
some payloads prior to this one to be integrity protected but not
encrypted. I suppose since RFC 4306 allows it we don't have a lot of
wiggle room here.
8) Section 4, "Every implementation MUST be capable of responding to an
INFORMATIONAL exchange, but a minimal implementation MAY respond to any
INFORMATIONAL message with an empty INFORMATIONAL reply." Is that true
even if the INFORMATIONAL request contained a Delete payload for a Child
SA?
9) Appendix D -- we need to fill this in.
Scott Moonen ([email protected])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen
From:
Yaron Sheffer <[email protected]>
To:
"[email protected]" <[email protected]>
Date:
12/10/2009 04:05 AM
Subject:
[IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!)
This is to begin a 4 week working group last call for
draft-ietf-ipsecme-ikev2bis-06. The target status for this document is
Proposed Standard, obsoleting RFC 4306 and RFC 4718.
Please send your comments to the ipsec list by Jan. 5, 2010, as follow-ups
to this message.
This is a large document, and arguably the most important document this WG
is entrusted with. The LC period is longer than usual but will include
vacation time for most of us. Nevertheless, please make an effort to
review the entire document, or at least large portions of it. Feel free to
post multiple partial reviews.
In this particular case, we are starting the review with a few open issues
. We will make an effort to close them during the WG LC period.
As a reminder regarding the document’s scope (and our constraints while
reviewing it), I will quote from my mail of Aug. 2008:
General: The goal of the IKEv2 bis document is to clarify the protocol.
The goal is not to extend it. Specifically:
* The document will combine RFC 4306 (IKEv2) and RFC 4718 (IKEv2
clarifications), but no other RFCs.
* The document will add clarifications based on the community's deployment
experience.
* It is OK to correct minor technical errors and contradictions in the
source documents. Any such corrections will be pointed out explicitly -
preferably in an appendix (so that people using the old documents can scan
it to discover problem areas).
* The document will not add any "nice to have" extensions, no matter how
much technical sense they make.
Please clearly indicate the position of any issue in the Internet Draft,
and if possible provide alternative text. Please also indicate the nature
or severity of the error or correction, e.g. major technical, minor
technical, nit, so that we can quickly judge the extent of problems with
the document.
The document can be accessed here:
http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-06
Thanks,
Yaron_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
