Subject: Re: 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 09:49:07 -0300

SM,

On 03/31/2013 06:29 AM, SM wrote:
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> [email-masked] mailing lists by 2013-04-12. Exceptionally, comments may be
> 
> From Section 6:
> 
>   "In general, the possible mitigations boil down to enforcing on native
>    IPv6 and IPv6 transition/co-existence traffic the same security
>    policies currently enforced for IPv4 traffic, and/or blocking the
>    aforementioned traffic when it is deemed as undesirable."
> 
> My reading of the mitigation is that it comes down to block everything
> IPv6.  The draft seems to treat every network as a military operation
> network.

Please re-read the above paragraph -- you missed the part that says
"...the same security policies".

> In the Section 1:
> 
>   "Native IPv6 support could also possibly lead to VPN traffic leakages
>    when hosts employ VPN software that not only does not support IPv6,
>    but that does nothing about IPv6 traffic.
>    [I-D.ietf-opsec-vpn-leakages] describes this issue, along with
>    possible mitigations."
> 
> I don't understand the relationship between the above and "IPv4-only"
> networks.

Those issues are not present when your network employs v4-only.

> From Section 2:
> 
>  "This means that even if a network is expected to be IPv4-only,
>   much of its infrastructure is nevertheless likely to be
>   IPv6 enabled."
> 
> What is an IPv4-only network?

A network were none of the devices connected to it implement v6.

>   "[CORE2007] is a security advisory about a buffer overflow which
>    could be remotely-exploited by leveraging link-local IPv6
>    connectivity that is enabled by default."
> 
> How is this attack mitigated within the context of the draft?

The reference is meant to illustrate that that even if you think your
network only employs IPv4 (and hence forget about the v6 support), you
could be hit by that.

>   "Additionally, unless appropriate measures are taken, an attacker with
>    access to an 'IPv4-only' local network could impersonate a local
>    router and cause local hosts to enable their 'non-link-local' IPv6
>    connectivity (e.g. by sending Router Advertisement messages),
>    possibly circumventing security controls that were enforced only on
>    IPv4 communications."
> 
> Where is the mitigation for this?

For attacks that employ link-local connectivity, it bolds down to packet
filtering (either by a personal firewall at the host, or by filtering v6
at layer-2) -- this is discussed in the I-D.

> From Section 4:
> 
>   "IPv6 deployments in the Internet are continually increasing"
> 
> I am no longer worried about IPv6 deployment as the OPSEC working group
> has a plan to stop that. :-)
> 
>   'Upstream filtering of transition technologies or situations
>    where a mis-configured node attempts to "provide" native IPv6
>    service on a given network without proper upstream IPv6 connectivity
>    may result in hosts attempting to reach remote nodes via IPv6, and
>    depending on the absence or presence and specific implementation
>    details of "Happy Eyeballs" [RFC6555], there might be a non-trivial
>    timeout period before the host falls back to IPv4 [Huston2010a]
>   [Huston2012].'
> 
> I don't see what "Happy Eyeballs" has to do with operational security.

Happy Eyeballs has to do with what you do when you drop packets. If you
silently drop them, the host may have rely on timeouts rather than
having a positive indication that a packet has been dropped.

>   "For this reason, networks attempting to prevent IPv6 traffic from
>    traversing their devices should consider configuring their local
>    recursive DNS servers to respond to queries for AAAA DNS records with
>    a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such
>    queries, and should even consider filtering AAAA records at the
>    network ingress point to prevent the internal hosts from attempting
>    their own DNS resolution."
> 
> The above breaks DNS in an attempt to remove everything IPv6 related
> from the network.

Could you please elaborate?

> The title of the draft is "Security Implications of IPv6 on IPv4
> Networks".  The Abstract mentions "IPv4-only" networks.  The
> Introduction Section mentions "networks that are assumed to be
> IPv4-only".

Please see the quotes when we say "'IPv4-only' networks" -- in practice,
there's no such a thing, and you should think v6 security even if you
think/want to run an IPv4-only network.

> I don't understand what this draft is about.

This one I cannot do much about. :-)

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

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,

---

From: "George, Wes" <[email-masked]>
Date: Mon, 1 Apr 2013 13:59:40 -0400

Since I was the one that provided some of this text and raised the issues it's addressing, I'll take a crack  at responding at a couple of your concerns below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> SM
>
[WEG] It doesn't. This is a second-order effect, but IMO an important one. If one is attempting to prevent IPv6 from being used on a network in an effort to "secure" it from IPv6-related vulnerabilities, one must consider the fact that there are multiple IPv6 transition technologies specifically designed to enable IPv6 access on a network that is otherwise without IPv6 connectivity, some that can be used without any coordination from the upstream network admins. It might even "helpfully" try to share its IPv6 service with other hosts on the network (rogue RAs...). The act of preventing those transition technologies from passing traffic (by doing things like blocking protocol 41, for example) may create IPv6 connectivity that is broken or otherwise impaired, where an end host believes that it has IPv6 connectivity via a transition technology when it fact it does not because its transition mechanism is being blocked upstream. Happy Eyeballs attempts to fix this by ensuring that fallbacks to IPv4 happen more rapidly and IPv4 is preferred when issues are detected with IPv6 connectivity. However, it's inappropriate to rely on pervasive implementation of Happy Eyeballs as the sole solution to prevent end host impacts, since the end user may not know that IPv6 is actively being disabled on this network, or that their IPv6 implementation is otherwise broken. This is a problem that continues to get worse the more dual-stack content becomes available.
> The above breaks DNS in an attempt to remove everything IPv6 related
[WEG] On a network with the stated goal of providing/allowing no IPv6 connectivity, AAAA records are effectively useless. Preventing hosts from receiving AAAA records in order to prevent them from attempting to connect to an IPv6 address and failing is not broken DNS.

Regards,

Wes George

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.

---

From: SM <[email-masked]>
Date: Mon, 01 Apr 2013 13:49:15 -0700

Hi Fernando,
>"...the same security policies".

I saw that. :-)  I commented on Section 6 first as it's only when I 
reached that part of the document that I saw the trade-off between 
blocking IPv6 traffic and security.

>Those issues are not present when your network employs v4-only.

What's missing is some text in the Introduction section explaining 
that the draft is discussing about IPv4 networks (what is mentioned above).

>A network were none of the devices connected to it implement v6.

If that is the case some of the attacks would not be possible.  The 
scenario the draft discusses about is when there are devices which 
have IPv6 support.  The draft could have an explanation about IPv4 
networks (see previous comment) and then follow it with the first 
sentence of Section 1.  It can then go into a discussion of the 
threats and how to mitigate them.

 From Section 1:

   "filtering IPv6 traffic (whether native or transition/co-existence)
    to mitigate IPv6 security implications on IPv4 networks should
   (generally) only be considered as a temporary measure until IPv6
   is deployed."

It's not a temporary measure in the sense that there is an assumption 
that the network should be IPv4 only.  If the network is to support 
IPv4 and IPv6, filtering of IPv6 traffic is not recommended then.

>network only employs IPv4 (and hence forget about the v6 support), you

Ok.

>at layer-2) -- this is discussed in the I-D.

I don't see anything about that in the draft.  There is a mention of 
filtering at Layer 2 and Layer 3.

>having a positive indication that a packet has been dropped.

This is a browser issue.  I'll comment further in another message.

>Could you please elaborate?

The text about DNS (Section 4) is about DNS replies.  What I meant 
was that the draft recommends changing the answer for a (DNS) AAAA 
query in an attempt to stop IPv6 traffic.  It's ok to block IPv6 
traffic as it's an IPv4-only network.  I don't think that it is ok to 
tamper with DNS replies (in this case you are covered by local policy 
and you can do that).

>think/want to run an IPv4-only network.

It might help to reword the Abstract and the Introduction Section so 
that the purpose of the document is clear.  I agree that it is good 
to think IPv6 security even if I want an IPv4-only network.

>This one I cannot do much about. :-)

:-)

Regards,
-sm

---

From: SM <[email-masked]>
Date: Mon, 01 Apr 2013 14:14:29 -0700

At 10:59 01-04-2013, George, Wes wrote:
>Since I was the one that provided some of this text and raised the 
>issues it's addressing, I'll take a crack  at responding at a couple 
>of your concerns below.

Ok.

>[WEG] It doesn't. This is a second-order effect, but IMO an 
>important one. If one is attempting to prevent IPv6 from being used 
>on a network in an effort to "secure" it from IPv6-related 
>vulnerabilities, one must consider the fact that there are multiple 
>IPv6 transition technologies specifically designed to enable IPv6 
>access on a network that is otherwise without IPv6 connectivity, 
>some that can be used without any coordination from the upstream 
>network admins. It might even "helpfully" try to share its IPv6 
>service with other hosts on the network (rogue RAs...). The act of 
>preventing those transition technologies from passing traffic (by 
>doing things like blocking protocol 41, for example) may create IPv6 
>connectivity that is broken or otherwise impaired, where an end host 
>believes that it has IPv6 connectivity via a transition technology 
>when it fact it does not because its transition mechanism is being 
>blocked upstream. Happy Eyeballs attempts to fix this by ensuring 
>that fallbacks to IPv4 happen more rapidly and IPv4 is preferred 
>when issues are detected with IPv6 connectivity. However, it's 
>inappropriate to rely on pervasive implementation of Happy Eyeballs 
>as the sole solution to prevent end host impacts, since the end user 
>may not know that IPv6 is actively being disabled on this network, 
>or that their IPv6 implementation is otherwise broken. This is a 
>problem that continues to get worse the more dual-stack content 
>becomes available.

I agree with the last sentence.  Happy Eyeballs is about the 
HTTP.  There are other applications protocols too. :-)  In the 
context of the draft you have an IPv4 network and you want the 
devices or applications to be IPv4-only.  I see that as configuring 
the applications (there is a browser option for IPv4 only 
access).  There isn't any mis-configured node as the document 
intentionally argues for blocking IPv6 traffic and IPv6 transition 
technologies.

>[WEG] On a network with the stated goal of providing/allowing no 
>IPv6 connectivity, AAAA records are effectively useless. Preventing 
>hosts from receiving AAAA records in order to

Yes.

>  prevent them from attempting to connect to an IPv6 address and 
> failing is not broken DNS.

If there isn't any IPv6 connectivity it is useless to query for AAAA 
RRs as the host is not going to establish an IPv6 
connection.  Instead of looking at the problem from that angle the 
proposal uses a "middlebox" (not the correct term) to change 
things.  Once it becomes best practice to tamper with DNS there is 
one more problem to solve as you can no longer rely on DNS working 
according to specifications.

Regards,
-sm

---

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

On 04/01/2013 06:14 PM, SM wrote:
> If there isn't any IPv6 connectivity it is useless to query for AAAA RRs
> as the host is not going to establish an IPv6 connection.  Instead of
> looking at the problem from that angle the proposal uses a "middlebox"
> (not the correct term) to change things.  Once it becomes best practice
> to tamper with DNS there is one more problem to solve as you can no
> longer rely on DNS working according to specifications.

Welcome to the real world:  That cat has been out of the box for years
(no matter whether you consider that a problem, or a feature).

FWIW, my TP-LINK router does that, even if I don't want it to.

Thanks,

---

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: Tue, 02 Apr 2013 20:30:12 -0300

On 04/01/2013 06:14 PM, SM wrote:
>> with IPv6 connectivity. However, it's inappropriate to rely on
>> pervasive implementation of Happy Eyeballs as the sole solution to
>> prevent end host impacts, since the end user may not know that IPv6 is
>> actively being disabled on this network, or that their IPv6
>> implementation is otherwise broken. This is a problem that continues
>> to get worse the more dual-stack content becomes available.
> 
> I agree with the last sentence.  Happy Eyeballs is about the HTTP. 
> There are other applications protocols too. :-) 

Happy eyeballs is about HTTP. But part of the approach predates "Happy
Eyeballs" -- please see RFC5461.

Signaling hosts when packets are being dropped allows for a more
informed decision/reaction on the host-side.

Removing the AAAA records when you're not going to allow such
connectivity reduces the potential problem (at the end of the day, this
is kind of the whitelisting approach that has been applied to the
general case by content providers -- with the caveat that in this case
you positively know that such connectivity is not present).

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Apr 2013 01:25:09 +0000

> Eyeballs" -- please see RFC5461.

It's certainly true that we usually talk about Happy Eyeballs in the context of HTTP, but I use it for ssh as well, and I think it's applicable across a broad range of application protocols.   It is not applicable to _every_ protocol, but that's as strong a qualification as I'd put on it—saying it's only applicable to HTTP is not correct.

---

From: SM <[email-masked]>
Date: Tue, 02 Apr 2013 21:08:33 -0700

Hi Fernando,

Ok.

>you positively know that such connectivity is not present).

Here's an extract from RFC 4924:

   'In particular, the DNSSEC protocol described in "Protocol
    Modifications for the DNS Security Extensions" [RFC4035] has been
    designed to verify that DNS information has not been modified between
    the moment they have been published on an authoritative server and
    the moment the validation takes place.  Since that verification can
    take place at the application level, any modification by a recursive
    forwarder or other intermediary will cause validation failures,
    disabling the improved security that DNSSEC is intended to provide.'

I am ok with resolving the problem of the day.  If I am of the 
opinion that it may cause problems in the long run I'll mention 
it.  I am not inclined to do anything more than that.

Regards,
-sm

---

From: Fernando Gont <[email-masked]>
Date: Wed, 03 Apr 2013 00:06:58 -0300

> It's certainly true that we usually talk about Happy Eyeballs in the context of HTTP, but I use it for ssh as well, and I think it's applicable across a broad range of application protocols.   It i…

Exactly. For instance, I seem to recall benefiting of RFC5461 for ssh in
NetBSD long before the first version of the Happy Eyeballs I-D was
published.

As noted in RFC5461, the approach is useful for any protocol -- but for
obvious reasons the benefits become evident for interactive protocols
such as HTTP, SSH, telnet, and the like...

Cheers,

---

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,