-----Original Message-----
From: John C Klensin [mailto:john-ietf(_at_)jck(_dot_)com]
Sent: Wednesday, March 07, 2007 9:09 AM
To: alh-ietf(_at_)tndh(_dot_)net
Cc: ietf(_at_)ietf(_dot_)org
Subject: RE: NATs as firewalls
(off list)
--On Tuesday, 06 March, 2007 15:46 -0800 Tony Hain
<alh-ietf(_at_)tndh(_dot_)net> wrote:
While I agree with Brian that the enterprise draft will be
difficult,
I also believe the SOHO one will be virtually impossible to get
agreement over.
I agree, although I think we might disagree a bit about the
reasons. On the other hand, I also think that a serious IETF
(or other) effort to try to define such a thing would have
value, even if it only produced an info document about why
the problem is hard and what the issues are before failing
and collapsing.
The issue is that most ISP's
don't yet get the point that the device needs to be dual managed,
because they are still in the mindset that there are just a
couple of
devices behind each customer nat at most and very little
change to the
configuration over time.
Hmm. Unless the economics of ISPs who deliver services to
residences and SOHO setups have changed _very_ significantly
since I was last deeply immersed in those very confidential
numbers, no one is doing any real remote management regardless
of what Phillip considers appropriate or necessary. One could
imagine ISPs able to download new images that were the same
for everyone, but the margins just aren't there for anything
other than the "everyone gets the same boundary config and
you can put whatever you like behind it" or "if you fuss with
this, it is your problem" arrangements that are prevalent today.
My guess is that the economics would support a device that
combined a cable modem or DSL box with some significant
inbound and outbound firewall capabilities, including the
ability to do some rate-limiting, reasonable control over
ICMP as well as TCP and UDP and probably some real-time
protocol. I'd expect that box to be delivered to the
customer either fully locked up or configured at setup time
with any new configuration requiring
payment of a separate fee. If I were designing one of these,
I think I'd put a couple of flash memory slots in it (SD or
whatever one prefers) that could be used to reimage or reprogram
the box or give the customer more control. They wouldn't do
anything that could not, in principle, be done over the net
but the idea of sending the customer off to _pay_ for an
unlocking function or some other set of functions and then
receiving a key would, I think, be a lot more plausibly
marketable than paying for something that appears to be less tangible.
And that is the answer to Phillip's concern about what to do
about old hardware too. Just as Verizon sent me a letter
last week that said that I'd better have a plan about getting
rid of any analog-capable mobile phones I might still have,
the ISPs, if backed by either judicial or government
pressures (which I believe to be necessary to accomplish
anything) could easily put out a note that says "a reasonable
level of protection for the network from you is now
necessary. That can be done in two ways. One is to upgrade
your box, which will also give you the capability of
obtaining fewer restrictions. The other is that we do it
centrally, which will give you a very restricted environment
(but not so restricted as to have impact on the typical
residential user), and we will charge you a fee for it."
FWIW: nat has not slowed the consumption of IPv4 addresses
enough to
be the panacea people keep hoping for. It is clear that
most network
managers are going to do squat until there is a crisis to force
action. That will occur sometime after 2010 when they need
more than
they already have and find that the lease price per IPv4
address per
day has been moving up from its current averages of $1/day
or $5/day
depending on contract length (a price service providers
seem to have
no trouble collecting while the addresses are still Free
from IANA).
For those who wonder about the date see:
tndh.net/~tony/ietf/IPV4-pool-combined-view.pdf
Agreed, but we have had this discussion before. And I am in
strong agreement that the perception of crisis --either of
the type you identify here or of a serious threat of
regulation or litigation as above-- is the only thing that is
likely to create actual motion. If nothing else, the margins
are just too small to do anything "because it is good" if it
drives up costs even to the extent of a few training courses
for support staff.
There will need to be something, almost certainly external,
that can be blamed as a reason for introducing disruption,
forcing new hardware, or increasing costs (probably all three
in practice). But, if we can predict something happening,
under any scenario about cause, the time for the IETF to get
started on its part of the job is "soon" or even "now", not
after the crisis occurs and everyone starts running off in
their own directions because no one has pointed the way.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf