RE: Storage over Ethernet/IP
--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 no means of countering such -security threats is -broken, and should not be considered for standardization. -It is perfectly possible that after conducting a threat and modality -analysis, one ends up with saying that hardware-accelerated -IPsec using -host identities is adequate for the scenarios involving -otherwise-unprotected Internet links, and that a mode with no -protection is -adequate when the media is physically secured. - -But the analysis MUST BE DONE. - is vulnerability and threat analysis part of the standardization process ?? /pd
Re: Storage over Ethernet/IP
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 made, remade and made again here is: -- Any protocol that offers no means of countering such -security threats is -broken, and should not be considered for standardization. -It is perfectly possible that after conducting a threat and modality -analysis, one ends up with saying that hardware-accelerated -IPsec using -host identities is adequate for the scenarios involving -otherwise-unprotected Internet links, and that a mode with no -protection is -adequate when the media is physically secured. - -But the analysis MUST BE DONE. - is vulnerability and threat analysis part of the standardization process ?? Yes, in order to come up with a reasonable security considerations section. (Clearly, much of it is site-specific. But the protocol developers can't ignore it.) --Steve Bellovin
RE: Storage over Ethernet/IP
--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: - - ---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 no means of countering such --security threats is --broken, and should not be considered for standardization. - --It is perfectly possible that after conducting a threat -and modality --analysis, one ends up with saying that hardware-accelerated --IPsec using --host identities is adequate for the scenarios involving --otherwise-unprotected Internet links, and that a mode with no --protection is --adequate when the media is physically secured. -- --But the analysis MUST BE DONE. -- - -is vulnerability and threat analysis part of the -standardization process ?? - -Yes, in order to come up with a reasonable security considerations -section. (Clearly, much of it is site-specific. But the protocol -developers can't ignore it.) - - - --Steve Bellovin - OK...but nowhere in rfc2401/2402 do the STD doc's specify finding's of the security /threat analysis, so how does one state that the std doc, is within the reasonable limits to counter "such threats and security" ?? /pd
Re: Storage over Ethernet/IP
is vulnerability and threat analysis part of the standardization process ?? yes.
RE: Storage over Ethernet/IP
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
RE: Storage over Ethernet/IP
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. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway [EMAIL PROTECTED]
RE: Storage over Ethernet/IP
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 much effect this warning has had in practice is hard to say, of course). New documents have been written that do indeed do a vulnerability analysis, not in any great depth but enough to motivate the mechanisms recommended to deal with the identified threats. In particular see RFC 2829 (which should appear any minute now, draft-ietf-ldapext-authmeth-04.txt in the mean time). - RL "Bob"
Re: Storage over Ethernet/IP
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 authentication are actually compatible with that specified by higher level protocols and the authentication actually meets the needs of users. (if your network interface needs to use and verify users' credentials, as opposed to the host's credentials, it might be a stretch.) A network server will still authenticate user requests. Only the host needs to be authenticated with the disk/disks. Up to a point. Yes, there are NICs available today with IPsec on-card. But given the prevalence of -- how shall I put this? -- single-user computers with user physical access, no OS protection and crufty software, you really need user-granularity protection of the file access requests. NFS-style protection with host authentication works if and only if the server trusts the remote system to authenticate its users. That's demonstrably not true today. Yes, IPsec does, in theory, support user-granularity protection. That's very hard to do when you're using outboard IPsec implementations, since you then need some way to pass the user's credentials (generally a certificate, not a user-id) back to the host, and tie every received packet to that identity. It can be done, but (speaking as one of the primary participants in the IPsec development effort) I'm not impressed with its applicability in this case. It will run over incredibly fast Packet over SONET Wide Area Networks--behind firewalls. ...it's inappropriate to assume that it will always be used behind firewalls... If the larger network that is employing this technology doesn't hire a decent consultant, you might be right. If they do, it will ALWAYS be behind a firewall :-) Speaking as someone whose firewall credentials are more or less beyond reproach, you're wrong -- period. *Many* such uses will be behind firewalls. Others won't. The large corporate firewall is a dinosaur, because of extranets, telecommuters, unofficial links through or around the firewall, etc. Comprehensive firewalls generally can't protect a network larger than one run by a single systems administrator (or, in some cases, a systems administration group); otherwise, they don't know where the links are. And even when one sysadmin runs the net, what does he or she do when word comes down from the pointy-haired layer of the stack that there *will* be a VPN link to a joint venture partner? Like it says on the (U.S.) toothpaste tubes -- firewalls can be an effective security measure when used as part of a program including good network hygiene and decent authentication. But they're not magic security pixie dust, and they're not a substitute for authentication in the protocol. --Steve Bellovin
RE: Storage over Ethernet/IP
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 exact form the technology will take -- NAS vs. SAN, etc. a. TCP is too CPU intensive and creates too much latency for storage I/O operations. There are now task specific processors and co-processors that can handle 1 Gbps line rate today, and will run at 10 Gbps line rate in 18-24 months. So this argument has already fallen by the wayside. b. The IP stack is too top heavy and processing packet headers is too slow to support storage I/O operations. Too slow? If that were true, we wouldn't be able to handle OC-192, would we? The real question is how much the chips, switch fabric and specialized memory will cost, and how competitive this will be with existing technologies such as Fibre Channel, both for short and long haul. c. The maximum throughput of a GE TCP/IP connection is 768 Mps, which is too slow to support storage I/O operations. That figure was achieved with minimal hardware acceleration. Pushing it by an order of magnitude within 24 months is not unimaginable. If you were willing to throw more hardware at the problem, it might be possible to handle a 1 Gbps bit rate on 8 lambdas at the same time *today*. How does 8 Gbps of throughput today sound, with 80 Gbps in 18-24 months? Is any of this true? No.
HAAGENS,RANDY (HP-Roseville,ex1): RE: IETF mailing list question on Storage over Ethernet/IP
Jon, A few more comments on SCSI over IP. Also, anyone interested in this subject can subscribe to the IPS reflector? Info on the IPS reflector: IPS Name: IP Storage Purpose: Semi-official reflector for the IETF IPSWG communication. Postings are made following "authors group" consensus. Hosted by: CMU Subscribe: Send mail to [EMAIL PROTECTED] with the command subscribe ips E-mail: [EMAIL PROTECTED] URL: http://www.ece.cmu.edu/~ips --- Forwarded Message Date:Thu, 25 May 2000 21:38:11 -0700 From:"HAAGENS,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 implemented in hardware. It will be as fast as any other protocol implemented in hardware. 2. Adaptec should speak for themselves; but I believe that the reference to STP is a misunderstanding. At the N+I conference, Adaptec demoed a software prototype of their SCSI Encapsulation Protocol (SEP). SEP allows SCSI to be transported over a lightweight protocol of Adaptec's own design for the the local area, or over TCP for the wide area. 3. The IP Storage Working Group (IBM, Cisco, HP, Adaptec, Quantum, EMC, and others) are working on a mapping of SCSI to TCP, for use both in the WAN and in the LAN. All of us agree on the use of TCP as the transport for the WAN and LAN, while a minority would probably favor using a lighter-weight transport for the LAN. In summary, TCP is suitable as the transport for the WAN and LAN, and it will be as fast as any protocol when implemented in hardware. Using a single transport for the WAN and LAN removes the artificial barrier between these two environments, and means that applications (like mirroring) can be designed to scale seamlessly from the local to the wide area. Randy Haagens Networked Storage Architecture Storage Organization 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:28 PM To: SCSI-over-TCP List Subject: IETF mailing list question on Storage over Ethernet/IP --- Forwarded Message Date:Thu, 25 May 2000 22:55:49 - From:Mike Fisk [EMAIL PROTECTED] To: Jon William Toigo [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: Storage over Ethernet/IP 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 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. c. The maximum throughput of a GE TCP/IP connection is 768 Mps, which is too slow to support storage I/O operations. This is not a theoretical limitation, but is in the ballpark reported by many general-purpose operating systems with commodity hardware. Is any of this true? I don't believe that TCP/IP implementations couldn't be optimized to support full link rate and low latency. If you're building a hardware adapter that can do SCSI and RAID fast, adding TCP shouldn't be prohibitively hard. 2. Adaptec has posited a replacement for TCP called STP for use as a transport for storage. Does anyone know anything about this? STP is the Scheduled Transfer protocol being standardized by the ANSI T11 folks. ST was designed to run on top of GSN (a.k.a. HIPPI-6400). In my opinion, it is as heavy-weight as TCP with respect to most of the things stated above. It does have the potential advantage of being designed from scratch to support zero-copy access to user space using specialized interface cards. 3. Current discussions of the SCSI over IP protocol seem to ignore the issue of TCP or any other transport protocol. Does anyone know definitively what transport is being suggested by the IBM/Cisco crowd? I believe the assumption is that you will have a local network with no packet loss or significant bit error rate. Basically, you assume that your ethernet is as reliable as your SCSI cable or fiber-channel network. For a well engineered, fully-switched LAN, that may be a reasonable assumption. - -- Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab See http://home.lanl.gov/mfisk/ for contact information --- End of Forwarded Message
IETF mailing list question on Storage over Ethernet/IP
A few comments about this one. 1. FC does not provide reliable transmission. It provides for error detection, but escalates recovery to "upper level protocol". FCP-2 has improved this situation, but is not widely implemented yet. One of the advantages of using a transport such as TCP is that link errors will be corrected in a manner that is transparent to the application protocol (SCSI). 2. Jumbo frames will not be necessary when TCP is implemented in hardware. Most FC implementations use 1024 byte frames, and performance is very adequate, given hardware implementation of FCP. 3. The cost of using different transport protocols in the LAN and WAN is that the two will not interoperate. Many of us believe that TCP has proven itself in both the LAN and WAN. I bet your PC or UN*X workstation is using TCP for all its protocol needs. 4. The IPS working group is mapping SCSI to TCP. Another working group is mapping FC to IP. These are very different approaches. The first (ours) preserves SCSI, but does not include any vestige of Fibre Channel. It is intended for use in the LAN, MAN and WAN. Its best use is for connecting hosts computers to storage controllers using Ethernet and IP WAN technology. It will be possible, but non-trivial, to translate between SCSI over TCP/IP and SCSI over Fibrechannel. The second is a tunneling scheme for extending Fibre Channel over the IP WAN. It does not contemplate Ethernet-based hosts or storage controllers. 5. Just about any reliable transport will do nicely for transporting SCSI commands. We chose TCP because its implementation and behavior are well-known, and it is well-supported with load-balancing, QoS and security features. While another protocol (such as reliable datagram) might be arguably better suited to storage transport applications, we'll use TCP "because it's there". We'll have the benefit of all the other investment that's going into improving TCP for internet uses. Randy Haagens Networked Storage Architecture Storage Organization 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 Storage over Ethernet/IP --- Forwarded Message Date:Thu, 25 May 2000 19:27:02 -0400 From:Dave Nagle [EMAIL PROTECTED] To: "Jon William Toigo" [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: Storage over Ethernet/IP Jon, Original Message - 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 IP stack is too top heavy and processing packet headers is too = slow to support storage I/O operations. There is a lot of work to show that this is not true. Check out Van Meter's 1998 ASPLOS paper "VISA - Netstations virtual internet SCSI adaptor." Perhaps more importantly, there are many companies that are building TCP in silicon ASICs. This should make TCP's performance comparable to Fibre Channel. Both TCP/IP and FC provide about the same functionality ... reliable, in-order transmission. The bottom line is that FC is done in hardware while TCP has traditionally been done in software. Therefore, previous performance numbers are not going to be fair. Once TCP is in silicon, its performance should be roughly equal to FC. c. The maximum throughput of a GE TCP/IP connection is 768 Mps, which = is too slow to support storage I/O operations. I believe there are higher numbers (especially with Jumbo Frames). Alteon's web site show's 920 Mbps. Microsoft and Duke University have both shown TCP performance o 1Gb+/s performance over other networks. BTW, why is 768 Mbps too slow for storage. Many apps (e.g., transaction workloads) are I/O's per second bound, not bandwidth bound. Also, even if storage over IP/ether is a bit slower than FC, the benefits of leveraging IP's infrastructure (i.e., routers, switches, NICs, network management, networking people) is a huge advantage. There is also the issue of SCSI over TCP/IP in the SAN vs. the LAN/WAN. Some companies, focusing on the SAN, are building SCSI/lightweight transport/IP while others, focusing on the WAN, propose SCSI/TCP/IP. It may be the case that SAN and WAN traffic use different transport protocols to gain a bit of extra performance in the SAN. Is any of this true? 2. Adaptec has posited a replacement for TCP called STP for use as a = transport for storage. Does anyone know anything about this? From Paul von Stamwitz's posting to the i
Re: IETF mailing list question on Storage over Ethernet/IP
Thank you all for some excellent discussions on the subject. For all the reasons mentioned, I am mapping TCP/IP to DWDM to create very high performance SANs. I hope to share more on this as we progress and launch products. You can see more on this at www.lightel.com. On Fri, 26 May 2000, Dave Nagle wrote: A few comments about this one. 1. FC does not provide reliable transmission. It provides for error detection, but escalates recovery to "upper level protocol". FCP-2 has improved this situation, but is not widely implemented yet. One of the advantages of using a transport such as TCP is that link errors will be corrected in a manner that is transparent to the application protocol (SCSI). 2. Jumbo frames will not be necessary when TCP is implemented in hardware. Most FC implementations use 1024 byte frames, and performance is very adequate, given hardware implementation of FCP. 3. The cost of using different transport protocols in the LAN and WAN is that the two will not interoperate. Many of us believe that TCP has proven itself in both the LAN and WAN. I bet your PC or UN*X workstation is using TCP for all its protocol needs. 4. The IPS working group is mapping SCSI to TCP. Another working group is mapping FC to IP. These are very different approaches. The first (ours) preserves SCSI, but does not include any vestige of Fibre Channel. It is intended for use in the LAN, MAN and WAN. Its best use is for connecting hosts computers to storage controllers using Ethernet and IP WAN technology. It will be possible, but non-trivial, to translate between SCSI over TCP/IP and SCSI over Fibrechannel. The second is a tunneling scheme for extending Fibre Channel over the IP WAN. It does not contemplate Ethernet-based hosts or storage controllers. 5. Just about any reliable transport will do nicely for transporting SCSI commands. We chose TCP because its implementation and behavior are well-known, and it is well-supported with load-balancing, QoS and security features. While another protocol (such as reliable datagram) might be arguably better suited to storage transport applications, we'll use TCP "because it's there". We'll have the benefit of all the other investment that's going into improving TCP for internet uses. Randy Haagens Networked Storage Architecture Storage Organization 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 Storage over Ethernet/IP --- Forwarded Message Date:Thu, 25 May 2000 19:27:02 -0400 From:Dave Nagle [EMAIL PROTECTED] To: "Jon William Toigo" [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: Storage over Ethernet/IP Jon, Original Message - 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 IP stack is too top heavy and processing packet headers is too = slow to support storage I/O operations. There is a lot of work to show that this is not true. Check out Van Meter's 1998 ASPLOS paper "VISA - Netstations virtual internet SCSI adaptor." Perhaps more importantly, there are many companies that are building TCP in silicon ASICs. This should make TCP's performance comparable to Fibre Channel. Both TCP/IP and FC provide about the same functionality ... reliable, in-order transmission. The bottom line is that FC is done in hardware while TCP has traditionally been done in software. Therefore, previous performance numbers are not going to be fair. Once TCP is in silicon, its performance should be roughly equal to FC. c. The maximum throughput of a GE TCP/IP connection is 768 Mps, which = is too slow to support storage I/O operations. I believe there are higher numbers (especially with Jumbo Frames). Alteon's web site show's 920 Mbps. Microsoft and Duke University have both shown TCP performance o 1Gb+/s performance over other networks. BTW, why is 768 Mbps too slow for storage. Many apps (e.g., transaction workloads) are I/O's per second bound, not bandwidth bound. Also, even if storage over IP/ether is a bit slower than FC, the benefits of leveraging IP's infrastructure (i.e., routers, switches, NICs, network management, networking people) is a huge advantage. There is also the issue of SCSI over TCP/IP in the SAN vs. the LAN/WAN. Some companies, focusing on the SAN, are building SCSI/lightwe
RE: Storage over Ethernet/IP
Encryption will be offloaded to the network interface. ASICs on the NICs will greatly improve encryption and authentication performance. It won't run over the Internet because of latencies inherent on the public network. 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. Also, IPv6 has significantly improved authentication capabilities that will help ensure security on the Storage WAN (SWAN?) Brian -Original Message- 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 IP then you are potentially allowing it to be run over the global Internet. If you do that you need good authentication and privacy, and (if you try to do them in software) authentication and encyption will eat far more in performance than anything inherent to TCP or IP. and no, it's not acceptable to assume that the storage device will be behind a firewall. Keith
Re: Storage over Ethernet/IP
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 authentication actually meets the needs of users. (if your network interface needs to use and verify users' credentials, as opposed to the host's credentials, it might be a stretch.) It won't run over the Internet because of latencies inherent on the public network. at least for some storage applications, latency is not as important as bandwidth. e.g. you can do backups over a high-latency medium as long as your bandwidth is adequate (though recovery from write errors gets a bit tricky). It will run over incredibly fast Packet over SONET Wide Area Networks--behind firewalls. I'm sure it will be used behind firewalls in some cases but it's inappropriate to assume that it will always be used behind firewalls. Firewalls don't help with the majority of security threats, and it's less and less the case that network topologies reflect trust domains. Keith
RE: Storage over Ethernet/IP
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 authentication actually meets the needs of users. (if your network interface needs to use and verify users' credentials, as opposed to the host's credentials, it might be a stretch.) A network server will still authenticate user requests. Only the host needs to be authenticated with the disk/disks. It won't run over the Internet because of latencies inherent on the public network. at least for some storage applications, latency is not as important as bandwidth. e.g. you can do backups over a high-latency medium as long as your bandwidth is adequate (though recovery from write errors gets a bit tricky). Backups could go through VPNs, I suppose. Good point. That would free your WAN of the backup jobs. I wasn't thinking of backups when I ruled out the Internet as a disk I/O medium. I suppose infrequently used and low priority files could also be accessed over the 'net. It will run over incredibly fast Packet over SONET Wide Area Networks--behind firewalls. ...it's inappropriate to assume that it will always be used behind firewalls... If the larger network that is employing this technology doesn't hire a decent consultant, you might be right. If they do, it will ALWAYS be behind a firewall :-) Firewalls don't help with the majority of security threats... True, but whether the server accesses the disks via SCSI over TCP or SCSI over Fibre Channel, the SERVER is still the weak link. The transport protocol doesn't create any inherent weaknesses of the type you are refering to--e-mail borne viruses, internal hackers, etc. The server would still be the attack point. Why goodness, the server and storage devices could be in a VLAN or something to deny direct hack attempts against the storage device, but the chink in the armor is how hardened is your OS? Brian
Re: Storage over Ethernet/IP
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 belive Dave Clark and Van Jacobson about the length of instruction sequences to handle TCP. I'm not sure that those ever became RFCs. Those papers came up with figures indicating that if one structures code "correctly" and if the net path is "clean" (i.e. not a lot of packet loss, reordering, replication, etc) than the per-packet instruction sequences (sans IP checksum calculation) were potantially very short. Does anyone have the references to these papers? --karl--
Re: Storage over Ethernet/IP
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 employing this technology doesn't hire a decent consultant, you might be right. If they do, it will ALWAYS be behind a firewall :-) Double Hmm.. 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, we can't deploy this technology. Somehow, that doesn't smell right. the server and storage devices could be in a VLAN or something to deny direct hack attempts against the storage device, but the chink in the armor is how hardened is your OS? If your OS is hardened enough, a firewall may not be appropriate. "New from Kellogs - Firewalls cereal - part of this *COMPLETE* and *BALANCED* security breakfast". -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
RE: Storage over Ethernet/IP
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 vendor has already demonstrated 10 Gig Ethernet switch interfaces at Interop/LV earlier this month. Such 10 GE boxes are generally much less expensive than OC-192 POS boxes. Another post indicated that these systems will use frame sizes of 1024 bytes, which is well within the abilities of any Ethernet interface. Also, IPv6 has significantly improved authentication capabilities that will help ensure security on the Storage WAN (SWAN?) 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. Note that I have no axe to grind for or against IPv6, but the disinformation campaign that "IPv6 is secure and IPv4 isn't" is highly annoying and completely wrong. Ran [EMAIL PROTECTED]
RE: Storage over Ethernet/IP
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, we can't deploy this technology. Somehow, that doesn't smell right. If your OS is hardened enough, a firewall may not be appropriate. I am not saying that you don't have a clue if you don't utilize a firewall. I AM saying that if you have Internet access to your network, a firewall is extremely important. It isn't complete, in and of itself. OS hardening is still very important, as are other technologies (as necessary to facilitate application needs). I understand your point that if your OS is perfectly hardened, then a firewall isn't going to add any *extra* protection. You miss the point, though. You can prevent unnecessary processor and bandwidth utilization on the server by filtering it out at the perimeter of your network. You might not get a security advantage if you are an OS hardening god, but you would CERTAINLY get performance increases on your LAN. If you are utilizing pure access lists on routers for perimeter security, then you are assuming that this technology is as adept at securing a network as port filters combined with Network Address Translation or cicuit proxying. Don't make that assumption. Brian
RE: Storage over Ethernet/IP
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. Yeah, okay. I will grant that. But, should a good technology be nixed because some idiots might mis-use it? I personally don't think so. Brian
RE: Storage over Ethernet/IP
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. I must admit my error in that statement. I was reciting something that I had read a year ago. You are correct about AH and ESP in IPv4 as well as v6. Thanks for the correction. Brian
Re: Storage over Ethernet/IP
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 authentication actually meets the needs of users. (if your network interface needs to use and verify users' credentials, as opposed to the host's credentials, it might be a stretch.) FWIW, it has been tried, and it didn't succeed in the market, although whether that was a matter of timing, insufficient market push, or no market existing isn't clear. Specifically, Digital used to make a little gadget called a Cryptonette that you inserted into your Ethernet cable that did this. (The chip inside was something called a TANDU, and had DES and two Ethernet ports built in. The whole thing was the size of a pack of cards.) And I believe there were at least two other similar gadgets at some point, although I cannot recall their names... The demo I saw had the boxes doing IPSEC-style operations (this was before IPSEC was standardized), with the credential verification being done on the host side. OTOH, at least one of the problems with these sorts of things is that it's hard to change the cryptography embedded in them. So, while I think hardware cryptographic acceleration of this sort could be quite useful, I'm skeptical that it will ever be something that is universally deployed. It won't run over the Internet because of latencies inherent on the public network. at least for some storage applications, latency is not as important as bandwidth. e.g. you can do backups over a high-latency medium as long as your bandwidth is adequate (though recovery from write errors gets a bit tricky). Yep. Backups done over the public Internet (usually with an appalling lack of security, alas) are actually quite common. Ned
Storage over Ethernet/IP
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 IP stack is too top heavy and processing packet headers is too slow to support storage I/O operations. c. The maximum throughput of a GE TCP/IP connection is 768 Mps, which is too slow to support storage I/O operations. Is any of this true? 2. Adaptec has posited a replacement for TCP called STP for use as a transport for storage. Does anyone know anything about this? 3. Current discussions ofthe SCSI over IP protocol seem to ignore the issue of TCP or any other transport protocol. Does anyone know definitively what transport is being suggested by the IBM/Cisco crowd? 4. Another storage company is looking at Reliable UDP as a substitute for TCP in storage data transfers. Where can I learn more about this protocol, which I am told was introduced many years ago by Cisco? Thanks in advance for your assistance. Jon William Toigo Independent Consultant and Author [EMAIL PROTECTED]
Re: Storage over Ethernet/IP
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 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. c. The maximum throughput of a GE TCP/IP connection is 768 Mps, which is too slow to support storage I/O operations. This is not a theoretical limitation, but is in the ballpark reported by many general-purpose operating systems with commodity hardware. Is any of this true? I don't believe that TCP/IP implementations couldn't be optimized to support full link rate and low latency. If you're building a hardware adapter that can do SCSI and RAID fast, adding TCP shouldn't be prohibitively hard. 2. Adaptec has posited a replacement for TCP called STP for use as a transport for storage. Does anyone know anything about this? STP is the Scheduled Transfer protocol being standardized by the ANSI T11 folks. ST was designed to run on top of GSN (a.k.a. HIPPI-6400). In my opinion, it is as heavy-weight as TCP with respect to most of the things stated above. It does have the potential advantage of being designed from scratch to support zero-copy access to user space using specialized interface cards. 3. Current discussions of the SCSI over IP protocol seem to ignore the issue of TCP or any other transport protocol. Does anyone know definitively what transport is being suggested by the IBM/Cisco crowd? I believe the assumption is that you will have a local network with no packet loss or significant bit error rate. Basically, you assume that your ethernet is as reliable as your SCSI cable or fiber-channel network. For a well engineered, fully-switched LAN, that may be a reasonable assumption. -- Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab See http://home.lanl.gov/mfisk/ for contact information
Re: Storage over Ethernet/IP
Thanks for the feedback, Mssrs. Fisk and Nagle, I think a problem for IT folks who are hearing early statements about SANs based on GE has to do with an issue to which you both alluded. Specifically, what parameters -- bandwidth, throughput, latency, etc. -- must designers consider when evaluating or building a storage networking interconnect? Put another way, when I design an aircraft, I know about lift, drag and other engineering parameters and can plug them into calculations that will enable me to design a wing to lift X number of pounds. When it comes to storage networks, I cannot get a straight answer from any vendor regarding the parameters that must be observed or satisfied -- whether stated as straightforward quantities/formula or general rules of thumb -- in order to develop a working storage networking interconnect! What factors determine the amount of bandwidth required? What amount of latency can be tolerated? How quickly must erred information be re-sent? Does this all depend upon the characteristics of the storage traffic itself? Are the parameters application dependent? Surely, traditional SCSI bus design delivered a solution that must be equaled or improved upon by SAN interconnects such as FC, GE or Infiniband for the latter to be regarded as viable storage interconnects. This can't be rocket science: Is there a convenient set of storage architecture design parameters here that I am simply overlooking? I have no axe to grind with the FC folks, but there seems to be a holy war shaping up around FC versus GE as a storage interconnect. I am tracking strategies for TCP offload or ASICS speed-up and agree that the optimization of TCP/IP functionality to support the use of GE and 10 speed GE as a SAN as well as a LAN interconnect. I find such a solution to be quite practical, but I do not say that FC is inferior. There are many roads that lead to Rome, as the saying goes. What is of concern to me (and to my readers) is to avoid deploying a technology (FC, for example) that may need to be "forklift upgraded" within a year. Please let me know if you are aware of any storage networking design criteria that must be addressed by any interconnect regardless of its underlying protocol. Thanks, Jon Toigo Independent Consultant and Author The Holy Grail of Data Storage Management [EMAIL PROTECTED] - Original Message - 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 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 IP stack is too top heavy and processing packet headers is too = slow to support storage I/O operations. There is a lot of work to show that this is not true. Check out Van Meter's 1998 ASPLOS paper "VISA - Netstations virtual internet SCSI adaptor." Perhaps more importantly, there are many companies that are building TCP in silicon ASICs. This should make TCP's performance comparable to Fibre Channel. Both TCP/IP and FC provide about the same functionality ... reliable, in-order transmission. The bottom line is that FC is done in hardware while TCP has traditionally been done in software. Therefore, previous performance numbers are not going to be fair. Once TCP is in silicon, its performance should be roughly equal to FC. c. The maximum throughput of a GE TCP/IP connection is 768 Mps, which = is too slow to support storage I/O operations. I believe there are higher numbers (especially with Jumbo Frames). Alteon's web site show's 920 Mbps. Microsoft and Duke University have both shown TCP performance o 1Gb+/s performance over other networks. BTW, why is 768 Mbps too slow for storage. Many apps (e.g., transaction workloads) are I/O's per second bound, not bandwidth bound. Also, even if storage over IP/ether is a bit slower than FC, the benefits of leveraging IP's infrastructure (i.e., routers, switches, NICs, network management, networking people) is a huge advantage. There is also the issue of SCSI over TCP/IP in the SAN vs. the LAN/WAN. Some companies, focusing on the SAN, are building SCSI/lightweight transport/IP while others, focusing on the WAN, propose SCSI/TCP/IP. It may be the case that SAN and WAN traffic use different transport protocols to gain a bit of extra performance in the SAN. Is any of this true? 2. Adaptec has posited a replacement for TCP called STP for use as a = transport for storage. Does anyone know anything about this? From Paul von Stamwitz's posting to the ips mailing list ... The link to the SEP
Re: Storage over Ethernet/IP
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 different fora. At a recent DoE meeting there were several different examples cited, though I don't have the details at hand this minute. Ran [EMAIL PROTECTED]
