1.7: This also lead to -> This also led to
2.21.: EAP Failure cases are missing altogether. Also, the first paragraph says
that if an auth failure occurs at the responder, AUTHENTICATION_FAILED is
included in the protected response (to IKE_AUTH), while the last paragraph says
it's a separate Informational exchange.
1.3.2 and 2.18 (IKE SA rekey) have lots of overlap. If we don't consolidate
them, we should at least have them reference one another.
2.19: grammar: "it simply causes the Child SA creation *to* fail".
2.21.2: grammar: "in case an error happened *in* when processing"
2.23: what do we mean by this - "In addition, firewalls may be configured to
pass IPsec traffic over UDP but not ESP/AH or vice versa"? This would be less
confusing: "In addition, firewalls may be configured to pass UDP-encapsulated
IPsec traffic but not plain, unencapsulated ESP/AH or vice versa".
2.23: "The recipient of either the NAT_DETECTION_SOURCE_IP or
NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied value to a
SHA-1 hash of the SPIs, source IP address, and port, and if they don't match it
SHOULD enable NAT traversal. In the case there is a mismatch of the
NAT_DETECTION_SOURCE_IP hash with all of the NAT_DETECTION_SOURCE_IP payloads
received, the recipient MAY reject the connection attempt if NAT traversal is
not supported." In the first sentence, the comparison is not just with the
source address/port. Also, while NAT-T is a MAY, once you decide that you
implement NAT-T, this comparison becomes at least a SHOULD. "If they don't
match it SHOULD enable NAT-T" contradicts an earlier MUST: "if a NAT is
detected, both devices MUST send UDP encapsulated packets". And the second
sentence doesn't make sense as pointed out before - if you recognize these
payloads, then obviously you support NAT-T. Overall, the normative part of this
section needs to be reworked.
2.23: replace the second-last bullet with a pointer to the subsequent
subsection, on Transport Mode and NAT.
2.23: the last bullet (automatically updating the peer's IP address) is too
important to be only mentioned as a side note. We should at least mention it in
Sec. 2.6, following the sentence: "Incoming IKE packets are mapped to an IKE SA
only using the packet's SPI, not using (for example) the source IP address of
the packet."
2.24: what's this section (ECN) doing here? It is 100% IPsec, nothing to do
with IKE. If there's a reason, let's explain it in the text.
3.1: "The Recipient SPI in the header identifies an instance of an IKE security
association. It is therefore possible for a single instance of IKE to multiplex
distinct sessions with multiple peers." In fact it's more than that, you can
have multiple sessions with one peer! So I would rephrase: "The Recipient SPI
in the header identifies an instance of an IKE security association. It is
therefore possible for a single instance of IKE to multiplex distinct sessions
with multiple peers, including multiple sessions per peer."
3.2: grammar: "by appending it" -> "by appending them" (or "each one").
3.2, "Next Payload": we say that the Encrypted payload gets a different Next
Payload value. But then, we should also say (here or where describing the
Encrypted payload) that the last *contained* payload gets a zero Next Payload
value.
3.3.2: Tiger - we closed issue #33, but according to the text of the issue,
should have left the algorithm "unspecified". Which I think would be much more
accurate.
3.3.5: "Attributes described as fixed length MUST NOT be encoded using the
variable-length encoding." This cannot be correct, a new 4-octet attribute will
have to be encoded as variable-length. It won't fit into the other format.
3.3.6: "The initiator of an exchange MUST check that the accepted offer is
consistent with one of its proposals, and if not that response MUST be
rejected." We are not specifying how to reject such erroneous responses, so why
not say: "The initiator of an exchange MUST check that the accepted offer is
consistent with one of its proposals, and if not MUST terminate the exchange".
3.3.6: we somehow never say what you do when you receive a Transform ID (i.e.
protocol) that you don't understand. This can be added to 3.3.6. E.g., change
"Similarly, if the responder receives a transform that contains a Transform
Attribute it does not understand..." to "Similarly, if the responder receives a
transform that it does not understand, or one that contains a Transform
Attribute it does not understand...".
3.5: "IPv6-only implementations MAY be configurable to send only ID_IPV6_ADDR."
We probably don't mean it, but rather: "IPv6-only implementations MAY be
configurable to send only ID_IPV6_ADDR, rather than ID_IPV4_ADDR, in addition
to the other three types."
3.6: "DNS Signed Key" is marked Unspecified. Is it not RFC 4025? It's not used
anywhere, but still...
3.6: [Hash and URL] "makes IKE less subject to denial of service attacks that
become easier to mount when IKE messages are large enough to require IP
fragmentation." This statement is hard to take seriously. When the certificate
is NOT cached, this encoding eliminates a difficult-to-perform DOS attack,
replacing it with a much easier one: stop the endpoint from obtaining the cert.
3.6: clarification, replace "Use the following ASN.1 definition for an X.509
bundle" by "The "Hash and URL of a bundle" type uses the following ASN.1
definition of an X.509 bundle:"
3.7: "If multiple CAs are trusted and the certificate encoding does not allow a
list, then multiple Certificate Request payloads would need to be transmitted."
This doesn't make sense: we are not sending the cert itself here. we're just
sending an encoding on a CA. Moreover, the text further down indicates that the
CA field is *always* a list - at least for the defined cert types (4, 12, 13).
Overall, this looks like a placeholder, and I suggest to delete the sentence.
3.9: "The size of a Nonce" -> "The size of the Nonce Data".
3.10.1: "in any case where the offered proposal" -> "... proposals".
3.10.1: INVALID_SELECTORS is underspecified. It should be rate limited (I
suppose), also, how long is the packet fragment included in the notification?
In addition, Sec. 2.21.2 implies that it is sent during Child SA negotiation,
which is not what 3.10.1 is saying.
3.14: "denoted SK{...} or E in this document" -> "denoted SK{...} in this
document."
3.15: "type length values" -> "Type Length Value (TLV) structures".
3.15.1: "With IPv6, a requestor MAY supply the low-order address octets it
wants to use." This means to me that you *don't* provide all 16 octets. But
according to the table, the field is a fixed-length 16 octets!
3.15.2: "is in CFG_REQUESTs is unclear" - delete the first "is".
3.16: the text here, "...this field MAY be set to any value" implies that the
Identifier field can be constant, e.g. always zero. But this would contradict
RFC 3748, that says:
In order to avoid confusion between new Requests and retransmissions, the
Identifier value chosen for each new Request need only be different from the
previous Request, but need not be unique within the conversation. One way to
achieve this is to start the Identifier at an initial value and increment it
for each new Request. Initializing the first Identifier with a random number
rather than starting from zero is recommended, since it makes sequence attacks
somewhat more difficult.
4: what do we mean by "Ability to support various types of legacy
authentication"? If we mean, "Ability to support EAP-based authentication",
let's say so.
5: what do we mean by "leaves all SAs vulnerable to ... overrun of either
endpoint"?
5: unfortunately we have to revise the text about group strengths - or remove
it altogether. It is non-normative, so it's probably best to eliminate it.
6: the are not -> they are not.
B.1 (Group 1): We may want to add: "Use of this group is NOT RECOMMENDED."
C: I suggest to repeat at the top of this appendix this text from 2.5:
"Although new payload types may be added in the future and may appear
interleaved with the fields defined in this specification, implementations
SHOULD send the payloads defined in this specification in the order shown in
the figures in Sections 1 and 2; implementations MUST NOT reject as invalid a
message with those payloads in any other order."
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
