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

["Di Ma" <[e-mail]>]

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: [phone]
Mobile:[phone]
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
Subject: Re: [renum] I-D Action: draft-ietf-6renum-gap-analysis-03.txt

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


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