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:j...@joelhalpern.com]
Sent: Friday, October 02, 2015 1:25 PM
To: A. Jean Mahoney; General Area Review Team;
draft-mglt-ipsecme-clone-ike-sa....@ietf.org
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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
