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

Hi, Di
Thanks for your review and the new contribution.
Personally, I think the issue you pointed out is worth to be documented. If the IP addresses are renumbered, the SA would be definitely broken. But I would like to hear the  co-authors' and the WG's opinions about it, since it is been under WGLC.
For the texts, I think it may need to be simplified, especially the IKEv2 relevant details may confuse people that it is talking about a IKEv2 gap, but in fact it is about SA.

B.R.
Bing

From: renum-bounces@ietf.org [mailto:renum-bounces@ietf.org] On Behalf Of Di Ma
Sent: Friday, September 14, 2012 11:00 AM
To: Sheng Jiang
Cc: 6renum
Subject: Re: [renum] I-D Action: draft-ietf-6renum-gap-analysis-03.txt

I am in favor of moving forward this work.

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.

So, I propose adding some words into this draft as Section 8.3 (IPSec SA Management), a sector of Section 8 (Miscellaneous), which is described as follows:

Network renumbering events get networking mechanisms that are bound to IP addresses, or applications using specific IP addresses, involved. As defined in [RFC4301], IPSec Security Association (SA), as a kind of IP address oriented "connection", cannot function after the change of the involved IP addresses, which means extra configuration of SA parameters is inevitable after network renumbering.

SA is a "connection" that provides security services to the traffic carried by it and details the key and algorithm that the IPSec connection relies on. SA can be established with manual configuration by the administrator. IKEv2 [RFC5996] eliminates manual reconfiguration. It employs two rounds of message exchanges. The first exchange of messages establishes a trust relationship between the two IKEv2 participants. This exchange uses two authentication methods, digital signature and pre-shared key. The digital signature method needs certificate management. If the participants are not configured with the same trust anchor, certificate-based IKEv2 cannot be realized. While the pre-shared key method is the simpler of the authentication methods for IKEv2 and pre-shared keys are tied to particular IP addresses, unlike public key certificates used by digital signature method. 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. Also, when pre-shared key is employed, IKEv2 computations cannot be offloaded to the attached hardware. Therefore, pre-shared key method fails to be a pure automatic one and does not go well with network renumbering. A mechanism that is able to integrate SA management into IP address assignment in an automatic and an adaptive manner is desired to go with network renumbering.

________________________________
Di Ma
CNNIC Advanced Research Department
___________________________________________________
China Internet Network Information Center
Tel: (8610)-58813216
Https://www.cnnic.cn
Add: 4, South 4th Street, Zhongguancun
Haidian District, Beijing
P.R.China 100190
POB: Beijing 349, Branch 6
____________________________________________________

From: Sheng Jiang<mailto:jiangsheng@huawei.com>
Date: 2012-09-04 11:44
To: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>; i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>
CC: renum@ietf.org<mailto:renum@ietf.org>
Subject: Re: [renum] I-D Action: draft-ietf-6renum-gap-analysis-03.txt
A new version with minor editorial modifications are submitted. Your review and comments are appreciated.

Best regards,

Sheng

>-----Original Message-----
>From: renum-bounces@ietf.org [mailto:renum-bounces@ietf.org] On Behalf
>Of internet-drafts@ietf.org
>Sent: Tuesday, September 04, 2012 11:38 AM
>To: i-d-announce@ietf.org
>Cc: renum@ietf.org
>Subject: [renum] I-D Action: draft-ietf-6renum-gap-analysis-03.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IPv6 Site Renumbering Working Group of the
>IETF.
>
> Title           : IPv6 Site Renumbering Gap Analysis
> Author(s)       : Bing Liu
>                          Sheng Jiang
>                          Brian Carpenter
>                          Stig Venaas
> Filename        : draft-ietf-6renum-gap-analysis-03.txt
> Pages           : 20
> Date            : 2012-09-03
>
>Abstract:
>   This document briefly introduces the existing mechanisms could be
>   utilized by IPv6 site renumbering and tries to cover most of the
>   explicit issues and requirements of IPv6 renumbering. Through the gap
>   analysis, the document provides a basis for future works that
>   identify and develop solutions or to stimulate such development as
>   appropriate. The gap analysis is presented following a renumbering
>   event procedure clue.
>
>
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-6renum-gap-analysis
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-6renum-gap-analysis-03
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=draft-ietf-6renum-gap-analysis-03
>
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>renum mailing list
>renum@ietf.org
>https://www.ietf.org/mailman/listinfo/renum
_______________________________________________
renum mailing list
renum@ietf.org
https://www.ietf.org/mailman/listinfo/renum