Hi all. There are only three issues this time, because this is the last batch.
Issue #173 - Trigger packets should not be required =================================================== In a few places in the new section 2.23.1 in IKEv2bis, it says that one must have a trigger packet when starting negotiation. This assumption should be removed so as not to cause new requirements in IKEv2bis: there is no requirement for trigger packets in RFC 4306 or in the rest of IKEv2bis. - "When the client starts creating the IKEv2 SA and Child SA for sending traffic to the server, it has a triggering packet with source IP address of IP1, and a destination IP address of IPN2" should be changed to "...it may have a triggering packet...". - "The first traffic selector of TSi and TSr SHOULD have very specific traffic selectors including protocol and port numbers from the packet triggering the request" should be changed to "...SHOULD have very specific traffic selectors including protocol and port numbers, such as from the packet...". - The same change is made in the third bullet of the client list near the end of the section. I fully agree with this, and I think the document should be updated as suggested here. Moreover, section 2.9 describes the SINGLE_PAIR_REQUIRED error notification. Obviously you can't have both a trigger packet and a single_pair, so one of them should go. Trigger packets are at best recommended, not mandatory. Issue #174 - How to behave when EAP identity is not send by AAA =============================================================== In ikev2bis07 ----- ikev2-bis-07 section 2.16, last paragraph ------------ When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for AAA routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method. It is important that policy look ups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder. In this case, the authenticated identity has to be sent from the AAA server to the IKEv2 responder. It says the authenticated EAP identity "has to" be send from AAA server, my interpretation and implementation "has to" is obvious MUST. If AAA doesn't send the authenticated EAP identity, what should be the behavior? Also, what if AAA server EAP server is not AAA server? There has been a lively discussion about this (a thread titled "Regarding EAP identity"). I can't say that the thread reached any firm conclusion, but a lot of ground has been covered about how AAA servers work, and about whether or not they communicate to the server something other then identity, such as policy. Despite the fact that the second A in AAA stands for "authorization", it was generally agreed that it is still the job of the IKE gateway to enforce policy, and if that policy comes from a AAA server, that is totally outside the scope of this document. So in conclusion, how about replacing "the authenticated identity has to be sent" with "the authenticated identity, if different from that in the IDi payload, has to be sent..." ? Would that satisfy everyone? Issue #175 - Better wording for NAT mobility issues =================================================== The last bullet in 2.23 is confusing. A proposed rewrite is: Old: 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. New: 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). This will be apparent to a host if it receives a packet whose integrity protection validates, but has a different port, address, or both from the one that was associated with the SA in the validated packet. When such a validated packet is found, a host that does not support other methods of recovery such as MOBIKE [MOBIKE], and that is not behind a NAT, SHOULD send all packets (including retransmission packets) to the IP address and port in the validated packet, and SHOULD store this as the new address and port combination for the SA (that is, they SHOULD dynamically update the address). A host behind a NAT SHOULD NOT do this type of dynamic address update if a validated packet has different port and/or address values because it opens a possible denial of service attack (such as allowing an attacker to break the connection with a single packet). 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. No discussion, but I like the change. Anyone objects? _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
