Re: CPE equipments and stateful filters

[Fred Baker <fred@cisco.com>]

we seem to be talking past each other. I have a very strong feeling  
that some of us are not listening, or deliberately misunderstanding.  
I'll refer you to my note of 24 July 8:34 AM PDT; this one builds on  
that.
The objective of IPv6 is to restore the end to end addressing  
architecture. I believe that it does that, if we don't install  
network address translation and in so doing jinx that.
Alain's comment in the plenary Thursday evening that James document  
and my comments on this list advocate NAT are, in the best possible  
case, incorrect - nobody is talking about NAT in IPv6, although I do  
believe that there will be places that network operators choose to  
use that class of capability. In the worst case, it constitutes a  
deliberate misstatement calculated to cause confusion and troll for a  
flame war in this venue. I choose to believe the former, although I  
ask myself the question.
Alain's comment in the v6ops meeting Monday afternoon is patently  
disingenuous, however. His assertion was that there should be no  
protection of the capacity in a home because he wants to offer  
services in the home. Well, if the network is one of his subscribers,  
he already has a trojan in the network - the set-top box. It will  
manage all of the services he offers, and for a significant subset of  
them will be the chassis from which his service is offered. That set- 
top box will be configured by him and installed (often by his  
subscriber) in the subscriber network. It will connect to equipment  
in his network and offer those services. So traversal of a stateful  
firewall (my canonical example of which is a Cisco CBAC firewall,  
google for it) is in his case an absolutely done deal.
Now let me make an observation. RFC 4193 describes "Unique Local IPv6  
Unicast Addresses". They, and their predecessors, Site-local  
Addresses, were defined because there is a recognized need in  
networks - there are systems for which there is no legitimate reason  
that a system in a different network would ever communicate with it  
other than directly using a link-local address. Obvious examples  
include routers and other network equipment; such systems also  
include servers that are intended to be private to the company. There  
is a move right now to centrally assign prefixes for unique local  
addresses to administrations, the reason being to ensure that  
neighboring networks do not in fact accidentally choose the same  
prefix and so expose themselves to each other. So we as a community  
have agreed that not all hosts should be reachable by other hosts.  
This provides a routing solution to a basic issue addressed by common  
firewalls - hiding systems from each other and making it impossible  
for them to communicate.
Question: under what circumstances would my upstream provider enable  
me to access systems in his network? I can think of three potential  
reasons:
- for me to be able to send datagrams using my upstream router
- for me to access servers and services in his network that I have
  contracted for access to
- for my network to exchange information with the upstream network;
  routing, network management, and so on

I suspect that any other system will be completely inaccessible to  
me. The reason is essentially that I have no need to know and no  
legitimate reason to access it.
So, question: what is the argument that I must open all of my systems  
to him? If I am multihomed, what argument says that this must be  
observable by one of those upstream networks, or that my use of  
competing services need be visible to him? Alain wants to offer  
services in my home; what if I don't want them? How do I know that  
the services he is deploying are benign to me? Lawful Intercept is a  
service...
If I have contracted services from Alain's company, why would I not  
make it possible to use those services?
Now, let's talk a little about how a stateful firewall (which is  
different than a NAT) works. The internal implementations vary, but  
in the simplest case a stateful firewall is a network-layer-only  
device. It has an "inside" and an "outside". On the "inside"  
interface, any new session perceived outbound results in a dynamic  
access list entry permitting responses to its messages to enter the  
network on the "outside" interface. On the "outside" interface, there  
are essentially three sets of rules:
 - traffic responding to datagrams from "inside" is permitted
 - other traffic that has been pre-authorized is permitted
   example: an ACL rule permitting SMTP traffic to go to an internal  
mail server
 - everything else is denied

What is the reason for that? To prevent misuse of the capacity in the  
network. Yes, it is often seen as a protection of the host, but the  
sense in which that is actually true is limited. Most attacks happen  
from behind the firewall, and in any event there are ways to subvert  
such defenses by having a trojan access outbound.
Now, Remi (I believe) observed that address-based rules like "let  
mail traffic go to my mail MTA" are a bit dated. OK, no problem. That  
said, one of the most effective spam filters in use today is based on  
a simple reputation service - one allows mail from one's business  
partners to get to one's secondary spam trap, but traffic from bots  
(whose addresses are determined and distributed by some form of  
reputation service) are in effect null routed. The SYN never gets to  
the secondary spam trap, the SYN ACK never gets back, a RST kills the  
session, or maybe the EHLO is responded to with an appropriate error  
message. Bottom line, a very high percentage of spam email simply  
never leaves the bot. No prophylactic protection on one's network?  
Well, I guess we'd better rethink our spam filters. SpamAssasin and  
its cousins are excellent secondary spam filters, but at least at my  
company refusing the SYN from a bot is orders of magnitude less  
costly and more effective.
We also discussed the use of firewall traversal protocols like UPnP.  
I profess no knowledge of the particulars of any of them, but in  
concept they are pretty straightforward. Given a global address  
space, if I want an application to have access to the systems in my  
home and trust it to not misuse the capacity I have provided, I have  
two choices. I can go to each system and configure it accordingly, or  
if I have a prophylactic I can program the firewall. In reality, I  
probably do both. I configure the firewall with some appropriate  
credential and give that credential to the peer I want to grant  
access to, and now anyone that has that credential can get added to  
my "came from inside" dynamic rule or to the list of pre-authorized  
sessions. If one does that, sessions initiated from outside are  
pretty straightforward.

Lets make one thing real clear. It is abundantly clear to the vendors  
in the room that there is a market for IPv6 CPEs with firewalls.  
Technology religion to the contrary isn't going to stop that. So  
shouting at the top of your lungs that "we don't like firewalls" is  
in essence pissing into the wind. Save your breath. The products are  
going to be built and deployed. It is equally clear that there is a  
set of people who don't want to deploy a firewall. More power to them  
- the firewall capability needs to be optional, either by product  
feature set or by configuration. The market they represent will  
dictate either that there will be routers without firewall features  
or that ones with firewalls features can be usefully deployed without  
them. vedors will respond to them as well.
We need to not be silly enough to think that one size fits all. If  
the service providers can hide their network elements, homes need to  
be able to do the same thing, and for the same reason.