Are you actually saying that providers in the middle should build their
networks to accommodate any amount of DDOS traffic their ingress can
support instead of filtering it at their edge? How do you expect them
to pay for that? Do you really want $10,000/megabit transit costs?
Owen
--On Friday,
Are you actually saying that providers in the middle should build their
networks to accommodate any amount of DDOS traffic their ingress can
support instead of filtering it at their edge? How do you expect them
to pay for that? Do you really want $10,000/megabit transit costs?
I remember
I remember GM saying something like that about this car that
put Nader on political arena. Are we that dumb that we need
to be taught the same lessons?
GM seems to still be building cars and trucks, and Nader lost a presidential
election.
Which lesson were we supposed to learn?
Matthew
I remember GM saying something like that about this car that
put Nader on political arena. Are we that dumb that we need
to be taught the same lessons?
GM seems to still be building cars and trucks, and Nader lost a presidential
election.
GM seems to also have cut a very big check to
Date: Tue, 28 Oct 2003 21:51:01 -0500
From: [EMAIL PROTECTED]
The real problem is that we have an environment where the
malware can figure out how to disable the firewall but the user
can't.
And part of why the current Internet has so much peer-to-peer
traffic on it. ;-)
Eddy
--
JB Date: Wed, 29 Oct 2003 15:27:27 -0600
JB From: Jack Bates
JB I think the point that was being made was that NAT allows the
JB filtering of the box to be more idiot proof. Firewall rules
JB tend to be complex, which is why mistakes *do* get made and
JB systems still get compromised. NAT
That was _exactly_ the point I was attempting to make. If you recall
there was a case recently where a subcontractor at a power generation
facility linked their system to an isolated network which gave
unintentional global access to the isolated network. a NAT at the
subcontrator's interface
On Thu, 2003-10-30 at 09:22, Scott McGrath wrote:
That was _exactly_ the point I was attempting to make. If you recall
there was a case recently where a subcontractor at a power generation
facility linked their system to an isolated network which gave
unintentional global access to the
Leave content filtering to the ES, and *force* ES to filter the content.
Its not content filtering, I'm not filtering only certain html traffic
(like access to porn sites), I'm filtering traffic that is causing harm to
my network and if I know what traffic is causing problems for me, I'll
Recently, [EMAIL PROTECTED] (Alex Yuriev) wrote:
Leave content filtering to the ES, and *force* ES to filter the content.
Its not content filtering, I'm not filtering only certain html traffic
(like access to porn sites), I'm filtering traffic that is causing harm to
my network and
Alex, please re-read the first paragraph. He said
I'm filtering traffic that is causing harm to *my* network...
(emphasis mine).
He's not filtering out packets he thinks are causing problems
to the ES, he's filtering out packets that are causing him
problems directly, as the IS.
And
At 02:41 PM 10/30/2003, Alex Yuriev wrote:
Alex, please re-read the first paragraph. He said
I'm filtering traffic that is causing harm to *my* network...
(emphasis mine).
He's not filtering out packets he thinks are causing problems
to the ES, he's filtering out packets that are causing
to the ES, he's filtering out packets that are causing him
problems directly, as the IS.
And since the IS is not the ES, it SHOULD NOT be filtering based on content
since it is NOT IS's content. Again, *force* ES to filter and hold it
responsible for not doing it.
Do you have a
At 03:25 PM 10/30/2003, Alex Yuriev wrote:
to the ES, he's filtering out packets that are causing him
problems directly, as the IS.
And since the IS is not the ES, it SHOULD NOT be filtering based on
content
since it is NOT IS's content. Again, *force* ES to filter and hold it
On Thu, 30 Oct 2003 12:12:22 EST, Alex Yuriev said:
Leave content filtering to the ES, and *force* ES to filter the content.
Its not content filtering, I'm not filtering only certain html traffic
(like access to porn sites), I'm filtering traffic that is causing harm to
my network and
Christian:
And I bet then still somebody will build an IPv6 NAT box for some
bizarro
reason.
ftp://ftp.rfc-editor.org/in-notes/rfc2766.txt
Gary Blankenship
Foundry Networks (Japan)
On Wed, Oct 29, 2003 at 10:06:37AM +0100, Stefan Mink wrote:
Does anybody honestly think companies will commit the capex needed to
implement IPv6?
Not without additional benefits. We need either applications that are
working a lot better at ipv6 or we may yet have to see ipv4 space ran
Avleen Vig wrote:
If more IP addresses is the only motivation for using IPv6, it's
really not enough. For environments where direct access to the
internet isn't required, NAT serves perfectly well.
IPSec, SIP/VoIP or almost anything that relies on UDP borks on NAT,
doesn't it?
No.
Anything that relies on knowing which host it is talking to by looking at
the source address of packets breaks.
Plenty of UDP based apps work over NAT.
Simon
On Wed Oct 29, 2003 at 10:57:35AM -, Dave Howe wrote:
Avleen Vig wrote:
If more IP addresses is the only motivation for
On Wed, Oct 29, 2003 at 11:03:11AM +, Simon Lockhart wrote:
No.
Anything that relies on knowing which host it is talking to by looking at
the source address of packets breaks.
Plenty of UDP based apps work over NAT.
Indeed, and IPSec tunnels are frequently done between routers on
On Wed, 29 Oct 2003 03:14:20 -0800 Avleen Vig [EMAIL PROTECTED] wrote:
On Wed, Oct 29, 2003 at 11:03:11AM +, Simon Lockhart wrote:
No.
Anything that relies on knowing which host it is talking to by looking at
the source address of packets breaks.
Plenty of UDP based apps work over
Simon Lockhart wrote:
Anything that relies on knowing which host it is talking to by
looking at the source address of packets breaks.
Indeed. Novell networking for example - or MS Exchange New Mail
notification. of course, you shouldn't be doing either on the internet,
but a common small
Avleen Vig wrote:
Indeed, and IPSec tunnels are frequently done between routers on
networks, rather than individual hosts on networks (at least in most
multi-site enterprises i've seen).
Indeed so yes - however... A large and increasing segment of my users are
VPN laptop users with ADSL at
On Wed, 29 Oct 2003, Avleen Vig wrote:
Indeed, and IPSec tunnels are frequently done between routers on
networks, rather than individual hosts on networks (at least in most
multi-site enterprises i've seen).
The most common use of VPN links is the roadwarrior.
IPSEC in this context is broken
Kuhtz, Christian wrote:
And there are workarounds for all those.
NAT-T for ipsec is really intended for endnodes only - which is fine if
you are doing the NAT yourself (typical medium/large company scenario -
internal users shouldn't be using IPSEC, that is done at the
gateway/firewall) but
; Dave Howe; Email List: nanog
Subject: Re: [arin-announce] IPv4 Address Space (fwd)
On Wed, 29 Oct 2003, Avleen Vig wrote:
Indeed, and IPSec tunnels are frequently done between routers on
networks, rather than individual hosts on networks (at
least in most
multi-site enterprises
Dave Howe wrote:
Indeed so yes - however... A large and increasing segment of my users are
VPN laptop users with ADSL at home. our accounts department looks a
certain amount of askance at IT when they get a large phone bill in
expenses for someone using a 33.6 modem right next to a nice shiny
Kuhtz, Christian wrote:
Seems several commercial clients (such as Cisco's VPN client) offer
workaround for that (tunneling IPSEC in a TCP session). Works great.
Yup. there are various proprietary solutions that require us to trash out
an expensive and *working* VPN-1 solution, buy an equally
On Wed, 29 Oct 2003, Kuhtz, Christian wrote:
Seems several commercial clients (such as Cisco's VPN client) offer
workaround for that (tunneling IPSEC in a TCP session). Works great.
I'm sure I could also setup a PPPoEmail shim that would bypass most of
these problems..
Who needs routers
The fact that something can be worked around with enough
footwork really doesn't make okay.
Sure. Neither is it ok for VPN vendors to pretend as if NAT wasn't a part
of daily life and reality.
Consider the congestion related behavior of TCP inside TCP.
Consider the additional perpacket
On Wed, 29 Oct 2003 15:10:18 GMT, Dave Howe [EMAIL PROTECTED] said:
but sucks if your cable or xDSL ISP decides NAT is the
way to go. (usually followed by a well, you shouldn't need two or more
nodes there/want to run a server/care about SIP, a business should pay for
a
Kuhtz, Christian wrote:
Kuhtz, Christian wrote:
Seems several commercial clients (such as Cisco's VPN client) offer
workaround for that (tunneling IPSEC in a TCP session).
Works great.
Yup. there are various proprietary solutions that require us
to trash out an expensive and *working* VPN-1
In a message written on Wed, Oct 29, 2003 at 09:35:13AM -0600, Kuhtz, Christian wrote:
Simply ignoring present reality isn't a globally wise solutions. Hence we
have broken VPN products incapable of dealing with NAT. Some are capable of
dealing with NAT just fine, and are readily available.
No. IPSEC and SIP break because their payloads include information that
is dependent on the IP address header. In the case of IPSEC, this is
to support end-to-end authentication and avoid certain kinds of man-in-
the-middle attacks. In the case of SIP, it's because SIP is a call setup
protocol
Right... Forgot about the SNMP breakage. SIP doesn't depend on knowing
which host it's talking to from the source address, but, it does depend
on being able to assign RTP session parameters based on IP addresses
contained within the SIP payload. Thus, when the SIP payload goes through
a NAT box
However, what is authenticated in the IPSEC datagrams is the addresses
of the IKE gateways (the routers). The fact that an entire netblock
exists within the tunnel is not especially relevant to the part
that suffers from NAT breakage.
Owen
--On Wednesday, October 29, 2003 3:14 AM -0800 Avleen
And sometimes you use NAT because you really do not want the NAT'ed device
to be globally addressible but it needs to have a link to the outside to
download updates. Instrument controllers et.al.
The wisdom of the design decision to use the internet as the only method
to provide software
In article [EMAIL PROTECTED],
Scott McGrath [EMAIL PROTECTED] wrote:
And sometimes you use NAT because you really do not want the NAT'ed device
to be globally addressible but it needs to have a link to the outside to
download updates. Instrument controllers et.al.
I don't understand. What is
The end result is that in the near future it will be much
harder, or impossible for network operators to collect
statistics based on traffic type or to filter particular
types of traffic without being able to dig into the payload
itself and see what type of traffic is passing.
Some
In article
[EMAIL PROTECTED]
arvard.edu,
Scott McGrath [EMAIL PROTECTED] wrote:
And sometimes you use NAT because you really do not want the NAT'ed
device to be globally addressible but it needs to have a link to the
outside to download updates. Instrument controllers et.al.
I
Life would be much simpler without NAT howver there are non-computer
devices which use the internet to get updates for their firmware that most
of us would prefer not to be globally reachable due to the human error
factor i.e. Oops forgot a rule to protect X.
The radar on your cruise ship uses
In a message written on Wed, Oct 29, 2003 at 02:24:54PM -0600, Kuhtz, Christian wrote:
Isn't that the whole point of running a VPN connection?
Yes. What I'm saying is network operators are slowly forcing
everyone to run _everything_ over a VPN like service. That's fine,
but it makes network
On Wed, 29 Oct 2003, Scott McGrath wrote:
Life would be much simpler without NAT howver there are non-computer
devices which use the internet to get updates for their firmware that most
of us would prefer not to be globally reachable due to the human error
factor i.e. Oops forgot a rule to
In a message written on Wed, Oct 29, 2003 at 02:24:54PM
-0600, Kuhtz, Christian wrote:
Isn't that the whole point of running a VPN connection?
Yes. What I'm saying is network operators are slowly forcing
everyone to run _everything_ over a VPN like service. That's
fine, but it
David Raistrick wrote:
You seem to be arguing that NAT is the only way to prevent inbound access.
While it's true that most commercial IPv4 firewalls bundle NAT with packet
filtering, the NAT is not required..and less-so with IPv6.
I think the point that was being made was that NAT allows the
Owen DeLong wrote:
It's much the
same problem as FTP. The reason FTP doesn't BORK is because most NAT
gateways understand about the need to proxy FTP and because PASSIVE mode
FTP doesn't have the same call-setup problems.
Passive mode has the same problems that PORT FTP does. It just
In a message written on Wed, Oct 29, 2003 at 02:24:54PM -0600, Kuhtz, Chris=
tian wrote:
Isn't that the whole point of running a VPN connection?
Yes. What I'm saying is network operators are slowly forcing
everyone to run _everything_ over a VPN like service. That's fine,
but it
I think the other point that may be escaping some people,
is that as more and more connections take on this VPN-like
quality, as network operators we lose any visibility into
the validity of the traffic itself.
As the network operators, we move bits and that is what we should stick to
On Wed, 29 Oct 2003, Alex Yuriev wrote:
As the network operators, we move bits and that is what we should stick to
moving.
We do not look into packets and see oh look, this to me looks like an evil
application traffic, and we should not do that. It should not be the goal
of IS to enforce
On Wed, 29 Oct 2003, Alex Yuriev wrote:
As the network operators, we move bits and that is what we should stick to
moving.
We do not look into packets and see oh look, this to me looks like an evil
application traffic, and we should not do that. It should not be the goal
of IS to
Recently, [EMAIL PROTECTED] (Alex Yuriev) wrote:
On Wed, 29 Oct 2003, Alex Yuriev wrote:
As the network operators, we move bits and that is what we should stick to
moving.
We do not look into packets and see oh look, this to me looks like an evil
application traffic, and we
Jack Bates wrote:
David Raistrick wrote:
You seem to be arguing that NAT is the only way to prevent inbound access.
While it's true that most commercial IPv4 firewalls bundle NAT with packet
filtering, the NAT is not required..and less-so with IPv6.
I think the point that was
On Wed, 29 Oct 2003, Alex Yuriev wrote:
application traffic, and we should not do that. It should not be the goal
of IS to enforce the policy for the traffic that passes through it. That
type of enforcement should be left to ES.
Well, that is nice thery, but I'd like to see how you
Some would ask, What about increasing address usage?
Only the ones who weren't at the ARIN meeting in
Chicago where we saw a chart showing that monthly
consumption of IP addresses continues to decrease
as it has since around the year 2000.
I would ask, What evidence do you have that usage is
Does anybody honestly think companies will commit the
capex needed to
implement IPv6?
William Leibzon wrote:
Not without additional benefits.
I agree, and they're all gone now. To my deepest regrets,
IPv6 has become nothing more than IPv4 with more bits (it's
actually worse
On Tue, 28 Oct 2003, Kuhtz, Christian wrote:
Excuse my rambling and what some may consider heresy even :), but..
One question to ask is whether IPv6's approach is the right one, furthering
a particular way of doing things rather than really reinventing itself. Do
I really need global
End-to-end requires that people writing the software at the end learn about
buffer overruns (and other data-driven access violations) or program using
tools that prevent such things. It is otherwise an excellent idea.
Unfortunately, the day that someone decided their poorly-designed machine
and
On Tue, 28 Oct 2003 [EMAIL PROTECTED] wrote:
The bottom line is that there are three different models
which may predict when we run out of IPv4 addresses. The
models predict dates ranging from 2022 to 2045. None of
the models predict an exact year, they all predict a range
of 4 to 8 years
On Tue, 28 Oct 2003, Matthew Kaufman wrote:
End-to-end requires that people writing the software at the end learn about
buffer overruns (and other data-driven access violations) or program using
tools that prevent such things. It is otherwise an excellent idea.
A lack of end-to-end just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andy Dills wrote:
| On Tue, 28 Oct 2003 [EMAIL PROTECTED] wrote:
|
|
|The bottom line is that there are three different models
|which may predict when we run out of IPv4 addresses. The
|models predict dates ranging from 2022 to 2045. None of
|the
Yes, because IPv6 is merely and incremental improvement, not a grand
elegant solution to world hunger like ATM. Look at how we managed the
incremental step of adding MPLS to our IPv4 networks. It was fairly
painless because it uses the same boxes, the same people and the same
management
Matthew Kaufman wrote:
End-to-end requires that people writing the software at the end learn about
buffer overruns (and other data-driven access violations) or program using
tools that prevent such things. It is otherwise an excellent idea.
There is supposedly some magic going into this in the
Kuhtz, Christian wrote:
I'm not saying IPv6 is dead, but I think a leap, rather than an incremental
improvement may be needed. Unless somebody actually does come up with an
IPv6 killer app...
Most Internet traffic is p2p traffic. IPv6 (by virtue of eliminating
most perceived needs for NAT
I think if program design criterion would change, to coding secure applications then
the problem would be reduced dramatically
-HenryPetri Helenius [EMAIL PROTECTED] wrote:
Matthew Kaufman wrote:End-to-end requires that people writing the software at the end learn aboutbuffer overruns (and other
and operating system would be safer sitting behind a firewall
pretty much marked the end of universal end-to-end connectivity,
and I don't see it
An OS-level (software) firewall doesn't preclude end-to-end connectivity,
and even a per-machine hardware firewall doesn't given it can pass inbound
On Tue, 28 Oct 2003 18:28:55 CST, Adam Selene [EMAIL PROTECTED] said:
A probably configured firewall will protect a machine against everything but
it's user, and therein lies a problem you will likely never solve.
The real problem is that we have an environment where the malware can figure
On Tue, 28 Oct 2003 18:28:55 CST, Adam Selene [EMAIL PROTECTED] said:
A probably configured firewall will protect a machine against
everything but
it's user, and therein lies a problem you will likely never solve.
The real problem is that we have an environment where the malware
can
I love this.
ARIN publicly states, Whatchoo talkin about, Willis? (see announcement
below)
So, by extrapolation, if we've collectively used 20 /8s over the past 5
years, and we have 90 left, that's over 20 years of IPv4 growth we have
left.
Some would ask, What about increasing address
Andy Dills wrote:
Technologies like NAT and efforts to reclaim poorly assigned address space
have a large negative pressure on the increase of IP utilization. As more
and more appliances need IP addresses, people will realize more and more
that the last thing they want is those applicances on
On Mon, Oct 27, 2003 at 04:10:26PM -0500, Andy Dills wrote:
Technologies like NAT and efforts to reclaim poorly assigned address space
have a large negative pressure on the increase of IP utilization. As more
and more appliances need IP addresses, people will realize more and more
that the
Does anybody have statistics for assigned-but-not-announced space? I'd be
willing to bet there will be more and more dead space over the years, and
in fact quite a bit of increasing usage is just churn.
I have these statistics at
http://www.completewhois.com/statistics/ip_statistics.htm
At
Does anybody honestly think companies will commit the capex
needed to implement IPv6?
William Leibzon wrote:
Not without additional benefits.
I agree, and they're all gone now. To my deepest regrets, IPv6 has
become nothing more than IPv4 with more bits (it's actually worse than
IPv4 as of
We need either applications that are working a lot better at
ipv6 or we may yet have to see ipv4 space ran out before it
becomes clear to everybody that ipv6 is a must.
Besides, IPv4 will never run out; as pointed out to me recently, it will
simply become more expensive as it becomes
73 matches
Mail list logo
