Hi. Another week, another 5 issues to discuss.
Issue #159 - Payload processing order within messages
=====================================================
(3.1) Clarify that the text:
Payloads are processed in the order in which
they appear in an IKE message by invoking the appropriate processing
routine according to the "Next Payload" field in the IKE header and
subsequently according to the "Next Payload" field in the IKE payload
itself until a "Next Payload" field of zero indicates that no
payloads follow.
does NOT mean strict left-to-right processing within the message. This is just
initial parsing, and further payload processing can be in any order.
It's clear to me from the surrounding text, that this means that the next
payload field is used to *identify* the payloads, and this is the meaning of
"process" here, rather than "act upon". So how about:
Payloads are identified in the order in which
they appear in an IKE message by looking in the "Next Payload" field in
the IKE header, and subsequently according to the "Next Payload" field
in the IKE payload itself until a "Next Payload" field of zero indicates
that no payloads follow.
Does this clarify it for everyone?
Issue #161 - Contradiction re: authentication failure
=====================================================
2.21: 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.
I think this has already been fixed, no? Here's the text:
2.21. Error Handling
There are many kinds of errors that can occur during IKE processing.
The general rule is that if a request is received that is badly
formatted, or unacceptable for reasons of policy (such as no matching
cryptographic algorithms), the response contains a Notify payload
indicating the error. The decision whether or not to send such a
response depends whether or not there is an authenticated IKE SA.
If there is an error parsing or processing a response packet, the
general rule is to not send back any error message because responses
should not generate new requests (and a new request would be the only
way to send back an error message). Such errors in parsing or
processing response packets should still cause the recipient to clean
up the IKE state (for example, by sending a DELETE for a bad SA).
Only authentication failures (AUTHENTICATION_FAILED) and malformed
messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without
requiring an explicit INFORMATIONAL exchange carrying a DELETE
payload. Other error conditions MAY require such an exchange if
policy dictates that this is needed.
Issue #162 - Clarifying NAT-T
=============================
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.
I think there are two issues here. The first is with the text "SPIs, source IP
address, and port", when referring to both SOURCE_IP and DESTINATION_IP. I
think this can be resolved by replacing it with "SPIs, source or recipient IP
address respectively, and port".
The other issue is with the apparent contradiction with the MUSTs and the
SHOULDs. I disagree with that. Although NAT-T is a MAY, it makes sense even for
implementations that don't support it to recognize the detection payloads. An
implementation that does not support NAT-T should really fail the creation of
an IKE SA if NAT is there, because IPsec will not work. Using the detection
payloads is a good way to find this out. So:
- the recipient MAY compare (because NAT-T is optional)
- SHOULD enable NAT Traversal (not MUST because maybe NAT-T is not supported,
only detection)
- MAY reject the connection attempt in NAT-T is not supported.
The text doesn't specifically refer to such semi-supporting implementations,
and the whole normative part actually refers only to implementations that
support NAT-T. Reading it over, it does sound a little clumsy, but I don't see
how an implementer could get it wrong. Unless there is some alternative text
for this entire section, I suggest we leave it as is.
Issue #163 - Emphasize dynamic source address update
====================================================
Replace the last bullet in 2.23 by the slightly reworded paragraph, which I
suggest to move up (before the paragraph "The specific requirements...").
Dynamic updates of peers' soucre address: there are cases where a NAT box
decides to remove mappings that are still alive (for example, the keepalive
interval is too long, or the NAT box is rebooted). To recover in these cases,
hosts that do not support other methods of recovery such as MOBIKE [MOBIKE],
and that are not behind a NAT, SHOULD send all packets (including
retransmission packets) to the IP address and port from the last valid
authenticated packet from the other end (that is, they should dynamically
update the address). A host behind a NAT SHOULD NOT do this because it opens a
possible denial of service attack. Any authenticated IKE packet or any
authenticated UDP-encapsulated ESP packet can be used to detect that the IP
address or the port has changed. When IKEv2 is used with MOBIKE, dynamically
updating the addresses described above interferes with MOBIKE's way of
recovering from the same situation. See Section 3.8 of [MOBIKE] for more
information.
Also, append to the sentence (in 2.6): "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." this text: "Refer to Sec. 2.23 for cases where an IKE
endpoint needs to handle dynamic change of a peer's IP address."
Not much discussion here, except for a posting by Paul on February 2nd, which
didn't actually address the issue. only the section. I have no problem
accepting this change or leaving it out. Let's hear from the rest of the WG.
Issue #164 - Next Payload header of last contained (encrypted) payload
======================================================================
Change the sentence: "In the header of an Encrypted payload, the Next Payload
field is set to the payload type of the first contained payload (instead of
0)." to "In the header of an Encrypted payload, the Next Payload field is set
to the payload type of the first contained payload (instead of 0); conversely,
the Next Payload field of the last contained payload is set to zero."
I'm fine with this change. Others?
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
