Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-06.txt

["George, Wes" <[e-mail]>]

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, "[e-mail]" <[e-mail]>
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.