Re: Last Call on draft-ietf-v6ops-security-overview-02.txt

[Tim Chown <tjc@ecs.soton.ac.uk>]

On Fri, Aug 19, 2005 at 04:03:49PM +0100, Elwyn Davies wrote:
> Today is the last day of the wg last call for this document (assuming we 
> actually count forwards ;-) ).
> 
> I have not seen any comments during the last call, but my own scan of 
> the document has revealed a few nits and I have added an improved 
> example in section 4.3.

I agree it's ready.   Overall it's an excellent document.

A handful of minor comments:

One other minor nit: P.12, in 2.1.11

   o  IPv4  addresses are not universally supported across operating
      systems, and

=> 'IPv4 link-local addresses'

In 2.1.11.1

In addition to advertising 'routing services which it will not fulfill'
a node may be able to DoS by deprecating the existing good prefix.  With
router preferences (draft-ietf-ipv6-router-selection-07), an attacker may 
be able to launch a DoS attack, also with load balancing 
(draft-ietf-ipv6-host-load-sharing-04) there are similar concerns.  See
the security considerations sections of both documents.   I would also
say that in the example of IETF WLAN networks, DoS is not (probably) 
malicious, just misconfiguration with people not turning off their IPv6
configurations from other locations.   

In 4.1

I think this is a bit wishy-washy.  It's really saying that IPv6 firewall,
IDS and other security/resilience system implementations are lacking.
I think the last paragraph doesn't really fit at all.   One recommendation
should be that admins support IPv6 deployment such that they control it
rather than having (ab)users do so first.  Another could be that any
tunneled connectivity be terminated outside the site's (native) IPv6 firewall
(which may or may not be the same system as the IPv4 firewall).

In 4.4

For the security and management perspective, vendors and admins need to
assume that multiaddressing is normal in IPv6.  Being able to tokenise ACLs
and configs in general for multiple prefixes and/or addresses would be
generally useful.   I think the only way to disable privacy addresses is
to use full stateful DHCPv6 (where the client may request provacy addresses
to be allocated, but the server need not honour that).   I suspect many 
enterprise admins will wish to disable RFC3041.

In 4.7

May wish to look at or cite draft-ietf-ipv6-node-requirements-11 which
recommends base security implementation for IPv6 nodes.

In 4.8

Seems to overlap 4.1 in scope?  I'm not sure the second paragraph really
holds true now - at least separate admin experience from vendor 
experience :)

In 4.9

This is already said in 4.4?

In Appendix A:

"Hosts behind the
   6to4 router can use methods such as RFC 3041 addresses to conceal
   themselves, though."

=> Only if they are not meant to be reachable - otherwise they will have
   a static global address for receiving communications initiated inbound,
   while using 3041 for initiating communications outbound. 

In Appendix B.2:

Just cite NAP here?

In Appendix B.3:

I would say here most users would *want* a static /48, so they can run
services more easily.  


Cheers,
-- 
Tim/::1