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

[Dave Cridland <[e-mail]>]

On Fri Oct 16 12:18:17 2009, [e-mail] wrote:
> (replying as document author, not AD)
> 
> Thanks for your review, Dave!
> 
> > 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 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.  [...]
> 
> 
Yes, that's much clearer.


> > 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.
> 
> 
It seems to be traditional, yes.


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

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.