ietf
[Top] [All Lists]

Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt> (Security Implications of IPv6 on IPv4 Networks) to Informational RFC

2013-04-01 13:00:09
Brian,

On 03/29/2013 10:38 AM, Brian E Carpenter wrote:

My minimal request for this draft is for my name to be removed from
the Acknowledgements, as I do not think that my comments have been
acted on.

That has been my intent, and I sent a note before publishing one of the
latest revs to double-check that (not sure if I missed your respond, or
you didn't respond).


In fact, I think that in its current state, this document is harmful
to IPv6 deployment. It in effect encourage sites to fence themselves
into an IPv4-only world. Particularly, it explicitly suggests a
default/deny approach to IPv6-in-IPv4 tunnels, which would prevent
the typical "baby steps" first approach to IPv6 deployment.

Sites that implement any kind of security policy employ a "default deny
policy" (for the simple reason that it's safer to open holes than
explicitly close them). The bottom-line is that if your site enforces
any kind of security policy, you should make an explicit decision
regarding what you do with v6, rather than being unaware that it's there
in your network.



I would like to see the document convey a positive message, suggesting
that an IPv4 site first decides which IPv6 deployment mechanism it
will use, and then configures security appropriately (to allow that
mechanism and block all others).

There's an operational gap here: in many cases, operators have no tools
to enforce security policies on such tunneled traffic.

Besides, when thinking about v6, enterprise networks and the like should
be doing native IPv6 (in which case v6 security controls would be
enforced throughout the network), rather than having each node go their
own way.


A specific aspect of this is that if a site provides one well-managed
6in4 tunnel mechanism, all tunneled IPv6 packets will pass through
well-defined points where security mechanisms may be applied.

In which case you'd be "enforcing IPv6 security controls", which is
entirely in-line ith what this document is saying.


We shouldn't imply that not having an IPv6 plan and blocking all IPv6
by default is a sound strategy.

It's not, and I don't think we're implying that. However, I'd note that
some people are in the position of blocking traffic, or not doing
anything about it. Check for IPv6 support in different security
products, and you might get depressed.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492