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

["Liubing (Leo)" <[e-mail]>]

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.

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Friday, September 14, 2012 9:09 PM
> To: Liubing (Leo)
> Cc: madi; Sheng Jiang; 6renum
> Subject: Re: [renum] I-D Action: draft-ietf-6renum-gap-analysis-03.txt
> 
> 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