Vernon Schryver wrote:
Actually, those who understand the security problem of IP source routes
knows something else. IP source route options are not problems except to
broken hosts. It would be nice to think there are no longer such broken
hosts on the net, but that is too much to expect.
"Parkinson, Jonathan" wrote:
Well he's obviously devoted to this mailing list and hey, perhaps they have
the same problems with the Internet on the other side !
Well, I actually have that problems. Even working as a ghost, I am
making efforts to contribute to this really large network
Please excuse my incessant ramblings, but I am sure some of this makes sense. I am
tired and thies email proves it.most of this is in the context of DDos
Obviously the very nature of the distributed attack makes it difficult to protect
against. Employing packet chokes, or CAR at some
: Re: Internet SYN Flooding, spoofing attacks
On Fri, 25 Feb 2000, Jean Paul Sartre wrote:
Stephen Kent wrote:
I'll suggest one course of action, but I keep emphasizing the issue
is not one of alternates, but of recognizing the limitations of
proposals now on the table and considering
, February 24, 2000 14:40
Subject: RE: Internet SYN Flooding, spoofing attacks
Well he's obviously devoted to this mailing list and hey, perhaps they have
the same problems with the Internet on the other side !
-Original Message-
From: Lloyd Wood [mailto:[EMAIL PROTECTED]]
Sent: Thursday
Lloyd Wood wrote:
On Fri, 25 Feb 2000, Jean Paul Sartre wrote:
I am willing to write a document on the means of packet filtering and
how rules should work for different configurations and environments.
You can't, because you died in 1980.
His TTL ran out.
--
]
Date: Thursday, February 24, 2000 14:40
Subject: RE: Internet SYN Flooding, spoofing attacks
Well he's obviously devoted to this mailing list and hey, perhaps they have
the same problems with the Internet on the other side !
-Original Message-
From: Lloyd Wood [mailto:[EMAIL
: [EMAIL PROTECTED]
Subject: RE: Internet SYN Flooding, spoofing attacks
Furthermore, he was posting from the future...
snip
You can't, because you died in 1980.
Existentialists don't "die," they just go from being to nothingness.
RGF
Robert G. Ferrell, CISSP
Information Security Officer
National Business Center, US DoI
[EMAIL PROTECTED]
Nothing I have
On Thu, 24 Feb 2000, Parkinson, Jonathan wrote:
Well he's obviously devoted to this mailing list and hey, perhaps they have
the same problems with the Internet on the other side !
Talk about cognitive dissonance, can you imagine the shock felt by an
existentialist to discover that there is
Source-routed packets from untrusted hosts, as many of us know, have to
be dropped/ignored. I do not know if there is another kind of attack
regarding the forging of IP headers, as I didn't study ( :( ) the TCP/IP
RFCs.
Actually, those who understand the security problem of IP source
At 02:20 17-02-00 , Phil Karn wrote:
It's not because fixed addresses actually cost them more. Indeed,
another cable modem provider in the other part of town allocates fixed
addresses in an otherwise identical service that's $5/mo cheaper. No,
my provider does it simply because they can. They're
Stephen Kent wrote:
Eliot,
Some of the DoS attacks we saw last week were good, old-fashioned SYN
floods. Hosts do have a responsibility here, more than ISPs, since
it is quite feasible to tie up a host's pool of TCBs with a small
number of packets, even if the attack tool does not use
Dan,
I'll suggest one course of action, but I keep emphasizing the issue
is not one of alternates, but of recognizing the limitations of
proposals now on the table and considering approaches that may work
irrespective of whether everyone performs filtering.
With regard to a wide range of DoS
Yes, and you chose the CORRECT solution. Think about it... VPN in most
cases also means encryption, and at that probably back to a central
site.
Yes, I often use encryption, but not to a central site. Generally I
apply it at the application layer (SSH/SSL) so the peer is whoever I happen
to be
Eliot,
Some of the DoS attacks we saw last week were good, old-fashioned SYN
floods. Hosts do have a responsibility here, more than ISPs, since
it is quite feasible to tie up a host's pool of TCBs with a small
number of packets, even if the attack tool does not use spoofed
sourced addresses
In message v04220802b4d078236d2c@[171.78.30.107], Stephen Kent writes:
Eliot,
Some of the DoS attacks we saw last week were good, old-fashioned SYN
floods. Hosts do have a responsibility here, more than ISPs, since
it is quite feasible to tie up a host's pool of TCBs with a small
Steve,
The ATT experiences might be different, but at GTE-I, a SYN flood
was the primary attack mechanism for one major web site that we host.
Also, it is not at all clear that our network had a problem handling
the other flooded traffic (ICMP Echo Reply and UDP traffic) that was
sent to 3
Date:Wed, 16 Feb 2000 18:20:43 -0800
From:Phil Karn [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| Even if I could find somebody at their help desk
| who understood a request to open up their filter to my own IP addresses,
| they would have no incentive to
From: "Charles E. Perkins" [EMAIL PROTECTED]
...
I really wish "we" actually knew how to filter.
But maybe filtering is putting the cart before the horse.
I agree.
...
From that analogy, I claim that the appropriate action is to
develop tracing systems that will help to identify a
At 11:15 AM 02/15/2000 +, Lloyd Wood wrote:
A lot of surveillance can be based on 'if A is talking to B, then A
must be as guilty as B', and message content is irrelevant. This
helps counters that.
Well, get over it. ;-)
(Smiley included for the humor impaired.)
- paul
On Mon, 14 Feb 2000 16:04:28 PST, Phil Karn said:
Source address ingress filtering is one of those ideas that seems like
a good one when you first think about it, but it just doesn't pan out.
It interferes with some perfectly legitimate activities, it doesn't
really stop the bad guys, and it
From: [EMAIL PROTECTED]
...
Well.. as soon as somebody presents us with "the real solution", we'll start
implementing. In the meantime, filtering is the best we know how to do.
...
I really wish "we" actually knew how to filter.
Just as I feared when the news broke, I'm seeing more paths
On Tue, Feb 15, 2000 at 10:22:46AM -0700, Vernon Schryver wrote:
From: [EMAIL PROTECTED]
...
Well.. as soon as somebody presents us with "the real solution", we'll start
implementing. In the meantime, filtering is the best we know how to do.
...
I really wish "we" actually knew how
From: "Michael H. Warfield" [EMAIL PROTECTED]
...
But some of us turn off ICMP except for ICMP_FRAG_NEEDED and keep
MTU discovery alive while cutting off the ICMP food fights and script
kiddie probes that seem to be endemic in our current mess.
Why couldn't you do as has been
Hello Vernon,
Well.. as soon as somebody presents us with "the real solution", we'll start
implementing. In the meantime, filtering is the best we know how to do.
...
I really wish "we" actually knew how to filter.
But maybe filtering is putting the cart before the horse.
I compare
From: Vernon Schryver [EMAIL PROTECTED]
...
The basic idea then would be to trace back bad packets that
conform to some typically innocent, but occasionally troublesome,
profiles. The profiles will become self-evident with experience,
and once people know they will be caught by this
Date:Mon, 14 Feb 2000 00:37:29 -0500
From:"Donald E. Eastlake 3rd" [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| I think that making egress filtering a BCP, applying community
| pressure, bringing law suites, etc., will be about as effective
| at
Phil Karn wrote:
tomorrow demands. And, agreed, bogus source IPs _does_ at present time
look like nothing but the devils work. But in, say, 10 years a new flashy
techology could be requiring that you have the ability to stamp packets with
other IPs than your own. Unfortunately, back in
Robert Elz [EMAIL PROTECTED] wrote:
I'm not sure there is a good analogy there.There's no good purpose
in sending packets with incorrect source addresses I can think of, and
stopping the practice is the basic intent of the filters.
"In his early days at Intel, Andy Grove was approached by an
Robert Elz wrote:
There's no good purpose
in sending packets with incorrect source addresses I can think of, and
stopping the practice is the basic intent of the filters.
Mobile IP would like to send out packets with the mobile node's
home address,
tomorrow demands. And, agreed, bogus source IPs _does_ at present time
look like nothing but the devils work. But in, say, 10 years a new flashy
techology could be requiring that you have the ability to stamp packets with
other IPs than your own. Unfortunately, back in year 2000, somebody put in
At 03:41 PM 02/14/2000 -0800, Charles E. Perkins wrote:
Mobile IP would like to send out packets with the mobile node's
home address, while it is attached to a network in a foreign
domain. The home address is likely to look "incorrect" from
the standpoint of such a filter.
If I'm not mistaken
"Charles E. Perkins" wrote:
Robert Elz wrote:
There's no good purpose
in sending packets with incorrect source addresses I can think of, and
stopping the practice is the basic intent of the filters.
Mobile IP would like to send out packets
ebruary 12, 2000 1:55 PM
Subject: Re: Internet SYN Flooding, spoofing attacks
Paul,
When one suggests that a first tier ISP would not need to filter
traffic from down stream providers, because IF they do the
filtering,
then the problem will not arise via those links, one is suggesting
[EMAIL PROTECTED] writes:
Given that RFC2267 is over 2 years old now, what *do* you suggest the network
community at large do to motivate the sites that still haven't
implemented it?
I think a simple motivation is appearing on the horizon. Lawyers are
revving up their word processors as we
We (at least cisco, anyways) already have a knob for this:
[no] ip verify unicast reverse-path
We call it Unicast RPF.
And its well documented... NOT
and available on all routers/interfaces... NOT
If it was documented and available on things like PRIs then it would
be a lot
This is a small percentage, I would thing, since the percentage of
ISP's offering transit pales in comparison to all other "access"
ISP's that do not. And in cases where ISP's _do_ offer transit, or
have transit agreements, will they really do this on their transit
Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs
required to put filtering on their networks that PREVENTS packets with
invalid source addresses ever entering their infrastructure? If every
site connected to the Internet did this, spoofing would be much more
difficult because
Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs
required to put filtering on their networks that PREVENTS packets with
invalid source addresses ever entering their infrastructure?
maybe you want to be reading the nanog mailing list, [EMAIL PROTECTED], where
the problems
At 02:40 PM 02/11/2000 -0500, Bernie Volz wrote:
Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs
required to put filtering on their networks that PREVENTS packets with
invalid source addresses ever entering their infrastructure?
Because there is no "Internet Police", that's
At 11:57 AM 02/11/2000 -0800, Randy Bush wrote:
Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs
required to put filtering on their networks that PREVENTS packets with
invalid source addresses ever entering their infrastructure?
maybe you want to be reading the nanog
On Fri, 11 Feb 2000 14:40:15 EST, Bernie Volz [EMAIL PROTECTED] said:
Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs
required to put filtering on their networks that PREVENTS packets with
invalid source addresses ever entering their infrastructure? If every
site connected
Bernie Volz wrote:
Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs
required to put filtering on their networks that PREVENTS packets with
invalid source addresses ever entering their infrastructure?
That wouldn't help with the current version of the problem. An attacker
Paul,
I object to the characterization of my comments as "propagating FUD."
One might equally well suggest that 2267 constitutes a naive model of
how to prevent IP spoofing, but I was polite enough not to say that
:-).
From a security perspective, it is never desirable to rely on a
In message [EMAIL PROTECTED], Valdis.Kletnieks@vt
.edu writes:
Does anybody have statistics on how effective RFC2350 (Expectations
for Computer Security Incident Response) was? Or RFC2502 (Anti-Spam
Recommendations for SMTP MTAs)? Or RFC2644 ( Changing the Default for
Directed Broadcasts
CC'd to NANOG, maybe we can move this there.
On Fri, 11 Feb 2000, Paul Ferguson wrote:
It would allow the attacks to be traced back to the zombies (in
the case of these DDoS attacks), and the perpetrators to be traced
back and identified.
To make that easier, what is needed is something
[EMAIL PROTECTED] wrote:
On Fri, 11 Feb 2000 16:35:18 EST, Paul Ferguson said:
Do you think that if RFC2267 was advanced as a BCP that
it would carry more weight, and therefore more ISP's would
implement RFC2267-style filtering? Coupled with the latest
denial of service attacks?
On
Vijay,
We (at least cisco, anyways) already have a knob for this:
[no] ip verify unicast reverse-path
We call it Unicast RPF.
See also:
Craig Huegen's very useful web page on minimizing the effects
of DoS attacks:
http://users.quadrunner.com/chuegen/smurf.cgi
Cisco: Distributed Denial of
At 09:14 PM 02/11/2000 -0500, Vijay Gill wrote:
This only works on single homed customers. Due to asymmetric routing, the
customer can source _valid_ ip addresses from an ip source address that is
not routed over that interface. I too would prefer some sort of magic
unicast RPF, but the best
On Fri, 11 Feb 2000 21:09:47 EST, Paul Ferguson said:
We (at least cisco, anyways) already have a knob for this:
[no] ip verify unicast reverse-path
We call it Unicast RPF.
Paul:
What are the chances of setting up "The Next Release" of IOS
so that for simple configs (for example, a
At 11:33 PM 02/11/2000 -0500, [EMAIL PROTECTED] wrote:
What are the chances of setting up "The Next Release" of IOS
so that for simple configs (for example, a customer backbone and
one upstream link to a provider) the knob would automagically default
to Doing The Right Thing? I of course am
52 matches
Mail list logo
