Re: [Gen-art] Review: draft-mglt-ipsecme-clone-ike-sa-05.txt

[Jari Arkko <[e-mail]>]

Joel, thank you very much for uncovering this issue, and thank you Daniel for addressing it. I have balloted no-obj for tonight’s IESG telechat for this document.

Jari

On 08 Oct 2015, at 19:18, Joel M. Halpern <[e-mail]> wrote:

> That would work very well for me.  Thank you for addressing my concerns.
> Yours,
> Joel
> 
> On 10/8/15 10:20 AM, Daniel Migault wrote:
>> Hi Joel,
>> 
>> Thank you for taking time to review and comment the draft.
>> 
>> We propose to add the following text to clarify the example in section 2 before the two last paragraphs. The following text expects to clarify the following points:
>>    - 1) The creation of VPN is a local policy matter
>>    - 2) Moving one duplicated VPN to different interfaces may involve multiple MOBIKE operations
>>    - 4) There is no needs to create all possible VPNs ( might be similar to item 1)
>> 
>> The following text has been added to our local copy. If you would like us to publish a new version, feel free to let us know. Our intention is to keep the updates local until you ask us to publish the draft.
>> 
>> BR,
>> Daniel and Valery
>> 
>> NEW TEXT -- BEGIN
>> Note that it is up to host's local policy which additional VPNs to create and
>> when to do it. The process of selecting address pairs for migration is
>>  a local matter. Furthermore, in the case of multiple interfaces on
>>  both ends care should be taken to avoid the VPNs to be duplicated by both ends or moved to the both interfaces.
>> 
>>  In addition multiple MOBIKE operation may be involved from the
>>  Security Gateway or the VPN End User.
>>  Suppose, as depicted in Figure 3 for example that the cloned VPN is
>>  between Interface _0 and Interface_0', and the VPN End User and the
>>  Security Gateway wants to move it to Interface_1 and Interface_1'. The
>>  VPN End User may initiate a MOBIKE exchange in order to move it to
>>  Interface_1, in which case the cloned VPN is now between Interface_1
>>  and Interface_0'. Then the Security Gateway may also initiate a MOBIKE exchange in order to move the VPN to Interface_1' in which case the VPN has reached its final destination.
>> NEW TEXT -- END
>> 
>> -----Original Message-----
>> From: Joel M. Halpern [mailto:[e-mail]]
>> Sent: Friday, October 02, 2015 1:25 PM
>> To: A. Jean Mahoney; General Area Review Team; [e-mail]
>> Subject: [Gen-art] Review: draft-mglt-ipsecme-clone-ike-sa-05.txt
>> 
>> I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.
>> 
>> For more information, please see the FAQ at
>> 
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Document: draft-mglt-ipsecme-clone-ike-sa-05.txt
>> Cloning IKE SA in the Internet Key Exchange Protocol Version 2 (IKEv2)
>> 
>> Reviewer: Joel M. Halpern
>> Review Date: 2-Oct-2015
>> IETF LC End Date: 27-Oct-2015
>> IESG Telechat date: N/A
>> 
>> Summary: This document is nearly ready for publication as a Propsoed Standard RFC.
>> 
>> Major issues:
>>      The introductory material talks about the case where both sides have multiple interfaces.  It is not clear what will happen with this mechanism in that case.
>>      In particular, if I have two systems, with three interfaces, it seems that this will start by creating the S1-D1 Security Association.
>> It seems straightforward for each side to create their simple additional assocations (S2-D1, S3-D1, and S1-D2, S1-D3).
>>      But the introduction suggests that we also want to create S2-D2, S3-D3, S2-D3, and S3-D2.  With no other guidance, it appears that both sides will try to create all four of those, creating 8 security associations instead of 4.
>>      I hope that I have simply missed something in the document that resolves this.
>> 
>> Minor issues:
>> 
>> Nits/editorial comments:
>> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art