Subject: Fwd: Simple Security - Layered Filtering should be in the document

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Tue, 28 Jul 2009 16:36:33 -0700

>
>James,
>Layered filtering should be included in the document. It is an 
>OPTION that people really need in an environment where the use of 
>tunneling is growing rapidly. I would appreciate it if others who 
>agree would ack this email to the list.
>
>I volunteer to write the text needed to achieve this. I believe 
>Yaron Shaffer would help as well.
>
>Gregory.
>
>+++++++++++++++++++++++
>IETF-related email from
>Gregory M. Lebovitz
>Juniper Networks
>g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m

+++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m

---

From: Pekka Savola <[email-masked]>
Date: Wed, 29 Jul 2009 10:32:21 +0300 (EEST)

On Tue, 28 Jul 2009, Gregory M. Lebovitz wrote:
>> James,
>> Layered filtering should be included in the document. It is an OPTION that 
>> people really need in an environment where the use of tunneling is growing 
>> rapidly. I would appreciate it if others who agree would ack this email to 
>> the list.

Could you provide a list of, say, 5 CPE equipments from various 
vendors in sub-100$ price range that currently provide this feature 
(with v4)? That might go a long way in convincing those unbelievers in 
the WG such as myself that this is a common and important feature in 
this context?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 29 Jul 2009 09:56:44 +0200

Pekka Savola wrote:
>>> Layered filtering should be included in the document. It is an OPTION
>>> that people really need in an environment where the use of tunneling
>>> is growing rapidly. I would appreciate it if others who agree would
>>> ack this email to the list.
> 
> Could you provide a list of, say, 5 CPE equipments from various vendors
> in sub-100$ price range that currently provide this feature (with v4)?
> That might go a long way in convincing those unbelievers in the WG such
> as myself that this is a common and important feature in this context?

Speaking from the enterprise operations perspective the reliance on port
443 ssl as a generic tunneling mechanism (think ssl vpn) greatly reduces
the utility of layered filtering. To the extent that you succeed in
getting people to put strong crypto on the wrapper the payload becomes
opaque.

---

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Wed, 29 Jul 2009 01:54:51 -0700

At 12:32 AM 7/29/2009, Pekka Savola wrote:
>(with v4)? That might go a long way in convincing those unbelievers 
>in the WG such as myself that this is a common and important feature 
>in this context?

Point well taken in v4, Pekka. But the Internet is changing. There 
wasn't tons of encapsulation layering in the past. It's becoming more 
and more relevant now, and especially in v6. I'm sitting in Softwires 
WG right now. Most of this is about tunneling one IP think over 
another. We're on the 5 proposal now, or so.

Conclusion: I don't think looking at what vendors have been doing for 
the past 10 years is a good indicator of what is needed in the next 
10 years, because the networking is dramatically changing.

Hope that helps,
Gregory.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Jul 2009 11:18:48 +0200

On 29 jul 2009, at 10:54, Gregory M. Lebovitz wrote:

> wasn't tons of encapsulation layering in the past. It's becoming  
> more and more relevant now, and especially in v6. I'm sitting in  
> Softwires WG right now. Most of this is about tunneling one IP think  
> over another. We're on the 5 proposal now, or so.

> Conclusion: I don't think looking at what vendors have been doing  
> for the past 10 years is a good indicator of what is needed in the  
> next 10 years, because the networking is dramatically changing.

So what?

Let me reiterate a point that I made yesterday: you can't attack a  
host with an encapsulated packet unless the host is actively  
decapsulating. That's why it's not an issue to allow IPsec through: a  
host will simply ignore those packets unless it's interested in IPsec  
traffic to/from the remote host in the first place. So you can't do  
password brute forcing or exploit daemon vulnerabilities through  
encapsulated packets in the general case. And if the host is  
decapsulating, it obviously wants to receive those packets to provide  
some kind of utility to the user so then blocking them gets in the way  
of the user.

Also don't forget that today's hosts are well prepared to fend for  
themselves, they don't need firewalls like a pre-SP1 Windows XP  
machine does. If that weren't true there'd be a big "clean up your  
system after it has been compromised on the completely open IETF  
network" activity in the terminal room. Hosts connect to 3G or wifi  
networks that may or may not be firewalled all the time and that  
rarely creates problems that would be avoided by the type of filtering  
I'm seeing proposed in addition to what's already in the draft.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 29 Jul 2009 12:19:11 +0300

Hi Gregory,

Yes, I will be happy to help. I suspect though that this cannot be optional,
if we assume that all (most?) transition mechanisms will use tunnel
mechanisms. In other words, if you enable tunnel traffic by default, you
should have security for this traffic, by default. 

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Gregory M. Lebovitz
> Sent: Wednesday, July 29, 2009 1:37
> To: [email-masked]
> Subject: Fwd: Simple Security - Layered Filtering should be in the
> document
> 
> 
> >
> >James,
> >that people really need in an environment where the use of tunneling is
> >growing rapidly. I would appreciate it if others who agree would ack
> >this email to the list.
> >
> >I volunteer to write the text needed to achieve this. I believe Yaron
> >Shaffer would help as well.
> >
> >Gregory.
> >
> >+++++++++++++++++++++++
> >IETF-related email from
> >Gregory M. Lebovitz
> >Juniper Networks
> Scanned by Check Point Total Security Gateway.

---

From: Shane Amante <[email-masked]>
Date: Wed, 29 Jul 2009 18:07:57 +0200

Greg,

On Jul 29, 2009, at 10:54 GMT+02:00, Gregory M. Lebovitz wrote:
>> in the WG such as myself that this is a common and important  
>> feature in this context?
>

I agree with what Pekka said, however I'll add an additional twist.   
Specifically, it's important to bear in mind the principle of "least  
surprise".  IOW, if this isn't widely implemented in v4 CPE routers  
today, then it's a new thing non-technical users will have to  
specifically learn to disable in v6 CPE routers to get things working  
in a v6 world.

On a separate, but related, note, I would also add the obvious  
argument that if the proposal is to enable filtering for protocols  
within the tunnel, then this will restrict a significant avenue of  
deployment and/or expansion of new (Internet) protocols over tunnels,  
which IMO is NOT a good thing.  For better or worse, tunneling seems  
to be a default avenue for building new protocols on top of legacy  
infrastructure.

-shane

---

From: james woodyatt <[email-masked]>
Date: Wed, 29 Jul 2009 18:51:15 +0200

> Yaron Shaffer would help as well.

Before we get too far into this, I think it's important to note that  
there are two separate concerns regarding the treatment of IP-in-IP  
and GREv1 tunnels by IPv6 Simple Security.

+ Whether to disallow inbound tunnel initiations by DEFAULT.

+ Whether to write recommendations for applying stateful filters to  
the encapsulated content in tunnels.

The answer to each of these questions is independent of the other.   
The complication that I predict will consume an excessive quantity of  
time and mindshare is that the DEFAULT forwarding policy for  
encapsulated flow initiations need not-- and probably SHOULD NOT-- be  
identical to the forwarding policy for non-encapsulated flow  
initiations.  Setting a DEFAULT policy for encapsulated flow  
initiations may not even be really possible to specify as a best  
current practice.

I'm not even aware of any examples of actual current practice in IPv6  
firewalls.  What do enterprise IPv6 firewalls do here in the DEFAULT  
configuration?  Probably DENY ALL, I expect... the assumption being  
that enterprise gear is always configured by experts prior to  
deployment.  That's not the case for residential simple security, so  
we have to be more careful.

What do you propose?

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

---

From: Gert Doering <[email-masked]>
Date: Wed, 29 Jul 2009 19:35:06 +0200

Hi,

On Wed, Jul 29, 2009 at 06:51:15PM +0200, james woodyatt wrote:
> configuration?  Probably DENY ALL, I expect... 

Well, enterprise gear tends to have a knob to switch the default policy
for "no rule specifically matched this traffic, so what to do with it?"
from PERMIT to DENY.

> the assumption being  

Right - enterprise gear tends to ship with "out of the box, it does
nothing at all" defaults, assuming that someone "in the know" will set it 
up the way they need it.

Residential is for people that want to plug it in and use it, and do
not understand anything about networking.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  128645

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Wed, 29 Jul 2009 16:27:33 -0700

>to be a default avenue for building new protocols on top of legacy

Shane, everything you say is quite right. And if tunneling is the 
default avenue for building new protocols, then you can bet the under 
ground economy attack authors are going to be forming exploits on 
them. Which is why customers need tools that are able to block them, 
if so desired. Without the finer grain controls they will be forced 
into an all-or-nothing decision of security. And that is worse. 
UI:  "do you want to be secure?" User:  "Heck yeah!" Then it all gets 
closed down. Not good.

Hope this makes sense,

Gregory.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 30 Jul 2009 14:14:55 +0200

On 30 jul 2009, at 1:27, Gregory M. Lebovitz wrote:

> if tunneling is the default avenue for building new protocols, then  
> you can bet the under ground economy attack authors are going to be  
> forming exploits on them. Which is why customers need tools that are  
> able to block them

Surprisingly, that doesn't necessarily follow.

What's needed is a mechanism to protect hosts from packets that:

1. They have no interest in receiving
2. Could harm them

Note that this is a weaker proposition than in a corporate  
environment, where the local interest in receiving packets is not a  
relevant factor. However, in a home environment we must allow users to  
be stupid if they so choose.

As far as I know, there are no existing <something>-in-IPv6  
encapsulations that mainstream OSes decapsulate by default. So any  
encapsulated packets will be dropped on the floor by a typical Windows  
or MacOS box, and as such there is no need to spend cycles to filter  
them out.

> if so desired

Of course going beyond what's in the draft is always a possibility,  
but that has to require an explicit action by the user, we need to  
have a standard level of permeability so the makers of peer-to-peer  
applications have a standardized way in.

I know there is a school of thinking that says incoming packets of any  
kind except ones explicitly desired by the host as shown by previous  
outgoing packets are unacceptable, but the consequence of that line of  
thought is that many classes of peer-to-peer applications become  
impossible. In this situation, only a simultaneous open can work, and  
these require a control channel and are notoriously hard to get right.

However, I would love to apply such a policy to my mailboxes, both the  
electronic and dead tree types.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 30 Jul 2009 17:53:19 +0300

[snip]
> or MacOS box, and as such there is no need to spend cycles to filter
For the sake of argument, if *all* the current <something>-in-IPv6 proposals
are standardized, then presumably they *will* go into mainstream OSes. And
we're planning exactly for that future - when IPv6 is widely available to
the home.
And hey, if there are no such packets, you're not wasting any cycles on
filtering them. Just a few IETF cycles :-)

Thanks,
	Yaron

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 30 Jul 2009 17:38:01 +0200

On 30 jul 2009, at 16:53, Yaron Sheffer wrote:

> are standardized, then presumably they *will* go into mainstream OSes.

So whenever there's a new protocol there must be a new filter?

Isn't it simpler for the hosts that don't want to receive certain  
packets to not run the protocol?

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 30 Jul 2009 19:57:27 +0300

No, setting up a new filter for each new app is obviously impractical. On
the other hand, you cannot expect any odd app to be secure, just because it
is part of the OS. So the best we can do is have the generic filter "closed"
by default, and have applications open pinholes as necessary (when the app
is started, or when the user configures it to accept incoming connections,
or whatever). It's not as secure as I would have liked, but it's better than
leaving everything wide open.

And hopefully this doesn't have anything to do with net neutrality...

	Yaron

> From: Iljitsch van Beijnum [mailto:[email-masked]]
> Sent: Thursday, July 30, 2009 17:38
> To: Yaron Sheffer
> Cc: Gregory M. Lebovitz; Shane Amante; Pekka Savola; [email-masked]
> Subject: Re: Simple Security - Layered Filtering should be in the document
>

---

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Thu, 30 Jul 2009 23:56:17 -0700

>So whenever there's a new protocol there must be a new filter?

Maybe not for home gateways, but for true policy enforcement points 
in the network, yes, that his the case.

>packets to not run the protocol?

Sure. If all the valuable possessions in my home were unremovably 
bolted to the floor, and it was impossible for anyone without the 
retinal patterns and fingerprints of my direct family and invited 
friends to tough any of those things, then yes, I would have no need 
for the locks on my home's doors. Likewise, if hosts were perfect at 
protecting themselves and the network infrastructure between them 
across all subnets, then there would be no need for network perimeter filters.

Gregory.

---

From: Gert Doering <[email-masked]>
Date: Fri, 31 Jul 2009 09:27:40 +0200

Hi,

> across all subnets, then there would be no need for network perimeter 

That's actually missing the point.  

This analogy isn't going to work as you would need to envision a 
"tunneled" burglar who would only be able to steal or touch enything 
if there is someone inside who "un-tunnels" the burglar.

On all common OSes, a tunneled packet will just be ignored unless a 
specific un-tunneling device is configured - and if you configure
such an interface, it's reasonable to assume that you want to receive
these packets (IPSEC comes to mind).

Don't forget we're not talking about enterprise maximum annoyance^Wsecurity
policy enforcement devices but about "simple security for home networks".

Gert Doering
        -- NetMaster

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 31 Jul 2009 12:18:55 +0300

Hi Gert,

Your argument is valid today. But once any tunnel-based transition mechanism
is standardized and widely adopted by commercial operating systems, there
will be untunneling done by default, with no security mechanisms attached.
Note that IPsec requires access control from all implementations, but other
mechanisms don't. So suddenly you have to be wary of "tunneled burglars",
too.

Thanks,
	Yaron

> From: Gert Doering [mailto:[email-masked]]
> Sent: Friday, July 31, 2009 9:28
> To: Gregory M. Lebovitz
> Cc: Iljitsch van Beijnum; Yaron Sheffer; Shane Amante; Pekka Savola;
> [email-masked]

---

From: james woodyatt <[email-masked]>
Date: Fri, 31 Jul 2009 11:43:04 +0200

> mechanisms don't. So suddenly you have to be wary of "tunneled  

We already have two standard, automatic, transitional tunnel  
mechanisms: 6to4 and Teredo, both of which are explicitly treated in  
the current draft.  The DS-Lite protocol comes to mind as a third  
example, but its automatic usage would have to be enabled directly by  
the residential gateway with a DHCP6, which would be *stupid* because  
it would make infinitely more sense to terminate the DS-Lite tunnel in  
the gateway directly.

It's hard to imagine why any new transitional tunnel mechanisms might  
need to be developed, widely deployed and enabled in ubiquitous  
default platform configurations.

Do you know about something else that the rest of us don't?  Please  
share.

---

From: Gert Doering <[email-masked]>
Date: Fri, 31 Jul 2009 11:48:49 +0200

Hi,

> will be untunneling done by default, with no security mechanisms attached.

Given the history of operating systems (changing from "every service is
running by default and reachable from the whole world" to "only those
services that are needed are running, and everything is firewalled by
default") I find your assumption quite unlikely.

Gert Doering
        -- NetMaster