|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Final Pittsburgh MinutesIP Storage BOF minutes Summer IETF 2000 Pittsburgh, PA Wednesday, August 2, 2000 --------------------------- Co-chairs: Steve Bellovin (smb@research.att.com) and David Black (black_david@emc.com) Area directors: Allison Mankin (mankin@isi.edu) and Scott Bradner (sob@harvard.edu) Attendance: ~100 people NOTE on consensus: There are several places in the minutes in which "consensus in the room" is noted. These items can be re-opened on the mailing list (preferably by those who were not at the meeting), especially if there are important technical aspects that are not reflected in the minutes. In the absence of list discussion, the WG co-chairs will assume that the "consensus in the room" is the WG consensus. Agenda bashing - David Black, co-chair -------------- There were no comments on the agenda. Area director - Scott Bradner, Transport AD ------------- Intellectual property rights: If there is intellectual property in anything discussed in the WG, the person discussing it is responsible for saying that there is intellectual property involved. If what someone says is going to be constrained by intellectual property rights, they shouldn't say it, especially if they're not prepared to describe the resulting restrictions. A lot of work on iSCSI has been done in a very focused and very dedicated design team. From now on, this is a WG effort. Most of the work should be done on the WG's mailing list in order to: - minimize interim meetings - minimize phone calls - discuss issues on a common mailing list accessible to all Charter status and bashing - David Black, co-chair -------------------------- Concerns were raised about emphasis of TCP as the protocol. The charter should not and currently does not limit itself to TCP. Instead, it states a requirement for congestion control. Congestion control without TCP is possible, the ECM working group and SCTP are examples. Scott Bradner reminded the group that the charter comes from the IESG and IAB. This group is only suggesting a charter to the IESG/IAB. It was agreed that all specific references to Gigabit Ethernet should be removed from the charter (editor's note: there weren't any). The question was raised about why FC/IP may be worked on by ips. The answers were: similar application domains, same people interested in both technologies, maybe even similar network traffic patterns. The question was raised of how a charter and a requirements document differ. Scott Bradner answered that a charter is commands from the IESG to the working group, i.e., it's the general structure of what the working group is going to do and what it won't do. A requirements document lays out requirements for the area of investigations. It is expected to be longer, it is expected to go into detail, doesn't prescribe a specific solution, and is expected to be published as an RFC. iSCSI requirements - Randy Haagens, Hewlett-Packard ------------------ iSCSI is a native SCSI transport on IP, not FCP on top of IP. TCP may be deficient for iSCSI use in a couple of areas. The TCP reassembly buffer is inefficient at higher speeds. The 16-bit checksum seems insufficient. These problems need to be addressed. A concern was raised that using multiple TCP connections adds a lot of complexity to the protocol that is not present in other IETF protocols, and that this is premature optimization. Randy responded that storage bandwidth needs (esp. at high end) will always outrun speeds on a single link, thus the need to use multiple links through the fabric (which multiple TCP connection enables). There was also a brief discussion of whether to use a TCP connection per LUN - the primary reason not to is scalability concerns for large storage controllers with lots of LUNs. Suggestions were made by a number of people that the requirements document should focus on the required functionality, not the required implementation. The requirements presentation spent time talking about the SMU concept from the SCSI Architecture Manual-2. Ralph Weber, secretary of T10, and technical editor of SAM-2, pointed out that SAM-2 is changing significantly in that area. T10 is also working on lifting the 64-bit limit on the size of target names. The need for multiple connections to a single LUN was questioned, since a LUN will not be able to use more than one network link (a gigabit link). Several people pointed out that this is not true, since many LUNs are backed by RAM, which can source data at full link rates. An issue was raised about whether gigabit performance should be required. It was agreed that the requirements should allow a gigabit or more, but not require it, and it was noted that the charter explicitly mentions small devices. ------------------ Question for consensus: All we have available is the 16-bit checksum. looking for direction on whether 16-bit checksum is adequate, or should be requirements that there will be strong checksum? Consensus in the room: Need to investigate checksums stronger than 16-bits. SCTP was noted as having a 32-bit checksum. iSCSI spec - Julian Satran, IBM Research - Haifa ---------- General overview and summary of iSCSI. See the document for details. The issue of using multiple connections came up again. After some discussion, it was agreed to take this issue to the list for discussion and resolution. An issue was raised about whether iSCSI's error recovery on dropped TCP connections is necessary, as some other have no such error recovery scheme. FCP (the Fibre Channel encapsulation of SCSI) has discovered the hard way that it needs error recovery for dropped frames, which is now part of the FCP-2 effort. On the other hand, a parallel SCSI bus makes no attempt to recover from breaking the physical connection. It was pointed out that since iSCSI uses TCP, it has fewer cases to deal with than FCP, since it must only deal with connection drops, not packet loss. More discussion on the list is needed on error recovery, including scenarios that may require the target to drop data that TCP has successfully delivered (e.g., where the TCP connection breaks before the ACK or response is delivered and hence the initiator retries the operation via some other connection). There was some confusion on SCSI's ordering requirements. SCSI requires commands to be delivered to the target in the same order as the initiator issued them. However, the order in which the target executes the commands is also controlled by the queuing attributes on the device and command. There is an inconsistent use of words like should, may, and can in the document. For example, the ping response appears to be optional as currently worded. This is wrong and needs to be corrected. In general, the authors of the document should review RFC-2119 for definitions of terms like MUST, SHOULD, and MAY and use them appropriately to clarify the requirements on implementations. Security Discussion - led by Steve Bellovin, co-chair ------------------- The discussion started by asking about the need for encryption: It was generally stated by the audience that authentication and integrity seem most important. Speed is also a requirement, as initial link speeds of a gigabit are envisioned. Steve Bellovin noted that encryption generally runs faster than authentication algorithms and that there were encryption algorithms doing a gigabit in hardware already. It was noted that it is difficult to turn on IPSec in the middle of a connection. Consensus call -------------- There was a consensus call eventually. Should encryption be mandatory to implement? The consensus in the room was that encryption should not be mandatory to implement. A lot of people were concerned about the overhead that implementation would imply on cheap devices. Security negotiation is required so that a device that doesn't implement encryption can say so in an understandable fashion. There was some discussion that secure negotiation was highly desirable, to prevent a man-in-the-middle from causing the security negotiation to result in no security. It was noted that most application of iSCSI expect a secure interconnect. Also, secure interconnects are least likely to be available at the low end, where people have the least ability to pay for a secure network. ------- Steve Bellovin asked the group about authentication. "Whom are you authenticating? Is it bi-directional or uni-directional? How many parties does the SCSI device have to authenticate. How do you administer this?" The AD noted that the WG did not have the option of not making the implementation of authentication non-mandatory. It was suggested that the host OS be authenticated and that the authentication should be bi-directional. Web servers could be used for administration. It was pointed out that the web server doesn't scale to large installations and that LDAP could be used to configure a group of machines. It was also pointed out that disks may not have room for a large number of keys and ACLs, which may necessitate the use of an authentication server. At the other end of the spectrum, it was observed that storage arrays are in many cases more powerful than the servers they connect to. It was decided that it is feasible have good random numbers from disks. Steve Bellovin asked if we can do public key calculations at login time? The general consensus in the room is that even most disks have enough CPU power to do this at login time. A hard disk has about as much CPU as a cell phone, which is capable of doing public key calculations. The issue of providing customer support for badly configured security mechanism came up. How do you deal with a user that has lost his keys? Add back-door passwords? There were no good answers in the meeting. Consensus call -------------- Should public keys be mandatory for login authentication? (About half of the people voted for and half against) Scott Bradner suggested that this issue be remitted to the mailing list. Steve Bellovin pointed out that it's much harder to do something for security for UDP than TCP. TCP is easier because there's a steady, in-order context. For UDP, one have to do something like IPSec. Other parting words: There's no confidentiality without integrity checking. A separate session key is probably needed for each TCP connection. For some choices of crypto algorithms (e.g. RC4), it is important to make sure that you NEVER reuse the same key, as key reuse enables some relatively easy attacks on the crypto. ---------------- There was no iSCSI MIB discussion due to insufficient time. FC-over-IP - Elizabeth Rodriguez, Lucent ------------------ It has not been decided where FC-over-IP will be worked on in the IETF. The ipfc WG's time slot will be used to discuss FC-over-IP, but it is not an official work item of the ipfc WG. FC-over-IP is a gateway-to-gateway protocol. Multiple gateways can talk amongst themselves. This was described as complementary to iSCSI. See the draft for current technical details. Scott Bradner asked for input over about where the FC-over-IP work should be done. Send Scott mail privately (sob@harvard.edu) or on the ips mailing list. There was some discussion of a 10km limit in FibreChannel. Standard Fibre Channel has a 10km limit on a single link based on emitter and detector characteristics. The actual protocol timeouts are several seconds which should go allow the protocol to go much further. One important timeout is R_A_TOV (resource allocation time-out value), maximum packet lifetime in a Fibre Channel fabric, which is in the seconds. Default time-out values in fibre-channel fabrics are between 1-10 seconds. Should be good for fairly long hauls. SEP - Paul von Stamwitz, Adaptec ---------------- SEP work is progressing. The one LUN per connection limitation has been removed and the packet format is being changed to resemble packetized SCSI. iSCSI/VI - Constantine Sapuntzakis, Cisco --------------------- This was a quick presentation to set up a bar/dinner BOF for further discussion. Note that VI is currently not an official work item for the ips WG. Protocol stack overhead is too high for IP-based protocols. To reduce the number of copies/page flips, the NIC must place data in the correct place in memory the first time. One way for the NIC to do this is to parse the upper-layer protocol. Another way is to add a generic RDMA protocol which works with multiple upper-layer protocols. VI is one good way of doing an RDMA abstraction. By running iSCSI over VI, we can leverage this generic infrastructure.
Home Last updated: Tue Sep 04 01:07:45 2001 6315 messages in chronological order |