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

[Brian E Carpenter <[e-mail]>]

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:
> 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: [e-mail] [mailto:[e-mail]] 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 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.
> 
> 
> ________________________________
> Di Ma
> CNNIC Advanced Research Department
> ___________________________________________________
> China Internet Network Information Center
> Tel: [phone]
> 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:[e-mail]>
> Date: 2012-09-04 11:44
> To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> CC: [e-mail]<mailto:[e-mail]>
> 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: [e-mail] [mailto:[e-mail]] On Behalf
>> Of [e-mail]
>> Sent: Tuesday, September 04, 2012 11:38 AM
>> To: [e-mail]
>> Cc: [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/renum
> _______________________________________________
> renum mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/renum
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> renum mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/renum