Subject: [Gen-art] Gen-ART LC Review of draft-ietf-ipsecme-ikev2-ipv6-config-02

From: Avshalom Houri <[email-masked]>
Date: Thu, 24 Sep 2009 17:28:23 +0300

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-ipsecme-ikev2-ipv6-config-02
Reviewer: Avshalom Houri
Review Date: 2009-09-24
IETF LC End Date: 2009-09-25
IESG Telechat date: (if known)

Summary:

This draft is almost ready for publication as an experimental standard.

Major issues:

I am not a security expert but it seems that the security considerations 
section
is too short given that authentication and re-authentications are 
described in the draft.

Minor issues:

There should be a section describing how the requirements in section 3 are 
being
addressed by the solution.

Nits/editorial comments:

None

Thanks
--Avshalom

---

From: <[email-masked]>
Date: Mon, 28 Sep 2009 21:17:32 +0200

Thanks for your review, Avshalom!

This draft doesn't change how authentication (or re-authentication) works in IKEv2 in any way, and that's why the security considerations text doesn't talk about authentication-related security
considerations.

I agree that it would be useful to explain how the goals/requirements were actually met. Perhaps something like this?

Appendix B. Evaluation (Non-Normative)

   Section 3 described the goals and requirements for IPv6
   configuration in IKEv2. This appendix briefly summarizes how the
   solution specified in Sections 4 and 5 meets these goals.

   o  (3.1) Assigning addresses from multiple prefixes is supported,
      without requiring the client to know beforehand how many prefixes
      are needed.
   o  (3.2) Link-local addresses are assigned, and can be used for
      protocols between the VPN client and gateway.
   o  (3.3) The entire prefix is assigned to a single client, so
      the client can freely select any number of interface IDs (which
      may depend on the prefix).
   o  (3.4) This document does not specify how the VPN client would
      share the VPN connection with other devices. However, since the
      entire prefix is assigned to a single client, the client could
      further assign addresses from it without requiring coordination
      with the VPN gateway.
   o  (3.5) The solution does not add any new periodic messages over
      the VPN tunnel.
   o  (3.5) Re-authentication works (see Section 4.2).
   o  (3.5) The solution is compatible with other IPsec uses, since
      the LINK_ID notification makes it unambiguous which CHILD_SAs
      are related to the virtual link and which are not (see Sections
      4.3 and 5.3).
   o  (3.5) The new mechanisms do not prevent the VPN client and/or
      gateway from implementing the INTERNAL_IP6_ADDRESS configuration
      attribute as well; however, the two mechanisms are not intended
      to be used simultaneously (see Section 4.5).
   o  (3.5) Implementation dependencies are, obviously, implementation
      dependant (and their cleanliness somewhat subjective). Possible
      drawbacks of some alternative solutions are discussed in
      Appendix A.6.
   o  (3.5) The mechanism for configuring the prefixes (configuration
      payloads) is specific to IKEv2, for reasons described in Appendix
      A. However, Section 4.1 recommends using DHCPv6 Information-Request
      message for obtaining other configuration information (such as DNS
      server addresses).

Paul, Julien, Cheryl:  does the text look OK to you?

Best regards,
Pasi

From: ext Avshalom Houri [mailto:[email-masked]]
Sent: 24 September, 2009 17:28
To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]; [email-masked]
Cc: Tim Polk; General Area Review Team
Subject: Gen-ART LC Review of draft-ietf-ipsecme-ikev2-ipv6-config-02

Summary:

Major issues:

I am not a security expert but it seems that the security considerations section
is too short given that authentication and re-authentications are described in the draft.

Minor issues:

There should be a section describing how the requirements in section 3 are being
addressed by the solution.

Nits/editorial comments:

None

Thanks
--Avshalom

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 28 Sep 2009 13:05:33 -0700

Thanks for the new text Pasi, it looks good to me.

--julien

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, September 28, 2009 12:18 PM
To: [email-masked]; Laganier, Julien; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Gen-ART LC Review of draft-ietf-ipsecme-ikev2-ipv6-config-02

Best regards,
Pasi

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

None

Thanks
--Avshalom

---

From: Avshalom Houri <[email-masked]>
Date: Tue, 29 Sep 2009 18:41:06 +0200

Hi,

Is it possible to add a sentence in the security considerations similar to 
the following: "Since the draft does not change any current security 
mechanisms of IKEV2 the only security consideration that should be taken 
into account is assigning each client...."

The changes that explain how the requirements are met looks good to me.

Thanks
--Avshalom

From:
"Laganier, Julien" <[email-masked]>
To:
"[email-masked]" <[email-masked]>, Avshalom 
Houri/Haifa/IBM@IBMIL, "[email-masked]" <[email-masked]>
Cc:
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
Date:
28/09/2009 10:05 PM
Subject:
RE: Gen-ART LC Review of draft-ietf-ipsecme-ikev2-ipv6-config-02

--julien

 
This draft doesn't change how authentication (or re-authentication) works 
in IKEv2 in any way, and that's why the security considerations text 
doesn't talk about authentication-related security
considerations.
 
I agree that it would be useful to explain how the goals/requirements were 
actually met. Perhaps something like this?

 

Best regards,
Pasi

To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]; 
[email-masked]

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

None 

Thanks 
--Avshalom