[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CPE equipments and stateful filters
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
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
- 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
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
- 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
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.