Hi all. Again we have some more issues:
Issue #147 - Allowing limited retransmission of one-way IKE messages ==================================================================== Either in 2.1 or in 1.5 we should say something about allowing limited retransmission of the rare one-way IKE messages, for reliability. How about the following new paragraph at the end of 2.1: The retransmission policy for one-way messages is somewhat different from that of regular messages. Since no acknowledgement is ever sent, there is no reason to gratuitously retransmit. Since all these messages are errors, it makes sense to send them only once per "offending" packet, and retransmit is further offending packets are received. Still, it makes sense to limit retransmissions of such error messages. Issue #149 - Use of "SA" and "SA pair" ====================================== 2.8: "The responder can be assured that the initiator is prepared to receive messages on an SA if either (1) it has received a cryptographically valid message on the new SA." this should really be "...on the new SA's dual SA" (or better wording thereof) since there's a pair of SAs, and we are determining the state of one based on the other. In general I think we are using the terms SA and SA Pair interchangeably, which is rather confusing. The term "dual SA" does not appear anywhere in the draft. OTOH section 1.4.1 has the term "half of an SA pair". How about The responder can be assured that the initiator is prepared to receive messages on an SA if either (1) it has received a cryptographically valid message on the other half of the SA pair, or (2) ... Issue #165 - Incorrect wording on Transform Attributes ====================================================== 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. I agree with this. How about: The only currently defined attribute type (Key Length) is fixed length; the variable-length encoding specification is included only for future extensions. Attributes described as fixed length MUST NOT be encoded using the variable-length encoding, unless that length exceeds two bytes. Variable-length attributes MUST NOT be encoded as fixed-length even if their value can fit into two octets. NOTE: This is a change from IKEv1, where increased flexibility may have simplified the composer of messages, but certainly complicated the parser. Issue #166 - Clarify INVALID_SELECTORS notification =================================================== 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. I'm pretty sure that this needs to be removed from 2.21.2, but we need alternative text suggestion for 3.10.1. Issue #167 - IPv6 config attributes =================================== 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! Tero suggested we leave the text as-is, and live with the implication that you send the full 128 bits, with only the suffix meaningful (or the prefix being a suggestion). I'm fine with that, so unless someone objects... Please send comments to the list. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
