I gave this doc a read, and have a few comments: 2.1 - I'm not certain that the unsubstantiated assertion about renumbering being difficult helps this section. If you really want to discuss renumbering, perhaps cite the documents that discuss this in gory detail? http://tools.ietf.org/wg/6renum/ Also, might be worth discussing the idea of geographical/topological hierarchy to ease security in a bit more detail, specifically calling out things like simplifying ACLs by limiting the number of address blocks, using nibble boundaries, etc. since that's actually the more useful/relevant justification for having a good address plan.
There's not really any discussion of DHCPv6 PD (vs IA_NA) in 2.5.2, and that might be of interest since the inventory and correlation and logging might be at per-address level, but there may be a much larger block that is actually associated with a given customer or site, like a /48 or a /56 that has been allocated with the idea that it will be further delegated to subnets as appropriate. Basically, you may want to discuss the idea of per-host addressing vs per-network delegation and whether it has any impact here. 2.5.2.2 - CMTS devices use a method called gleaning to watch the DHCPv6 messages as they go by. This might be an additional method to add. See RFC 4779 5.2.2.5.2. 3.1 - reference for anti-spoofing? (BCP38/84 or something else?) Finally, not sure exactly where this fits: Might be useful to have some discussion about single-stack (IPv6-only) as a security method. In other words for a given set of features or services, if everything using it can reach it over IPv6, it makes sense to disable IPv4 access so that you reduce the attack surface. This is especially interesting for internal services like management protocols since you control both ends and can be more aggressive about moving away from dual-stack. I know in my own network it would allow me to eliminate some very long ACLs that have had lots of holes punched over time without sufficient cleanup in favor of a much cleaner and smaller list of permitted IPv6 prefixes from in many cases one single block of permitted addresses. It's almost like a reset button for access controls, because you start with nothing, and explicitly add things such that the legacy cruft that everyone was afraid to touch for fear of breaking something critical goes away. General idea is that anywhere you can go single stack, you're reducing the overhead of management by eliminating the need to duplicate and maintain your security for two stacks. Thanks, Wes On 3/9/15, 7:07 AM, "[email protected]" <[email protected]> wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Operational Security Capabilities for >IP Network Infrastructure Working Group of the IETF. > > Title : Operational Security Considerations for IPv6 >Networks > Authors : Kiran K. Chittimaneni > Merike Kaeo > Eric Vyncke > Filename : draft-ietf-opsec-v6-06.txt > Pages : 41 > Date : 2015-03-09 > >Abstract: > Knowledge and experience on how to operate IPv4 securely is > available: whether it is the Internet or an enterprise internal > network. However, IPv6 presents some new security challenges. RFC > 4942 describes the security issues in the protocol but network > managers also need a more practical, operations-minded document to > enumerate advantages and/or disadvantages of certain choices. > > This document analyzes the operational security issues in all places > of a network (service providers, enterprises and residential users) > and proposes technical and procedural mitigations techniques. Anything below this line has been added by my company’s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
