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

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

Thanks Elwyn, those comments/answers are all fine to me.

B.2 is a can of worms, and probably not one to dig too deep into in a
document like this.   I just hope for IPv6 that ISPs appreciate that a
/48 (or /56 by RFC3177-bis) is the norm, and hence a per-device fee
is inappropriate.   I would assume many dual-stack home networks would 
run IPv6 on a /56 alongside an IPv4+NAT scheme.  

Tim

On Mon, Aug 22, 2005 at 01:36:13PM +0100, Elwyn Davies wrote:
> Thanks for the comments.
> 
> Responses in line..  If there is no pushback from the mailing list I 
> will incorporate the changes and send a note of the changes asap
> 
> Regards,
> Elwyn
> 
> Tim Chown wrote:
> 
> >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'
> > 
> >
> Yep.
> 
> >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.   
> > 
> >
> As an aside, having this section as a 4th level subsection seems a bit 
> peculiar... the relation with 2.1.11 is  through SEND but the topic is 
> really unrelated. I propose to promote it to level 3 as 2.1.12, 
> renumbering Mobile IP to 2.1.13.
> 
> I think it would be useful to add notes pointing to the additional 
> problems highlighted in these drafts, especially as these are headed 
> towards RFC status.  I'll draft some text and send it out shortly.
> 
> >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.  
> >
> This section is trying to a bit more than this: advising people to try 
> and avoid the 'suck it and see approach' but still to 'please actually 
> go and implement IPv6' rather than succumbing to FUD.  The emphasis 
> should be on doing it properly, and that there are tools to help.
> 
> The last para has been around for a while.. it has got separated from 
> the v6onbydefault reference which is where it belongs.  I'll try an come 
> up with a better arrangement and a firmer recommendation.
> 
> >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).
> > 
> >
> This thought is well taken... I think it belongs in 3.3
> 
> What we are emphasising is that packets should be routed (at least 
> logically) as follows:
> 
> 'Inside' <---> IPv6 Firewall <---> v6 in v4 tunnel endpoint <---> IPv4 
> Firewall <---> Outside
> 
> A sort of extra DMZ for IPv6.
> 
> >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. 
> >
> Certainly making it even clearer that multiple addresses are a fact of 
> normal life, and not an occasional aberration, for IPv6 would be 
> worthwhile.  A few words of advice for vendors on ease of configuration 
> also.
> 
> > 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.
> > 
> >
> Again this would be a useful comment.. I'll add it.
> 
> >In 4.7
> >
> >May wish to look at or cite draft-ietf-ipv6-node-requirements-11 which
> >recommends base security implementation for IPv6 nodes.
> > 
> >
> It would probably be worth citing this earlier on in a more general 
> context (maybe as well).
> 
> >In 4.8
> >
> >Seems to overlap 4.1 in scope?  
> >
> I think the changes I suggested above reduce the (perceived) overlap.  I 
> think they are separate issues.
> 
> >I'm not sure the second paragraph really
> >holds true now - at least separate admin experience from vendor 
> >experience :)
> > 
> >
> The admin experience is certainly still true I believe.. we could alter 
> the software piece to emphasise lower maturity.
> 
> >In 4.9
> >
> >This is already said in 4.4?
> > 
> >
> A different perspective I think.. the issue of fast changing addresses 
> does crop up in a number of places.  I don't propose to change this.
> 
> >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. 
> > 
> >
> I'll add a few words.
> 
> >In Appendix B.2:
> >
> >Just cite NAP here?
> > 
> >
> The business model discussion doesn't appear in NAP!  That being said 
> the business model discussion cannot necessarily be solved by 
> addressing.. Steve Bellovin's work on determining the number of hosts 
> behind a NAT can be extended to IPv6 (although the data will be scarcer 
> than in IPv4 because not all packets contain an IPid) (see the FNAT 
> reference).
> 
> OTOH it would be worth citing NAP for further discussion of privacy 
> issues for the whole of Appendix B.
> 
> >In Appendix B.3:
> >
> >I would say here most users would *want* a static /48, so they can run
> >services more easily.  
> > 
> >
> We could mention the conflict.
> 
> Regards,
> Elwyn
> 
> >
> >Cheers,
> > 
> >

-- 
Tim/::1