Skip to main content

Last Call Review of draft-ietf-ipsecme-ikev2-redirect-
review-ietf-ipsecme-ikev2-redirect-secdir-lc-kaufman-2009-09-10-00

Request Review of draft-ietf-ipsecme-ikev2-redirect
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-07-01
Requested 2009-06-22
Authors Kilian Weniger , Vijay Devarapalli
Draft last updated 2009-09-10
Completed reviews Secdir Last Call review of -?? by Charlie Kaufman
Assignment Reviewer Charlie Kaufman
State Completed
Review review-ietf-ipsecme-ikev2-redirect-secdir-lc-kaufman-2009-09-10
Completed 2009-09-10
review-ietf-ipsecme-ikev2-redirect-secdir-lc-kaufman-2009-09-10-00
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”