Subject: Re: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03)

From: Mark Smith <[email-masked]>
Date: Tue, 2 Sep 2008 06:40:39 +0930

Hi James,

On Wed, 27 Aug 2008 15:20:37 -0700
james woodyatt <[email-masked]> wrote:

> On Aug 27, 2008, at 14:42, Mark Smith wrote:
> > Only permitting inbound authenticated tunneling protocols like  
> > IPsec, l2tp or pptp would easily defeat that.
> 
> IPsec is not necessarily authenticated.
> 

I had thought of that. Couldn't the statefulness/negotiated identity of
unauthenticated IPsec (and other stateful tunnelling protocols) at
least be the minimum threshold of what is allowed blindly?

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Tue, 2 Sep 2008 07:07:19 +0930

On Thu, 28 Aug 2008 09:48:25 +0200
Rémi Denis-Courmont <[email-masked]> wrote:

> 
> On Thu, 28 Aug 2008 07:12:00 +0930, Mark Smith
> 
> <[email-masked]> wrote:
> 
> > In that case, I'd still strongly suggest limiting the IPv6 in IPv6
> 
> > tunnel support to authenticated protocols only. Bypassing the CPE
> 
> > security using a linux box (or anything else that supports end-user
> 
> > manually configured tunnels, on which the user has admin priviledges)
> 
> > will be as simple as something like this (syntax probably not right ,
> 
> > but that's because I've got a few minutes before I need to get ready for
> 
> > work):
> 
> 
> 
> This is silly. If the user wants to bypass the CPE, (s)he can do it anyway.
> 
> The point of a CPE is to provide security that the user _wants_ to have,
> 
> not force security upon the user.
> 
> 

I'm specificly talking about the *external to internal* direction. Note
the text doesn't specify a direction for these tunnelled protocols:

"Therefore, this document recommends the
   DEFAULT operating mode for residential IPv6 simple security is to
   permit all virtual private networking tunnel protocols to pass
   through the stateful filtering function.  These include IPsec
   transport and tunnel modes as well as other IP-in-IP protocols."

This would seem to me to allow unsolicited inbound tunnel encapsulated
traffic from any source, via any of the stateless over-IPv6
tunnelling protocols or methods. I don't think that's very good
security at all, going slightly higher level than my earlier
example, here's the attack:

(1) purchase a banner add on a popular webpage, with the advertisement
image coming from your server, and use that to record valid and
current global unicast IPv6 addresses.

(2) attack those recorded addresses. Bypass all the v6 CPE security
measures specified in this draft by sending your malicious packets
inside an IPv6 in IPv6 or GRE in IPv6 tunnel.

With luck, the end-node has its own firewalling, and I think that is
fairly likely. The concern I have is that the CPE devices that will be
built to this draft will have a big "security" sticker on the box, and
yet it is so easy to bypass if we continue to permit all unsolicited
inbound stateless tunnelling protocols. If people see a big "security"
sticker on their CPE they may turn off their end-node security,
"because they don't need it anymore." I think a false sense of security
is worse than no security at all, because you think you've got it when
you actually don't.

I agree with the fundamental intention of the text I quoted above - I'm
just concerned at how permissive it is. Limiting it to authenticated or
negotiated state/session based tunnelling protocols would seem to me to
limiting this firewall bypass method significantly without limiting too
much the functionality that is intended by permitting these exterior
initiated tunnels.

Regards,
Mark.

> 
> We are talking about simple CPEs - not corporate firewalls!
> 
> 
> 
> Blocking automatic tunneling (6to4 and/or Teredo) might make sense, but
> 
> blocking manually configured tunnel does not - regardless of
> 
> authentication.
> 
> 
> 
> -- 
> 
> Rémi Denis-Courmont
> 
>

---

From: james woodyatt <[email-masked]>
Date: Tue, 2 Sep 2008 13:53:10 -0700

On Sep 1, 2008, at 14:37, Mark Smith wrote:
> [...]
> Note the text doesn't specify a direction for these tunnelled  
> protocols:
>
> [...]

This is the informative text in Section 2.2 of the Overview, whereas  
the Detailed Recommendations are split between sections 3.2.4 and  
3.2.5.  I think it would be more helpful if you were to address your  
concerns about sections 3.2.4 first, and 3.2.5 separately if necessary.

> [...]
> This would seem to me to allow unsolicited inbound tunnel  
> encapsulated traffic from any source, via any of the stateless over- 
> IPv6 tunnelling protocols or methods. I don't think that's very good  
> (1) purchase a banner add on a popular webpage, with the  
> advertisement image coming from your server, and use that to record  
> valid and current global unicast IPv6 addresses.
>
> fairly likely. The concern I have is that the CPE devices that will  
> be built to this draft will have a big "security" sticker on the  
> box, and yet it is so easy to bypass if we continue to permit all  
> unsolicited inbound stateless tunnelling protocols. If people see a  
> big "security" sticker on their CPE they may turn off their end-node  
> security, "because they don't need it anymore."
> [...]

Having thought long and hard about the problem, I confess to not  
viewing VPN protocols as a particularly important attack surface to  
guard for residential networks.  I think interior nodes configured as  
vulnerable tunnel endpoints can be expected to be uncommon on  
residential networks and limited only to those nodes where an  
administrator has solicited inbound flows by some out-of-band method  
invisible to any CPE firewall gateway.  They are not very likely to be  
present as a result of naïve user misconfiguration or the deployment  
of ubiquitous-and-buggy legacy applications.

Requiring applications using tunnel protocols to use authentication  
where it otherwise isn't needed adds complexity without providing any  
*real* additional security.  Some peer-to-peer applications, i.e.  
those which do not require parties to authenticate with one another  
until some time after unauthenticated communications have been  
ongoing, will be given a perverse incentive to initiate with with  
contrived anonymous credentials just to recover the transparency lost  
to residential CPE filters that block unauthenticated inbound tunnel  
flows.

At this point, what have you done?  You've just shifted the attack  
scenario above so that it looks like this:

(2) attack those recorded addresses. Bypass all the v6 CPE security  
measures specified in this draft by sending your malicious packets  
inside a tunnel using the well-known anonymous credentials widely used  
by P2P applications for legitimately bypassing CPE simple security  
measures.

In considering the recommendations in section 3.2.5, the IPv6  
residential CPE simple security design team considered DEFAULT limits  
on inbound IPsec and IKE flows, e.g. allowing only authenticated flows  
or denying all inbound tunnel flows altogether, and came to rough  
consensus that it couldn't be done in a way that A) would be  
sufficiently simple for residential users, i.e. zero configuration,  
and B) would provide any real improvement in the minimum baseline  
security for the lowest common denominator of residential users,  
without C) gravely damaging the utility of the public Internet for  
everyone.

Do you agree with the design team that breaking IKE and IPsec  
altogether by DEFAULT isn't acceptable?

If you don't break authenticated IKE and IPsec by DEFAULT, then a  
specialization of the attack I describe above will still be possible,  
and CPE router firewalls will not be in any position to guard against  
it.  Conversely, *unless* you break authenticated IKE and IPsec by  
DEFAULT, then restricting all other flows will only serve as a  
perverse incentive to use a contrived anonymous authentication in IKE  
and IPsec (instead of the more appropriate and standards track BTNS)  
when bypassing CPE simple security, because that's the only reliable  
and legitimate way to initiate secure communications with residential  
endpoints.

In fact, as BTNS is currently specified, limiting inbound flows only  
to IPsec and authenticated IKE might still not reduce the attack  
surface significantly.  You'd have to specifically recommend breaking  
BTNS with an IKE-layer filter, and even that would only stop the  
*standard* method of anonymous authentication, not any of the non- 
standard ones that would surely arise as legitimate methods of  
bypassing CPE simple security.

In simple terms: it may turn out that the attack scenario under  
discussion here cannot be addressed effectively in the long term  
except by blocking inbound tunnel protocols *altogether*, including  
IPsec and IKE, yet the price to pay for any mechanisms we recommend  
now is a recurring one stretching indefinitely into the future for as  
long as a significant fraction of the residential networks have CPE  
deployed that follows the practice in this draft.

Is preserving the utility of inbound IKE and IPsec across residential  
site boundaries really a controversial idea?  Does the working group  
believe that IKE and IPsec are flawed because they don't rely on  
middleboxes to allow only "trustworthy" exterior nodes to initiate key  
exchange and security associations with interior nodes?  The design  
team didn't believe so.

The design team also considered leaving inbound IKE and IPsec  
unrestricted by DEFAULT while recommending stricter limits on other  
inbound tunnels, but we were unpersuaded that the substantial loss of  
network transparency would be an acceptable price to pay for the  
meager reduction in attack surface area associated with them.  Others  
may disagree with the design team on that decision, and their opinions  
are welcome in the working group discussion.

We don't believe we have been chartered to challenge the utility of  
IPsec and IKE for exterior nodes initiating secure communications with  
interior nodes protected by residential CPE simple security, and we  
have taken care not to do so.  The rest of our decisions relevant to  
this discussion follow from that one.

To summarize, what you see above is the line of reasoning that led the  
design team to specify sections 3.2.4 and 3.2.5 as they are in the  
current draft.  Are there objections to the detailed recommendations?

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering