Subject: [secdir] secdir review of draft-ietf-ipsecme-ikev2-ipv6-config-02.txt

From: Dave Cridland <[email-masked]>
Date: Tue, 06 Oct 2009 13:41:38 +0100

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.

---

From: <[email-masked]>
Date: Fri, 16 Oct 2009 13:18:17 +0200

(replying as document author, not AD)

Thanks for your review, Dave!

> a unique, and therefore identifiable, prefix. 

It indeed does this, and the paragraph should be clearer about it.
Perhaps something like this?
  
   The mechanism described in this document assigns each client a
   unique prefix, which makes using randomized interface identifiers
   [RFC4941] ineffective from privacy point of view: the client is
   still uniquely identified by the 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.

Since this is a very small extension to RFC 4306, indeed all the
security considerations of RFC 4306 still apply. Perhaps we
should add something like:

   Since this document is an extension to IKEv2, the security 
   considerations in [IKEv2] apply here as well.

>    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.
> 

I don't think RFC 4891 is relevant here; remote access VPNs are almost
never end-to-end, and the situation is the same with IPv4 and IPv6. So
this document doesn't introduce anything new here...

Best regards,
Pasi

---

From: Dave Cridland <[email-masked]>
Date: Fri, 16 Oct 2009 12:26:21 +0100

>    still uniquely identified by the prefix.  [...]
Yes, that's much clearer.

>    considerations in [IKEv2] apply here as well.
It seems to be traditional, yes.

> this document doesn't introduce anything new here...

I was under the impression it potentially moved one of the ends in  
any communication away from the tunnel endpoint?

That is, if one is connecting into a secured, trusted network, using  
this secured VPN tunnel, that doesn't mean that any packets  
traversing a local network to get to that tunnel are secured. (For  
whatever meaning of secured you intend to put here).

To put it another way, under RFC 4306, the client VPN'ing into the  
network is always "attached to the IPSec tunnel", whereas this  
document extends things such that this may not be the case.

I'm not jumping up and down insisting on this, by the way, I'm just  
trying to make sure you understood what I meant. :-)

Dave.

---

From: <[email-masked]>
Date: Fri, 16 Oct 2009 14:04:05 +0200

> document extends things such that this may not be the case.

No, not really; a VPN client using plain RFC 4306 can also share its
IPv4 VPN connection to other hosts in the vicinity if it wants; it
just needs to do NATting, while here we avoid the NAT.

(And this is relatively common case for IPv4 VPNs nowadays -- the
"other hosts" using the VPN connection are most likely VMs running
on the same physical hardware.)

Best regards,
Pasi

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 16 Oct 2009 08:02:05 -0700

> Thanks for your review, Dave!

Ditto!

>    still uniquely identified by the prefix.  [...]

Hmm. How about being more explicit about the implications, something along these lines: 

The mechanism described in this document assigns each client a unique prefix. Doing so might make the use of randomized interface identifiers [RFC4941] ineffective from privacy point of view because the client would still be uniquely identified by the prefix. However, to be able to track a client based on its prefix, one has to be aware of the fact that the client configures all of its addresses within the same prefix. [...]

Thoughts?

--julien