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

From: RJ Atkinson <[email-masked]>
Date: Wed, 19 Sep 2012 15:12:15 -0400

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.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 20 Sep 2012 02:22:05 +0000

Hi, Ran

Thanks a lot for the detailed clarification of the IPSEC renumbering issue. I think it is fully clear now.

But I think what Di and Marc argued is that, they might found in their cases, the FQDN ability was not easy to enable, which may caused by various deployment/implementation issues. Especially in the Not-well-managed networks, the issue may be common.
If I understood them correctly. I think we need to emphasize the IPSEC FQDN as a BCP in the draft-ietf-6renum-enterprise-scenarios, we can add some more description according to your detailed comments below.

So, may I ask Di and Marc's opinions about it?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> RJ Atkinson
> Sent: Thursday, September 20, 2012 3:12 AM
> To: [email-masked]
> Subject: Re: [renum] I-D Action: draft-ietf-6renum-gap-analysis-03.txt
> 
> 
> Earlier Di Ma wrote:
> > "connection" that cannot function after the change of the involved
......

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 20 Sep 2012 07:30:13 -0400

On 19  Sep 2012, at 22:22 , Liubing (Leo) wrote:
> But I think what Di and Marc argued is that,
> they might found in their cases, the FQDN ability
> was not easy to enable, which may caused by various deployment/implementation issues.

It really is very easy to enable in products from
multiple vendors (e.g. Netscreen, Cisco, Juniper).

In any case, both "ease of use" and "user interface"
are outside the usual scope of the IETF.

The big issue appears to be that folks don't realise
why using FQDN is better than IP addresses -- which
is why RFC 5887 talked about this.

Yours,

Ran

---

From: "Di Ma" <[email-masked]>
Date: Fri, 21 Sep 2012 03:56:58 +0800

Hi, Ran,
 
Thank you very much indeed for your detailed comments. You have provided plenty of valuable information. Yet in my previous mail, what I was trying to say is that IPSec itself is an address-based connection, which, by the way, has nothing to do with the methods IKE employs to identify the peers negotiating SA parameters. 
 
Conspicuously, non-IP-address identifiers such as FQDN can help IPSec participants to exchange notes, and with IKE IPSec endpoints can recover automatically as you mentioned. The reason why I threw the IPSec issue in the category of network renumbering is that at some specific circumstances IPSec SA parameters, as IP address oriented, can be configured in a better way other than IKE (v2) to go with renumbering events.
 
By the virtue of specific network operations, SA configuration management could be fancied in an optimized way. Customer Premises Network (CPN) offers a scenario where the configuration of SA parameters for specific IPSec participants can be integrated into IP address assignment. As widely observed, some CPN services such as DNS recursive resolution service, SIP proxy service, are expected to have integrity and confidentiality protection. That is, from the point of view of a user host, SA parameters bound to DNS recursive name server or SIP server, can be considered undifferentiated with other network parameters, such as IP address of the user host, default gateway address, that are commonly configured via DHCP.
 
Since the IPSec is address-oriented and the DHCP server is responsible for IP address configuration, we might as well integrate IPSec SA parameters configuration into IP address assignment by extending DHCP where the IP address configuration node (DHCP server) plays like an “administrator” using DHCP to configure IPSec SA parameters in a host, after it, in deputy of the host, has negotiated with a CPN server the very host wants to establish IPSec with.  Consequently, after the renumbering event, the user host can get a new IP address and new SA parameters piggybacked via DHCP messages.
 
To be exact, in this scenario, the user host will be a SA establishment initiator and the DHCP server will serve as the deputy for the user host to negotiate SA parameters with the CPN server such as DNS recursive name server, SIP server, etc. The superiority of granting SA management to DHCP server is that the SA negotiation will be simplified based on the preconfigured trust relationship between the DHCP server and other CPN servers, since in regular CPN scenarios, the DHCP server and CPN servers are usually at the same administration domain, sometimes even integrated in the same device, which makes the IKEv2 authentication exchanges unnecessary.  Secure tunnels, such as HTTPS or other secure protocols with less rounds could be easily applied to protect the communication between the DHCP server and CPN server when needed.  
 
Once the very method is realized, the IPSec SA negotiation is transparent to user hosts especially the handheld devices that are considered as “thin clients”. The user host tells the configuration entity, DHCP server for instance, it wants to know the IP address of DNS recursive name server and it wants to employ IPSec to secure the “DNS last mile”, then via some processes at the side of the access network, it gets the IP address (es) of the DNS server and the SA parameters it needs to configure to establish IPSec with the very DNS server. 
 
Recently we are working on the design and a draft is going to be submitted soon. 

Yours,
Di Ma

China Internet Network Information Center （CNNIC）
Tel: (8610)-58813216
Mobile:(86)-18611718301
Https://www.cnnic.cn
Add: 4, South 4th Street, Zhongguancun
Haidian District, Beijing
P.R.China 100190
POB: Beijing 349, Branch 6
____________________________________________________

From: RJ Atkinson
Date: 2012-09-20 19:30
To: renum

Yours,

Ran

_______________________________________________
renum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/renum

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 21 Sep 2012 07:11:23 -0400

On 20  Sep 2012, at 15:56 , Di Ma wrote:
> Since the IPSec is address-oriented...

We continue to disagree about this.

> ...and the DHCP server is responsible for IP address configuration,
> we might as well integrate IPSec SA parameters configuration into
> IP address assignment by extending DHCP where the IP address
> configuration node (DHCP server) plays like an “administrator”
> using DHCP to configure IPSec SA parameters in a host, after it,
> in deputy of the host, has negotiated with a CPN server the
> very host wants to establish IPSec with.  

This seems very unwise for any IETF standards work,
from multiple perspectives.  A quick subset of examples,
each by itself sufficient to illustrate why this would
be unwise, follow:

* A very basic one is that one would not want to standardise 
  the trust model issues that such an approach would create.

  EXAMPLE:
  While I might trust the DHCP server at the coffee shop
  for the limited function of assigning an IP address and
  conveying minimally essential IP-layer information to my
  laptop, I definitely DO NOT trust the coffee shop network
  or its infrastructure components (e.g. DHCP server).  So
  when I would begin work, I would always want to directly
  secure the communications channel between my laptop and
  my workplace -- without ANY intermediaries.

* Related to that, user security and privacy would be 
  compromised by such centralisation and the delegation 
  implied by "in deputy of the host".  

  EXAMPLE:
  Basically, the proposal would be to standardise use of any
  DHCP server as an attacker for an automated "man in the middle" 
  attack.  I see zero chance of the IETF Security Area
  approving this.

* DHCP is not suitable for key management, while the above
  proposes using DHCP to manage keys (IPsec SAs).

Given these issues, and previous notes in this thread explaining
how IPsec-related renumbering works today, it is not obvious that 
the contents of your note are appropriate for this gap analysis 
document.  

Yours,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Sep 2012 13:27:20 +0100

> We continue to disagree about this.

Put it this way. The community needs to change its bad habit of using IPSec
in an address-oriented way, and renumbering is one of the main reasons
for that. So it is 6renum's job to strongly recommend the change.

It remains true, of course, that even if an SA survives renumbering,
the transport session running over that SA will also have to be renumbered,
but that's a separate problem.

   Brian

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 21 Sep 2012 09:16:20 -0400

On 21  Sep 2012, at 08:27 , Brian E Carpenter wrote:
> Put it this way. The community needs to change its bad habit
> of using IPSec in an address-oriented way, and renumbering
> is one of the main reasons for that. So it is 6renum's job
> to strongly recommend the change.

I fully agree.

Ran