Re: NATs as firewalls

[Elwyn Davies <elwynd at dial.pipex.com>]

John C Klensin wrote:
> (off list)
>
> --On Tuesday, 06 March, 2007 15:46 -0800 Tony Hain
> <alh-ietf at tndh.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.
>   
Also this appears to be tied to the US business model where the ISP 
supplies you with the box and you don't get to change it (or even own it).
For example in the UK we are already down the path of selling such a DSL 
+ NAT/fireewall + router box (I have one here) but the ISP just sells me 
the DSL connection.  Depending on which ISP I choose they may sell or 
rent me a specialized box (e.g. BT which has estra telephone 
capabilities) or just sell/rent me a standard off the shelf 
modem/router.  The ISP managing the box would be a non-starter in most 
cases here.  I believe it would contravene the regulatory rules if you 
forced to buy the ISP's box.

/Elwyn
> 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.org
> https://www1.ietf.org/mailman/listinfo/ietf
>
>   

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf