Subject: IPv6 transition technologies

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Mon, 2 Jul 2007 01:56:56 +0900 (JST)

> NAT-PT really needs to be wiped off the face of the earth.  It provides
> all of the disadvantages of IPv4+NAT with all of the transition costs of
> IPv6.  If there is ever any significant penetration of NAT-PT, then the
> pseudo-IPv6 network will not be able to support any more kinds of
> applications than the NATted IPv4 does today.

	i tend to agree, but in rfc-index.txt i could not find the change of
	state to "Historic".  what happend to very similar (and much more evil
	IMHO) transition technology, SIIT?

itojun

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

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 1 Jul 2007 10:49:39 -0700

>	IMHO) transition technology, SIIT?

<https://datatracker.ietf.org/idtracker/?search_filename=draft-ietf-v6ops-natpt-to-historic> 
indicates that the document making NAT-PT is in the RFC Editor's 
queue.

--Paul Hoffman, Director
--VPN Consortium

---

From: John C Klensin <[email-masked]>
Date: Sun, 01 Jul 2007 20:36:36 -0400

--On Sunday, 01 July, 2007 10:49 -0700 Paul Hoffman
<[email-masked]> wrote:

>>  > NAT-PT really needs to be wiped off the face of the earth.
>>  > It provides all of the disadvantages of IPv4+NAT with all
>>>  of the transition costs of IPv6.  If there is ever any
>>>  significant penetration of NAT-PT, then the pseudo-IPv6
>>>  network will not be able to support any more kinds of
>>	i tend to agree, but in rfc-index.txt i could not find the
>>	change of state to "Historic".  what happend to very similar
>>	(and much more evil IMHO) transition technology, SIIT?
> 
> <https://datatracker.ietf.org/idtracker/?search_filename=draft
> -ietf-v6ops-natpt-to-historic> indicates that the document
> making NAT-PT is in the RFC Editor's queue.

I wasn't aware that the RFC Editor couldn't simply move a
document to historic in the index when something is queued that
explains that action.  The two actions -- reclassification and
publication-- ought to be largely independent.   Or is this
another example of the triumph of procedure over good sense?

    john

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 1 Jul 2007 18:00:39 -0700

>another example of the triumph of procedure over good sense?

Or is this another example of not reading all of the information in 
the I-D tracker or the ietf-announce mailing list?

<http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg03556.html>

"This document also reclassifies RFC 2766 from Proposed Standard to 
Historic status."

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Mon, 2 Jul 2007 17:29:11 +0900 (JST)

> indicates that the document making NAT-PT is in the RFC Editor's 

	i am not convinced at all with the content of the draft.  if NAT-PT
	is to be made historic due to the claims presented in the draft,
	all of the NAT related documents have to be made historic, instead of
	informational, since "informational" can be misleading to people who
	try to implement stuff.
	the worst of all is RFC3235.  and all of the NAT traversal documents
	(RFC3489, RFC3519, RFC3715, RFC3947, RFC4091, RFC4092, RFC4380) has to
	be banned at once.

itojun@fahrenheit 911

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 02 Jul 2007 10:35:59 +0200

> 	IMHO) transition technology, SIIT?

If you look at draft-ietf-v6ops-natpt-to-historic-00.txt (the
draft that obsoletes NAT-PT), it is quite critical of SIIT
(RFC 2765), but does not obsolete it.

[I attempted to obsolete SIIT before it was written (RFC 1671
section B) but that didn't work :-) . There are parts of
RFC 1671 that are wrong, but not that part.]

     Brian

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Mon, 2 Jul 2007 17:39:09 +0900 (JST)

> RFC 1671 that are wrong, but not that part.]

	i cannot agree more.
	maybe it is time to revisit draft-itojun-v6ops-v4mapped-harmful-02.txt?

itojun

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Jul 2007 07:01:28 -0700

Its not exactly a surprise, folk seem to place a higher premium on shooting NAT than anything else. Meanwhile the vast majority of residential broadband access is behind NAT.

And from a security point I want to see as much NAT as possible. Without NAT we would be in a much worse situation security wise than we are today. NAT is a blunt instrument but it shuts down inbound server connects. And that is such a good thing from the point of view of stopping propagation of network worms.

The situation is even worse when you consider the basis for the inter-ISP organizations that you might be able to use to drive a transition to IPv6. The ones that have the capability to drive change are built out around security issues - spam, phishing. They didn't like NAT because it was a threat to revenues, they would like to charge for every device in the house. But now they see it as driving down their security and customer service costs which is much more important to them.

When people are solving a problem with a blunt instrument the solution is to give them a better solution to meet their problem. I think I have found one, default deny infrastructure based on domain centric administration.

The security objective here is to lock down a network tighter than has ever happened in the past. Every hub, every NIC becomes a policy enforcement point and no packet moves anywhere in the network unless a policy says it should. Note here that the rules for the network are not the same as for the inter-network. The inter-network continues as before.

Default deny is quite straightforward, we could almost do it today with existing network tools and technologies, the only problem is that the administration load would be crippling. Every application or network change would require an administrative change and router updates to be processed and deployed.

Which brings me to domain centric administration. To support the security objectives we need a support infrastructure for network administration that gets us out of the machine code era. Today we don't administer networks, we administer individual hosts connected to the network. With rare exceptions such as SNMP we don't have network level abstractions, everything is configured manually at the level of individual config files.

In breif, give every device the ability to authenticate itself at build time, define a device description language, push the information out using the DNS [not multicast, not broadcast, not LDAP even, just plain old DNS plus a security layer]

draft-hallambaker-Domain_Centric-00

>From an IPv6 point of view domain centric administration makes the transition easy, the day IPv6 service becomes available at the ISP the system just configures itself to use it without any fuss. Its just like recompiling a 32 bit program to work on a 64 bit machine.

So now lets get back to why NAT today is a good thing.

Most residential systems don't need inbound service requests. So block them. Its not quite default deny, its much blunter, but it creates real cost reductions. 

>From a security point of view the idea that we will ever arrive at a situation where the endpoints are secure against penetration attacks is nonsense. Not when the endpoints have ten million lines of code runing (linux) or a hundred million (vista). We could put every programmer in the world on fixing bugs, they would generate almost as many as they fixed.

We have to arrive at a network version of Butler Lampson's security reference monitor, something that is small, lightweight and simple enough to be coded reliably. We put our best people on coding that component and we we make it pervasive. A firewall comes close but its not as fine grained as we want.

Default deny allows the same benefit to be achieved without the collateral damage. Instead of shutting off every inbound service we enable precisely the services we require to be externally visible. The NAT configuration can be appropriately enabled at the same time. 

> -----Original Message-----
> From: Jun-ichiro itojun Hagino [mailto:[email-masked]] 
> Sent: Monday, July 02, 2007 4:29 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: draft-ietf-v6ops-natpt-to-historic-00.txt
> 
> > >>  all of the disadvantages of IPv4+NAT with all of the transition 
> > >> costs of  IPv6.  If there is ever any significant penetration of 
> > >> NAT-PT, then the
> <https://datatracker.ietf.org/idtracker/?search_filename=draft-ietf-v6
> > ops-natpt-to-historic> indicates that the document making 
> NAT-PT is in 
> > the RFC Editor's queue.
>

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 02 Jul 2007 23:20:36 +0900

>Its not exactly a surprise, folk seem to place a higher premium on
>shooting NAT than anything else. Meanwhile the vast majority of
>residential broadband access is behind NAT.
>
>And from a security point I want to see as much NAT as possible. Without
>NAT we would be in a much worse situation security wise than we are
>today. NAT is a blunt instrument but it shuts down inbound server
>connects. And that is such a good thing from the point of view of
>stopping propagation of network worms.
(snip)

	a few points.  IPv6 technology really needs to be demystified.

	you do not have to rewrite IP address to ensure that there's no
	inbound connections.  you just have to have a packet filter which
	watches/drops TCP SYN or whatever alike.  if you do not have enough
	address space to serve your enterprise, it is a good reason to use
	IPv6 :-)

	even if you have NAT, or any middle system which rewrites IP address/
	port number, or RFC3041 trick in your end system, your privacy is
	leaked by the use of HTTP cookie and OS fingerprinting.  if you do not
	use HTTP cookies, you cannot buy things at Amazon.  if you have RFC3041
	and other tricky systems, your system will have higher likelyhood of
	having implementation bugs (violation of KISS principle).

	even if you stop all inbound connections, malicious parties which
	controls HTTP/whatever servers can inject your end node any kind of
	crufted TCP options, which might cause buffer overflow (DoS/privilege
	user hijacking).  the only solution (internet-wise) to this is to have
	TCP relaying proxies like TIS firewall toolkit/Gauntlet.  even skype
	cannot go across TCP relays.

	spam, phishing and botnet are independent from presense/absense of NAT.
	OSes have to be secured by default, that's all.  heavy use of firewall/
	NAT have propagated "false sense of security" inside enterprise
	network, and therefore, many of end systems within enterprise are very
	vulnerable to attacks.  the most common attack vector these days are
	laptops owned by people like IETFers (goes in and out of enterprise)
	or VPN-connected laptops, which carry worms.  so, many people purchase
	end node firewall systems ("fire suit" in the old terminology), but,
	if your end node operating systems are secure by default, you do not
	need those end node firewall systems and/or keep upgrading signature
	files.

	http://www.openbsd.org/papers/asiabsdcon07-network_randomness/index.html

itojun

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Jul 2007 08:14:24 -0700

> From: [email-masked] [mailto:[email-masked]] 

> >And from a security point I want to see as much NAT as possible. 
> >Without NAT we would be in a much worse situation security 
> wise than we 
> >are today. NAT is a blunt instrument but it shuts down 
> inbound server 

My point here is that the principal objection being raised to NAT, the limitation on network connectivity is precisely the reason why it is beneficial.

There is no other device that can provide me with a lightweight firewall for $50.

> 	  if 
> you have RFC3041

Same can be said of IPv6.

We have a lot of really good ways of avoiding issues we don't like: complexity, accessibility, limited access in third world countries. 

Unless the arguments are applied consistently they should not be made at all. Otherwise they just become special pleading.

> 	user hijacking). 

As I told Bruce Schneier after his silly IPSEC and Certification Authority papers, security is risk control, not risk elimination. 

It is not helpful to criticise a security measure that empirically offers a high degree of security for failing to address cases it is not designed to deal with. An HTTP server behind a NAT box is no HTTP server and thus no threat.

In a full default deny infrastructure I can allow the HTTP server external access and deal with issues such as HTTP server corruption by requiring the HTTP server to run in an isolated O/S partition so that compromise of the server cannot lead to compromise of the host.

> 	spam, phishing and botnet are independent from 

I can shut down 95% of existing botnets using reverse firewalls. I have yet to find a legitimate network use with an access pattern that remotely resembles the access patern of a production botnet.

The approach I propose in the dotCrime Manifesto is that by default the newtork access point throttles outgoing SYN and DNS requests to some large number that is well short of the needs of spammers, DDoS SYN flooding etc.

> 	OSes have to be secured by default, that's all.

Linux is ten million odd lines of code. When you have more than a million lines of code you can be certain that at least 50% of the people working on it were below average in talent. Vista is ten times bigger.

We simply don't know how to build a secure operating system today.

>  heavy use of firewall/

The 'security through obscurity' argument is bogus. 

Back in the early 1990s people were arguing AGAINST the use of shaddow passwords in UNIX on the grounds that they give a 'false sense of security'.

I agree that most enterprises have an exagerated idea of what perimeter security can do for them, but that does not mean that the solution is to drop all the firewalls. That is not what is being discussed when people are talking about deperimeterization.

> 	need those end node firewall systems and/or keep 

There is no individual security control that cannot be trumped. Host based security can be disabled if the host is compromised. We don't yet have the trustworthy systems we need to prevent that attack.

There is no individual security control that cannot be trumped, but we can deploy combinations of security controls that make it very much harder for an attacker to succeed.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 02 Jul 2007 11:22:27 -0400

> There is no other device that can provide me with a lightweight firewall for

Of course there is - the same device that's providing the NAT.

NAT by itself is intrinsically policy-free, although it implements
policy as a side-effect.  I'm unclear on why you think that a
default-deny policy is better implemented on a NAT than on a
firewall.

Melinda

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Jul 2007 09:40:04 -0700

> From: Melinda Shore [mailto:[email-masked]] 

> Of course there is - the same device that's providing the NAT.

The $50 includes the cost of administration. I get the NAT effect for free when I plug the box in. Turning it off on the other hand requires rather a lot of thinking for the average user.

> NAT by itself is intrinsically policy-free, although it 
> implements policy as a side-effect.  I'm unclear on why you 
> think that a default-deny policy is better implemented on a 
> NAT than on a firewall.

That is not what I am tying to say here.

My point on NAT is that the objections being made against NAT are actually considered to be benefits in the wider Internet world. Turing off functionality you don't need is actually a good thing.

We need a way to turn off unneeded functionality that is more effective than NAT. 

NAT is crude and turns off slightly more functionality that we would want. So we have Skype and others doing aggressive peer-peer end runs around NAT to make VOIP work. And I still can't find anyone with a set of comprehensible instructions on how I make video-conferencing work with my home network. But I would much rather forego videoconferencing and the ability to run multiple VOIP boxes than spend $10 per computer per month for every machine in the network to have its own separate IP address. That's a saving of over $1,000 a year for me.

The IPv4 address space is scarce. NAT allows us to conserve what we have. Like they tell people in the disabled community: don't hate the wheelchair, its your friend, not your enemy. I use one IPv4 address instead of nine.

The idea behind Domain Centric administration is we put in place a set of administrative support tools that make the NAT debate moot. 

This weekend I filled up the van with super instead of regular gas. If I put the wrong gas in the MGB it would send the engine seriously out of tune as the carbs are tuned for super. On a modern car the engine management unit detects and adjusts automatically.

We need the same sort of approach to network administration. The devices on the network should not care whether they are on IPv4 or IPv6, they should detect and adjust automatically without the need for network administrator intervention.

I have spent some time looking into the incentives for upgrading to IPv6 and they are not at all promising for us in the IETF. We seen the importance of making the change because we recognize the value to the community. Clearly joining the Internet will have great value to potential user number 4 billion plus 1. The problem for designing deployment incentives is that the cost of deployment falls on the first four billion users and the value to them of user 4 billion plus one joining is a rounding error using Real32.

If we are going to deploy IPv6 we have to design deployment incentives that work for the parties that have to make the investment, not continue to hope that they see the light.

If we go the way we are going at present there will be no IPv6 transition. There will be occasional IPv6 deployments but most end users will simply sit behind honking great big hyperNATs. In addition to losing the NAT argument we will end up losing the network neutrality argument (regardless of which position you take in that debate we will end up at a position that is not Pareto optimal).

Deployment of IPv6 must be hooked into the solution to problems that are already recognized as pain points. Security is one widely recognized pain point, the cost of network administration is another.

What I am saying is, please don't try to sell IPv6 as a replacement for NAT. The NAT boxes are not causing a pain point as far as proponents are concerned. Having spent over a decade trying to get people to consider security to be a pain point before they were prepared to accept that it was I would really urge you not to waste time trying to convince people that NAT is a pain point.

Domain Centric allows us to avoid the whole debate altogether. Address the recognized pain points, finesse the transition to IPv6.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 02 Jul 2007 12:50:50 -0400

On 7/2/07 12:40 PM, "Hallam-Baker, Phillip" <[email-masked]> wrote:
> The $50 includes the cost of administration. I get the NAT effect for free
> when I plug the box in. Turning it off on the other hand requires rather a lot
> of thinking for the average user.

There's no reason that a default firewall configuration
need be any more complicated than a NAT.  Somewhat less,
actually.  But anyway, I think you're muddying the discussion
somewhat by framing it in terms of NAT.  You're talking
about network policy and NAT is not a policy function.
NAT workarounds tend to introduce security problems while
a decent, usable policy infrastructure would not, or would
at least localize them.  I think we probably both see the
same outcome as desirable but I do think that it's a big
mistake to frame the problem as "NAT is good" rather than
"default deny is good."

Melinda

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 02 Jul 2007 13:06:22 -0400

> And from a security point I want to see as much NAT as possible.

Whereas I want my applications to work, and people to stop conflating NAT 
and firewalls.

You don't want to see as much NAT as possible; you want to see as much 
blocking of inbound connections to consumers as possible, and for some 
reason you seem to think that a firewall which does that must necessarily 
also be a NAT.  In fact, it does not; it's perfectly reasonable to build a 
box that can be sold for <$50 which sits between a subscriber's computer 
and the Internet and provides a basic firewall.  Such a thing could be 
combined in the same box as an ethernet switch, wireless AP, maybe a basic 
router, DNS cache, and so on.  In fact, plenty of such boxes are sold 
today, except they all come with NAT turned on by default.

That is _not_ because NAT makes the network more secure - it doesn't.
It's because most of the people buying those boxes "need" NAT because their 
ISP's won't give them more than one address, or at least won't do so for a 
reasonable price.  Fix _that_ problem, and you'll start seeing boxes that 
provide security and flexibility without needing NAT.

Frankly, Phill, I'm surprised and disappointed that you are not only making 
such a basic mistake, but spreading FUD about it.

-- Jeff

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 02 Jul 2007 19:58:57 +0200

> There is no other device that can provide me with a lightweight firewall for $50.

Yes there is; it's a SOHO gateway with its NAT function switched
off for use with a "fixed IP address".

SOHO gateways with IPv6 support will provide exactly as much firewall
protection as a NAT-capable IPv4 SOHO gateway. The only question is
when they will cost $50.

     Brian

---

From: John C Klensin <[email-masked]>
Date: Mon, 02 Jul 2007 14:06:07 -0400

--On Monday, 02 July, 2007 13:06 -0400 Jeffrey Hutzelman
<[email-masked]> wrote:

>...
> It's because most of the people buying those boxes "need" NAT
> because their ISP's won't give them more than one address, or
> at least won't do so for a reasonable price.  Fix _that_
> problem, and you'll start seeing boxes that provide security
> and flexibility without needing NAT.

Jeff,

I completely agree with your basic comment, and with your
comment above FUD.  However, the problem is not _only_ "one
address only" policies as I and others have pointed out.   In
particular...

(1) For the ISP selling a low-end service, having all user LANs
with the same configuration (or being able to tell users with
different configurations that they are on their own)
considerably reduces support costs.  Since, at the low [pricing]
end, a single call can cancel out several months of profits,
minimizing customer support costs and calls can be very
significant.

(2) While DHCP could, in principle, be used to deliver an
address range to a router for use on the LAN behind it, I know
of no devices, especially low-end devices, that support such a
service.

(3) If a user is given a small pool of public addresses (say the
/28 that is fairly typical for SOHO "business" services), and
has to use that pool for both the external (WAN-side) address on
the router and for the LAN-side, setting up the router suddenly
becomes a job for experts, with some very specific routing
requirements.  For devices costing under $200 (much less $50), I
know of no vendors or ISPs who are willing to offer support and
walk users through this process.   Maybe I just haven't looked
hard enough, of course.

Of course, almost none of the issues above are likely to go
away, or even get better, with IPv6... unless we make some
improvements elsewhere.   And none of them make NAT a good idea,
just a "solution" that won't easily go away unless we have
plausible alternatives for _all_ of its purported advantages,
not just the address space one.

    john

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 02 Jul 2007 19:10:01 +0100

> protection as a NAT-capable IPv4 SOHO gateway. The only question is

going-nicely-ietf-offtopic:

google(WRT cheap EUR) returned me with:

http://www.dd-wrt.com/shop/catalog/product_reviews_info.php?products_id=28&reviews_id=21

Which is a "Buffalo WHR-G54S" for 49.99EUR. When buying them there you
get them preloaded with DD-WRT which does IPv6 (and even aiccu :) out of
the box.

Instead of there you can of course buy a lot of variants of the WRT type
of 'routers' in your local shop and make them into real routers by
upgrading them to OpenWRT/DD-WRT and a number of variants.
WRT's are accidentally also the cheapest managed router/switch/wifibox
as you can install SNMPd, SSH/telnet/webif etc etc ;)

Problemo solved and yes IMHO those are really nice boxes to have. There
are also a few of those boxes which can do DSL for you btw, all depends
on the config they come with.

Of course there are also a number of vendors who ship with IPv6 support
as a standard feature.

Greets,
 Jeroen

==
Oh and to 'prove' that they do IPv6:
 7  sheol.unfix.org (2001:7b8:20d:0:20f:66ff:fec8:5fd4)  16.9 ms  14.006
ms  14.308 ms

 7  gehenna.unfix.org (2001:7b8:20d:0:214:bfff:fe72:f83c)  18.911 ms
13.978 ms  15.3 ms

Yep, both still work fine and I haven't touched those for quite some
time now ;)

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Jul 2007 11:14:43 -0700

What I am really objecting to here is the normative aspect of the discussion. NAT may be good or it may be the work of Satan. Either way we have to deal with the issue more constructively than simply telling people 'please do not'.

I don't like NAT workarounds either. In fact I would like to suggest that we return to an old principle of layered network architecture in which no layer knows or cares as to what is going on in any other layer it does not interface to directly.

So instead of saying NAT is good or bad lets instead frame the debate in terms of 'A NAT box operates at layer 3 and should not therefore make assuptions about application interactions at layer 7'. 

It is equally a layer violation for FTP to communicate IP addresses and port numbers in the protocol. An application should not know if the transport is IPv4, IPv6 or SNA. Get rid of FTP type layer violations and the need for NAT workarrounds is also eliminated.

And at the same time let us ask 'how can we share an IPv4 connection on an IPv4 network without causing layer violations?' or 'how can Alice log into her corporate VPN from a hotel?'

> Sent: Monday, July 02, 2007 12:51 PM
> To: Hallam-Baker, Phillip; [email-masked]
> Cc: [email-masked]
> Subject: Re: Domain Centric Administration, RE: 
> draft-ietf-v6ops-natpt-to-historic-00.txt 
> 
> > The $50 includes the cost of administration. I get the NAT 
> effect for 
> > free when I plug the box in. Turning it off on the other 
> hand requires 
> > rather a lot of thinking for the average user.
> 
> There's no reason that a default firewall configuration need 
> be any more complicated than a NAT.  Somewhat less, actually. 
>  But anyway, I think you're muddying the discussion somewhat 
> by framing it in terms of NAT.  You're talking about network 
> policy and NAT is not a policy function.
> NAT workarounds tend to introduce security problems while a 
> decent, usable policy infrastructure would not, or would at 
> least localize them.  I think we probably both see the same 
> outcome as desirable but I do think that it's a big mistake 
> to frame the problem as "NAT is good" rather than "default 
> deny is good."
> 
> Melinda
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Jul 2007 11:47:39 -0700

John, 

I completely agree with you here, when I said $50 I meant $50 including the cost of administration. If the user has to do anything more than plug the box in its going to cost a lot more than $50.

If no users were stupid and no users were criminals and all programmers were competent there would be absolutely no need for any security technology at all. 

It took ten years to convince enough people that there were enough stupid, criminal and incompetent people that they had to think about security before deploying stuff like cookies, javascript, BASIC authentication and so on. You were in the room when we had to convince MarcA that integrity was a security inssue they had to take notice of. That was 1994, it took till 2004 till professional Internet crime was accepted as a real phenomenon that designers needed to consider seriously.

Lets look for commonality here. I think we can all agree on the following:

1) NAT workarrounds are bad, they are layer violations that other network applications end up having to cope with.

2) Applications that assume end to end consistency of network addresses violate the layering principle and are therefore bad.

3) Network administration has real costs and is too complicated as far as most users are concerned.

I agree that today stamping out cookie cutter networks in NET 10.x.x.x and gating them to the Internet via NAT is the way to go. Domain Centric Administration would allow us to meet that set of requirements better.

The draft is not yet in the repository, but the principles are pretty straightforward:

1) It is a directory driven network administration approach

1a) The directory is DNS. The SRV record is used for service discovery, prefixed TXT records for protocol policy statements, XPTR to allow a wildcard effect. 

1b) The security layer is DNSSEC or possibly TSIG combined with a lightweight keying mechanism

1c) There are no more reserved port numbers. All discovery takes place via SRV.

1d) We don't use broadcast or multicast, just plain DNS.

1e) DHCP is used to obtain an IP address and the DNS prefix for the local network. A given machine will use the IP address specified but may override the domain name assignment.

2) All devices have built in authentication capability

2a) This follows the DOCSIS 2.0 cable modem spec, bind a cheap device cert into the device during manufacture. This allows the MAC/EUI address to be used as an authenticated identifier

3) All devices and services have the ability to describe their functions and requirements

3a) If Mr Coffee says it needs NTP service and this is allowed by the local network policy it can send/receive NTP packets, otherwise it can't. And even if it is allowed NTP service this might well be rate limited.

The idea here is to design a system that offers consumer level ease of use while meeting an enterprise pain point. Schemes such as UPnP failled in my view because they never got vendor buy in which was in turn because consumers don't write RFPs and the schemes suggested did not offer real value to enterprises that do write RFPs.

In order to get deployment a scheme needs to meet an enterprise pain point. In this scheme I am aiming to address both the security pain point and the cost of administration pain point. 

> From: John C Klensin [mailto:[email-masked]] 
> Sent: Monday, July 02, 2007 2:06 PM
> To: Jeffrey Hutzelman
> Cc: [email-masked]
> > It's because most of the people buying those boxes "need" 
> NAT  because 
> >their ISP's won't give them more than one address, or  at 
> least won't 
> >do so for a reasonable price.  Fix _that_  problem, and you'll start 
> >seeing boxes that provide security  and flexibility without needing 
> >NAT.
> 
> Jeff,
> 
> (1) For the ISP selling a low-end service, having all user 
> LANs with the same configuration (or being able to tell users 
> with different configurations that they are on their own) 
> considerably reduces support costs.  Since, at the low 
> [pricing] end, a single call can cancel out several months of 
> profits, minimizing customer support costs and calls can be 
> very significant.
> 
> address range to a router for use on the LAN behind it, I 
> know of no devices, especially low-end devices, that support 
> such a service.
> 
> has to use that pool for both the external (WAN-side) address 
> on the router and for the LAN-side, setting up the router 
> suddenly becomes a job for experts, with some very specific 
> routing requirements.  For devices costing under $200 (much 
> less $50), I know of no vendors or ISPs who are willing to 
> offer support and

---

From: Douglas Otis <[email-masked]>
Date: Mon, 2 Jul 2007 12:08:38 -0700

On Jul 2, 2007, at 8:14 AM, Hallam-Baker, Phillip wrote:
>
> My point here is that the principal objection being raised to NAT,  
> the limitation on network connectivity is precisely the reason why  
> it is beneficial.
>

Teredo enabled NATs are likely how IPv6 address use becomes common  
place.  This creates interesting security problems as this bypasses  
normal policies.  Even so, many exploits are not prevented by NATs  
and peripheral defenses.  Exploits simply depend on the lines of code  
found within browsers and their many hooks into OS services and  
applications.

The problem has become so pervasive as to require extensive  
retooling.  For example, SMTP reputations must be made more  
progressive in an attempt to accommodate a pervasive level of 0wned  
systems.  The battle rages where NATs are not a complete solution,  
but instead represent a new challenge.

-Doug

---

From: Keith Moore <[email-masked]>
Date: Mon, 02 Jul 2007 15:40:23 -0400

> And from a security point I want to see as much NAT as possible. Without NAT we would be in a much worse situation security wise than we are today. NAT is a blunt instrument but it shuts down inbou…
from a security point the thing to do is for everyone to disconnect from
the Internet and go back to stone knives and bear skins.

NAT hasn't done a thing to stop the propagation of network worms.  The
worms just interpreted the NATs as damage and routed around them by
using email attachments and http until they could set up their own
connections to tunnel through the NATs.   misplaced confidence in NATs 
as a security measure did a lot to help make this possible.
> Which brings me to domain centric administration. To support the security objectives we need a support infrastructure for network administration that gets us out of the machine code era. Today we don't administer networks, we administer individual hosts connected to the network. 
The days in which an IP network is a reasonable security domain are
quickly disappearing.  People have to stand on their heads to make this
work.  IP addresses never have been good security tokens.

> Most residential systems don't need inbound service requests. So block them.
>   
in other words, you want to effectively cripple residential users to
only running applications that are supported by big media companies, and
hamper the development of new applications on the internet.

there are no polite words to describe how heinous an idea this is.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 02 Jul 2007 15:55:45 -0400

Hallam-Baker, Phillip wrote:
> It is equally a layer violation for FTP to communicate IP addresses and port numbers in the protocol. An application should not know if the transport is IPv4, IPv6 or SNA. 

dream on.  in every case where I have worked with an application that
tried to be independent of lower layers, that has failed.  there's
always been some need for the application to be aware of the
characteristics of an underlying layer.  TCP and SCTP aren't
semantically equivalent because of the lack of urgent data and clean
close, SMTP and lpr over DECnet had to be aware of record-size
limitations that don't exist in TCP, etc.

applications need to be able to log IP addresses, they need to be able
to create referrals to other hosts to the the same protocol engine that
is a TCP peer.  a TCP peer address happens to be an IP address and port
number.  adding an extra naming layer and indirection for the sake of
layering purity simply isn't worth it, and the people who tout the
benefits of the extra naming layer (and there are some) tend to
disregard the cost and complexity of providing and maintaining that
layer and dealing with the cases where it fails. 
> Get rid of FTP type layer violations and the need for NAT workarrounds is also eliminated.
>   
ten years ago, such naivete would have been amusing.  now it's only
anachronistic.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Jul 2007 13:31:40 -0700

> From: Keith Moore [mailto:[email-masked]] 

> from a security point the thing to do is for everyone to 
> disconnect from the Internet and go back to stone knives and 
> bear skins.

That does not work. The Internet has driven a coach and horses through the assumptions that underly the financial services infrastructure even if the bank never connects to the net.

The fact that the bad guys can network to trade stolen credit card numbers is the most significant impact of the Internet on credit card fraud. 

> in other words, you want to effectively cripple residential 
> users to only running applications that are supported by big 
> media companies, and hamper the development of new 
> applications on the internet.

Oh so I am the one who is peddling FUD eh? The above pretty much looks like FUD to me.

The whole point of domain centric is that anyone who wants to set their own rules can. All they need to do is to buy themselves a domain name. 

If you don't own your domain name someone else if going to be making the rules for you anyway so it isn't an additional expense.

---

From: Keith Moore <[email-masked]>
Date: Mon, 02 Jul 2007 16:35:54 -0400

> That does not work. The Internet has driven a coach and horses through the assumptions that underly the financial services infrastructure even if the bank never connects to the net.
well, the point is that you can't consider security in isolation.  you
need to consider it in light of what you're trying to do.  and the
network is (by design) very flexible, so it gets used to do lots of
different kinds of things, and these things vary from one
user/customer/network to another.
> Oh so I am the one who is peddling FUD eh? The above pretty much looks like FUD to me.
you were the one trying to cripple residential users.

Keith

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Jul 2007 13:59:07 -0700

> you were the one trying to cripple residential users.

No, I was intending to cripple their machines which is not the same thing at all.

Specifically I am looking to put the residential user in complete control of their network, deciding exactly what happens within it without requiring them to understand the low level details.

I expect that at some point every lightswitch in my house will be IP addressable. That does not mean that I want every lightswitch in my house to be able to run a full HTTP server or even to have access to the general Internet at all. 

I do not want to have to worry about whether Mr Coffee has joined a botnet run by the East European mafia. I don't want Mr Coffee to have any more Internet access than is strictly necessary for the process of making coffee and telling me when it is ready.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 Jul 2007 09:05:57 +1000

> My point here is that the principal objection being raised to NAT, the > limitation on network connectivity is precisely the reason why it is > beneficial.
> 
> There is no other device that can provide me with a lightweight firewall > for $50.
	
	We ask for one.  Don't say "I want NAT" say "I want a
	stateful firewall".  That's what you are really asking for
	and getting a lot of other @#$%%n in the process.

	Every $50 PNAT vendor could deliver you a stateful firewall
	at the same price point.  It's only a matter of removing the
	address translation.
 
> We have a lot of really good ways of avoiding issues we don't like: > complexity, accessibility, limited access in third world countries. 
> 
> Unless the arguments are applied consistently they should not be made at > all. Otherwise they just become special pleading.
> 
> 
> As I told Bruce Schneier after his silly IPSEC and Certification > Authority papers, security is risk control, not risk elimination. 
> 
> It is not helpful to criticise a security measure that empirically > offers a high degree of security for failing to address cases it is not > designed to deal with. An HTTP server behind a NAT box is no HTTP server > and thus no threat.
> 
> In a full default deny infrastructure I can allow the HTTP server > external access and deal with issues such as HTTP server corruption by > requiring the HTTP server to run in an isolated O/S partition so that > compromise of the server cannot lead to compromise of the host.
> 
> 
> I can shut down 95% of existing botnets using reverse firewalls. I have > yet to find a legitimate network use with an access pattern that > remotely resembles the access patern of a production botnet.
> 
> The approach I propose in the dotCrime Manifesto is that by default the > newtork access point throttles outgoing SYN and DNS requests to some > large number that is well short of the needs of spammers, DDoS SYN > flooding etc.
> 
> Linux is ten million odd lines of code. When you have more than a > million lines of code you can be certain that at least 50% of the people > working on it were below average in talent. Vista is ten times bigger.
> 
> Back in the early 1990s people were arguing AGAINST the use of shaddow > passwords in UNIX on the grounds that they give a 'false sense of > security'.
> 
> I agree that most enterprises have an exagerated idea of what perimeter > security can do for them, but that does not mean that the solution is to > drop all the firewalls. That is not what is being discussed when people > are talking about deperimeterization.
> 
> 
> There is no individual security control that cannot be trumped. Host > based security can be disabled if the host is compromised. We don't yet > have the trustworthy systems we need to prevent that attack.
> 
> There is no individual security control that cannot be trumped, but we > can deploy combinations of security controls that make it very much > harder for an attacker to succeed.
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 3 Jul 2007 08:15:12 +0900 (JST)

> protection as a NAT-capable IPv4 SOHO gateway. The only question is

	if they use software to forward packets (it is unlikely for $50 routers
	to have silicon to forward packets) and they are wise enough to use
	free software, there is almost no real reason to raise the price for
	IPv6 support.

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 3 Jul 2007 08:49:43 +0900 (JST)

> There is no other device that can provide me with a lightweight firewall for $50.

	other reponses gave you some good news.

> Unless the arguments are applied consistently they should not be made at all. Otherwise they just become special pleading.

	well, you can say this for IPv4, or operating systems which does not
	have enough history.  for the record, KAME group found a bug in IPv4
	options handling, rooted in Net/1 timeframe, in year 2000.  so i use
	operating systems which has its roots in 1970s only :-P
	http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_input.c
	revision 1.132

> In a full default deny infrastructure I can allow the HTTP server external access and deal with issues such as HTTP server corruption by requiring the HTTP server to run in an isolated O/S partitio…

	i can understand your point about "security is risk control".  we trust
	16-digit credit cards as credit card companies have $$$ insurance in
	the back.  ATM machines and credit card CAT systems use stone age
	technology called MODEM, so wiretapping them should be less than
	trivial for those who read the "2600 magazine".

	however, we are internet engineers, aren't we?  we are not forced
	to use modems, and even if we use modems, we put IP layer on top.
	do check Steve Deering's "hour glass" presentation if you missed it.
	http://www3.ietf.org/proceedings/01aug/slides/plenary-1/index.htm

	and, not to offend Verisign or anything, and really a off topic,
	but i still believe PKI and other tree-based authentication technology
	does not scale enough.
	since we need to install keys for famous certificate authorities into
	the browsers, it became more difficult for small free software people 
	to implement/distribute HTTPS capable browsers without hitting the
	problem "we do not have CA key for Amazon.com".
 
> The approach I propose in the dotCrime Manifesto is that by default the newtork access point throttles outgoing SYN and DNS requests to some large number that is well short of the needs of spammers…

	so you install both forward and reverse firewalls, then what kind
	of communication would you permit? :-P

> We simply don't know how to build a secure operating system today.

	well, you are using OSes which are not in AT&T UNIX family tree so you
	are in the wrong world.  sorry Microsoft guys, i do try hard not to
	offend you :-P
	http://www.freebsd.org/cgi/cvsweb.cgi/src/share/misc/bsd-family-tree

> I agree that most enterprises have an exagerated idea of what perimeter security can do for them, but that does not mean that the solution is to drop all the firewalls. That is not what is being di…

	funny that you say "obscurity".  i would say that NAT is the obscurity
	device.  if you are in Linux camp you know that RMS does not use
	password at all.  but i'm in OpenBSD camp so i randomize/encrypt every
	single bit of information i use, even process IDs are random.
	i do not trust MD5 password.  i use Blowfish-based password developed
	by Niels Provos.  i think i am more paranoid than most of Verisign
	guys, modulo those who are managing the root CA key in the secret vault
	in a data center which i cannot guess the location.
	http://www.usenix.org/events/usenix99/provos.html

> There is no individual security control that cannot be trumped, but we can deploy combinations of security controls that make it very much harder for an attacker to succeed.

	if you install secure OSes to the end clients, you do not have to
	worry about the infection by worms almost forever.  you just need to
	adjust youself to use MagicPoint instead of PowerPoint, and use
	vi/roff/TeX instead of MS Word.

itojun

---

From: David Morris <[email-masked]>
Date: Mon, 2 Jul 2007 18:14:31 -0700 (PDT)

As the administrator of several small networks, it is quite simple. By
re-writing the address, the NAT is a defacto default deny. I have a lot
more trust in the simplicity of a basic NAT in a consumer firewall then I
do in any firewall which has to examine each packet for conformance to
complex policy rules.

But, this misses the point I see in Phillips discussion... I read his
ultimate proposal as:
  a. Stop bashing NAT, it provides value in the current network and
     has prevented a total meltdown which would have happened if every
     early OS were directly attached to the internet
  b. REPLACE NAT with a default deny infrastructure ... more than
     just a single FW choke point.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 Jul 2007 11:49:39 +1000

> do in any firewall which has to examine each packet for conformance to

	The re-writing of the address has nothing to do with the
	security benefit of the box.  Looking the incoming packet
	up in a state table and forwarding (with re-write) the
	packet if a match is found otherwise dropping / icmping it
	is what provides the security.

	Otherwise I could just loose source route around the NAT box.

	It is much better to have a box that is designed to provide
	security than it is to have a box that provides security
	as a side effect.  I'm sure you will find that there are
	NAT boxes that you can use the loose source route trick to
	bypass any perceived security benefits.  NAT boxes have
	different design goals to firewalls.  They are designed to
	translate addreses.  LSR is also designed to translate
	addreses.  LSR and NAT are complementry technologies.  One
	is end initiated the other is done in the middle of the
	network.

>      early OS were directly attached to the internet

	People arn't bashing NAT.  They are saying that NAT is not
	a appropriate for solution in a IPv6 world.  It adds a lot
	more complexity than just a stateful firewall.

> > > There is no other device that can provide me with a lightweight firewall 
> for
> > > $50.
> >

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Jul 2007 18:57:53 -0700

That is pretty much it

The one additional point being that we all take a realistic view of what people out there will actually pay for and what they will actually use.

I can manage get people to pay for security. Getting them to then use the security they have paid for is a much harder problem. How many of us have installed S/MIME or PGP, how many people use them?

The reason I am raising these issues is not to be defeatist. I think that we can solve these problems but only if we are prepared to build a solution around the one problem that every CIO has to take notice of - the cost of administration.

I don't mean one of those marketecture TCO type jobs either where someone spends $100K to save $300K in hypothetical costs. I mean a system where the incremental costs are no more than $0.25 per device and the savings are clearly two orders of magnitude greater than the costs.

There is a large consortium of bit IT customers calling itself Jericho Forum that is talking about deperimeterization and the need for a new network architecture. So far they have not really found one but when they do they have the power to make every vendor sit up and take notice as they are going to write a requirement to support their architecture into every RFP they issue.

They want security and they understand that cost of administration is a major issue they need to control.

It would be to everyone's advantage if the architecture they decide on also makes a transition to IPv6 easy and painless.

> From: David Morris [mailto:[email-masked]] 

> As the administrator of several small networks, it is quite 
> simple. By re-writing the address, the NAT is a defacto 
> default deny. I have a lot more trust in the simplicity of a 
> basic NAT in a consumer firewall then I do in any firewall 
> which has to examine each packet for conformance to complex 
> policy rules.
> 
> But, this misses the point I see in Phillips discussion... I 
> read his ultimate proposal as:
> > default-deny policy is better implemented on a NAT than on 
> a firewall.
> 
>

---

From: Ned Freed <[email-masked]>
Date: Mon, 02 Jul 2007 19:11:46 -0700 (PDT)

> limitations that don't exist in TCP, etc.

Keith, while I agree with your general point that applications have no choice
but to be aware of lower layer semantics in many if not most cases, this last
is not a good example of that. There is really no difficulty running SMTP or
any other stream oriented protocol on top of a record-based protocol - all you
have to do is ignore the record boundaries and make sure your buffer isn't
larger than the maximum record size. Not only did our SMTP implementation
require nothing more than a change of low-level network primitives to work over
DECnet, it interoperated fine with several other SMTP over DECnet
implementations back in the day with no need to agree on any sort of additional
semantics.

The converse is not true, however - you cannot simply slap a protocol that
depends on record boundaries onto a stream protocol and expect it to work, such
as MAIL-11 over TCP (not that anyone in their right mind would use MAIL-11 this
way...). Even worse, if you do it what often happens is it appears to work fine
because often as not a TCP write of a given amount of data results in the read
on the other end returning just that data and no more. But look out once you
try your application on a connection with a smaller path MTU than the records
you're passing around.

> is a TCP peer.

And even if logging weren't an issue, things like SMTP relay blocking are. The
way relay blocking is commonly implemented is to instruct your MTA as to which
IP addresses are "outside" and which are "inside" and allow relay only for
"inside" sources. Of course you can eliminate this need by using mutlple MTAs
in different roles, but not everyone has the hardware available to do this, and
even if they do, all you've done is implement the same policy with cables
instead of a configuration file.

> a TCP peer address happens to be an IP address and port

I don't discount the costs, however, I think that sooner or later we're going
to be forced to implement some additional naming services. Whether or not these
need to reuse existing DNS services, use DNS protocols as part of a new
service, or use something other than DNS to build the service is not a question
I'm prepared to answer right now. I know you're strongly against basing such
things on existing DNS services but I'm not convinced this is a bad idea - the
vast existing infrastructure is a fairly compelling point in its favor.

				Ned

---

From: David Conrad <[email-masked]>
Date: Mon, 2 Jul 2007 20:17:35 -0700

Mark,

On Jul 2, 2007, at 6:49 PM, Mark Andrews wrote:
> 	People arn't bashing NAT.

Oh, please.  Sure they are.

>         They are saying that NAT is not

A stateful firewall doesn't also provides provider independence and  
an ability to have a form of multi-homing without playing BGP games  
or even telling your ISPs.

I am also a bit confused how a "dual stack" transition strategy to  
IPv6 is going to work when the IPv4 address free pool is exhausted in  
a few years without some form of NAT/ALG, but maybe that's just me.

Rgds,
-drc

---

From: Keith Moore <[email-masked]>
Date: Mon, 02 Jul 2007 23:45:05 -0400

> larger than the maximum record size.
well, mumble.   you still get into interesting boundary cases when, for
example, an application reads a zero-length record from a record-based
source that it wants to treat as a stream, and interprets the
zero-length read as end of file.  I suppose that's an API issue rather
than a protocol issue, but the API differences are consequences of the
underlying protocol differences.  practically speaking, the code nearly
always has to have been written with awareness of the lower layer(s) its
going to be used with, before it can be expected to work reliably. 
sometimes you can isolate that awareness to a protocol-specific
adaptation layer, sometimes not.

(in running lpr over DECnet, I seem to recall that one of the problems
was that DECnet has no way to shutdown one end of a connection will
keeping the other end open, so some sort of protocol change was
necessary to make this work.)
> vast existing infrastructure is a fairly compelling point in its favor.
if the only tool you have is a hammer...

basically I think if we're going to bother adding an extra layer of
naming, it had better work a hell of a lot better than DNS.   between
widespread misconfiguration and lots of lame hacks like DNS-ALG and
multifaced DNS, not to mention ambiguities in how DNS APIs interface
with things like LLMNR and proprietary name lookup services, and fairly
poor reliability, we need to be thinking about how to replace DNS rather
than how to add yet another layer that depends on it.  IMHO.

Keith

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 Jul 2007 14:10:29 +1000

> or even telling your ISPs.

	What real benifits are there in NAT compared with carrying
	multiple PA prefixes?  Active connections are still going
	to break when links go down.  ICMPv6 will provide feedback
	when the external link is gone.

> a few years without some form of NAT/ALG, but maybe that's just me.

	How many legacy boxes are going to need global connectivity
	that can't be covered by a ALG, bump in the stack or something
	else.  I suspect most of the legacy boxes will only need
	to talk locally and RFC 1918 addresses will suffice in most
	cases.

	If you offer a service to others you run "dual stack" either
	natively or with a ALG (e.g. RIPE's whois over IPv6 did
	this).  When the crunch comes you start to see IPv6 only
	services.

	The problem is eveyone is waiting until the crunch and not
	running "dual stack" now.  Microsoft is doing the right
	thing with Vista by turing on IPv6 on by default.  Each
	Vista box is a client waiting for you to turn on your dual
	stack service.

	This is the time when everyone should be running dual stack.

---

From: SM <[email-masked]>
Date: Mon, 02 Jul 2007 21:55:18 -0700

>There is no other device that can provide me with a lightweight 

NAT is not a firewall although its side-effect is that it may be seen 
as one.  That $50 device makes everyone a RIR.  Protocols are tweaked 
to get around the problems associated with NAT.  That may not be seen 
as a problem if we remain in a web-centric world.

>It is not helpful to criticise a security measure that empirically 
>offers a high degree of security for failing to address cases it is 
>not designed to deal with. An HTTP server behind a NAT box is no 
>HTTP server and thus no threat.

It offers a fall sense of security.  A person running a HTTP server 
behind a NAT box usually does port redirection to that server.  The 
threat remains.

Regards,
-sm

---

From: <[email-masked]>
Date: Tue, 3 Jul 2007 09:44:16 +0100

> A stateful firewall doesn't also provides provider 
> independence and an ability to have a form of multi-homing 
> without playing BGP games or even telling your ISPs.

This could be done using ULA-random addresses and a form of IPv6 address
translation that does a pure one-to-one mapping of internal and external
addresses. In other words, no PAT because that is where the concept of
NAT and firewall really start to become confused. Straightforward
address translation doesn't need to carry any state in the translation
device because it is simply swapping the address prefix bits.

> IPv6 is going to work when the IPv4 address free pool is 
> exhausted in a few years without some form of NAT/ALG, but 
> maybe that's just me.

I don't think the IETF needs to do anything to enable ALG between v4 and
v6. People are going to write code to do that anyway.

--Michael Dillon

---

From: Melinda Shore <[email-masked]>
Date: Tue, 03 Jul 2007 06:34:45 -0400

On 7/2/07 9:14 PM, "David Morris" <[email-masked]> wrote:
> re-writing the address, the NAT is a defacto default deny.

A lot of administrators feel that way, and I undersatnd
why (NAT is basically configuration-free, for the moment).
However, for the past 7 years (at least), currently, and
for the foreseeable future manufacturers, users, application
authors, and standards bodies like the IETF, the ITU-T,
PacketCable, and the various 3s are working hard at finding
ways to bypass NAT "security" outside of any consideration
of policy and without giving the user control of the process.
(Control will belong to applications).  And incidentally,
each of these new NAT bypass techniques introduces new
security exposures, some by virtue of the fact that they're
bypassing what some people think is security and others by
virtue of the fact that they're actually not secure.
Good luck to all of us in staying on top of all of them.

> I have a lot

"Drop all inbound traffic" is complex?

Melinda

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 3 Jul 2007 08:37:18 -0700

> body is going to do it or nobody is going to be put any trust 
> in a new technology. IETF has to pioneer this as it did so 
> far (multicast, security, IPv6, and hopefully more will 
> experimented at the IETF). 
> 
> Anyway, IPv6 is not experimental, it runs alright in 
> operational networks. 
> 
> What I think the IETF should experiment now at a wider scale 
> is the transition tools between IPv6 and IPv4. This would 
> only be meaningful if results of the experiments are 
> published, for instance in the IETF journal.
> 
> Regards,
> Thierry.
> 
> 
> On Mon, 02 Jul 2007 16:18:11 -0700
> Dave Crocker <[email-masked]> wrote:
> 
> >
> >
> >Jun-ichiro itojun Hagino wrote:
> >>>> The IETF network is not, and never has been, for 
> experimentation, 
> >>>> showing off new technology, or making political 
> statements.  Please 
> >>>> keep it that way.
> >>> +1
> >> 
> >> 	RFC1883 is not new.
> >
> >
> >Neither is X.400, TP0, or many other specs.  But then, 
> that's not the issue.
> >
> >The issue is operational risk.
> >
> >d/
> >
> >--
> >
> >   Dave Crocker
> >   Brandenburg InternetWorking
> >   bbiw.net
> >
> Thierry ERNST, PhD
> INRIA Rocquencourt France Project-Team IMARA / JRU LARA 
> http://www.lara.prd.fr +33 1 39 63 59 30 (office)
> --
> The coming end of the IPv4 world: http://penrose.uk6x.com
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 3 Jul 2007 08:37:18 -0700

> From: SM [mailto:[email-masked]] 

> It offers a fall sense of security.  A person running a HTTP 
> server behind a NAT box usually does port redirection to that 
> server.  The threat remains.

Arguments about false senses of security are usually wrong. We are adapted for an environment where sabre toothed tigers are running around at night. So our tolerance for insecurity is much higher than you might think. A sense of security is created by familiarity, not by analysis.

The point here is not to shut off connectivity, but to shut it off by default. If the user knows they want to run an HTTP server they can set it up accordingly. The nice thing about NAT boxes is that a user who knows nothing about their network can plug one in and the default state is to deny inbound connections.

What that means is that the MYSQL server or the embedded SQL Server in their application they didn't even know they had is shut off from external access. I was running an unpatched version of SQL server when slammer hit without ill effect. I have boxes that have not been booted for several years. I'll bet that much on the code on those boxes is vulnerable too. I don't patch systems I am not currently using.

Sure you can do much better if you 1) know what you are doing and 2) are prepared to put in the necessary time. Most people don't meet either condition.

o/ietf>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

> From: SM [mailto:[email-masked]] 

> It offers a fall sense of security.  A person running a HTTP 
> server behind a NAT box usually does port redirection to that 
> server.  The threat remains.

Arguments about false senses of security are usually wrong. We are adapted for an environment where sabre toothed tigers are running around at night. So our tolerance for insecurity is much higher than you might think. A sense of security is created by familiarity, not by analysis.

The point here is not to shut off connectivity, but to shut it off by default. If the user knows they want to run an HTTP server they can set it up accordingly. The nice thing about NAT boxes is that a user who knows nothing about their network can plug one in and the default state is to deny inbound connections.

What that means is that the MYSQL server or the embedded SQL Server in their application they didn't even know they had is shut off from external access. I was running an unpatched version of SQL server when slammer hit without ill effect. I have boxes that have not been booted for several years. I'll bet that much on the code on those boxes is vulnerable too. I don't patch systems I am not currently using.

Sure you can do much better if you 1) know what you are doing and 2) are prepared to put in the necessary time. Most people don't meet either condition.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 3 Jul 2007 08:37:18 -0700

> From: David Conrad [mailto:[email-masked]] 

> exhausted in a few years without some form of NAT/ALG, but 

Perhaps the idea here is that when the IPv4 pool is exhausted, people will be forced to use IPv6.

If so it comes from the same school of politics that led folk to say 'IF NXT means that DNSSEC can't be deployed in .com that's a good thing because it will force people to reduce the size of .com'. That is an actual quote from a real DNSEXT meeting.

Its not going to work that way. All we will end up with is hyper-NAT.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 3 Jul 2007 08:37:17 -0700

> From: Ned Freed [mailto:[email-masked]] 

> Keith, while I agree with your general point that 
> applications have no choice but to be aware of lower layer 
> semantics in many if not most cases, this last is not a good 
> example of that. There is really no difficulty running SMTP 
> or any other stream oriented protocol on top of a 
> record-based protocol - all you have to do is ignore the 
> record boundaries and make sure your buffer isn't larger than 
> the maximum record size. Not only did our SMTP implementation 
> require nothing more than a change of low-level network 
> primitives to work over DECnet, it interoperated fine with 
> several other SMTP over DECnet implementations back in the 
> day with no need to agree on any sort of additional semantics.

Quite, and HTTP runs happily on DECNET. 

> The converse is not true, however - you cannot simply slap a 
> protocol that depends on record boundaries onto a stream 
> protocol and expect it to work, such as MAIL-11 over TCP (not 
> that anyone in their right mind would use MAIL-11 this 
> way...).

Which of course is true and in my view indicates a flawed network architecture. If the application layer is required to take notice of what is going on at the lower levels its because the layering was botched.

The Internet stack is petty clean and that is one of its major advantages over other schemes.

Of course you have to log IP addresses etc for logging purposes. And there are rare cases where you want to break the layering model and take notice of an IP address for issues such as login attempt throtling. These are not actions that others need to depend on being done in particular ways.

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 3 Jul 2007 11:45:37 -0400

On Jul 3, 2007, at 11:37 AM, Hallam-Baker, Phillip wrote:

> If so it comes from the same school of politics that led folk to  
> say 'IF NXT means that DNSSEC can't be deployed in .com that's a  
> good thing because it will force people to reduce the size  
> of .com'. That is an actual quote from a real DNSEXT meeting.
>

And a Market in IPv4 addresses, which will certainly develop as IPv4  
exhaustion nears.

Regards
Marshall

---

From: Keith Moore <[email-masked]>
Date: Tue, 03 Jul 2007 11:51:25 -0400

> If the application layer is required to take notice of what is going on at the lower levels its because the layering was botched.
>   
no, it just means that all lower-level network services weren't designed
to provide exactly the same set of services and semantics to higher
layers. 

in the IP stack, we expect link layers to be diverse, we expect IP
service to be fairly uniform, precisely so that things layered on top of
IP don't have to worry about it.  expecting all applications to support
multiple transport protocols adds complexity where it is almost never
needed.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 4 Jul 2007 01:13:28 +0900 (JST)

> 	This is the time when everyone should be running dual stack.

	as I posted before, almost every one of people who attends IETF are
	running IPv6-capable operating system.  if you are not, you are very
	out of date like 5 years.

	IPv6 is not enabled just because implementers have been polite enough
	not to enable IPv6 transition technologies like Teredo or 6to4 on by
	default.  maybe we should think it over?

itojun

---

From: Keith Moore <[email-masked]>
Date: Tue, 03 Jul 2007 12:23:59 -0400

> 	out of date like 5 years.
well, even if your OS supports IPv6 doesn't mean that it works well with
things like your host-based firewall.
> 	default.  maybe we should think it over?
word I hear is that Vista's enabling of such technologies is causing
problems for enterprise networks because their traffic filters and
intrusion detectors aren't set up to handle them.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 3 Jul 2007 09:51:48 -0700

It might be a market.

It might well be something more Darwinian. 

> From: Marshall Eubanks [mailto:[email-masked]] 
> Sent: Tuesday, July 03, 2007 11:46 AM
> To: Hallam-Baker, Phillip
> Cc: David Conrad; Mark Andrews; [email-masked]
> exhausted in 
> > Perhaps the idea here is that when the IPv4 pool is 
> exhausted, people 
> > will be forced to use IPv6.
> >
> > If so it comes from the same school of politics that led 
> folk to say 
> > 'IF NXT means that DNSSEC can't be deployed in .com that's a good 
> > thing because it will force people to reduce the size of 
> .com'. That 
> > is an actual quote from a real DNSEXT meeting.
> >
> And a Market in IPv4 addresses, which will certainly develop 
> as IPv4 exhaustion nears.
> 
> Regards
> Marshall
> 
> >

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 03 Jul 2007 09:56:38 -0700

> intrusion detectors aren't set up to handle them.

It is trivial to filter teredo (knock down udp 3544) and I think you can
rest assured that enterprises are having no trouble doing so.
Organizations with internal default deny policies break teredo just like
they do everything else (I'm not advocating a position, just making an
observation).

If you want to selectively apply policy to packets inside encapsulated
teredo connections between clients you're going to have to do some work
(this applies generically to any tunneled protocol).

http://tools.ietf.org/html/draft-hoagland-v6ops-teredosecconcerns-00#section-3

joelja

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 04 Jul 2007 01:57:51 +0900

i will be a bit implite.

>things like your host-based firewall.

	if that is true, the company selling that host-based firewall is
	slacking.

>intrusion detectors aren't set up to handle them.

	firewalls and IDS companies are slacking.

itojun
PS: in openbsd community if you do not commit frequently enough you will be
scolded for being a slacker.

---

From: Keith Moore <[email-masked]>
Date: Tue, 03 Jul 2007 13:02:00 -0400

> 	if that is true, the company selling that host-based firewall is

either that or they're wanting you to pay a lot of money to upgrade to a
newer OS that's even more heinous than the previous one...
> 	firewalls and IDS companies are slacking.
waiting for sufficient market.  though because of the US DoD mandate to
support IPv6 (and perhaps other factors), it's starting to be there.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 03 Jul 2007 10:08:55 -0700

...
> as MAIL-11 over TCP (not that anyone in their right mind would use MAIL-11 this

I believe this highlights a basic opportunity (need) for the protocol 
engineering community.  Although it applies to any discussion about the 
relationship between layer n and layer n+1 (or, layer n and layer n-1, if you 
want to focus on the upper layer...), it seems to come up most often in 
relation to application/transport discussions:

    How can we discuss the essential services required of the lower layer, 
without worrying about the means by which those services are delivered?  That 
is, how do we discuss the what, without discussing the how?

    Related to that is discussion about lower layer services that supply more 
than is needed, but still suffice.

Your example of record boundaries is useful because TCP's lack of the 
construct used to cause all sorts of problems and hacks.  Another is in the 
realm of "performance" characteristics.  The need for predictable inter-packet 
times for real-time voice or video streams highlight TCP's limitations. I've 
also noted that applications developed for LAN environments rarely translate 
well to WAN environments, due to implicit requirements for low latency and 
high reliability.  Conversely, applications designed for WAN environments tend 
to work fine on LANs.  (However I'm told there was quite a debate about 
whether to tailor TCP to work differently on LANs, when LANs started to get 
popular; thank goodness uniformity/simplicity arguments won out over local 
optimization arguments.

The few times we've seen transport folks make efforts to solicit requirements 
or issues comments from the application protocols community, the responses 
have tended to be more along the lines of criticizing or recommending 
particular protocol features.

It seems that we lack a vocabulary for discussing service needs, without 
diving into protocol details.  Yet upper-layer independence of lower-layer 
details requires exactly that vocabulary.

d/

-- 

   Dave Crocker

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 3 Jul 2007 10:18:17 -0700

> PS: in openbsd community if you do not commit frequently 
> enough you will be scolded for being a slacker.

Which is part of where we need to get to.

What I propose is a brand, similar to WiFi that tells a customer, whether home or enterprise that a product:

1) Either
	Will install itself automatically and seamlessly within a network that is under domain centric administration.

	Will do the above, unless the network is not already under domain centric admin in which case it will establish the necessary DNS and DHCP infrastructure to support one (and yes would be nice if this also extended to redundancy).

2) Supports both IPv4 and IPv6 seamlessly.

3) Has a built in device cert and is able to perform 802.1X authentication to the network hub

4) In the case of a wireless device supports a network configuration mechanism that does not involve a user touching a keyboard.

In other words you have the current Internet and the 'it-just-works' Internet. And the IJW-Internet happens to support everything you need for IPv6.

Then on the ISP side a program for accrediting Internet service plans. Again, have them state whether they are delivering IPv6. At present I have Comcast which I am not that happy with. I could swich to Verizon but other folk are even less happy with that. I want to know exactly what level of service the ISP is committing to deliver. 

I am even happy to contract terms of the form 'I pay for 1mb/s connection flat rate but others can pay the ISP extra to boost that to 10Mb/sec for a temporary period'. What I am not going to accept is a situation where I pay for 1mb/sec and then the ISP goes to Google to demand that they pay them to provide the service that I already paid for.

The incentives for the consumer here is that they know that the products will just work together and that they are going to get what they paid for. 

The only incentive I can see at this point that would encourage a consumer to transition to IPv6 is if it allows them to have home video conferencing that actually works. That is the one thing that NAT effectively breaks that people are likely to care about.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 04 Jul 2007 02:50:45 +0900

>What I propose is a brand, similar to WiFi that tells a customer, >whether home or enterprise that a product:
>
>1) Either
>	Will do the above, unless the network is not already under domain
>centric admin in which case it will establish the necessary DNS and DHCP
>infrastructure to support one (and yes would be nice if this also
>extended to redundancy).
>
>4) In the case of a wireless device supports a network configuration >mechanism that does not involve a user touching a keyboard.
>
>
>In other words you have the current Internet and the 'it-just-works' >Internet. And the IJW-Internet happens to support everything you need >for IPv6.

	from what i've gathered from information sources, the device you want
	to buy is the latest version of Apple AirPort Extreme base station.

	i do not have one myself so please verify it by yourself.  i have
	used it at meetings (Jun Murai has almost every version of it) as well
	as while i have been war-driving in Tokyo.  nice (or bad) thing for the
	latter case was that there was no access control enabled for
	6to4-based IPv6 for the particular base station i've associated with:-P

	(1-2) are already covered as it implements NAT for IPv4 if you want.
	it can be configured as a pure L2 bridge between ethernet and 802.11,
	if you got enough IPv4 address to spare.
	in terms of IPv6, it has a button or something to turn on IPv6, and it
	even speak 6to4 if there is no ISP device/contact to terminate static
	IPv6-over-IPv4 tunnel.  of course you can bridge IPv6 as well.

	(4) is of course covered, almost every Apple product ships with GUI.

	i'm not too sure about (3) but i hope someone from Apple to comment.
	if necessary i'll meet people in Apple Japan tomorrow so i can ask.
	the device i've used were configured either with WEP or no auth.

	it runs *BSD variant, if you run namp on it you should be able to know
	which *BSD it is.

	so, Apple is not slacking and KAME/*BSD are not too.

	MacOS X is shipped with IPv6 enabled by default since 10.2 (or 10.3?)
	timeframe, and from WWDC2007 comment by Steve Jobs there are 22 million
	machines which runs 10.2 and beyond, so there are 22 million IPv6
	enabled machines.

	MacOS X is good, it is basically having Macintosh Aqua GUI on top of
	a BSD variant.  you will love it.

itojun

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 04 Jul 2007 03:06:38 +0900

>	so, Apple is not slacking and KAME/*BSD are not too.

	for the record, I do not get paid from Apple, just yet :-P

itojun

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 04 Jul 2007 03:13:20 +0900

>	6to4-based IPv6 for the particular base station i've associated with:-P

	I have no idea where the IPv4 access blocking was implemented.
	I could not single out the issue or find workarounds, because I had
	IPv6 access already :-P

itojun

---

From: Douglas Otis <[email-masked]>
Date: Tue, 3 Jul 2007 12:13:15 -0700

On Jul 2, 2007, at 11:06 AM, John C Klensin wrote:

> Of course, almost none of the issues above are likely to go away,  
> or even get better, with IPv6... unless we make some improvements  
> elsewhere.   And none of them make NAT a good idea, just a  
> "solution" that won't easily go away unless we have plausible  
> alternatives for _all_ of its purported advantages, not just the  
> address space one.

The initial use of IPv6 in North America will likely involve Teredo  
enabled NATs and Teredo servers.  It does not seem NATs will go away  
anytime soon, especially those adding Teredo compliance to ensure  
multi-player games function without router configuration.

Unfortunately many exploits now bypass protections once afforded by  
NATs or peripheral firewalls.  Browsers are always in transition and  
can be exploited with their many hooks into OS services and  
applications.  It seems security is sacrificed to enable some new  
proprietary interface.  This is an area where standardization has  
seemly failed.

Browser exploits have become so pervasive as to require our company  
to extensively retool behavior evaluations.  For example, SMTP  
reputations are being converted to a progressive scale to adjust for  
the growing prevalence of 0wned systems.  It seems much of the  
malware activity is just harder to detect.

It gets worse.  NATs are not a complete solution, and represent a new  
challenge.  PNRP clouds combined with new complex routing paths  
represents a risk that will be even harder to evaluate and to enforce  
policies in a scaleable fashion.

In the early days of the Internet, the level of commerce and related  
crime was far lower than it is today.  People are now filing their  
Federal taxes on-line.  What the Internet is being used for has  
changed significantly.  When defending against criminal exploits,  
there is less doubt about risks.  The hazards are very apparent,  
although they might be harder to detect.

The security section for the "next great idea" should carefully  
review and strategize how the world is to handle resulting abuse.   
That section is unfortunately significantly growing in importance  
every day.  What seemed like a good idea, can easily become a nightmare.

-Doug

---

From: Christian Huitema <[email-masked]>
Date: Tue, 3 Jul 2007 12:38:29 -0700

> multi-player games function without router configuration.

Just a point of clarity: Teredo works fine through most home
routers/gateways today. The manufacturers of these routers don't need to
do anything in particular to "enable Teredo". Only a minority of these
routers do need to be fixed, i.e. those implementing variations of
"symmetric NAT". 

-- Christian Huitema

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 3 Jul 2007 12:53:01 -0700

Doug,

You are entirely right about the internet crime issues. In my book (to be published in the Fall, Addison Wesley) I mention default deny and domain centric of course but they are not what I would regard as my first line of defense.

The problem we always get to with Internet crime is the 'The problem is X/ no its Y/ no its Z' debate. The problem is X, Y and Z and A through W as well. The idea of the book is to set out a straw man for a comprehensive solution so that instead of having that debate people can instead say 'your solution to X sucks, here is a better one', and I can reply 'thanks, now I can write the second edition'.

The point here is that I want to help people deploy IPv6 even though it is not the very top of my list of priorities and I am not a network routing person (not done work on that layer since my undergraduate thesis and proofs of deadlock freedom for routing protocols).

What I have learned from deploying security is that even though people say that security is their #1 concern, they lie. Their #1 concern is always going to be something else. But security will always top every poll of top 5 priorities because it is everyone's #2 or #3 issue.

We are dealling with very fine tipping points here. 95% right means zero deployment, get it to 96% and suddenly it takes over the world in 18 months. The gap between the Web and gopher or HyperG is very very small. HyperG was in many ways technically superior, certainly the application software was better right up to 1995/6 or so.

> From: Douglas Otis [mailto:[email-masked]] 
> Sent: Tuesday, July 03, 2007 3:13 PM
> To: John C Klensin
> Cc: [email-masked]; Jeffrey Hutzelman
> Subject: Re: Domain Centric Administration,RE: 
> away, or 
> > even get better, with IPv6... unless we make some improvements
> The initial use of IPv6 in North America will likely involve 
> Teredo enabled NATs and Teredo servers.  It does not seem 
> NATs will go away anytime soon, especially those adding 
> Teredo compliance to ensure multi-player games function 
> without router configuration.
> 
> Unfortunately many exploits now bypass protections once 
> afforded by NATs or peripheral firewalls.  Browsers are 
> always in transition and can be exploited with their many 
> hooks into OS services and applications.  It seems security 
> is sacrificed to enable some new proprietary interface.  This 
> is an area where standardization has seemly failed.
> 
> Browser exploits have become so pervasive as to require our 
> company to extensively retool behavior evaluations.  For 
> example, SMTP reputations are being converted to a 
> progressive scale to adjust for the growing prevalence of 
> 0wned systems.  It seems much of the malware activity is just 
> harder to detect.
> 
> It gets worse.  NATs are not a complete solution, and 
> represent a new challenge.  PNRP clouds combined with new 
> complex routing paths represents a risk that will be even 
> harder to evaluate and to enforce policies in a scaleable fashion.
> 
> In the early days of the Internet, the level of commerce and 
> related crime was far lower than it is today.  People are now 
> filing their Federal taxes on-line.  What the Internet is 
> being used for has changed significantly.  When defending 
> against criminal exploits, there is less doubt about risks.  
> The hazards are very apparent, although they might be harder 
> to detect.
> 
> That section is unfortunately significantly growing in 
> importance every day.  What seemed like a good idea, can 
> easily become a nightmare.
> 
> -Doug
>

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 3 Jul 2007 19:58:13 -0500

Thus spake "Melinda Shore" <[email-masked]>
>> I have a lot more trust in the simplicity of a basic NAT in a
>> consumer firewall then I do in any firewall which has to
>> examine each packet for conformance to complex policy
>> rules.
>

AFAIK, there's exactly one consumer CPE device on the market that does IPv6 
and it has a configuration option cleverly labelled "Block incoming IPv6 
connections" which is checked by default.

Perhaps he means Apple is overestimating users' intelligence by giving them 
a checkbox at all?  Leaving it at the default setting is rather complicated, 
after all...

Or perhaps he meant that an IPv4 NAT which has to do stateful packet 
inspection plus mangling both the packet headers and occasionally mangling 
packet payloads is less complicated than a IPv6 firewall that just has to do 
stateful inspection and either drop the packet or forward it without any 
mangling at all?

S

Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

---

From: SM <[email-masked]>
Date: Wed, 04 Jul 2007 00:03:19 -0700

At 08:37 03-07-2007, Hallam-Baker, Phillip wrote:
>Arguments about false senses of security are usually wrong. We are 
>adapted for an environment where sabre toothed tigers are running 
>around at night. So our tolerance for insecurity is much higher than 
>you might think. A sense of security is created by familiarity, not 
>by analysis.

NAT has coined an idiom that you are secure by virtue of using 
it.  That's not stopping the tigers.

>The point here is not to shut off connectivity, but to shut it off 
>by default. If the user knows they want to run an HTTP server they 
>can set it up accordingly. The nice thing about NAT boxes is that a 
>user who knows nothing about their network can plug one in and the 
>default state is to deny inbound connections.

Shutting off inbound connectivity comes five years too 
late.  Nowadays, the treat is also from the inside.  NAT makes it 
more difficult to identify and take measures against the offending host.

>What that means is that the MYSQL server or the embedded SQL Server 
>in their application they didn't even know they had is shut off from 
>external access. I was running an unpatched version of SQL server 
>when slammer hit without ill effect. I have boxes that have not been 
>booted for several years. I'll bet that much on the code on those 
>boxes is vulnerable too. I don't patch systems I am not currently using.

That $50 box can be set by default to deny incoming connections so 
that the user than knows nothing about their network can plug it 
in.  Outgoing connections could be restricted as well so as to deny 
these unpatched systems external access by default.  Currently, this 
is not viable due to IP addressing constraints.

>Sure you can do much better if you 1) know what you are doing and 2) 
>are prepared to put in the necessary time. Most people don't meet 
>either condition.

I agree.  Any solution for the type of user you mentioned is only 
effective if it is easy for them.

Regards,
-sm

---

From: "Tom.Petch" <[email-masked]>
Date: Thu, 5 Jul 2007 18:07:35 +0200

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 03, 2007 7:08 PM
Subject: Application knowledge of transport characteristics (was: Re: Domain
Centric Administration)

> construct used to cause all sorts of problems and hacks.

And perhaps still does.  SNMP and syslog work fine over UDP but both have had to
introduce a 'hack' to work over TCP (as seen in isms and syslog-tls
respectively).  netconf, which has never known UDP but would have been well
suited to it, also has a 'hack'.

But I see the converse too.  TLS defines what it needs of a transport layer and
TCP provides it (and more); UDP does not so DTLS introduces a shim to add some
(but not all) of TCP's features to UDP.

If we had a range of transports (perhaps like OSI offered), we could choose the
one most suited.  We don't, we only have two, so it may become a choice of one
with a hack.  But then that limited choice may be the reason why the Internet
Protocol Suite has become the suite of choice for most:-)

Tom Petch

Another is in the

---

From: Dave Crocker <[email-masked]>
Date: Thu, 05 Jul 2007 10:30:23 -0700

> one most suited.  We don't, we only have two, so it may become a choice of one

This nicely highlights a dilemma in this topic.  The OSI approach to multiple 
transports ensured that end-to-end interoperability was not achieved!

While the different transports were tailored to different underlying network 
characteristics, they did not deliver equivalent service to their 'customer' 
layer, in spite of the fact that those customers needed a uniform service.

I suppose this demonstrates why the discussion should be about layer n and 
n-1, rather than n and n+1...  Focus on the consumer-side of the architecture, 
when defining the service requirements that need to be abstracted, and then 
provided by the subordinate layer.

d/

-- 

   Dave Crocker

---

From: Lars Eggert <[email-masked]>
Date: Mon, 9 Jul 2007 08:53:05 +0300

> Protocol Suite has become the suite of choice for most:-)

We have four standards-track transport protocols (UDP, TCP, DCCP and  
SCTP), and, FWIW, SCTP has a concept of record boundaries.

Designers of applications and higher-layer protocols still have a  
tendency to ignore SCTP and DCCP and the particular features they can  
offer to applications. This can make applications more complex,  
because they need to re-invent mechanisms that a more appropriate  
transport protocol would have provided.

Lars

---

From: Douglas Otis <[email-masked]>
Date: Mon, 9 Jul 2007 00:46:14 -0700

On Jul 8, 2007, at 10:53 PM, Lars Eggert wrote:

>> If we had a range of transports (perhaps like OSI offered), we  
>> could choose the one most suited.  We don't, we only have two, so  
>> it may become a choice of one with a hack.  But then that limited  
>> choice may be the reason why the Internet Protocol Suite has  
>> become the suite of choice for most:-)
>
> We have four standards-track transport protocols (UDP, TCP, DCCP  
> and SCTP), and, FWIW, SCTP has a concept of record boundaries.
>
> tendency to ignore SCTP and DCCP and the particular features they  
> can offer to applications. This can make applications more complex,  

A desire to use TCP or UDP could also be due vested interests in  
existing solutions.  Utilization of transports with poor error  
detection capabilities as found with TCP or UDP checksums, and even  
Fletcher-32, have modulos that can mask fairly common memory or  
interface errors.  SCTP extends error detection and ensures jumbo  
frames are afforded end-to-end error detection equivalent to 1.5 KB  
ethernet LAN packets.  A number of errors go undetected by TCP or  
UDP.  Handling such errors by upper protocols layers is usually not  
robust, if even existent.  When reliability, high availability, low  
latency, and elimination of head of queue blocking matters, SCTP  
offers a clean solution.

-Doug

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 9 Jul 2007 10:07:06 +0200

On Jul 9, 2007, at 7:53 AM, Lars Eggert wrote:

>> could choose the
Yes, has the concept of record boundaries: It transfers user  
messages, not bytes like TCP.
But isn't the sane true for UDP and DCCP?
> Lars_______________________________________________
> Ietf mailing list
> [email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 9 Jul 2007 12:47:56 +0200

On Mon, Jul 09, 2007 at 08:53:05AM +0300,
 Lars Eggert <[email-masked]> wrote 
 a message of 98 lines which said:

> SCTP)

We have two standards-track protocols which have a reasonable chance
of being able to go through whatever stuff links your network to the
outside world.

> tendency to ignore SCTP and DCCP

Because experience shows them that, unfortunately, they do not cross
most firewalls and NAT devices?

This is, sadly, yet another case of Internet ossification.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 9 Jul 2007 08:16:40 -0700

On Jul 9, 2007, at 3:47 AM, Stephane Bortzmeyer wrote:

> Because experience shows them that, unfortunately, they do not  
> cross most firewalls and NAT devices?
>

SCTP does not illustrate Internet ossification at all, but rather  
these deployment issues are indicative of a particular desktop OS  
clinging to CP/M. : )

-Doug

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 10 Jul 2007 12:36:34 -0700

There are several reasons that application designers might not use DCCP and SCTP, one is that they are not aware of them, others are that they may not understand the deployment consequences of doing so or may lack the necessary support infrastructure to do so.
 
Attitudes may also be somewhat colored by bad experience with multicast which offers a wealth of intelectual excercises but not a platform that layer 7 people are likely to be interested in building on. I don't even know whether multicast packets will arrive at my ISP.
 
I think that the point you make really is at the heart of what domain centric is all about. Part of what we are lacking are properly structured session and presentation layers. If you get those right it becomes much easier to make lower layer changes.

Take SCTP for example. It makes perfect sense to use SCTP as a transport layer for HTTP Web browsing. But to make that possible we have to have some basic infrastructure like how the Web browser can know when to use HTTP over SCTP transport. If the system is going to work at all this information must be delivered through the DNS, thats what its for.
 
For unreliable protocols such as DCCP and Multicast we need to have an archetype (strictly speaking the term is paradigm but that has been abused) in which the bulk channel over the unreliable medium is paired with a control channel managed via a reliable medium. This approach allows us to finesse the entire problem of multicast security - integrity is managed via the unicast control channel.

For example, say that we have a web service intended to serve some heavyweight supply chain integration task (integ). example.com might advertize support for SCIT as follows
 
_integ.example.com TXT "wspolicy=http://policy.exampl.com/integ.xml"
 
Where the URI points to some sixteen page detailed XML profile of the protocol implementation, credentials required, etc. etc.

If on the other hand we are connecting to the web server we might have the following:
 
www.example.com <http://www.example.com>               XPTR example.com
_http.example.com            TXT "TCP SCTP"
_http._tcp.example.com       TXT "minv=1.0 maxv=1.1 TLS=(root=SHA256:1e23hd47ft34...)"
_http._sctp.example.com      TXT "minv=2.0 maxv=2.0 TLS=(root=SHA256:1e23hd47ft34...)"
 
_http._tcp.example.com       SRV 1 1 80   "web1.example.com"
_http._tls_tcp.example.com   SRV 1 1 443  "web2.example.com"
_http._sctp.example.com      SRV 1 1 8000 "web3.example.com"

The first line simply makes www.example.com an alias for example.com
The second line declares the toplevel policy parameters for http
The third  and fourth lines declare parameters for http over standard TCP and for SCTP
 
The last three lines are the SRV records for the three protocol variants (we assume that TLS upgrade takes place inband in HTTP/2.0.

The advantages to the protocol designer of this approach is that I can slot in a new transport protocol easily and I can make protocol changes that do not preserve backwards compatibility. HTTP/2.0 could use an incompatible binary transport designed for high speed rather than the traditional RFC822 approach. While we might debate the advantage of doing so for RFC822 it is pretty clear that the advantages for XML applications are real.

________________________________

From: Lars Eggert [mailto:[email-masked]]
Sent: Mon 09/07/2007 1:53 AM
To: Tom.Petch
Cc: [email-masked]; [email-masked]
Subject: Re: Application knowledge of transport characteristics (was: Re:Domain Centric Administration)

Lars