Skip to main content

Last Call Review of draft-ietf-ipsecme-ikev2-ipv6-config-
review-ietf-ipsecme-ikev2-ipv6-config-secdir-lc-cridland-2009-10-08-00

Request Review of draft-ietf-ipsecme-ikev2-ipv6-config
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-10-20
Requested 2009-09-18
Authors Cheryl R. Madson , Pasi Eronen , Julien Laganier
I-D last updated 2009-10-08
Completed reviews Secdir Last Call review of -?? by Dave Cridland
Assignment Reviewer Dave Cridland
State Completed
Request Last Call review on draft-ietf-ipsecme-ikev2-ipv6-config by Security Area Directorate Assigned
Completed 2009-10-08
review-ietf-ipsecme-ikev2-ipv6-config-secdir-lc-cridland-2009-10-08-00
I am reviewing this document as part of the security directorate's  


ongoing effort to review all IETF documents being processed by the  


IESG.  These comments were written primarily for the benefit of the  


security area directors.  Document editors and WG chairs should treat  


these comments just like any other last call comments. Feel free to  


forward to any appropriate forum.






This document extends the limited support for IPv6 VPN solutions in  


IKEv2, in particular allowing for multiple prefixes rather than a  


fixed number of addresses, which in turn allows various addressing  


strategies to be used.






The Security Considerations section is actually quite unclear to me -  


at first glance, the opening phrase suggests that the solution does  


indeed do the thing it warns against, that is, assigning each client  


a unique, and therefore identifiable, prefix. It also fails to draw  


the reader's attention to any other relevent considerations - I'm  


assuming that the two and a half pages of security considerations in  


RFC 4306 have some direct relevance here.






Also, the informative references noted in the Acknowledgements  


section would appear to have some potentially important security  


considerations - for example, RFC 4891's final consideration is:




  Please note that using IPsec for the scenarios described in Figures


  1, 2, and 3 does not aim to protect the end-to-end communication.   


It



  protects just the tunnel part.  It is still possible for an IPv6
  endpoint not attached to the IPsec tunnel to spoof packets.



... given that IKEv2's previous support for IPv6 limited it to a  


single host at the client end, one assumes that this document  


introduces at least this security consideration.




Dave.