Subject: RE: NATs as firewalls

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 7 Mar 2007 08:07:36 -0800

I agree with John's analysis of the constraints here.

It may be possible to get the ISPs to move on the expectation that if they do nothing government coertion will follow. The caveat here being that the pressure the vendors are most likely to be responsive to would be from the US and it is not likely that the ISPs would become concerned about iminent regulatory changes from an outgoing administration, particularly since uniquely in recent history there is no expectation that a sitting President or Vice President will be on the ballot in 2008.

The ISPs face costs from bots on their nets, so there is a direct cost benefit. I don't think that the game of charging to eliminate caps would be viable for devices other than a cable/dsl modem rented from the ISP. That approach would introduce a harmful oppositional dynamic with the slashdot crowd.

At present I would be happy to simply stop the problem getting worse by getting such measures introduced into legacy gateways.

Turnover of the legacy base is somewhat harder. One thing that I have found personally is that the WiFi hardware currently supplied is poorly made and not fit for 24/7 operation. The devices overheat in hot weather, the WiFi service definitely degrades over time. I have a box full of deceased brand name routers. If my experience is representative we don't need to worry much about turnover.

Otherwise what I would try to do to drive turnover would be to tie the security (bot capping) and future proofing (IPv6 transistion management) to a branding campaign that provides the user with a tangible direct benefit, vis peer-to-peer video conferencing 'just works' and administration issues 'just work'.

We agree at the requirements level here: peer to peer video conferencing must work seamlessly. The difference is that I am prepared to require the applications to make adjustments to allow for the deployment of NAT while you appear to be insisting on a particular means of achieving that requirement.

> -----Original Message-----
> From: John C Klensin [mailto:[email-masked]] 
> Sent: Wednesday, March 07, 2007 9:09 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: NATs as firewalls
> 
> (off list)
> 
> --On Tuesday, 06 March, 2007 15:46 -0800 Tony Hain 
> <[email-masked]> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Mar 2007 12:01:22 -0500

--On Wednesday, 07 March, 2007 08:07 -0800 "Hallam-Baker,

> I agree with John's analysis of the constraints here.

[skipping the conjectures about US politics -- it is a much
longer discussion that isn't clearly suitable for the IETF list] 

> The ISPs face costs from bots on their nets, so there is a
> direct cost benefit. I don't think that the game of charging
> to eliminate caps would be viable for devices other than a
> cable/dsl modem rented from the ISP. That approach would
> introduce a harmful oppositional dynamic with the slashdot
> crowd.

I would contend that such extra charges are in place now.
Whether one tries to get around it via public addresses, clever
NAT boxes, dynamic DNS, or otherwise, most of the ISPs in the
low-end market have terms and conditions of service that
prohibit "servers" and many prohibit long-lived connections.
Depending on the ISP, one may or may not be able to ignore those
constraints but, if one wants them removed, it typically
requires a shift from a "residential" to a "commercial" product.
And that shift is typically, modulo some support promises and
the like, essentially "same product, different (contractual)
blocks, higher price".

[ More speculation omitted without either agreeing or
disagreeing] 

> We agree at the requirements level here: peer to peer video
> conferencing must work seamlessly. The difference is that I am
> prepared to require the applications to make adjustments to
> allow for the deployment of NAT while you appear to be
> insisting on a particular means of achieving that requirement.

I am probably more agnostic on that subject than I appear.  It
is true that I tend to be pessimistic about changes to deployed
applications that can't be "sold" in terms of clear value.  I'm
also negative about changing the architecture to accommodate
short-term problems.  As examples of the latter, I've been
resistant to changing (distinguished from adding more features
and capability to) the fundamentals of how email has worked for
30+ years in order to gain short-term advantages against
spammers.  And, when I conclude that IPv6 is inevitable (unless
someone comes up with another scheme for global unique addresses
RSN), I get resistant to making architectural-level applications
changes that are justified on the basis of making the IPv4 space
behave better under scarcity.  You haven't justified NATs on
that basis so, on a case-by-case evaluation of particular
applications and particular adjustments, we might even agree,
although I'd predict that I'd be more conservative about the
choices than you might be.

     john

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 7 Mar 2007 11:26:49 -0800

JFC Morfin wrote:
> Dear Phillip,
> I do not think USA will have any say into this. For several reasons.
> They are the last to be harmed by IPv4 addresses shortage and most
> probably the home of the addressquatters. 

This is BS that just has to stop. The ARIN region continues to burn through
~30% of the space that is consumed every year. Everyone that is looking for
an address after the pool runs dry will feel the same impact, the only
question is who will get there first. 

On top of that look closely at the graph I referenced yesterday and you will
note that the RIPE region is burning through space the fastest. The last I
looked Geoff's numbers showed the APnic region having the fastest growth in
the routing system, so where are all those addresses going in Europe?

Tony

---

From: Douglas Otis <[email-masked]>
Date: Wed, 7 Mar 2007 11:32:47 -0800

On Mar 7, 2007, at 9:01 AM, John C Klensin wrote:

> It is true that I tend to be pessimistic about changes to deployed  
> also negative about changing the architecture to accommodate short- 
> term problems.  As examples of the latter, I've been resistant to  
> changing (distinguished from adding more features and capability  
> to) the fundamentals of how email has worked for 30+ years in order  
> to gain short-term advantages against spammers.

There will be growing concerns related to abuse when ISPs deploy IPv6  
internally and then use IPv4 gateways to gain "full" access to the  
Internet.  Any changes related to controlling abuse should be aimed  
at identifying entities controlling transmission.  Resolving the  
address using a domain name at least identifies the administrative  
entity of the client.  For example, multimedia streaming has been  
fraught with security exploits.

As traffic merges into common channels, there will be a desire to  
minimize cryptographic identifier abuse, in particular for things  
like DKIM.  While there exists an experimental method for a domain to  
"authorize" a client, this technique represents a significant  
hazard.  This hazard is created by the iterative construction of  
address lists and the macro expansion of local-part components of a  
email-address.  The inherent capability of this method permits a  
sizable attack to be stage without expending additional resources of  
the attacker.  In addition, this experimental scheme fails to  
identify the point of transmission staging the attack.

Those offering outbound services desire that acceptance be based upon  
their customer's reputation rather than upon that of their  
stewardship.  With the experimental scheme, the administrative entity  
for the client is not relevant, although essential when guarding  
against abuse.  There are several orders of magnitude more customers  
than outbound service providers.  Guarding against abuse must depend  
upon a means to consolidate the entities being assessed.

There are millions of new domains generated every day at no cost to  
the bad actors.  When IPv6 becomes more common, the IP address may  
even exceed a scalable defensive.  The long standing practice  
allowing clients to remain nameless will need to change.  For SMTP,  
the EHLO should resolve.  Any authorization scheme should then be  
based upon a name lookup and not upon a list of IP addresses for  
thousands of transmitters.

-Doug

---

From: Simon Leinen <[email-masked]>
Date: Sun, 11 Mar 2007 17:41:18 +0100

Tony Hain writes:
> On top of that look closely at the graph I referenced yesterday and
> you will note that the RIPE region is burning through space the
> fastest. The last I looked Geoff's numbers showed the APnic region
> having the fastest growth in the routing system, so where are all
> those addresses going in Europe?

By asking "where are all those addresses going in Europe", you suggest
that address hoarding has already started in the RIPE region.  I'm not
sure whether that's the best explanation for what you are seeing.

My counter-hypothesis would be this: Newly allocated addresses see a
similar (high) level of actual usage between the APNIC and RIPE
regions, but the general level of route aggregation differs
significantly between the regions.

For an illustration of the regional differences in route aggregation,
check out the "deaggregation factor" in the Weekly Routing Table
Reports (e.g. http://www.merit.edu/mail.archives/nanog/msg05078.html).
For possible reasons for these differences, I believe there was a
short presentation on this (by Philip Smith?) at the NANOG meeting
last month, but I cannot find the proceedings right now.
-- 
Simon.