I am reviewing this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Feel free to forward to any appropriate forum.
This document specifies an extension to IKEv2 supporting the case where the accepting end of an IPsec Security Association wants to redirect the initiating end to connect to a different address than the one it tried first. Uses include connections to a server or gateway that wants to balance the load among several equivalent instances, finding the closest instance with Anycast addresses and then redirecting the a fixed address, dealing with the orderly shutdown of a replicated service or gateway, and supporting IPv6 mobility. The document specifies how to do the redirection at three different protocol stages: during connection establishment before the client authenticates to the server, during connection establishment after authentication but before an ESP or AH security association is established, or after protected traffic has already started flowing. I found no security problems with the protocol. There does appear to be one critical missing piece of functionality, however. I would expect that any protocol that has clients connecting to gateways should work through NATs. The protocol specified in this document does not say how to do that, though the changes would be fairly simple and (I would think) non-controversial. It's possible that they are considered "obvious" and that this protocol is intended to be used with NATs, but I doubt it. There may have been some previous discussion of this on the IPsec list that I missed. Had I been involved with the design, there are some other suggestions I would have made. It's late in the process now, so feel free to rule them out of order for lateness, but I can't resist stating them: 1) If the initiator of the connection requests and obtains an "inner" IP address from the gateway, then in order to switch to a different gateway without tearing down existing TCP connections it would need to get that same IP address assigned by the new gateway. For a graceful transition from old to new, the initiator would want to make the new IKE connection before breaking the old one. But the new gateway cannot safely allocate the same IP address while the old connection is still open unless it somehow knows that it is talking to the same client and that a transition is in progress. It would seem desirable to put some indicator in the protocol to signal that case. Otherwise, IPv6 mobility and any other gateway move is going to be very disruptive for clients. 2) To deal with gateways that are behind NATs, it would seem helpful for redirection to be able to specify not just the new IP address but also the new port. If the port were other than 500, the initiator should assume it should use the UDP encapsulation protocol rather than ESP or AH directly. 3) The cookie and alternate Diffie-Hellman group negotiations are designed to take place in parallel to avoid extra round trips. It might be desirable to integrate IP redirection into the same exchange for the same reason. That way the initial message pair could do any subset of the three functions. 4) This document creates a new IANA registry for "GW Ident Type" (gateway identifier type) with three values: IPv4 address, IPv6 address, and DNS name. I would have instead reused the existing registry "ID type" and restrict the value to one of those three values in this context. I also would have had a two byte length for the gateway identifier. There may already be some architectural limit of 255 octets for a DNS name, but what with internationalization and other such things, I wouldn't wire it into a new protocol. 5) The spec seems a little squishy on the question of whether redirection only changes the address at which to find the gateway or whether it also affects the authenticated name (in other words, whether a redirection from gateway1.example.com to gateway27.example.com means that the client should now accept a certificate containing the name gateway27.example.com. It is pretty clear that in the first (unauthenticated) redirection type, accepting a new name would clearly be unacceptable because it would trivially allow gateway spoofing. But when it occurs after the first gateway has authenticated, the appropriate policy is less clear. I couldn't figure out whether it was disallowed in all cases or not. Some more minor issues: 1) First line of abstract: "IKEv2 is a protocol for setting..." -> "IKEv2 is a protocol that can be used for setting..." 2) Last two lines of page 2: "The gateway MUST keep track of those clients that indicated support..." This statement is only true for gateways that themselves support redirection. If they don't, they can ignore such indicators. 3) Middle of page 6: "one of the VPN gateway." -> "one of the VPN gateways." 4) Section 7 (Handling Redirect Loops): This section mandates a default maximum number of redirects and a default time limit over which that default applies. The IKEv2 spec goes out of its way to never specify such counts and timeouts, because the appropriate values are scenario dependent and the protocol is designed so that the values never affect interoperability. In this case, the values chosen still do not affect interoperability. I would recommend that the spec recommend these values rather than mandate them as defaults. 5) This document defines some new IANA code points but calls for others to be assigned by IANA. Unless there is some convention to the contrary or other good reason, I'd propose values for all of the code points rather than expecting the RFC editor to do it as the document is made into an RFC. This makes life simpler for the RFC editor and makes it possible to implement prototypes before the spec is advanced. 6) Middle of page 5: "cannot also" -> "also cannot" 7) Last sentence of section 11: "and should be done" -> "and redirection should be done"
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
