Subject: Netmeeting - NAT issue

From: "Vivek Gupta" <[email-masked]>
Date: Tue, 12 Mar 2002 16:48:10 -0500

Hi
I have been bugging U guys a lot for long now ..... especially Hari

OK here is another question quite similar to previous one:

Net meeting by Microsoft is not suppoted by NAT ..... this is the major problem 

--this is a problem with NAT or with NET meeting.??

I think I should rephrase my query ...wait

--Is it that the net meeting doesn't support NAT .... or the NAT doesn't support netmeeting.??

I know that Net Meeting doesn't work with NAT ..... but where exactly is the problem .......with NAT or with netmeeting

attached is my network set up

thanx
Vivek

---

From: "Peter Ford" <[email-masked]>
Date: Mon, 18 Mar 2002 11:51:45 -0800

Joe, 

To a large extent I agree with the goals.  And I am not saying NATs are
the cats pajamas, but they do existing and you and I yacking about it
are not going to make them go away.  (by the way, most people buying
NATs think they are buying a firewall and often have no clue as how they
work).  

Thus, we need to figure out how to get all the nice E2E properties at
the same time living in the world where we have intermediate systems
that need to be  convinced to let us do so.     What I am suggesting is
that there needs to be a generic way to ask for that permission, get the
request granted, and to operate under that permission.   I am proposing
negotiated signaling following the data path, not having the permission
implicitly granted by simply sending data.   At a minimum the end system
(application) makes the request, but the architecture should allow
proxies to operate on their behalf as well.

Adding the constraints of preserving dynamic routing (or routing
transparency) is fair.  I believe we have seen protocols that can do
that.  There have been sightings in networks that implement traffic
management for connectionless networks.

Regards, peterf

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Monday, March 18, 2002 8:08 AM
To: Peter Ford
Cc: Andrew McGregor; Vivek Gupta; [email-masked]
Subject: Re: Netmeeting - NAT issue

Peter Ford wrote:
> If one really believes in end to end architectures, then one probably
> would want generalized protocols for supporting hosts telling the
> network what to do wrt opening holes at NATs/Firewalls for inbound
> traffic.

Actually, if one believes in the E2E arch (more specifically, the STD 
documents), we should admit that:

	- NATs are _designed_ to make everything behind them
	look like a single host

	- they work fine exactly where that's sufficient

	- they break very badly for EVERY new protocol that
	coordinates ports or IP addresses in-band, and in any
	other case where everything behind them does NOT
	want to work like a single host

A generalized protocol for opening holes would fundamentally alter the 
Internet architecture (as specified in the STD docs) to _require_ path 
setup, which defeats dynamic routing, and, more specifically, the 
fundamentally connection-free property of datagram service.

Joe

---

From: "John Stracke" <[email-masked]>
Date: Mon, 18 Mar 2002 13:18:57 -0500

>The protocols explicit probe the first hop router on the network for
>upnp capabilities.  In their model of a home gateway/LAN there is no
>"internal" routing, the world is bridged, so the signaling should not
>damage routing transparency.

But just imposing that model removes transparency.  Maybe I have a router
between my wireless and wired Ethernets.  That's a reasonable thing to
do--say, if the wired segment is 100Mbps and is carrying high-bandwidth
{broad|multi}cast traffic.  Or maybe I have a substantial number of home
appliances with network connections, and I don't trust their software to
be secure, so I put them in a DMZ, like this:

(Internal LAN) <--> (Firewall A) <--> (DMZ LAN) <--> (Firewall B) <-->
(Outside world)

/===============================================================\
|John Stracke                    |Principal Engineer            |
[email-masked]   |Incentive Systems, Inc.       |
|http://www.incentivesystems.com |My opinions are my own.       |
|===============================================================|
|If God had not given us duct tape, it would have been necessary|
|to invent it.                                                  |
\===============================================================/

---

From: "Peter Ford" <[email-masked]>
Date: Tue, 19 Mar 2002 13:37:11 -0800

Keith,

In a just world, people freely purchase the things they want and believe
solves a real world problem for them.   

The Internet has grown at an incredible rate and I suspect in large part
due to NATs.   I wonder if the Internet would sue the NAT vendors, or
thank them for establishing a broader customer base, especially
customers who pay for broadband?  (in the u.s. they would certainly be
honored for accomplishments and sued! )     

I would like to close this discussion with: the Internet has v6 coming
in the pipeline, and the AT of NATs will go probably go away as a
result.  apps in general need transparent connectivity amongst peers,
but the tacit assumption that all an app has to do is send a packet is
not realistic  and things will just work is unrealistic.  In other
words, NATs becoming personal firewalls is a growth market.   Like
almost every other resource, the network is something that will be
managed, inspected, measure, and controlled by some policy.  This will
be manifested in a collection of protocols from the host "asking" the
network to do things.  MobileIP is an example, authenticated firewall
traversal is another.   I predict you will see what some have called the
"remote bind" problem of opening holes in firewalls and NATs for
listening services behind firewalls to be an important protocol to get
nailed.  The extent to which we can help people NOT be firewall admins,
the better off we all will be.

I would not be wasting my time sending mail to this list if I did not
suspect the IETF knew where the problems are.   What I am hoping will
arise is action and results.

Cheers, peterf

P.S.  lighten up.   We will get v6 tunneled over v4 over NATs as well.
What bliss!

---

From: "John Stracke" <[email-masked]>
Date: Wed, 20 Mar 2002 12:14:08 -0500

>Since software doesn't have
>the same attention variability over time as humans,

The variability isn't as great, but it's certainly there.  It's not that 
the software's attention falters, but that the attention of the human who 
has to maintain the system falters--and, when that happens, the software's 
attention, in effect, drops, and does not vary upwards again until the 
human installs the security fix.

/=================================================================\
|John Stracke                    |Principal Engineer              |
[email-masked]   |Incentive Systems, Inc.         |
|http://www.incentivesystems.com |My opinions are my own.         |
|=================================================================|
|McDonald's, which does not wait on your table, does not cook your|
|food to order, and does not clear your table, came up with the   |
|slogan "We Do It All For You." -- Dave Barry                     |
\=================================================================/

---

From: "Peter Ford" <[email-masked]>
Date: Wed, 20 Mar 2002 10:05:57 -0800

(caveat emptor: I have an end system^H^H^H^H^H^H^H^H^H^H host bias)

There are several good reasons to have BOTH a border and end system
depth in defense.

From an architectural view, the advantage of edge/border elements is
that they are in a better position to protect against
distributed/correlated attacks. (the downside is how fast do they have
to run).

Due to the nature of the "last bug" and its unwillingness to get fixed,
it will be necessary to  multiple points of security to avoid single
points of failure - good engineering.  Hosts should handle as close to
everything as possible.

Security through obscurity is always laughed at, but one of the big
roles of intermediate firewalls is to provide a blinding function.
Sure, the thief knows I have a wallet somewhere in my house when I am
asleep.  The fact that he does not know exactly where it is  helps.  It
is not an absolute solution, it is just another layer in the onion.(and
there are lots of other reasons for "blinding boxes").

In most enterprises there is separation of management responsibilities.
It is natural to think that the roles and responsibilities of edge vs
host based protection are different.  The controller of a company is
responsible for being sure the business is conforming to a set of rules.
The line of business owner is implementing a business, generally aware
and conforming to the rules, but does make mistakes, overt or
inadvertent (one LOB not understanding what another LOB is doing and
potentially breaking an aggregate rule).   I agree with the earlier
comments on checks and balances.

  (in a just world we would not need a justice system, but I think we
have concluded that a lot of the internet resides in the real world)

-----Original Message-----
From: Tony Hain [mailto:[email-masked]] 
Sent: Wednesday, March 20, 2002 8:23 AM
To: [email-masked]
Cc: J. Noel Chiappa; [email-masked]
Subject: RE: Netmeeting - NAT issue 

Valdis.Kletnieks wrote:
> The host may be too stupid to protect itself - read Bugtraq
> or other similar
> lists for the gory details.

The fact that many hosts are too stupid to protect themselves is not a
reason to architecturally require that the border provide security. The
marketplace may find an opportunity there, but 'the right thing' is to
set the expectation that self defense is the requirement.

> In addition, an external border is useful as a
> checks-and-balances, for the
> same sort of reasons why the person balancing your company's
> books shouldn't
> be the guy writing the checks,

Since I do both, I have a hard time agreeing with this analogy. Also if
you start down this path as justification for a filtering router as a
security device, there needs to be an external auditor in the picture.
Where is that service in the average NAT?

> or having Customs inspectors at the border
> crossing - what percent of the people on international
> flights understand
> the rules about carrying live biologicals (both animal and
> vegetable) for
> any country they may be visiting?

This argument has some level of merit, but has the orientation
backwards. The border guard is not there to protect the traveler who
might be inadvertently (or maliciously) carrying contraband substances
across the border. They are there because it is cheaper to have a few
educated guards than to continually educate the entire internal
population on proper isolation and disposal. Since software doesn't have
the same attention variability over time as humans, or the continual
churn in education level for each generation, there is reason to believe
that eventually self protection could be cheaper than the overhead of a
collection of border guards.

My question was directed at Noel's assertion that security requires a
site border router as the implementation. Just because that may be
cheaper than fixing all the current hosts, wouldn't we be better off in
the long run if all future hosts protected themselves?

Tony

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Thu, 21 Mar 2002 11:13:22 -0500

> From: "Tony Hain" <[email-masked]>

    > it may be more convenient to have the border deal with DOS, but is it
    > *required* as Noel asserted?

First, there's "good idea", "required", and "*required*". It's *required*
that your computer have a test-and-branch instruction to be a Turing machine.
It's not *required* that it have a jump instruction, but all computers do -
so it're pretty much required in a machine architecture. An example of "good
idea" would be lots of registers - most machines have that, but not all. Etc,
etc.

I never said it was *required* to have some security functions at the border
- merely that it was likely to happen for a variety of reasons (e.g. policy
enforcement in a large organization). I think my meaning was somewhere
between "good idea" and "required" (as defined above) - I don't know exactly
where.

Second, when I made my statement about "security alone demands that we be
able to move some functionality to a 'site border router', or some such", I
was speaking of security stuff in general, not DoS protection in particular.

I think there are different kinds of DoS attacks (I actually created a
taxonomy of DoS attacks for a research effort I'm involved with), and I expect
that different DoS attacks will need different mechanisms to handle them (i.e.
in the most efficient and robust manner - bearing in mind the old adage that
"and engineer is someone who can do for $1 what any fool can do for $5"). I
suspect that some might be at the borders, some might be at the servers - but
that's my intuition.

But DoS is still a very limited corner of "security".

	Noel