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

From: [email-masked]
Date: Mon, 03 Sep 2012 20:37:58 -0700

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/

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 4 Sep 2012 03:44:18 +0000

A new version with minor editorial modifications are submitted. Your review and comments are appreciated.

Best regards,

Sheng

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of [email-masked]
>Sent: Tuesday, September 04, 2012 11:38 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: [renum] I-D Action: draft-ietf-6renum-gap-analysis-03.txt
>
>
>_______________________________________________
>renum mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/renum

---

From: "Di Ma" <[email-masked]>
Date: Fri, 14 Sep 2012 11:00:04 +0800

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
Date: 2012-09-04 11:44
To: [email-masked]; [email-masked]
CC: [email-masked]
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

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 14 Sep 2012 09:19:45 +0000

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: [email-masked] [mailto:[email-masked]] 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

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.

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

From: Sheng Jiang<mailto:[email-masked]>
Date: 2012-09-04 11:44
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>
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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Sep 2012 14:09:08 +0100

It is a good point to mention. As far as I can tell, there is no solution;
sessions using address-based SAs will need to renegotiate (just like
a TCP or TLS session, in fact).

See RFC 5887, however, which gives the solution for the VPN application
of IPsec (use FQDN-based SA).

I noticed that RFC 4192 doesn't mention IPsec!

Regards
   Brian

On 14/09/2012 10:19, Liubing (Leo) wrote:
> 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 re
numbering 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.
> ------------------------------------------------------------------------
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 17 Sep 2012 06:49:15 +0000

Hi, Brian

Thanks for your comment. 
I also noticed the FQDN-based solution in RFC5887, it is a good candidate solution.

But the problem itself is indeed a gap need to be mentioned in the draft. If there's no objection, I'll include it in the revision.

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Friday, September 14, 2012 9:09 PM
> To: Liubing (Leo)
> Cc: madi; Sheng Jiang; 6renum
> > 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
> >
> Of Di Ma
> > 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 re
> numbering 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.
> >
> >
> > To: [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>