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)

[Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>]

On Thu, 28 Aug 2008 09:48:25 +0200
Rémi Denis-Courmont <rdenis@simphalempin.com> wrote:

> 
> On Thu, 28 Aug 2008 07:12:00 +0930, Mark Smith
> 
> <ipng@69706e6720323030352d30312d31340a.nosense.org> 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
> 
>