From: Bill Manning [EMAIL PROTECTED]
So, of the 7763 visable servers, 45 are improperly configured in the
visable US. tree. Thats 4.53% of those servers being "not well
maintained.
Keith, These two data points seem to bear your assertion out.
It is always possible to do something poorly.
Hello,
I've some questions about transporting frame relay over IP (I know, the
world is getting crazy):
1. Does anybody have any experience with encapsulation of frame relay by
means of GRE with IPv4 as delivery protocol (RFC1701, 1702, 2784)?
2. Why shouldn't I try to transport FR (FRF1.1)
On the subject of infinite possibilities - given that there are an infinite
number of of possible mistakes and only one correct solution, it is
statistically impossible to do anything right.
IP4 was definitely a mistake. Whatever replaces it will invariably also be a
mistake. Besides, if
For more information on the SCSI over IP (IP storage) proposed working group,
please see http://www.ece.cmu.edu/~ips. The IBM/Cisco draft and other material
is there.
Date: Tue, 25 Apr 2000 17:13:07 -0600
From: Jasen Strutt [EMAIL PROTECTED]
To: Jon William Toigo [EMAIL PROTECTED], [EMAIL
In message 001501bfaf43$127e4d00$[EMAIL PROTECTED], "Eliot Lear" writes:
It is a complete fallacy that NAT provides any sort of security. It does
no such thing. Security is provide by a firewall, and (more importantly)
by strong security policies that are policed and enforced.
Eliot is
It seems to me that the decision to just use NATv6 rather than
do a site-wide runumber will be a very easy decision to make.
Actually, if your assumption is that NATv6 is better than IPv6 with
renumbering, then IPv4 and NATv4 was good enough to start with and
there was need to move to IPv6 in
So what I am suggesting is that it seems that there is evidence that one
can do an "association" protocol that is relatively lightweight in terms
of machinery, packets, packet headers, and end-node state if one leaves
the heavy lifting of reliability to the underlying TCP protocol.
the
Thanks for the referral, Dave. Now that I have the SCSI over IP RFC text, I
am wondering how soon, if ever, we will likely see a standard and/or product
based on the specification?
To your knowledge, is SCSI over IP being pursued in earnest by IP networking
equipment companies at present?
JWT
In his previous mail, Thomas Narten writes:
Now, consider someone in the process of deploying massive numbers of
devices (100's of millions) together with the infrastructure to
support them (e.g., wireless). With IPv4, they face not only the
necessity of using NAT to get to outside
Thomas Narten writes:
| Actually, if your assumption is that NATv6 is better than IPv6 with
| renumbering, then IPv4 and NATv4 was good enough to start with and
| there was need to move to IPv6 in the first place.
^
no (right? maybe this is where the previous "not" came
From: "Steven M. Bellovin" [EMAIL PROTECTED]
In message 001501bfaf43$127e4d00$[EMAIL PROTECTED], "Eliot Lear" writes:
It is a complete fallacy that NAT provides any sort of security. It does
no such thing. Security is provide by a firewall, and (more importantly)
by strong security policies
right, noels wrong.
Noel is happy to wait, and see who's right. (I've been through this exact
same experience before, with CLNP, so I understand the life-cycle.) So far,
I've been waiting for quite a few years with IPv6, and so far I'm right.
Let's see, how many years have these standards
I agree completely with what you say about needing to push
the multi-address complexity to the host. As you kindly
pointed out (and I self-servingly expand on here), this is
an architecture I put forth about a decade ago in a sigcomm
paper (in Zurich, I don't remember the year).
The paper
mid-connection. I would assume that what people have in
mind for this are the mobility mechanisms? (The alternative
is 8+8 or some variant, which I understand to be contentious
enough that it is a defacto non-starter.)
The rubbing point is that identifying is not quite enough
From: Greg Hudson [EMAIL PROTECTED]
But anybody clear understand that if your internal hosts do not have
a public address then all attacks may be only static - wait until
internal host open TCP to somewhere.
This is a naive understanding. Source-routing would let me get
packets
Turn it any way you want, TCP sessions can only survive renumbering through
end to end mechanisms...
Which raises the interesting (to me anyway) question: Is there value in
considering a new protocol, layered on top of TCP, but beneath new
applications, that provides an "association" the
It's also completely naive that source routing is your only threat. One
can break into a NAT. One can forge packets and address them
appropriately. Firewalls prevent this, not NATs.
From: "Eliot Lear" [EMAIL PROTECTED]
It's also completely naive that source routing is your only threat. One
can break into a NAT. One can forge packets and address them
appropriately. Firewalls prevent this, not NATs.
That statement is just as naive, unless you qualify the word
Keith,
even the DNS names for major services may not be well maintained.
at one time I did a survey of the reasons for mail bounces
for one of my larger mailing lists.
You appear to be saying that because historically people screwed up
configuring their DNS that it is impossible to rely on
draft-xie-stewart-sigtran-ddp-00 addresses redundancy and failover of
sessions within a server pool, where uncoordinated failover of sessions from
one endpoint to another is a requirement. There is signifcant overheard and
indirection added to the session to achieve this.
We seem to be
Christian;
But that architecture (hosts having multiple addresses
representing a site's multiple aggregation prefixes and
selecting among them) requires some method of identifying
hosts when they switch from one address to another
mid-connection. I would assume that what people have
Steve Bellovin;
To avoid connection hijacking, cookies, such as TCP port and sequence
numbers, is enough, if they are long enough.
That's preposterous. Long-enough numbers are good *if* and only if there are
no eavesdroppers present.
"good *if* and only if"?
With cookies, a network is
even the DNS names for major services may not be well maintained.
at one time I did a survey of the reasons for mail bounces
for one of my larger mailing lists.
You appear to be saying that because historically people screwed up
configuring their DNS that it is impossible to rely on
From: Keith Moore [EMAIL PROTECTED]
...
(email errors are usually detected by the sender of a message, since
that's who gets the bounced message. but the party who has responsibility
for fixing the error is usually not on the sender's end of things)
...
It may be irrelevant, and my
Hi all,
I guess this is somewhat unrelated to the thread's maing topic but
the paper that Christian mentioned is available to everyone (as
well as all papers from SIGCOMM since 91) through SIGCOMM's web site.
The exact pointer for the paper mentioned below is
So what I am suggesting is that it seems that there is evidence that one
can do an "association" protocol that is relatively lightweight in terms
of machinery, packets, packet headers, and end-node state if one leaves
the heavy lifting of reliability to the underlying TCP protocol.
At 2:42 PM -0700 4/26/00, David R. Conrad wrote:
Perhaps it is obvious to you, however it has been implied that one of the
advantages of v6 is that it has a limited number of TLAs which would be found
the the DFZ of the v6 Internet.
The truth is subtly different than what what was implied or
In message [EMAIL PROTECTED], Vernon Schryver writes
It may be irrelevant, and my personal sample size is trivially tiny. ...
In recent months very little email I've sent was bounced due to DNS errors
and only a little more has been delayed. My logs say the delivery of much
more from others to
draft-xie-stewart-sigtran-ddp-00 addresses redundancy and failover of
sessions within a server pool, where uncoordinated failover of sessions from
one endpoint to another is a requirement. There is signifcant overheard and
indirection added to the session to achieve this.
We seem to be
From: "Steven M. Bellovin" [EMAIL PROTECTED]
...
There is some data indicating that Keith is right, that there are problems in
the DNS. See, for example, http://www.research.att.com/~edith/Papers/infocom2000.ps
I don't think I understand the connection between that paper about
From: Greg Hudson [EMAIL PROTECTED]
But anybody clear understand that if your internal hosts do not have
a public address then all attacks may be only static - wait until
internal host open TCP to somewhere.
This is a naive understanding. Source-routing would let me get
packets through to
31 matches
Mail list logo
