Re: [renum] I-D Action: draft-ietf-6renum-gap-analysis-03.txt

[RJ Atkinson <[e-mail]>]

Earlier Di Ma wrote:
> Yet as a document providing a basis for future works that identify
> and develop solutions or to stimulate such development as appropriate,
> this draft might make IPSec Security Association (SA) management
> included, considering IPSec SA is a kind of IP address oriented
> “connection” that cannot function after the change of the involved
> IP addresses, which means extra configuration of SA parameters
> is inevitable after network renumbering.

In general, the above is NOT correct with regard to IPsec.

I wrote the IPsec specs (e.g. RFC-1825 et seq) and was,
for a time, IPsec WG Co-Chair.  I'm also the person who 
insisted upon having non-IP-address identities defined 
in the specs, not because of renumbering, but because of
the more general issue of different users wanting to use
different identity types.

IF AND ONLY IF, one configures IKE (either v1 or v2) 
to use the IP Address based identifiers (e.g. ID_IPV4_ADDR,
ID_IPV6_ADDR), then Di Ma's text is correct.

HOWEVER, if one configures IKE (either version) to use
non-address identifiers (e.g. ID_FQDN, ID_USER_FQDN) [1], 
then Di Ma's description above is NOT correct.  In that case, 
what happens is that when any IP address changes, the 
IPsec endpoints recover automatically, thereby making 
IPsec use resilient in the presence of renumbering.

I have personally relied upon this capability for many years,
dating back at least to 2001.  Circa 2001, the ID_USER_FQDN
and ID_FQDN identity types were being used with IKEv1 between 
a very small Netscreen box connected to the DOCSIS cable modem 
in my house and a larger VPN box at my (then) employer across 
the country.  The Cable-ISP regularly renumbered the IPv4 
address for my CPE, using DHCPv4, which changed the IPv4 
address of the public-side of the Netscreen box, yet the 
IPsec VPN tunnel was resilient, requiring no intervention 
from me to remain alive/available.

> Pre-shared key method cannot be used with mobile systems 
> or systems that may be renumbered, unless the renumbering 
> is within the previously determined range of IP addresses.

I also have used pre-shared keys with ID_USER_FQDN between
a mobile laptop (home, coffee shop, office) and an employer's 
VPN box.  So that also works just fine -- and has done 
for a decade or longer.  

One can find a renumbered "employer VPN box" simply by 
using DNS KX records from RFC-2230.  A simplified example 
of how the DNS records might look is provided below 
(caveat: I might have mistyped the DNS syntax):

	example.com         IN KX 5  vpn-box.example.com
	vpn-box.example.com IN A     <IP address here>

Of course, use of KX records ought to be authenticated
via DNS Security, but that (separately) is widely
available today (and has rapidly growing deployment).

> Also, when pre-shared key is employed, IKEv2 computations 
> cannot be offloaded to the attached hardware.

The above might be true for a particular implementation,
but it is not true in general for all implementations.
Better quality implementations simply do not have this
property.  


Accordingly, I object to the inclusion of the text that
Di Ma has proposed, on grounds that it is not correct.

Yours,

Ran

[1]  I've used RFC-4306 terminology above.  The same
     capability exists in IKEv1, but uses slightly
     different terminology (e.g. ID_USER_FQDN rather
     than ID_RFC822_ADDR).  See RFC-2407, Section 4.6.2.1,
     which dates back to 1998, and was widely supported
     in commercially available products by 2000.