--Original Message-
-From: Harald Tveit Alvestrand [mailto:[EMAIL PROTECTED]]
-Sent: Friday, May 26, 2000 6:27 PM
-To: [EMAIL PROTECTED]
-Cc: [EMAIL PROTECTED]
-Subject: RE: Storage over Ethernet/IP
-The point being made, remade and made again here is:
-- Any protocol that offers
In message [EMAIL PROTECTED],
"Dawson, Peter D" writes:
--Original Message-
-From: Harald Tveit Alvestrand [mailto:[EMAIL PROTECTED]]
-Sent: Friday, May 26, 2000 6:27 PM
-To: [EMAIL PROTECTED]
-Cc: [EMAIL PROTECTED]
-Subject: RE: Storage over Ethernet/IP
-The point being ma
--Original Message-
-From: Steven M. Bellovin [mailto:[EMAIL PROTECTED]]
-Sent: Monday, May 29, 2000 1:56 PM
-To: Dawson, Peter D
-Cc: [EMAIL PROTECTED]
-Subject: Re: Storage over Ethernet/IP
-
-
-In message
-[EMAIL PROTECTED],
-"Dawson, Peter D" writes:
-
-
---Origin
is vulnerability and threat analysis part of the
standardization process ??
yes.
Peter - for the last few years the IESG has required IETF working groups
to have meaningful Security Considerations sections in standards
track RFCs - these must include a threat and security analysis
Scott
At 17:02 29.05.2000 +, Dawson, Peter D wrote:
is vulnerability and threat analysis part of the
standardization process ??
Yes.
RFC 2223, "Instructions to RFC authors", section 9.
See also RFC 2316, "Report from the IAB security workshop", section 9,
which gives further guidance.
is vulnerability and threat analysis part of the standardization
process ??
RFCs 2251-2256, which specify LDAPv3, carry a stern warning up front that
that these documents lack a standard mandatory-to-implement strong
authentication method, hence limiting the applicability of the protocol
(how
In message A427D1278F7CD311B1670008C7FAA62AC89F1F@CORPNT3, Brian.Rubarts@born
.com writes:
Encryption will be offloaded to the network interface. ASICs on the NICs
will greatly improve encryption and authentication performance.
all well and good, provided that this encryption and
I too
have heard these arguments. When I heard them I felt a sense of deja vu --
anyone remember
when
the conventional wisdom was that "voice will never run over IP?"In fact,
most of the
assertions below are fallacies or soon will become
fallacies. The only real argument is
about
the
AGENS,RANDY (HP-Roseville,ex1)" [EMAIL PROTECTED]
To: "'Dave Nagle'" [EMAIL PROTECTED]
cc: "Scsi-Tcp (E-mail)" [EMAIL PROTECTED]
Subject: RE: IETF mailing list question on Storage over Ethernet/IP
Comments
-
1. I agree with your comments about TCP's being impl
tel: +1 916 785 4578
fax: +1 916 785 1911
-Original Message-
From: Dave Nagle [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 25, 2000 4:29 PM
To: SCSI-over-TCP List
Subject: IETF mailing list question on Storage over Ethernet/IP
--- Forwarded Message
Date:Thu, 25 May
rganization
Hewlett-Packard Co.
e-mail: [EMAIL PROTECTED]
tel: +1 916 785 4578
fax: +1 916 785 1911
-Original Message-
From: Dave Nagle [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 25, 2000 4:29 PM
To: SCSI-over-TCP List
Subject: IETF mailing list question on Stor
-
From: Keith Moore [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 26, 2000 9:23 AM
To: Jon William Toigo
Cc: [EMAIL PROTECTED]
Subject: Re: Storage over Ethernet/IP
None of the cited limitations of TCP performance are true.
they are also missing the point.
If you're going to run storage access over
Encryption will be offloaded to the network interface. ASICs on the NICs
will greatly improve encryption and authentication performance.
all well and good, provided that this encryption and authentication
are actually compatible with that specified by higher level protocols
and the
Encryption will be offloaded to the network interface. ASICs on the NICs
will greatly improve encryption and authentication performance.
all well and good, provided that this encryption and authentication
are actually compatible with that specified by higher level protocols
and the
a. TCP is too CPU intensive and creates too much latency for storage I/O operations.
b. The IP stack is too top heavy and processing packet headers is too
slow to support storage I/O operations.
There were some papers published duing the late '80's or early '90s by
John Romkey and I
On Fri, 26 May 2000 10:14:03 CDT, [EMAIL PROTECTED] said:
A network server will still authenticate user requests. Only the host
needs to be authenticated with the disk/disks.
Hmm.
Isn't this security model the cause of most grumbling regarding NFS security?
If the larger network that is
At 15:40 26-05-00 , [EMAIL PROTECTED] wrote:
It will run over incredibly fast Packet over SONET Wide Area
Networks--behind firewalls. OC-192 and soon-to-come OC-768 (terrabit)
switches will be the backbone of WANs and MANs of large networks in a few
years.
I'll note that at least one
Odd.. I thought we had a clue about security. The guys at SANS just
gave us a 'Technology Leadership Award'. I just walked across the hallway,
and I didn't see any firewall in our router swamp.
I guess because we don't have a firewall, we don't have a clue. Or because
we don't have a firewall,
Experience tells us that although we can design and specify for
"intra-nets", people will insist on using the results over the public
internet. Pretending this will not happen is akin to burying ones head in
the beach sand when one has heard a report of a large wave heading for the
beach.
IPv6 has NO authentication capability not already shipping for IPv4,
speaking as the person who designed both AH and ESP. Marketing aside,
there is nothing in IPv6 that makes it more easily secured than IPv4.
Both support AH and ESP. Deployed ISAKMP/IKE support IPv4, but might
not support IPv6.
Encryption will be offloaded to the network interface. ASICs on the NICs
will greatly improve encryption and authentication performance.
all well and good, provided that this encryption and authentication
are actually compatible with that specified by higher level protocols
and the
I am seeking a few points of
clarification:
1. Fibre Channel folks have attempted to
explain to me why TCP/IP could NEVER be a viable interconnect for block level
storage operations. They claim:
a. TCP is too CPU intensive and creates too
much latency for storage I/O operations.
b. The
On Thu, 25 May 2000, Jon William Toigo wrote:
I am seeking a few points of clarification:
1. Fibre Channel folks have attempted to explain to me why TCP/IP
could NEVER be a viable interconnect for block level storage
operations. They claim:
a. TCP is too CPU intensive and creates too
-
From: Dave Nagle [EMAIL PROTECTED]
To: Jon William Toigo [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, May 25, 2000 7:27 PM
Subject: Re: Storage over Ethernet/IP
Jon,
Original Message
I am seeking a few points of clarification:
1. Fibre Channel
At 22:52 25-05-00 , Jon William Toigo wrote:
c. The maximum throughput of a GE TCP/IP connection is 768 Mps, which is
too slow to support storage I/O operations.
Provably false. In fact TCP throughput above 768 Mbps over 1518-byte GE
has been demonstrated publicly in the past in several
26 matches
Mail list logo
