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

From: Fernando Gont <[email-masked]>
Date: Mon, 01 Apr 2013 10:04:33 -0300

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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 02 Apr 2013 10:45:24 +0100

Fernando,

Rather than repeating myself, I'll suggest a change to the Introduction
that would (IMHO) improve the message:

OLD:

1.  Introduction

   Most general-purpose operating systems implement and enable native
   IPv6 [RFC2460] support and a number of transition/co-existence
   technologies by default.  For cases in which the corresponding
   devices are deployed on networks that are assumed to be IPv4-only,

NEW:

1.  Introduction

   Most general-purpose operating systems implement and enable native
   IPv6 [RFC2460] support and a number of transition/co-existence
   technologies by default [RFC6434]. Support of IPv6 by all nodes is
   intended to become best current practice [RFC6540]. As a result,
   networks will need to plan for and deploy IPv6 and its security
   mechanisms. Some enterprise networks might, however, choose to delay
   active use of IPv6. For networks that are assumed to be IPv4-only,

It would be nice to refer to draft-ietf-v6ops-enterprise-incremental-ipv6
but I think that is too far from RFC publication to be very useful.

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 10 Apr 2013 02:17:39 -0300

Hi, Brian,

My apologies for the delay in my response. Please find my comments
in-line...

>    active use of IPv6. For networks that are assumed to be IPv4-only,

I've checked with a few folks, and it seems that the suggested text
would make everyone happy, except for the sentence that says "As a
result, networks will need to plan for and deploy IPv6 and its security
mechanisms.", on the basis that this is not the document to make a case
for v6 deployment. The suggestions has been to remove that sentence, and
apply the rest of your proposed text (or, alternatively, to tone down
that sentence).

For simplicity sake (and because I'm not sure how one would tone that
one down), my suggestion would be to apply you proposed text, modulo
that sentence.

Would that be okay with you? -- If not, please do let me know, so that
we can try to find a way forward that keeps everyone happy.

Thanks so much!

Best regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Apr 2013 17:06:20 +0100

Hi Fernando,

> we can try to find a way forward that keeps everyone happy.

Well, it's not for me to call the consenus, but with that sentence
removed I would personally enter the "no objection" state.

Thanks

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 13 Apr 2013 00:29:59 -0300

Hi, Brian,

> removed I would personally enter the "no objection" state.

Good.

BTW, it's unclear to me whether I should keep in in the acks or not...
so please do let me know how you'd like me to proceed in this respect.

P.S.: For any other future reviews: I usually do my best to address
others' comments. In the event that you submit feedback, and it looks
like I have not tried to address it, please resend/ping me (most likely
I tried but failed, the feedback slipped by, or whatever... )

Thanks!

Best regards,