Yoav Nir writes:
> Issue #159 - Payload processing order within messages
> =====================================================
> (3.1) Clarify that the text:
> ...
> 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?
That change looks fine for me.
> 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:
I think so.
> 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".
Yes. That change is fine.
> 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.
I agree on that too.
> 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...").
Moving it up is fine.
> Dynamic updates of peers' soucre address: there are cases where a
^^^^^^
typo
> 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.
So the text is same, but you just want to move it out from the bullet
list to normal text paragraph? That is fine for me.
> 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?
Looks good.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
