Skip to main content

Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 7791

Yes

(Kathleen Moriarty)

No Objection

Alvaro Retana
(Alia Atlas)
(Barry Leiba)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Spencer Dawkins)
(Terry Manderson)

Note: This ballot was opened for revision 06 and is now closed.

Alvaro Retana
No Objection
Kathleen Moriarty Former IESG member
Yes
Yes (for -06)

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -06)

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -06)

                            
Ben Campbell Former IESG member
No Objection
No Objection (2015-12-01 for -06)
I don't have any substantive comments, but do have a number of editorial comments:

- Abstract:
-- The abstract seems unnecessarily long, can it be edited down? I suggest moving most of the text into the introduction and creating a much shorter abstract.
-- 2nd paragraph, second sentence: "... using multiple interfaces requires to set up an IKE SA..."
There appears to be a missing word after "requires". That is, requires _what_ to set up the SA?  (Alternately, "...requires an IKE SA to be set up...")
-- Please expand MOBIKE on first use (both in the abstract and in the body).

- Section 2, 2nd paragraph after Figure 3: 
-- s/"In case of IPsec it means..."/"In the case of IPSEC, this means..."
-- s/"drawback of such approach"/"drawback of such an approach"
-- What does "transactionally" mean in context of "transactionally synchronized"? Is that different than just "synchronized"?
-- s/"The drawback of such  approach is that it requires new IKE SA"/"The drawback of such _an_approach is that it requires new IKE SA"

- 2, third paragraph from end:  "the VPN End User and the Security Gateway wants to move"
s/wants/want

-4, first paragraph:
-- The language "The goal of the document..." makes it sound like there is a chance the document might fail to achieve the goal. I assume that is not the intent. I suggest reformulating along the lines of "This document specifies..."
-- "without performing an authentication."
without performing a _new_ authentication?

- 5.2, 2nd paragraph from end:
I don't understand the phrase "If the CREATE_CHILD_SA request concerns an IKE SA rekey ..." Maybe s/concerns/requests?

-5.3, 4th paragraph:
s/"In some cases responder..."/"In some cases, the responder..."

- 8, third paragraph:
Does this talk about resource exhaustion in general, or a resource exhaustion _attack_?
Benoît Claise Former IESG member
No Objection
No Objection (for -06)

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -06)

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -06)

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2015-12-02 for -06)
needs an editorial scrub for clarity, bens review is spot on.
Spencer Dawkins Former IESG member
No Objection
No Objection (for -06)

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2015-12-02 for -06)
- General: What'd happen if I used MPTCP with this? In particular
with the multiple client i/f version. It should work I guess but I
wonder if anyone's thought about any corner case issues (e.g. 
timing) that might come up?

- section 4: "would be deleted" is too vague really - what did
you want to see happen? 

- section 2: I don't get the last paragraph. What's that mean?

nits:

- General: There are many minor grammatical issues, e.g. cases of
missing "an" or "the." It'd be nice to fix those before the RFC
editor has to.

- section 2: typo: "with with"
Terry Manderson Former IESG member
No Objection
No Objection (for -06)