From owner-ips@ece.cmu.edu Thu Feb 1 05:34:14 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23191 for ; Thu, 1 Feb 2001 05:34:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f118Pba09913 for ips-outgoing; Thu, 1 Feb 2001 03:25:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f118PCZ09876 for ; Thu, 1 Feb 2001 03:25:13 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id JAA46336 for ; Thu, 1 Feb 2001 09:25:05 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay02.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id JAA73160 for ; Thu, 1 Feb 2001 09:25:05 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569E6.002E391D ; Thu, 1 Feb 2001 09:24:52 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Thu, 1 Feb 2001 10:20:24 +0200 Subject: Re: iSCSI : Digest Error recovery causes data corruption Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Pierre, Please don't put salt on my wounds... (and explicitly for the reasons you mentioned) I suggested that back in San Diego. There where 2 reason for abandoning it: 1- it can be practically done without TCP modification if CRCs are put in the IPsec Authentication Header but the IPsec people won't have anything weaker that any of the cryptographic digests and without IPsec we are out of options (no change to TCP!) 2-more important Storage Proxies would like to have their separate data digest (or equivalent) Regards, Julo Pierre Labat on 31/01/2001 20:19:17 Please respond to Pierre Labat To: ips@ece.cmu.edu cc: Subject: iSCSI : Digest Error recovery causes data corruption Hello, I would invite you to revisit the Mike Krause mail about "iSCSI Data Integrity - Digests". If Alternative 1 or 2 is adopted, when a digest error (CRC) occurs, the segment could be discarded, and TCP will retransmit. For software implementation with an hardware assist to calculate the CRC, (same kind of the one that exists now to calculate the checksum now), if a CRC error is detected it could be assimilated as a checksum error. Hence there is no need to overload the iSCSI protocol to deal with digest errors, because the iSCSI layer could not see them. Why to do complicate when simple an efficient can be achieved? Regards, Pierre From owner-ips@ece.cmu.edu Thu Feb 1 06:12:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23468 for ; Thu, 1 Feb 2001 06:12:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1192cR11230 for ips-outgoing; Thu, 1 Feb 2001 04:02:38 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1191hZ11191 for ; Thu, 1 Feb 2001 04:01:43 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id KAA29368 for ; Thu, 1 Feb 2001 10:01:31 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id KAA23606 for ; Thu, 1 Feb 2001 10:01:31 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569E6.00319173 ; Thu, 1 Feb 2001 10:01:24 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Thu, 1 Feb 2001 10:38:44 +0200 Subject: Re: iSCSI: Text Commands Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Josh, Thanks. I will add a statement to this effect. Julo Joshua Tseng on 31/01/2001 20:41:11 Please respond to Joshua Tseng To: ips@ece.cmu.edu cc: Subject: iSCSI: Text Commands Julo, I think a statement needs to be added that the iSCSI initiator MUST support all of the text commands listed in Appendix C. Currently, it is unclear whether a target can respond with key:value pairs that were not solicited in the original text command. The spec should explicitly say the target can do so, and require the initiator to recognize all text keys. For example, if the target wants to specify a FirstBurst of less than 65535 (BTW, why is the the default value for FirstBurst so high???), it should be able to specify its own value for FirstBurst, even if the "FirstBurst:" text key was not listed in the original text command. Josh From owner-ips@ece.cmu.edu Thu Feb 1 09:07:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27440 for ; Thu, 1 Feb 2001 09:07:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f11BtgO27062 for ips-outgoing; Thu, 1 Feb 2001 06:55:42 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f11BtaZ27057 for ; Thu, 1 Feb 2001 06:55:36 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id MAA118150; Thu, 1 Feb 2001 12:55:27 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay02.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id MAA225826; Thu, 1 Feb 2001 12:55:27 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569E6.00417B8D ; Thu, 1 Feb 2001 12:55:14 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu cc: ralphoweber@compuserve.com Message-ID: Date: Thu, 1 Feb 2001 12:42:26 +0200 Subject: Re: iSCSI : Holes in StatSN Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, Overlaps and out of order delivery and gaps are not forbidden by SAM . I think we have to go to T10 for that I can't see a good reason to do it. We have a good solution without asking for it . I can see large and important future application that will relay on overlaps and/or gaps and I am not going to foolishly do something to disable or harm their efficient implementation. I think that T10s philosophy of keeping the target master of the transfer and not limiting it in any way is too valuable to ignore. IMHO your request violates our charter without any good reason to support it. Julo Santosh Rao on 01/02/2001 03:53:13 Please respond to Santosh Rao To: ips@ece.cmu.edu cc: Subject: Re: iSCSI : Holes in StatSN julian_satran@il.ibm.com wrote: > With a data sequence we may want to use a similar mechanism to ask for a > missed data block as soon as we see one of its successors or the status. Julian, The missing data PDU is missing due to either a header format error, header digest error or data digest error. [in all other cases, TCP ensures reliable delivery]. In 2 of the above 3 cases, [header format error & header digest error] the initiator CANNOT do a safe interpretation of the PDU header. Without interpreting the PDU header, the initiator does NOT get the Initiator Task Tag. Any request to re-send a particular data PDU MUST be qualified by : I.T.T + missing_DataSN [+ T.T.T + CmdSN, optionally]. Since I.T.T. cannot be reliably determined in 2 of the 3 cases, such a re-send request cannot be reliably achieved. The alternate proposal that was made should be considered in its place, which was to : - dis-allow overlapped data xfer's - initiators do a count check - a command level retry is performed at the iSCSI layer on detecting an underrun [due to a missing PDU]. On several ocassions, requests from different people have been made on this list to dis-allow overlapped data xfers. Can a WG consensus be sought on this issue to see if the benefits of allowing overlapped data xfer's offset its complexities and justify its support ? Regards, Santosh - santoshr.vcf From owner-ips@ece.cmu.edu Thu Feb 1 13:50:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07202 for ; Thu, 1 Feb 2001 13:50:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f11GEpD09969 for ips-outgoing; Thu, 1 Feb 2001 11:14:51 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f11GEQZ09952 for ; Thu, 1 Feb 2001 11:14:28 -0500 (EST) Received: from hpindlm.cup.hp.com (hpindlm.cup.hp.com [15.13.95.89]) by palrel3.hp.com (Postfix) with ESMTP id D4600717; Thu, 1 Feb 2001 08:14:06 -0800 (PST) Received: from mk731913.cup.hp.com (mk731912.cup.hp.com [15.8.80.111]) by hpindlm.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id IAA02266; Thu, 1 Feb 2001 08:16:44 -0800 (PST) Message-Id: <5.0.0.25.2.20010201073752.02800e88@hpindlm.cup.hp.com> X-Sender: krause@hpindlm.cup.hp.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 01 Feb 2001 08:01:58 -0800 To: Sean Quinlan From: Michael Krause Subject: Re: iSCSI Data Integrity - Digests Cc: ips@ece.cmu.edu In-Reply-To: <3A763A5B.B11ADDA6@bell-labs.com> References: <5.0.0.25.2.20010126165115.00a73a80@hpindlm.cup.hp.com> <5.0.0.25.2.20010129124010.023ce6d0@hpindlm.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk At 10:51 PM 1/29/2001 -0500, Sean Quinlan wrote: >I would suggest that if iSCSI requires that a PDU does not span a >TCP segment then iSCSI is indeed changing TCP. A valid implementations >of TCP has considerable freedom in deciding how to pack data into segments >and this is not under the control of the application layer. Such a >requirement in iSCSI would mean it is not feasible to implement iSCSI on >many existing TCP stacks. The continual assertion that TCP implementations are sacrosanct and thus not cannot be modified to support iSCSI combined with a tendency to make everything an option should someone object quite frankly leads one to question whether iSCSI will suffer the same 10-year growing pains / interoperability problems FC suffered and thus seriously raises a question of its viability within the industry. Yes, iSCSI could be implemented using SCTP which is, from an architecture point of view, more suitable in many ways than TCP. However, SCTP isn't really deployed today, is not targeted by those few that have deployed it for a high-volume market, and thus unclear whether it can generate sufficient interest to make it a viable transport from a business perspective. I don't want to debate SCTP vs. TCP - there has been enough of it already on this reflector and the only point was while it is interesting, the business issues are a major problem that is not going to be solved in the desired deployment time frames. Summary: Either iSCSI starts getting realistic in terms of what is subject to change without violating / major modifications to existing protocols (not implementations) and starts reducing the number of options so interoperability has a chance of success or it will suffer the fate of FC's early years. >If you change the requirements of for a valid TCP implementation I believe >you have effectively changed the protocol. The protocol is defined as a set of wire formats and semantics. The proposal did not violate any aspect of the RFC which does allow TCP a great deal of freedom in terms of how it packages segments. >I agree with Douglas Otis that such a change may not be well received. > >What would you suggest for situations such a iSCSI over a protocol such as >TLS(SSL). >TLS uses an internal framing mechanism that is not under the applications >control and is also not related to the underlying TCP segments. Put some intelligence into the solution's implementation and segment accordingly. >It would seem to me a little unwise to mandate end-to-end data integrity >within iSCSI >especially using a CRC algorithm. Rather a lot of data goes over protocols >such as HTTP, FTP, NFS and CIFS without any additional end-to-end data >integrity >over what is provided by TCP and link level integrity - I think it is a little >strong to say > strong end-to-end data integrity is not an option as customers will > not adopt solutions without such guarantees. The original proposal stated what the difference here is: these protocols target buffers and associated information that is not transmitted over the wire thus reducing the probability of a DMA targeting an incorrect location in memory. iSCSI communicates addressing information either direct VAs or a handle for the look-up. In either case, there is a greater probability of a DMA targeting the wrong location as a result. FC protects their data with a 32-bit CRC which provides customers with a lot greater confidence in the data integrity than what they get from TCP's checksum. Also, as noted by numerous people there is a measured evidence of silent data corruption getting past TCP's checksum today in the Internet. If people really believe iSCSI will flow across the Internet, then silent data corruption must be dealt with in a much stronger manner than what is being proposed and having it as an option is unacceptable for most vendors and customers. >If TLS or IPsec are used in conjunction with iSCSI, then strong >end-to-end integrity is already provided and duplicating this in iSCSI seem >rather a waste. It may be the case that some people are not satisfied with >the integrity provided by TCP and yet do not want to use TLS or IPsec to >ensure >integrity/authenticity, but I suspect that such people are not the >majority and >thus mandating a data integrity mechanism within iSCSI seems like a mistake - >perhaps as an option or perhaps leave it to other layers in the protocol >stack. One cannot mandate IPSec / TLS usage within the standard nor can one rely upon it for data integrity. To assume that the majority of people want it is incorrect as well since this is a function of the usage models being deployed. Many people interested in iSCSI are not interested per se in block storage over the actual Internet but block storage over IP-based networks - there is a very big difference here and the requirements for security as a result. >If data integrity is provided by iSCSI, CRC algorithms are not particularly >ideal from a software implementation point of view - surely there >are better alternatives than CRC that are easy to implement in hardware and >can take advantage of 32bit wide data ops. CRCs are well understood. While software is an interesting implementation and certainly one that I do not want to see harmed, many vendors are developing hardware-based solutions (keeps the CPU consumption to be the same as FC which is important for customers and vendors). The proposal put forth also provided a mechanism for some intelligence to be added to non-iSCSI hardware implementations similar to the way one does checksum off-load today allowing software to not necessarily be burdened with unnecessary overheads if so desired. Mike From owner-ips@ece.cmu.edu Thu Feb 1 16:04:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11528 for ; Thu, 1 Feb 2001 16:04:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f11J1J217646 for ips-outgoing; Thu, 1 Feb 2001 14:01:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f11IxoZ17549 for ; Thu, 1 Feb 2001 13:59:50 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel3.hp.com (Postfix) with ESMTP id 5931973D for ; Thu, 1 Feb 2001 10:59:49 -0800 (PST) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id KAA00779 for ; Thu, 1 Feb 2001 10:59:44 -0800 (PST) Message-ID: <3A79B2C6.2FD26DC7@cup.hp.com> Date: Thu, 01 Feb 2001 11:02:30 -0800 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 Cc: ips@ece.cmu.edu Subject: Re: iSCSI : Holes in StatSN References: Content-Type: multipart/mixed; boundary="------------0E5B87DD0869E3B98E81E4DE" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------0E5B87DD0869E3B98E81E4DE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian, I did'nt hear back on my issues related to attempting per-PDU recovery, namely : a) This goes back to attempting to recover a portion of the I/O as opposed to command level recovery. I believe the WG consensus at Orlando was to use command level recovery (?) b) A request to re-send a Data PDU within an I.T.T must be qualified by (I.T.T + missing_DataSN). The I.T.T & DataSN CANNOT be reliably extracted from the PDU in the cases of a header format error or header digest error. IOW, the per-PDU scheme does not solve all the cases. Regarding overlapped data xfers, FCP prohibited it and seems to have no problems with this. Also, this feature is un-used in most cases. I don't believe restricting iSCSI to support a sub-set of the optional features of SAM-2 violates either T10 philosophy or SAM-2. OTOH, specifying guidelines that mandate which features shall be used and un-used (along the lines of FC-PLDA and FC-FLA documents) is the only reliable recipe for interoperability. Regards, Santosh julian_satran@il.ibm.com wrote: > Santosh, > > Overlaps and out of order delivery and gaps are not forbidden by SAM . I > think we have to go to T10 for that I can't see a good reason to do it. We > have a good solution without asking for it . I can see large and important > future application that will relay on overlaps and/or gaps and I am not > going to foolishly do something to disable or harm their efficient > implementation. I think that T10s philosophy of keeping the target master > of the transfer and not limiting it in any way is too valuable to ignore. > > IMHO your request violates our charter without any good reason to support > it. > > Julo > > Santosh Rao on 01/02/2001 03:53:13 > > Please respond to Santosh Rao > > To: ips@ece.cmu.edu > cc: > Subject: Re: iSCSI : Holes in StatSN > > julian_satran@il.ibm.com wrote: > > > With a data sequence we may want to use a similar mechanism to ask for a > > missed data block as soon as we see one of its successors or the status. > > Julian, > > The missing data PDU is missing due to either a header format error, header > digest error or data digest error. [in all other cases, TCP ensures > reliable > delivery]. > > In 2 of the above 3 cases, [header format error & header digest error] the > initiator CANNOT do a safe interpretation of the PDU header. Without > interpreting the PDU header, the initiator does NOT get the Initiator Task > Tag. Any request to re-send a particular data PDU MUST be qualified by : > I.T.T + missing_DataSN [+ T.T.T + CmdSN, optionally]. > > Since I.T.T. cannot be reliably determined in 2 of the 3 cases, such a > re-send request cannot be reliably achieved. > > The alternate proposal that was made should be considered in its place, > which > was to : > - dis-allow overlapped data xfer's > - initiators do a count check > - a command level retry is performed at the iSCSI layer on detecting an > underrun [due to a missing PDU]. > > On several ocassions, requests from different people have been made on this > list to dis-allow overlapped data xfers. Can a WG consensus be sought on > this > issue to see if the benefits of allowing overlapped data xfer's offset its > complexities and justify its support ? > > Regards, > Santosh > > - santoshr.vcf --------------0E5B87DD0869E3B98E81E4DE Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------0E5B87DD0869E3B98E81E4DE-- From owner-ips@ece.cmu.edu Thu Feb 1 16:05:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11539 for ; Thu, 1 Feb 2001 16:05:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f11Jnpo20104 for ips-outgoing; Thu, 1 Feb 2001 14:49:51 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f11JnQZ20079 for ; Thu, 1 Feb 2001 14:49:26 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f11Ktu065333; Thu, 1 Feb 2001 12:55:56 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: "Michael Krause" , "Sean Quinlan" Cc: Subject: RE: iSCSI Data Integrity - Digests Date: Thu, 1 Feb 2001 11:44:17 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <5.0.0.25.2.20010201073752.02800e88@hpindlm.cup.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mike, I agree with most of your points with the exception of TCP being a wire protocol. Use the SCTP structures and apply them to TCP where the SCTP port locations become a pseudo frame word length and then allow padding to a predefined interval and you then have the required framing and all the benefits of SCTP while not harming TCP at the API. As we get mired down in amorphic iSCSI, a transport specification as complete as SCTP would immediately provide productive solutions and a clean migration to that uncharted land where SCTP dominates. Doug > At 10:51 PM 1/29/2001 -0500, Sean Quinlan wrote: > >I would suggest that if iSCSI requires that a PDU does not span a > >TCP segment then iSCSI is indeed changing TCP. A valid implementations > >of TCP has considerable freedom in deciding how to pack data > into segments > >and this is not under the control of the application layer. Such a > >requirement in iSCSI would mean it is not feasible to implement iSCSI on > >many existing TCP stacks. > > The continual assertion that TCP implementations are sacrosanct and thus > not cannot be modified to support iSCSI combined with a tendency to make > everything an option should someone object quite frankly leads one to > question whether iSCSI will suffer the same 10-year growing pains / > interoperability problems FC suffered and thus seriously raises a > question > of its viability within the industry. > > Yes, iSCSI could be implemented using SCTP which is, from an architecture > point of view, more suitable in many ways than TCP. However, SCTP isn't > really deployed today, is not targeted by those few that have deployed it > for a high-volume market, and thus unclear whether it can generate > sufficient interest to make it a viable transport from a business > perspective. I don't want to debate SCTP vs. TCP - there has been enough > of it already on this reflector and the only point was while it is > interesting, the business issues are a major problem that is not going to > be solved in the desired deployment time frames. > > Summary: Either iSCSI starts getting realistic in terms of what > is subject > to change without violating / major modifications to existing protocols > (not implementations) and starts reducing the number of options so > interoperability has a chance of success or it will suffer the > fate of FC's > early years. > > >If you change the requirements of for a valid TCP implementation > I believe > >you have effectively changed the protocol. > > The protocol is defined as a set of wire formats and semantics. The > proposal did not violate any aspect of the RFC which does allow > TCP a great > deal of freedom in terms of how it packages segments. > > >I agree with Douglas Otis that such a change may not be well received. > > > >What would you suggest for situations such a iSCSI over a > protocol such as > >TLS(SSL). > >TLS uses an internal framing mechanism that is not under the applications > >control and is also not related to the underlying TCP segments. > > Put some intelligence into the solution's implementation and segment > accordingly. > > > >It would seem to me a little unwise to mandate end-to-end data integrity > >within iSCSI > >especially using a CRC algorithm. Rather a lot of data goes > over protocols > >such as HTTP, FTP, NFS and CIFS without any additional end-to-end data > >integrity > >over what is provided by TCP and link level integrity - I think > it is a little > >strong to say > > strong end-to-end data integrity is not an option as > customers will > > not adopt solutions without such guarantees. > > The original proposal stated what the difference here is: these protocols > target buffers and associated information that is not transmitted > over the > wire thus reducing the probability of a DMA targeting an > incorrect location > in memory. iSCSI communicates addressing information either > direct VAs or > a handle for the look-up. In either case, there is a greater probability > of a DMA targeting the wrong location as a result. FC protects > their data > with a 32-bit CRC which provides customers with a lot greater > confidence in > the data integrity than what they get from TCP's checksum. > > Also, as noted by numerous people there is a measured evidence of silent > data corruption getting past TCP's checksum today in the Internet. If > people really believe iSCSI will flow across the Internet, then > silent data > corruption must be dealt with in a much stronger manner than what > is being > proposed and having it as an option is unacceptable for most vendors and > customers. > > >If TLS or IPsec are used in conjunction with iSCSI, then strong > >end-to-end integrity is already provided and duplicating this in > iSCSI seem > >rather a waste. It may be the case that some people are not > satisfied with > >the integrity provided by TCP and yet do not want to use TLS or IPsec to > >ensure > >integrity/authenticity, but I suspect that such people are not the > >majority and > >thus mandating a data integrity mechanism within iSCSI seems > like a mistake - > >perhaps as an option or perhaps leave it to other layers in the protocol > >stack. > > One cannot mandate IPSec / TLS usage within the standard nor can > one rely > upon it for data integrity. To assume that the majority of people want it > is incorrect as well since this is a function of the usage models being > deployed. Many people interested in iSCSI are not interested per se in > block storage over the actual Internet but block storage over IP-based > networks - there is a very big difference here and the requirements for > security as a result. > > > >If data integrity is provided by iSCSI, CRC algorithms are not > particularly > >ideal from a software implementation point of view - surely there > >are better alternatives than CRC that are easy to implement in > hardware and > >can take advantage of 32bit wide data ops. > > CRCs are well understood. While software is an interesting > implementation > and certainly one that I do not want to see harmed, many vendors are > developing hardware-based solutions (keeps the CPU consumption to be the > same as FC which is important for customers and vendors). The > proposal put > forth also provided a mechanism for some intelligence to be added to > non-iSCSI hardware implementations similar to the way one does checksum > off-load today allowing software to not necessarily be burdened with > unnecessary overheads if so desired. > > Mike > > From owner-ips@ece.cmu.edu Thu Feb 1 16:05:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11550 for ; Thu, 1 Feb 2001 16:05:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f11Io6k17057 for ips-outgoing; Thu, 1 Feb 2001 13:50:06 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f11In1Z17002 for ; Thu, 1 Feb 2001 13:49:01 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id 4C1CE485 for ; Thu, 1 Feb 2001 10:48:56 -0800 (PST) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id KAA29353 for ; Thu, 1 Feb 2001 10:48:49 -0800 (PST) Message-ID: <3A79B036.462E8F12@cup.hp.com> Date: Thu, 01 Feb 2001 10:51:35 -0800 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: Re: iSCSI : Holes in StatSN References: Content-Type: multipart/mixed; boundary="------------59DA8355A6A63836EBA8C8EC" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------59DA8355A6A63836EBA8C8EC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit julian_satran@il.ibm.com wrote: > The sack will specify a range to be filled. The initiator will revert to > bulk as soon as it has no holes. Julian, Once a StatSN hole is created, it is never filled. [since subsequent "retry" of the command results in a different StatSN being used.]. However, there is currently no association available to determine when it is safe to acknowledge that hole [which happens when the initiator switches back to bulk ACK scheme.] Given the above, the initiator needs to maintain a list of Initiator Task Tags for which StatSN holes were encountered (i.e. Status PDU was not received). It then needs to dequeue elements from this list when the "retry" command completes or the command is aborted. Once all elements are off this list, it can revert to the bulk StatSN ACK mechanism. > A target can also resend after a timeout or when seen the same StatSN on a > NOP. Not sure what is implied here. Surely, we are not attempting a re-transmit functionality akin to TCP re-transmit at the iSCSI layer for Status PDUs (?) > The initiator will query after > a long silence with a NOP (not longer than the SCSI timeout -:)) This is intriguing. Are you suggesting that on an I/O timeout, the initiator send a NOP-OUT to request a re-transmit of the Status PDU ? How does the initiator know one of the Data PDUs also did not time out ? (An I/O timeout also implies that the O.S. expects a response back without any further time being spent on the I/O. I/O timeouts cause the initiator to abort the I/O and error the I/O up the stack. ) Regards, Santosh > Santosh Rao on 01/02/2001 02:57:25 > > Please respond to Santosh Rao > > To: > cc: ips@ece.cmu.edu > Subject: Re: iSCSI : Holes in StatSN > > Julian, > > Once the selective StatSN ACK mechanism kicks in, how is the initiator to > revert to the bulk StatSN ACK ? (i.e. when/how does an initiator realize > that > the hole is filled ?) Or, does it only use selective StatSN ACK from there > on > ? > > The difficulty lies in the fact that a hole created will never be filled > since "retry" will result in target sending back a subsequent Status PDU > with > a different StatSN. However, the initiator does not know when to safely > claim > that the hole is filled (by sending a bulk StatSN ACK), since there is no > way > to detect this. > > Regards, > Santosh > --------------59DA8355A6A63836EBA8C8EC Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------59DA8355A6A63836EBA8C8EC-- From owner-ips@ece.cmu.edu Thu Feb 1 16:05:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11562 for ; Thu, 1 Feb 2001 16:05:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f11JS5d18949 for ips-outgoing; Thu, 1 Feb 2001 14:28:05 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp5.mail.yahoo.com (smtp5.mail.yahoo.com [128.11.69.102]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f11JRSZ18917 for ; Thu, 1 Feb 2001 14:27:28 -0500 (EST) Received: from unknown (HELO somesh) (206.112.111.132) by smtp.mail.vip.suc.yahoo.com with SMTP; 1 Feb 2001 19:27:25 -0000 X-Apparently-From: Reply-To: From: "Somesh Gupta" To: "Matt Wakeley" , Subject: RE: iSCSI : Digest Error recovery causes data corruption Date: Thu, 1 Feb 2001 11:24:26 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3A7860C3.E0764D73@agilent.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit One thing I would like to point out is that in the presence of any kind of middle boxes (isn't the CRC supposed to protect against that primarily?), the iSCSI data CRC has been proposed to provide an end-to-end integrity, whereas a TCP connection actually might exist from a middle box to the receiving end-system. In this case, retransmission at the TCP layer may continue to send corrupted data if the corruption happened somewhere prior to the sending point on the middle-box. > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Matt Wakeley > Sent: Wednesday, January 31, 2001 11:00 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI : Digest Error recovery causes data corruption > > > At first glance, the idea is nice. > > However, options 1 and 2 require changes to the implementation > and API of TCP > to provide the framing. As you (should) know, we are not allowed > to change > TCP. Another problem is that your proposal to drop segments that > have digest > errors violates the network layering. TCP will deliver the PDUs > to iSCSI. > iSCSI is the layer that checks the CRC. When TCP delivers the > data to iSCSI, > it has already acknowledged the segment, so it can't be discarded and > retransmitted. There is no way for iSCSI to tell TCP to accept or drop a > segment. > > [all of the above assumes existing TCP definition/implementation. > Anything is > possible if one is allowed to change things] > > -Matt > > Pierre Labat wrote: > > > > Hello, > > > > I would invite you to revisit the Mike Krause mail about > > "iSCSI Data Integrity - Digests". > > > > If Alternative 1 or 2 is adopted, when a digest error (CRC) > > occurs, the segment could be discarded, and TCP will > > retransmit. For software implementation with an hardware > > assist to calculate the CRC, (same kind of the one that exists > > now to calculate the checksum now), if a CRC error is detected > > it could be assimilated as a checksum error. > > Hence there is no need to overload the iSCSI protocol > > to deal with digest errors, because the iSCSI layer could not > > see them. > > > > Why to do complicate when simple an efficient can be achieved? > > > > Regards, > > > > Pierre _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ips@ece.cmu.edu Thu Feb 1 16:50:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12287 for ; Thu, 1 Feb 2001 16:50:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f11JSpb18980 for ips-outgoing; Thu, 1 Feb 2001 14:28:51 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f11JRBZ18905 for ; Thu, 1 Feb 2001 14:27:11 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f11KbX065314; Thu, 1 Feb 2001 12:37:33 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: , Cc: Subject: RE: iSCSI : Holes in StatSN Date: Thu, 1 Feb 2001 11:25:54 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, While I agree data delivery directed by the target with significant freedom is the convention used by SCSI, Santosh also speaks to a much larger issue. The present iSCSI transport is not reliable and repairing this weakness using the SCSI layer is a poor technique. Abandon a mixture of SCSI and iSCSI and make iSCSI a self sustaining independent layer. View iSCSI as a general transport that allows handling of digest errors, validation, multiple connections, and sequential delivery then its header may look something like this: +---------------+---------------+---------------+---------------+ 0| Type | Reserved | Word Length | +---------------+---------------+---------------+---------------+ 4| Validation Tag | +---------------+---------------+---------------+---------------+ 8| Checksum (Adler32) | +---------------+---------------+---------------+---------------+ 12| ->ClientSN or <-ServerSN | +---------------+---------------+---------------+---------------+ 16| ->ExpServerSN or <-ExpClientSN | +---------------+---------------+---------------+---------------+ 20| ->MaxServerSN or <-MaxClientSN | +---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+ 24| (Frame Check) | +---------------+---------------+---------------+---------------+ 28| SCSI_CMND ... | +- | 36| | +---------------+---------------+---------------+---------------+ 40| CDB ... | +---------------+---------------+---------------+---------------+ x | (Data ...) | +---------------+---------------+---------------+---------------+ The advantage of moving the Frame Check (if used) into the header would be with respect to data placement especially in regard to potential overlays or non-sequential data due to the freedom offered to SCSI. To assist in delineating this transport as independent of SCSI a better name could be SCSI Encapsulation Transport or SET. To indicate its use under IP, iSET. The frame type could include FC or Parallel versions of SCSI to assist in a more straight forward conversion. Doug > Santosh, > > Overlaps and out of order delivery and gaps are not forbidden by SAM . I > think we have to go to T10 for that I can't see a good reason to do it. We > have a good solution without asking for it . I can see large and > important > future application that will relay on overlaps and/or gaps and I am not > going to foolishly do something to disable or harm their efficient > implementation. I think that T10s philosophy of keeping the target master > of the transfer and not limiting it in any way is too valuable to ignore. > > IMHO your request violates our charter without any good reason to support > it. > > Julo > > Santosh Rao on 01/02/2001 03:53:13 > > Please respond to Santosh Rao > > To: ips@ece.cmu.edu > cc: > Subject: Re: iSCSI : Holes in StatSN > > > > > julian_satran@il.ibm.com wrote: > > > With a data sequence we may want to use a similar mechanism to ask for a > > missed data block as soon as we see one of its successors or the status. > > Julian, > > The missing data PDU is missing due to either a header format > error, header > digest error or data digest error. [in all other cases, TCP ensures > reliable > delivery]. > > In 2 of the above 3 cases, [header format error & header digest error] the > initiator CANNOT do a safe interpretation of the PDU header. Without > interpreting the PDU header, the initiator does NOT get the Initiator Task > Tag. Any request to re-send a particular data PDU MUST be qualified by : > I.T.T + missing_DataSN [+ T.T.T + CmdSN, optionally]. > > Since I.T.T. cannot be reliably determined in 2 of the 3 cases, such a > re-send request cannot be reliably achieved. > > The alternate proposal that was made should be considered in its place, > which > was to : > - dis-allow overlapped data xfer's > - initiators do a count check > - a command level retry is performed at the iSCSI layer on detecting an > underrun [due to a missing PDU]. > > On several ocassions, requests from different people have been > made on this > list to dis-allow overlapped data xfers. Can a WG consensus be sought on > this > issue to see if the benefits of allowing overlapped data xfer's offset its > complexities and justify its support ? > > Regards, > Santosh > > - santoshr.vcf > > > > From owner-ips@ece.cmu.edu Thu Feb 1 16:50:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12304 for ; Thu, 1 Feb 2001 16:50:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f11JRpK18937 for ips-outgoing; Thu, 1 Feb 2001 14:27:51 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f11JRZZ18922 for ; Thu, 1 Feb 2001 14:27:35 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f11KbY065317; Thu, 1 Feb 2001 12:37:35 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: , Subject: RE: iSCSI Data Integrity - Digests Date: Thu, 1 Feb 2001 11:25:55 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <0F31E5C394DAD311B60C00E029101A07041014C5@corpmx9.isus.emc.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Once dealing with 32-bit wide memory accesses, adding and subtracting are hardly difficult operations nor more difficult than that needed for CRC. Adler32 does not involve division in most implementations and requires few gates between states so minor pipe-lining easily handles any perceived difficulty. You will notice that s2 does not feed into s1. Here is the repetitive operation of adler32: s1 += *buf++; if (s1 >= BASE) s1 -= BASE; s2 += s1; if (s2 >= BASE) s2 -= BASE; Doug > > I am not sure I understand the difficulty imposed by adler32 > with respect > to > > hardware. Optimal assembly code looks different with about three > > instructions per byte. > > I believe the concern is about how fast a hot-rodded ASIC can go. > The arithmetic involved in CRCs doesn't have to cope with carry/borrow > propagation in contrast to the arithmetic involved in the Adler-32 > modulus. > > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Thu Feb 1 16:52:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12371 for ; Thu, 1 Feb 2001 16:52:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f11KLsW21595 for ips-outgoing; Thu, 1 Feb 2001 15:21:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dns.LampreyNetworks.com (IDENT:root@mail.lampreynetworks.com [64.31.72.26]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f11K5YZ20842 for ; Thu, 1 Feb 2001 15:05:34 -0500 (EST) Received: from breinhold ([140.186.41.177]) by dns.LampreyNetworks.com (8.9.3/8.8.7) with SMTP id PAA30401; Thu, 1 Feb 2001 15:07:33 -0500 From: "Barry Reinhold - Lamprey" To: "Julian_Satran@Il. Ibm. Com" Cc: "ISCSI" Subject: ISCSI: Immediate data extending beyond a single PDU Date: Thu, 1 Feb 2001 15:04:28 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, My understanding of your email in conjunction with the current draft is: The initiator may send zero or more immediate data bytes in the CMD PDU, and may send additional unsolicited DATA PDUs with further immediate data, with the last PDU having the F bit set. The total amount of immediate data to be limited by the value negotiated at login. There are two issues I have with this: First, the target does not know how much immediate data has being sent. There is no indication in the CMD frame to indicate that more immediate data is to follow (whether or not the CMD frame contains any immediate data). The initiator is free to send any amount, from zero up to the negotiated value. Therefore, the target will likely send an R2T to the host at whatever boundry it believes is present - which may cause a retransmission of much or all of the immediate data. Second, the additional unsolicited PDU's do not contain a target task/transfer tag. As such, in the mainline processing, you are perhaps forcing the target to look up the Initiator Task Tag in its list of active i/o's. This may exact a heavy performance penalty as optimizing this lookup maybe cost-prohibitive. The only other scenarios in which the target had to perform this lookup was in low-occurance error/abort conditions. Are there negative implications to keeping immediate data to a single PDU? -- Barry julian_satran@il.ibm.com wrote: > Barry, > > Immediate data is "attached to the command". If your unsolicited data (the > so called initial burst) is larger that what you are ready to commit to a > single PDU you can send several PDUs with the last having the F bit. After > that the target can decide that it wants more and send an R2T or send > status. > > You are no supposed to send both immediate and separate PDU. > > I admit that the text is bit confusing (in 1.2.5) and there is an error > also in the appendix. > 2.7.1 talk about unsolicited data (not immediate) (the context is data > PDUs). > > The new version of 1.2.5 now reads: > > Unsolicited data can be sent as part of an iSCSI command PDU ("immediate > data") or an in separate iSCSI data PDUs. An initiator may send > unsolicited data either as immediate (up to the negotiated maximum PDU > size - DataPDULength - disconnect-reconnect mode page) or in a separate > PDU sequence (up to the negotiated limit - FirstBurstSize - > disconnect-reconnect mode page). All subsequent data have to be > solicited. The maximum size of an individual data PDU or the > immediate-part of the initial unsolicited burst as well as the initial > burst size MAY be negotiated at login. > > Thanks, > Julo > > "Barry Reinhold - Lamprey" on 29/01/2001 16:34:30 > > Please respond to "Barry Reinhold - Lamprey" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: "Jon Sreekanth" , "James Smart" > > Subject: > > Issue: > > I am unclear on how to respond to an iSCSI SCSI command PDU when there is > immediate data but not enough to meet the requirements of the IO operation > as given in the expected data transfer length field. Should an R2T be > issued > or not? > > Background: > > Clause 2.7.1 in 03 reads: > > "2.7.1 F (Final) bit > > This bit is 1 for the last PDU of immediate data or the last PDU of a > sequence answering a R2T." > > This suggests that immediate data can extend beyond the iSCSI SCSI CMD PDU > (there is no final bit on the command PDU)but the closet thing we have to a > definition for immediate data, which is in clause 1.2.5 below, suggests > that > immediate data is limitted to the command PDU: > > "Outgoing SCSI data (initiator to target - user data or command > parameters) will be sent as either solicited data or unsolicited > data. Solicited data are sent in response to Ready To Transfer (R2T) > PDUs. Unsolicited data can be part of an iSCSI command PDU > ("immediate data") or an iSCSI data PDU. An initiator may send > unsolicited data (immediate or in a separate PDU) up to the > negotiated limit (initial burst size - mode page 02h). All subsequent > data have to be solicited. The maximum size of an individual data > PDU or the immediate-part of the initial unsolicited burst MAY be > negotiated at login (maximum connect size - mode page 02h)." > > Unsolicited data is bounded in a number of ways, but most significant to > this issue is in the description of the login key useR2t which states: > > "Note than only the first > outgoing data item (either immediate data or a separate PDU) can be > sent unsolicited by a R2T." > > Given the above it is unclear to me if the concept of immediate data is: > > 1. Write data that can be sent without an R2T (unsolicited write data)and > starts in the command PDU. > 2. Write data that is entirely contained within the command PDU. (my > initial > concept of immediate data) > 3. The non-zero portion of data, in a possible multi-PDU write operation, > that is contained in the iSCSI SCSI command PDU. Where the remaining PDUs > of > the write operation must be solicited with an R2T. > > Given the current definition of the Final bit and the current limits on > unsolicited data it is unclear to me what a target should do when receiving > an iSCSI SCSI command PDU that has immediate data in it, but not sufficient > data to meet the expected data transfer length specificied in the command. > Does an R2T go out of not? > > Barry Reinhold > 603-659-0885 Barry Reinhold 603-659-0885 From owner-ips@ece.cmu.edu Thu Feb 1 16:53:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12403 for ; Thu, 1 Feb 2001 16:53:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f11KArW21089 for ips-outgoing; Thu, 1 Feb 2001 15:10:53 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from main.connectcom.net (ns1.advansys.com [204.247.22.3] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f11KA3Z21024 for ; Thu, 1 Feb 2001 15:10:03 -0500 (EST) Received: from yp_portable (anubis.advansys.com [204.247.22.2]) by main.connectcom.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1DQGXJAB; Thu, 1 Feb 2001 12:09:59 -0800 From: "Y P Cheng" To: "'Ips@Ece. Cmu. Edu'" Subject: RE: iSCSI: CmdSN and Retry Date: Thu, 1 Feb 2001 12:07:49 -0800 Message-ID: <011801c08c8a$a669c920$90c809c0@yp_portable.advansys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julo wrote: > Except for sending the status - an executing command helds-up the LU queue > and makes the "local" recovery simpler than clearing the LU queue and > resending the commands. Santosh wrote: > This is correct, in the case where the target does NOT implement > data/status recovery. i.e. Assume ordering is required, 2 commands , say, > 1 & 2, executed in order at the target. Now, if 1 encountered a digest error > or format error at the initiator, and was re-sent with the "retry" bit > AND the target were to NOT implement data/status recovery, it would result > in target executing 1, 2, 1. This may be a problem and canot be addressed, > unless iSCSI mandates data/status recovery. I certainly understand the need of doing data/status recovery and the argument of "local" recovery being simpler. However, this comes with heavy cost of performance when pipelined design demands 100,000 IOs per second on a network with long delay. For services and responses happening a few times per second, it is OK to hold on the resources until we are certain the ACK is returned. However, in the example above, after completing command 1 if a target can't start command 2 until the status for 1 is ACK'ed, the wait can be 100 milliseconds on a network with long delay. The wait make it impossible to have large number of IOs in the pipeline. By mandating data/status recovery in iSCSI, we change the pipelined command execution to interlock handshakes. As I have said in the previous email, an initiator will never send an command which depends on the success of a previous command. This fact makes the pipeline execution in a target possible. On a separate note, I really respect Santosh's fine-tooth analysis of the iSCSI draft. But, in his arguments the fact that SCSI has been functional for the last 20 years was badly ignored. The CmdSN, DataSN, and StatSN allow iSCSI to detect missing PDUs and to quickly ask for retransmit. They should not be used to enforce sequentiality to slow things down. SCSI already has the semantics of ordered execution that requires the help of CmdSN when multiple TCP connections are used. However, using StatSN to mandate data/status retry pays a great performance price. Both overlapped and out-of-order data transfers are allowed in SCSI (Check out the Modify Data Pointer extended message). SCSI works fine without mandating non-overlapping transfers or data/status recovery. Retry can be done in a simple and clean manner without introducing complicated semantics for CmdSN, DataSN, and StatSN. Note, if we must retry more than once in a million IOs, something is wrong of the infrastructure. Therefore, let the pipeline flow quickly and don't optimize the retry. As long as we separate the TCP, iSCSI, and SCSI ULP layers cleanly -- for which this WG has done a good job -- SCSI will continue to work. Without wasting more bandwidth on this subject, I will be willing to discuss the SCSI retry implementations with anyone offline. From owner-ips@ece.cmu.edu Thu Feb 1 20:15:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16130 for ; Thu, 1 Feb 2001 20:15:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f11NHvf29212 for ips-outgoing; Thu, 1 Feb 2001 18:17:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f11NHjZ29199 for ; Thu, 1 Feb 2001 18:17:45 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id 53C7EBA6; Thu, 1 Feb 2001 15:17:43 -0800 (PST) Received: (from santoshr@localhost) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id PAA28159; Thu, 1 Feb 2001 15:17:38 -0800 (PST) From: Santosh Rao Message-Id: <200102012317.PAA28159@hpcuhe.cup.hp.com> Subject: Re: iSCSI: CmdSN and Retry To: ycheng@advansys.com (Y P Cheng) Date: Thu, 1 Feb 2001 15:17:36 -0800 (PST) Cc: ips@ece.cmu.edu ('Ips@Ece. Cmu. Edu') In-Reply-To: <011801c08c8a$a669c920$90c809c0@yp_portable.advansys.com> from "Y P Cheng" at Feb 01, 2001 12:07:49 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I certainly understand the need of doing data/status recovery and the > argument of "local" recovery being simpler. However, this comes with > heavy cost of performance when pipelined design demands 100,000 IOs per > second on a network with long delay. For services and responses > happening a few times per second, it is OK to hold on the resources > until we are certain the ACK is returned. However, in the example > above, after completing command 1 if a target can't start command 2 > until the status for 1 is ACK'ed, the wait can > be 100 milliseconds on a network with long delay. The wait make it > impossible to have large number of IOs in the pipeline. By mandating > data/status recovery in iSCSI, we change the pipelined command > execution to interlock handshakes. > As I have said in the previous email, an initiator > will never send an command which depends on the success of a previous > command. This fact makes the pipeline execution in a target possible. YP, I agree with the above and have been saying the same thing in a seperate thread. (See : "Command Ordering Proposal" http://ips.pdl.cs.cmu.edu/mail/msg03171.html) (The corner cases stated simply point out issues with the SNs as they exist in the draft today.) The bigger question of why iSCSI is attempting to provide ordering when its peers do not is still un-answered. iSCSI is trying to enforce strict ordering which is not required due to the following reasons : 1) Other SCSI Transport Protocols (FC, pSCSI) do not guarantee strict ordering across commands. 2) Most (All ?) operating system SCSI Stacks enforce ordering above the SCSI ULP and do not depend on the SCSI Stack to provide end-to-end ordering across commands. (The exception to this is ordering of commands followed by their aborts). 3) In the absence of (1) & (2) above, applications cannot depend on SCSI transport protocols to provide strict end-to-end ordering across commands, since they are transport agnostic and do not wish to base ordering assumptions on the transport they operate on. (i.e. appln code enforces ordering if it operates on FC and pSCSI and uses iSCSI ordering when it runs above iSCSI !) 4) Error recovery scenarios needed to maintain ordering across transport errors, resource allocation errors, errors at the target, digest errors and format errors becomes extremely complex, stalls all pipelined operations and in some cases cannot resolve the out-of-order situation induced unless the target executes 1 command at a time and ONLY starts on the next command after a StatSN ACK for the previous one. 5) Strict ordering results in performance penalties such as : a) non-concurrent command execution at the targets. b) stalled TCP connections in a session when a connection turns faulty. c) all commands need to be stalled and re-initiated on any I/O error in an attempt to maintain ordering. d) Flow Control mechanisms like QUEUE FULL error recovery will change to complete oscillating algorithms with the initiator completely stopping all further I/Os until order is restored in the sequence they were originally sent. 6) Strict ordering is not required in the majority if not all cases, since most (all ?) O.S' do not enforce strict ordering or do anything special in their error recovery to maintain strict ordering. 7) Several targets treat simple and ordered tags in a similar manner without differentiating and providing strict ordering for ordered tag commands. 8) Majority of the I/O traffic (if not all) is simple tag commands and all this ordering and error recovery for ordering will impact performance when ordering was never required in the first place. 9) The use of ordering within a SCSI stack is not prevalent. IN those few places where it is known to be in use, this is a static characteristic of that SCSI stack, and such stacks can use single-connection sessions to achive their ordering. IOW, the majority of stacks do NOT require strict ordering. Hence, iSCSI should optimize for this most common case and NOT penalize it. > > On a separate note, I really respect Santosh's fine-tooth analysis of the > iSCSI draft. But, in his arguments the fact that SCSI has been functional > for the last 20 years was badly ignored. YP, the corner cases simply bring out problems in the draft as they exist today. I have been consistently raising the bigger question about why iSCSI is attempting to differ from its peers in issues like ordering, overlapped data xfer's, etc. SCSI has been functioning over the last 20 years without applns depending on SCSI stacks for strict ordering or deploying un-used features like overlapped data xfers. Applns will continue NOT to depend on scsi transports for the above since they are written to be transport agnostic, and are based on lowest common denominator support. (i.e. assume no ordering from O.S SCSI Stack). > However, using StatSN to > mandate data/status retry pays a great performance price. Agreed. > Both overlapped > and out-of-order data transfers are allowed in SCSI (Check out the Modify > Data Pointer extended message). SCSI works fine without mandating > non-overlapping transfers or data/status recovery. The Modify Data Pointers needs to be explicitly enabled through Mode Select and I can't recollect seeing any instances of its usage. As for FCP, overlapped data xfer's are not allowed. period. Regards, Santosh -- ################################# Santosh Rao Software Design Engineer, HP, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################# From owner-ips@ece.cmu.edu Thu Feb 1 20:15:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16143 for ; Thu, 1 Feb 2001 20:15:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f11NQvI29548 for ips-outgoing; Thu, 1 Feb 2001 18:26:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f11NQ8Z29520 for ; Thu, 1 Feb 2001 18:26:08 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id 7CE165EA; Thu, 1 Feb 2001 15:26:06 -0800 (PST) Received: (from santoshr@localhost) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id PAA29083; Thu, 1 Feb 2001 15:26:01 -0800 (PST) From: Santosh Rao Message-Id: <200102012326.PAA29083@hpcuhe.cup.hp.com> Subject: Re: iSCSI: CmdSN and Retry To: dotis@sanlight.net (Douglas Otis) Date: Thu, 1 Feb 2001 15:26:01 -0800 (PST) Cc: ycheng@advansys.com (Y P Cheng), ips@ece.cmu.edu ('Ips@Ece. Cmu. Edu') In-Reply-To: from "Douglas Otis" at Feb 01, 2001 02:23:20 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Unless the transport maintains order, there will be a requirement to wait > for each command to complete to assure the sequence. Doug, The majority of SCSI stacks today DO function as stated above. The layer above ULP enforces the ordering and awaits completion of 1 I/O prior to posting the subsequent I/O , PROVIDED those 2 I/Os required ordering to be maintained. > This makes > compliance to SCSI impossible and not a means of improving the pipe-line. Are you saying that the majority of stacks today are not SCSI compliant (?) YP raises a valid concern in that if strict ordering is expected from the transport, it should be capable of providing this 100 %. (98% strict ordering is'nt good enough.). To attempt to provide 100% guarantee of strict ordering is going to prevent concurrent I/O processing at the target at a session level (NOT even a LUN level, which is the granularity where one would expect ordering, if at all !). Regards, Santosh -- ################################# Santosh Rao Software Design Engineer, HP, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################# From owner-ips@ece.cmu.edu Thu Feb 1 20:15:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16141 for ; Thu, 1 Feb 2001 20:15:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f11MPsX27187 for ips-outgoing; Thu, 1 Feb 2001 17:25:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f11MP4Z27131 for ; Thu, 1 Feb 2001 17:25:04 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f11NYx065445; Thu, 1 Feb 2001 15:35:03 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: "Y P Cheng" , "'Ips@Ece. Cmu. Edu'" Subject: RE: iSCSI: CmdSN and Retry Date: Thu, 1 Feb 2001 14:23:20 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <011801c08c8a$a669c920$90c809c0@yp_portable.advansys.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Y.P. Any TCP bandwidth is limited to .93 MSS/(RTT * loss_rate^-2) so your assumption of one in a million at 100 milli-seconds limits at Fast Ethernet rates. There will be significant overhead on long pipes dealing with TCP handshakes and any additional handshake will not add significantly to this resource overhead. The more immediate these handshakes, the less resources consumed with respect to any needed replays to satisfy the transport. I do not agree procrastination that depends on rediscovery of indexes unrelated to these handshakes to be more effective in allowing pipe-line execution. Unless the transport maintains order, there will be a requirement to wait for each command to complete to assure the sequence. This makes compliance to SCSI impossible and not a means of improving the pipe-line. An immediate handshake within the transport layer dealing with digest errors is the best means of improving performance. Reliance on the SCSI tag to recover from a failure deduced from a dropped transport sequence is not a clean separation of layers. The amount of resources saved by deleting this positive relationship is dwarfed by the window size required for such a fat pipe. Doug Should each IO represent > Julo wrote: > > Except for sending the status - an executing command helds-up > the LU queue > > and makes the "local" recovery simpler than clearing the LU queue and > > resending the commands. > Santosh wrote: > > This is correct, in the case where the target does NOT implement > > data/status recovery. i.e. Assume ordering is required, 2 > commands , say, > > 1 & 2, executed in order at the target. Now, if 1 encountered a digest > error > > or format error at the initiator, and was re-sent with the "retry" bit > > AND the target were to NOT implement data/status recovery, it > would result > > in target executing 1, 2, 1. This may be a problem and canot be > addressed, > > unless iSCSI mandates data/status recovery. > > I certainly understand the need of doing data/status recovery and the > argument of "local" recovery being simpler. However, this comes > with heavy > cost of performance when pipelined design demands 100,000 IOs per > second on > a network with long delay. For services and responses happening > a few times > per second, it is OK to hold on the resources until we are certain the ACK > is returned. However, in the example above, after completing > command 1 if a > target can't start command 2 until the status for 1 is ACK'ed, > the wait can > be 100 milliseconds on a network with long delay. The wait make it > impossible to have large number of IOs in the pipeline. By mandating > data/status recovery in iSCSI, we change the pipelined command > execution to > interlock handshakes. As I have said in the previous email, an initiator > will never send an command which depends on the success of a previous > command. This fact makes the pipeline execution in a target possible. > > On a separate note, I really respect Santosh's fine-tooth analysis of the > iSCSI draft. But, in his arguments the fact that SCSI has been functional > for the last 20 years was badly ignored. The CmdSN, DataSN, and StatSN > allow iSCSI to detect missing PDUs and to quickly ask for > retransmit. They > should not be used to enforce sequentiality to slow things down. SCSI > already has the semantics of ordered execution that requires the help of > CmdSN when multiple TCP connections are used. However, using StatSN to > mandate data/status retry pays a great performance price. Both overlapped > and out-of-order data transfers are allowed in SCSI (Check out the Modify > Data Pointer extended message). SCSI works fine without mandating > non-overlapping transfers or data/status recovery. Retry can be done in a > simple and clean manner without introducing complicated semantics > for CmdSN, > DataSN, and StatSN. Note, if we must retry more than once in a > million IOs, > something is wrong of the infrastructure. Therefore, let the > pipeline flow > quickly and don't optimize the retry. > > As long as we separate the TCP, iSCSI, and SCSI ULP layers cleanly -- for > which this WG has done a good job -- SCSI will continue to work. Without > wasting more bandwidth on this subject, I will be willing to discuss the > SCSI retry implementations with anyone offline. > > From owner-ips@ece.cmu.edu Thu Feb 1 20:15:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16163 for ; Thu, 1 Feb 2001 20:15:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f11NAtG28903 for ips-outgoing; Thu, 1 Feb 2001 18:10:55 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from main.connectcom.net (ns1.advansys.com [204.247.22.3] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f11NAgZ28889 for ; Thu, 1 Feb 2001 18:10:42 -0500 (EST) Received: from yp_portable (anubis.advansys.com [204.247.22.2]) by main.connectcom.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1DQGXJHB; Thu, 1 Feb 2001 15:10:40 -0800 From: "Y P Cheng" To: "Douglas Otis" , "'Ips@Ece. Cmu. Edu'" Subject: RE: iSCSI: CmdSN and Retry Date: Thu, 1 Feb 2001 15:08:31 -0800 Message-ID: <012a01c08ca3$e4c2bf60$90c809c0@yp_portable.advansys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Doug, I think you have misunderstood what I said about error recovery in different layers. I specifically have stated that we should separate the three layers: 1) Transport layer provides in order delivery on Internet, 2) iSCSI keeps the in order among multiple connections, and 3) SCSI has its own in order command semantics. Frame retransmit and congestion control belong to the transport. Digest error retransmit belongs to iSCSI layer. Finally, SCSI itself has done command level recovery very well for the last 20 years. We should mix iSCSI and SCSI retries. I want to be able to pipe 100,000 frames down the wire without letting retry and ACKs getting into the way. In my previous writings, I have stated that for TCP to support 10Gb/100Ms network with a huge reassembly buffer, message framing and TCP/RDMA must be used. Whether the maximum TCP bandwidth supports such a high IO rate is beyond the Charters of this WG. I have no problem in using SCTP, if this is what it would take for the 10Gb/100Ms network. Y.P. > Any TCP bandwidth is limited to .93 MSS/(RTT * loss_rate^-2) so your > assumption of one in a million at 100 milli-seconds limits at > Fast Ethernet > rates. There will be significant overhead on long pipes dealing with TCP > handshakes and any additional handshake will not add significantly to this > resource overhead. The more immediate these handshakes, the less > resources > consumed with respect to any needed replays to satisfy the > transport. I do > not agree procrastination that depends on rediscovery of indexes unrelated > to these handshakes to be more effective in allowing pipe-line execution. > Unless the transport maintains order, there will be a requirement to wait > for each command to complete to assure the sequence. This makes > compliance > to SCSI impossible and not a means of improving the pipe-line. > An immediate > handshake within the transport layer dealing with digest errors > is the best > means of improving performance. Reliance on the SCSI tag to > recover from a > failure deduced from a dropped transport sequence is not a clean > separation > of layers. The amount of resources saved by deleting this positive > relationship is dwarfed by the window size required for such a fat pipe. > > Doug From owner-ips@ece.cmu.edu Thu Feb 1 20:16:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16174 for ; Thu, 1 Feb 2001 20:16:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f11NFu529143 for ips-outgoing; Thu, 1 Feb 2001 18:15:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from main.connectcom.net (ns1.advansys.com [204.247.22.3] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f11NFWZ29070 for ; Thu, 1 Feb 2001 18:15:32 -0500 (EST) Received: from yp_portable (anubis.advansys.com [204.247.22.2]) by main.connectcom.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1DQGXJHK; Thu, 1 Feb 2001 15:15:31 -0800 From: "Y P Cheng" To: "Douglas Otis" , "'Ips@Ece. Cmu. Edu'" Subject: RE: iSCSI: CmdSN and Retry Date: Thu, 1 Feb 2001 15:13:21 -0800 Message-ID: <012b01c08ca4$91c7f5e0$90c809c0@yp_portable.advansys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Frame retransmit and congestion control belong to the transport. > Digest error retransmit belongs to iSCSI layer. Finally, SCSI > itself has done command level recovery very well for the last 20 > years. We should mix iSCSI and SCSI retries. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Should NOT. My apology. From owner-ips@ece.cmu.edu Thu Feb 1 21:23:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17148 for ; Thu, 1 Feb 2001 21:23:35 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f120auZ02189 for ips-outgoing; Thu, 1 Feb 2001 19:36:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f120aLZ02167 for ; Thu, 1 Feb 2001 19:36:21 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel3.hp.com (Postfix) with ESMTP id BFEA7976; Thu, 1 Feb 2001 16:36:19 -0800 (PST) Received: (from santoshr@localhost) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id QAA07788; Thu, 1 Feb 2001 16:36:15 -0800 (PST) From: Santosh Rao Message-Id: <200102020036.QAA07788@hpcuhe.cup.hp.com> Subject: Re: iSCSI: CmdSN and Retry To: dotis@sanlight.net (Douglas Otis) Date: Thu, 1 Feb 2001 16:36:14 -0800 (PST) Cc: santoshr@cup.hp.com (Santosh Rao), ips@ece.cmu.edu (ips) In-Reply-To: from "Douglas Otis" at Feb 01, 2001 04:15:26 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > An extra handshake that requires a small delay should there > be a non-sequential event would occur orders of magnitude less often than > similar waits for TCP. As this must be a rare event, the wait will be > insignificant. Doug, The non-sequential event may be rare. However, the handshake should occur on EVERY I/O to safeguard against that rare event. [if 100% ordering is attempted.]. Strict ordering of 2 commands, say, A followed by B, imply that : A target cannot execute B until the initiator acknowledges Status PDU for A. (This implies sequential operation on I/Os on the task set similar to untagged targets, only greater, because this behaviour is per session and not even per LUN.) Since iSCSI applies strict ordering to all commands (well, all non-0 CmdSN commands), the above behaviour will be required on all I/Os within a session. Regards, Santosh -- ################################# Santosh Rao Software Design Engineer, HP, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################# From owner-ips@ece.cmu.edu Thu Feb 1 21:26:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17165 for ; Thu, 1 Feb 2001 21:26:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f120Ju801570 for ips-outgoing; Thu, 1 Feb 2001 19:19:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f120JbZ01551 for ; Thu, 1 Feb 2001 19:19:37 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f121R5065531; Thu, 1 Feb 2001 17:27:05 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: "Santosh Rao" Cc: "Y P Cheng" , "'Ips@Ece. Cmu. Edu'" Subject: RE: iSCSI: CmdSN and Retry Date: Thu, 1 Feb 2001 16:15:26 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200102012326.PAA29083@hpcuhe.cup.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh, TCP mandates sequential delivery. As was often stated on this reflector, framing would be to place data payloads but would not impact the sequence of any operation. An extra handshake that requires a small delay should there be a non-sequential event would occur orders of magnitude less often than similar waits for TCP. As this must be a rare event, the wait will be insignificant. Assurance of sequential delivery improves reliability and does not require command-by-command pacing to provide expected SCSI operation that otherwise is easily done with parallel SCSI configurations. The buffer size will be nominally one packet larger to handle such extra handshake and again insignificant. I see nothing to justify complexity offered by convoluted recovery for a digest error. SCTP offers a means of delivering objects out-of-sequence and then perhaps flagging which objects can violate SCSI's sense of ordering could be done to help facilitate long pipes. If this ever becomes a significant factor, the bandwidth will be so small as to be of little concern anyway. Doug > > Unless the transport maintains order, there will be a > requirement to wait > > for each command to complete to assure the sequence. > > Doug, > > The majority of SCSI stacks today DO function as stated above. > The layer above ULP enforces the ordering and awaits completion of 1 I/O > prior to posting the subsequent I/O , PROVIDED those 2 I/Os required > ordering to be maintained. > > > This makes > > compliance to SCSI impossible and not a means of improving the > pipe-line. > Are you saying that the majority of stacks today are not > SCSI compliant (?) > > YP raises a valid concern in that if strict ordering is expected from the > transport, it should be capable of providing this 100 %. (98% strict > ordering is'nt good enough.). To attempt to provide 100% guarantee of > strict ordering is going to prevent concurrent I/O processing at the > target at a session level (NOT even a LUN level, which is the granularity > where one would expect ordering, if at all !). > > Regards, > Santosh > > > > -- > ################################# > Santosh Rao > Software Design Engineer, > HP, Cupertino. > email : santoshr@cup.hp.com > Phone : 408-447-3751 > ################################# > From owner-ips@ece.cmu.edu Thu Feb 1 23:21:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19804 for ; Thu, 1 Feb 2001 23:21:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f121dxV04304 for ips-outgoing; Thu, 1 Feb 2001 20:39:59 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f121dBZ04283 for ; Thu, 1 Feb 2001 20:39:11 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f122l6065597; Thu, 1 Feb 2001 18:47:06 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: "Santosh Rao" Cc: "ips" Subject: RE: iSCSI: CmdSN and Retry Date: Thu, 1 Feb 2001 17:35:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200102020036.QAA07788@hpcuhe.cup.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh, 1. iSCSI is based on TCP, a protocol that mandates sequential delivery. 2. TCP provides insignificant bandwidth if there is a high error rate. 3. Digest errors will happen at the 16-bit checksum undetected error rate. 4. Higher latency of networks makes such command-by-command constraints less effective than a transport that assures sequencing. 5. There are many cases (not most) where order is significant. You could make a better case for ensuring sequencing at the transport level than negligible benefits derived from non-sequential processing of commands following a digest error. > Doug, > > The non-sequential event may be rare. However, the handshake should occur > on EVERY I/O to safeguard against that rare event. [if 100% ordering is > attempted.]. The only potential delay would be with respect to any skew between connections. If the PDUs are delivered in order, as they would be normally, then there would be zero delay in the processing of the information. The pending handshake would only require the sender to retain a structure that relates the sequence value to the PDU sent. This handshake is trivial, already within the structures, and only requires the return of an additional packet before this structure can be removed. Yes every I/O would be examined to ensure its sequence but the same check is made to acknowledge now. Normally this results in no extra operation or delay. > Strict ordering of 2 commands, say, A followed by B, imply that : > > A target cannot execute B until the initiator acknowledges Status > PDU for A. (This implies sequential operation on I/Os on the task set > similar to untagged targets, only greater, because this behaviour is per > session and not even per LUN.) As status should enjoy the same independent assurance of delivery, SCSI would not be impacted by a transport error as you imply nor would there be a need to execute command-status-command-status. If you could not assure reliable sequential delivery, then should such become important, then indeed you would be required to execute command-status-command-status. The benefit from using the handshake would be to prevent this requirement. Digest errors will happen at the 16-bit checksum undetected error rate. We are taking about a flea of a flea with respect to any loss of performance. > Since iSCSI applies strict ordering to all commands (well, all non-0 CmdSN > commands), the above behaviour will be required on all I/Os within a > session. This is the claim but a claim that can not be assured due to the lack of integrity in the current handshake. Doug > Regards, > Santosh > > > -- > ################################# > Santosh Rao > Software Design Engineer, > HP, Cupertino. > email : santoshr@cup.hp.com > Phone : 408-447-3751 > ################################# > From owner-ips@ece.cmu.edu Thu Feb 1 23:58:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20443 for ; Thu, 1 Feb 2001 23:58:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f122t2E06868 for ips-outgoing; Thu, 1 Feb 2001 21:55:02 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dns.LampreyNetworks.com (IDENT:root@mail.lampreynetworks.com [64.31.72.26]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f11K5YZ20842 for ; Thu, 1 Feb 2001 15:05:34 -0500 (EST) Received: from breinhold ([140.186.41.177]) by dns.LampreyNetworks.com (8.9.3/8.8.7) with SMTP id PAA30401; Thu, 1 Feb 2001 15:07:33 -0500 From: "Barry Reinhold - Lamprey" To: "Julian_Satran@Il. Ibm. Com" Cc: "ISCSI" Subject: ISCSI: Immediate data extending beyond a single PDU Date: Thu, 1 Feb 2001 15:04:28 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, My understanding of your email in conjunction with the current draft is: The initiator may send zero or more immediate data bytes in the CMD PDU, and may send additional unsolicited DATA PDUs with further immediate data, with the last PDU having the F bit set. The total amount of immediate data to be limited by the value negotiated at login. There are two issues I have with this: First, the target does not know how much immediate data has being sent. There is no indication in the CMD frame to indicate that more immediate data is to follow (whether or not the CMD frame contains any immediate data). The initiator is free to send any amount, from zero up to the negotiated value. Therefore, the target will likely send an R2T to the host at whatever boundry it believes is present - which may cause a retransmission of much or all of the immediate data. Second, the additional unsolicited PDU's do not contain a target task/transfer tag. As such, in the mainline processing, you are perhaps forcing the target to look up the Initiator Task Tag in its list of active i/o's. This may exact a heavy performance penalty as optimizing this lookup maybe cost-prohibitive. The only other scenarios in which the target had to perform this lookup was in low-occurance error/abort conditions. Are there negative implications to keeping immediate data to a single PDU? -- Barry julian_satran@il.ibm.com wrote: > Barry, > > Immediate data is "attached to the command". If your unsolicited data (the > so called initial burst) is larger that what you are ready to commit to a > single PDU you can send several PDUs with the last having the F bit. After > that the target can decide that it wants more and send an R2T or send > status. > > You are no supposed to send both immediate and separate PDU. > > I admit that the text is bit confusing (in 1.2.5) and there is an error > also in the appendix. > 2.7.1 talk about unsolicited data (not immediate) (the context is data > PDUs). > > The new version of 1.2.5 now reads: > > Unsolicited data can be sent as part of an iSCSI command PDU ("immediate > data") or an in separate iSCSI data PDUs. An initiator may send > unsolicited data either as immediate (up to the negotiated maximum PDU > size - DataPDULength - disconnect-reconnect mode page) or in a separate > PDU sequence (up to the negotiated limit - FirstBurstSize - > disconnect-reconnect mode page). All subsequent data have to be > solicited. The maximum size of an individual data PDU or the > immediate-part of the initial unsolicited burst as well as the initial > burst size MAY be negotiated at login. > > Thanks, > Julo > > "Barry Reinhold - Lamprey" on 29/01/2001 16:34:30 > > Please respond to "Barry Reinhold - Lamprey" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: "Jon Sreekanth" , "James Smart" > > Subject: > > Issue: > > I am unclear on how to respond to an iSCSI SCSI command PDU when there is > immediate data but not enough to meet the requirements of the IO operation > as given in the expected data transfer length field. Should an R2T be > issued > or not? > > Background: > > Clause 2.7.1 in 03 reads: > > "2.7.1 F (Final) bit > > This bit is 1 for the last PDU of immediate data or the last PDU of a > sequence answering a R2T." > > This suggests that immediate data can extend beyond the iSCSI SCSI CMD PDU > (there is no final bit on the command PDU)but the closet thing we have to a > definition for immediate data, which is in clause 1.2.5 below, suggests > that > immediate data is limitted to the command PDU: > > "Outgoing SCSI data (initiator to target - user data or command > parameters) will be sent as either solicited data or unsolicited > data. Solicited data are sent in response to Ready To Transfer (R2T) > PDUs. Unsolicited data can be part of an iSCSI command PDU > ("immediate data") or an iSCSI data PDU. An initiator may send > unsolicited data (immediate or in a separate PDU) up to the > negotiated limit (initial burst size - mode page 02h). All subsequent > data have to be solicited. The maximum size of an individual data > PDU or the immediate-part of the initial unsolicited burst MAY be > negotiated at login (maximum connect size - mode page 02h)." > > Unsolicited data is bounded in a number of ways, but most significant to > this issue is in the description of the login key useR2t which states: > > "Note than only the first > outgoing data item (either immediate data or a separate PDU) can be > sent unsolicited by a R2T." > > Given the above it is unclear to me if the concept of immediate data is: > > 1. Write data that can be sent without an R2T (unsolicited write data)and > starts in the command PDU. > 2. Write data that is entirely contained within the command PDU. (my > initial > concept of immediate data) > 3. The non-zero portion of data, in a possible multi-PDU write operation, > that is contained in the iSCSI SCSI command PDU. Where the remaining PDUs > of > the write operation must be solicited with an R2T. > > Given the current definition of the Final bit and the current limits on > unsolicited data it is unclear to me what a target should do when receiving > an iSCSI SCSI command PDU that has immediate data in it, but not sufficient > data to meet the expected data transfer length specificied in the command. > Does an R2T go out of not? > > Barry Reinhold > 603-659-0885 Barry Reinhold 603-659-0885 From owner-ips@ece.cmu.edu Fri Feb 2 08:21:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07614 for ; Fri, 2 Feb 2001 08:21:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f12BkAM04139 for ips-outgoing; Fri, 2 Feb 2001 06:46:10 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f12BjjZ04125 for ; Fri, 2 Feb 2001 06:45:46 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id MAA81086 for ; Fri, 2 Feb 2001 12:45:39 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id MAA145004 for ; Fri, 2 Feb 2001 12:45:39 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569E7.0040994B ; Fri, 2 Feb 2001 12:45:35 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Fri, 2 Feb 2001 13:41:10 +0200 Subject: Re: ISCSI: Immediate data extending beyond a single PDU Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Barry, There is a misunderstanding: You can send EITHER immediate data OR a sequence of unsolicited PDUs. Immediate data was conceived for short writes - for which an initiator does not want to do two socket operations or 2 HBA operations. Larger unsolicited bursts can be sent with a sequence and then we felt that you won't gain too much by having the first one glued to the command. Julo "Barry Reinhold - Lamprey" on 01/02/2001 22:04:28 Please respond to "Barry Reinhold - Lamprey" To: Julian Satran/Haifa/IBM@IBMIL cc: "ISCSI" Subject: ISCSI: Immediate data extending beyond a single PDU Julian, My understanding of your email in conjunction with the current draft is: The initiator may send zero or more immediate data bytes in the CMD PDU, and may send additional unsolicited DATA PDUs with further immediate data, with the last PDU having the F bit set. The total amount of immediate data to be limited by the value negotiated at login. There are two issues I have with this: First, the target does not know how much immediate data has being sent. There is no indication in the CMD frame to indicate that more immediate data is to follow (whether or not the CMD frame contains any immediate data). The initiator is free to send any amount, from zero up to the negotiated value. Therefore, the target will likely send an R2T to the host at whatever boundry it believes is present - which may cause a retransmission of much or all of the immediate data. Second, the additional unsolicited PDU's do not contain a target task/transfer tag. As such, in the mainline processing, you are perhaps forcing the target to look up the Initiator Task Tag in its list of active i/o's. This may exact a heavy performance penalty as optimizing this lookup maybe cost-prohibitive. The only other scenarios in which the target had to perform this lookup was in low-occurance error/abort conditions. Are there negative implications to keeping immediate data to a single PDU? -- Barry julian_satran@il.ibm.com wrote: > Barry, > > Immediate data is "attached to the command". If your unsolicited data (the > so called initial burst) is larger that what you are ready to commit to a > single PDU you can send several PDUs with the last having the F bit. After > that the target can decide that it wants more and send an R2T or send > status. > > You are no supposed to send both immediate and separate PDU. > > I admit that the text is bit confusing (in 1.2.5) and there is an error > also in the appendix. > 2.7.1 talk about unsolicited data (not immediate) (the context is data > PDUs). > > The new version of 1.2.5 now reads: > > Unsolicited data can be sent as part of an iSCSI command PDU ("immediate > data") or an in separate iSCSI data PDUs. An initiator may send > unsolicited data either as immediate (up to the negotiated maximum PDU > size - DataPDULength - disconnect-reconnect mode page) or in a separate > PDU sequence (up to the negotiated limit - FirstBurstSize - > disconnect-reconnect mode page). All subsequent data have to be > solicited. The maximum size of an individual data PDU or the > immediate-part of the initial unsolicited burst as well as the initial > burst size MAY be negotiated at login. > > Thanks, > Julo > > "Barry Reinhold - Lamprey" on 29/01/2001 16:34:30 > > Please respond to "Barry Reinhold - Lamprey" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: "Jon Sreekanth" , "James Smart" > > Subject: > > Issue: > > I am unclear on how to respond to an iSCSI SCSI command PDU when there is > immediate data but not enough to meet the requirements of the IO operation > as given in the expected data transfer length field. Should an R2T be > issued > or not? > > Background: > > Clause 2.7.1 in 03 reads: > > "2.7.1 F (Final) bit > > This bit is 1 for the last PDU of immediate data or the last PDU of a > sequence answering a R2T." > > This suggests that immediate data can extend beyond the iSCSI SCSI CMD PDU > (there is no final bit on the command PDU)but the closet thing we have to a > definition for immediate data, which is in clause 1.2.5 below, suggests > that > immediate data is limitted to the command PDU: > > "Outgoing SCSI data (initiator to target - user data or command > parameters) will be sent as either solicited data or unsolicited > data. Solicited data are sent in response to Ready To Transfer (R2T) > PDUs. Unsolicited data can be part of an iSCSI command PDU > ("immediate data") or an iSCSI data PDU. An initiator may send > unsolicited data (immediate or in a separate PDU) up to the > negotiated limit (initial burst size - mode page 02h). All subsequent > data have to be solicited. The maximum size of an individual data > PDU or the immediate-part of the initial unsolicited burst MAY be > negotiated at login (maximum connect size - mode page 02h)." > > Unsolicited data is bounded in a number of ways, but most significant to > this issue is in the description of the login key useR2t which states: > > "Note than only the first > outgoing data item (either immediate data or a separate PDU) can be > sent unsolicited by a R2T." > > Given the above it is unclear to me if the concept of immediate data is: > > 1. Write data that can be sent without an R2T (unsolicited write data)and > starts in the command PDU. > 2. Write data that is entirely contained within the command PDU. (my > initial > concept of immediate data) > 3. The non-zero portion of data, in a possible multi-PDU write operation, > that is contained in the iSCSI SCSI command PDU. Where the remaining PDUs > of > the write operation must be solicited with an R2T. > > Given the current definition of the Final bit and the current limits on > unsolicited data it is unclear to me what a target should do when receiving > an iSCSI SCSI command PDU that has immediate data in it, but not sufficient > data to meet the expected data transfer length specificied in the command. > Does an R2T go out of not? > > Barry Reinhold > 603-659-0885 Barry Reinhold 603-659-0885 From owner-ips@ece.cmu.edu Fri Feb 2 08:24:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07696 for ; Fri, 2 Feb 2001 08:24:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f12BLAl03441 for ips-outgoing; Fri, 2 Feb 2001 06:21:10 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f12BKbZ03429 for ; Fri, 2 Feb 2001 06:20:38 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id MAA57876 for ; Fri, 2 Feb 2001 12:20:30 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id MAA282230 for ; Fri, 2 Feb 2001 12:20:30 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569E7.003E4C1F ; Fri, 2 Feb 2001 12:20:27 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Fri, 2 Feb 2001 13:16:01 +0200 Subject: Re: iSCSI : Holes in StatSN Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk comments in text - Julo Santosh Rao on 01/02/2001 20:51:35 Please respond to Santosh Rao To: IPS Reflector cc: Subject: Re: iSCSI : Holes in StatSN julian_satran@il.ibm.com wrote: > The sack will specify a range to be filled. The initiator will revert to > bulk as soon as it has no holes. Julian, Once a StatSN hole is created, it is never filled. [since subsequent "retry" of the command results in a different StatSN being used.]. However, there is currently no association available to determine when it is safe to acknowledge that hole [which happens when the initiator switches back to bulk ACK scheme.] Given the above, the initiator needs to maintain a list of Initiator Task Tags for which StatSN holes were encountered (i.e. Status PDU was not received). It then needs to dequeue elements from this list when the "retry" command completes or the command is aborted. Once all elements are off this list, it can revert to the bulk StatSN ACK mechanism. > A target can also resend after a timeout or when seen the same StatSN on a > NOP. Not sure what is implied here. Surely, we are not attempting a re-transmit functionality akin to TCP re-transmit at the iSCSI layer for Status PDUs (?) > The initiator will query after > a long silence with a NOP (not longer than the SCSI timeout -:)) This is intriguing. Are you suggesting that on an I/O timeout, the initiator send a NOP-OUT to request a re-transmit of the Status PDU ? How does the initiator know one of the Data PDUs also did not time out ? +++ I the status PDU (alone or with a data block) there is a the last data block sequence number This is how holes in data will be detected (the same as with sum of data-lengths versus expected-residual that you are advocating) (An I/O timeout also implies that the O.S. expects a response back without any further time being spent on the I/O. I/O timeouts cause the initiator to abort the I/O and error the I/O up the stack. ) Regards, Santosh > Santosh Rao on 01/02/2001 02:57:25 > > Please respond to Santosh Rao > > To: > cc: ips@ece.cmu.edu > Subject: Re: iSCSI : Holes in StatSN > > Julian, > > Once the selective StatSN ACK mechanism kicks in, how is the initiator to > revert to the bulk StatSN ACK ? (i.e. when/how does an initiator realize > that > the hole is filled ?) Or, does it only use selective StatSN ACK from there > on > ? > > The difficulty lies in the fact that a hole created will never be filled > since "retry" will result in target sending back a subsequent Status PDU > with > a different StatSN. However, the initiator does not know when to safely > claim > that the hole is filled (by sending a bulk StatSN ACK), since there is no > way > to detect this. > > Regards, > Santosh > - santoshr.vcf From owner-ips@ece.cmu.edu Fri Feb 2 13:10:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19524 for ; Fri, 2 Feb 2001 13:10:50 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f12FPGs11377 for ips-outgoing; Fri, 2 Feb 2001 10:25:16 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from main.connectcom.net (ns1.advansys.com [204.247.22.3] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f12FOQZ11342 for ; Fri, 2 Feb 2001 10:24:26 -0500 (EST) Received: from yp_portable (anubis.advansys.com [204.247.22.2]) by main.connectcom.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 11CPQC7C; Fri, 2 Feb 2001 07:24:25 -0800 From: "Y P Cheng" To: "Michael Krause" Cc: Subject: RE: iSCSI Data Integrity - Digests Date: Fri, 2 Feb 2001 07:22:25 -0800 Message-ID: <000001c08d2b$f33327a0$90c809c0@yp_portable.advansys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <5.0.0.25.2.20010201073752.02800e88@hpindlm.cup.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > The continual assertion that TCP implementations are sacrosanct and thus > not cannot be modified to support iSCSI combined with a tendency to make > everything an option should someone object quite frankly leads one to > question whether iSCSI will suffer the same 10-year growing pains / > interoperability problems FC suffered and thus seriously raises a > question of its viability within the industry. Mike, if iSCSI is deployed through the use of an adapter which collapses all three layers, SCSI, iSCSI, and TCP, into a single set of microcode, then, you got a new implementation of TCP anyway. All those sacrosanct talks that forbid changes of TCP implementations do not apply to an iSCSI adapter which at login time will exchange text parameters with each other to deploy new TCP options. Everything you wanted can be inside an iSCSI adapter. However, the right place to talk about what you want from TCP is in the end2end group, not here, as so many people repeatedly pointed out to me. :-) Y.P. From owner-ips@ece.cmu.edu Fri Feb 2 14:18:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23293 for ; Fri, 2 Feb 2001 14:18:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f12EFGq08782 for ips-outgoing; Fri, 2 Feb 2001 09:15:16 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [168.159.208.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f12EF6Z08776 for ; Fri, 2 Feb 2001 09:15:06 -0500 (EST) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2650.21) id <1DCB7626>; Fri, 2 Feb 2001 09:15:00 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A07041014D0@corpmx9.isus.emc.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI error recovery Date: Fri, 2 Feb 2001 09:14:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk There's been a lot of discussion on the list about this topic, including the proper use of CmdSN and StatSN to respond to errors including those detected by CRC. I hesitate to call consensus on any of this discussion because it's based on a version of the draft (-03) that is some combination of incomplete, incorrect, and/or difficult to comprehend in this area. Based on this and the length/detail of the discussion, I suspect that many people on the list are not completely aware of the issues here, and calling consensus when a large segment of the WG may not understand the issues is unlikely to be productive. The next version of the draft (-04) SHOULD contain a much better section on error recovery with explanations and examples that make it significantly easier to understand. Consensus calls on error recovery will not be made before it appears. Meanwhile, a few comments on ongoing issues: - If a CRC error occurs, trying to use any data covered by that CRC is generally not a good idea in the absence of other measures (e.g., an error-correcting code covering the field(s) of interest). - Given some of the CRC discussion, I think the conclusion in Orlando to have separate header and data CRCs is NOT the rough consensus of the WG. We need to go back to a requirements discussion on this rather than debating exactly where to put the CRCs. Would those envisioning middleboxes/gateways/etc. that would benefit from this sort of CRC separation please post short use cases/descriptions indicating the basic functionality of the box and which fields it needs to change (let's do this with reference to the header layout in -03 rather than subsequent changes)? As part of the use case/description, please explain how/why Fibre Channel's single CRC covering both the frame header and data causes problems/difficulties. - Mandating the use of IPsec or TLS solely to handle CRC-level integrity issues is overkill. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Feb 2 14:27:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23625 for ; Fri, 2 Feb 2001 14:27:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f12H4Jw15352 for ips-outgoing; Fri, 2 Feb 2001 12:04:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from main.connectcom.net (ns1.advansys.com [204.247.22.3] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f12H3GZ15313 for ; Fri, 2 Feb 2001 12:03:16 -0500 (EST) Received: from yp_portable (anubis.advansys.com [204.247.22.2]) by main.connectcom.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 11CPQC03; Fri, 2 Feb 2001 09:03:15 -0800 From: "Y P Cheng" To: Subject: RE: iSCSI error recovery Date: Fri, 2 Feb 2001 09:01:16 -0800 Message-ID: <000801c08d39$c17b27e0$90c809c0@yp_portable.advansys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <0F31E5C394DAD311B60C00E029101A07041014D0@corpmx9.isus.emc.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Meanwhile, a few comments on ongoing issues: > - Given some of the CRC discussion, I think the conclusion > in Orlando to have separate header and data CRCs is > NOT the rough consensus of the WG. We need to go > back to a requirements discussion on this rather than > debating exactly where to put the CRCs. Would those > envisioning middleboxes/gateways/etc. that would > benefit from this sort of CRC separation please post > short use cases/descriptions indicating the basic > functionality of the box and which fields it needs > to change (let's do this with reference to the header > layout in -03 rather than subsequent changes)? As > part of the use case/description, please explain > how/why Fibre Channel's single CRC covering both > the frame header and data causes problems/difficulties. With a single CRC covering both the frame header and payload, when a bad frame is thrown away which is the only one in a sequence, the only way for detecting the missing frame is timeout. With separate CRCs for header and payload, if the header CRC is still good, one can quickly inform the sender about the error. However, for iSCSI, the need for separate CRCs is not so obvious in this context. This is because the TCP header is still valid. Hence, without relying on timeout, one can use on the TCP header to identify the sender. Needless to say, any attempt to use the contents covered by the bad CRC is a cardinal sin for folks in storage industry. Y.P. Cheng, CTO, ConnectCom Solutions Corp. From owner-ips@ece.cmu.edu Fri Feb 2 14:34:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23823 for ; Fri, 2 Feb 2001 14:34:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f12HNHG16200 for ips-outgoing; Fri, 2 Feb 2001 12:23:17 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f12HMpZ16188 for ; Fri, 2 Feb 2001 12:22:51 -0500 (EST) Received: from phys-ha10nwka.ebay.sun.com ([129.150.151.210]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07813 for ; Fri, 2 Feb 2001 09:22:49 -0800 (PST) Received: from ebay.sun.com (d-nwk02-144-195 [129.150.144.195]) by phys-ha10nwka.ebay.sun.com (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id JAA26626 for ; Fri, 2 Feb 2001 09:22:48 -0800 (PST) Message-ID: <3A7AED08.8DEEB65C@ebay.sun.com> Date: Fri, 02 Feb 2001 09:23:20 -0800 From: David Robinson Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI Data Integrity - Digests References: <000001c08d2b$f33327a0$90c809c0@yp_portable.advansys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Y P Cheng wrote: > Mike, if iSCSI is deployed through the use of an adapter which collapses all > three layers, SCSI, iSCSI, and TCP, into a single set of microcode, then, > you got a new implementation of TCP anyway. All those sacrosanct talks that > forbid changes of TCP implementations do not apply to an iSCSI adapter which > at login time will exchange text parameters with each other to deploy new > TCP options. Everything you wanted can be inside an iSCSI adapter. > However, the right place to talk about what you want from TCP is in the > end2end group, not here, as so many people repeatedly pointed out to me. :-) YP, While I understand and can appreciate all the tricks that can be done with a merged stack that avoids the implementation layer, I strongly object to this WG allowing standard options that change the standard TCP wire protocol. Even if both ends agree to do the "special" processing, other nodes and protocols generally share these wires and "special" non-standard options can have nasty indirect effects. If your custom adapter does things that are not changes in the protocol, like always putting an iSCSI request in a single segment which allows the other end to fast-path processing, is an acceptable implementation trick as either end not "knowing" about the trick will function correctly, although maybe not optimally. Any changes to the standard TCP must go through end2end, this WG MUST NOT allow options that circumvent that process. -David From owner-ips@ece.cmu.edu Fri Feb 2 17:03:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01440 for ; Fri, 2 Feb 2001 17:03:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f12JYKG21618 for ips-outgoing; Fri, 2 Feb 2001 14:34:20 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f12JXFZ21580 for ; Fri, 2 Feb 2001 14:33:19 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id 7376A135C for ; Fri, 2 Feb 2001 11:26:20 -0800 (PST) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id LAA17754 for ; Fri, 2 Feb 2001 11:26:11 -0800 (PST) Message-ID: <3A7B0A5A.47909B63@cup.hp.com> Date: Fri, 02 Feb 2001 11:28:27 -0800 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI error recovery References: <000801c08d39$c17b27e0$90c809c0@yp_portable.advansys.com> Content-Type: multipart/mixed; boundary="------------69D6AAD56FE38184889DA736" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------69D6AAD56FE38184889DA736 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit YP, Y P Cheng wrote: > With a single CRC covering both the frame header and payload, when a bad > frame is thrown away which is the only one in a sequence, the only way for > detecting the missing frame is timeout. Not true for a Data PDU. An I/O timeout only occurs when the Status PDU is discarded due to a CRC error [or format error]. Discarding a Data PDU [due to a CRC error or format error] results in I/O underrun, [a terminology used to describe initiator receiving less data than sent by target] and can be detected by a count check . [using a DataSN based count as described by Julian in his last clarification on this issue.] If the Data PDU also contained the Status within, then discarding such a PDU does cause an I/O timeout. Regards, Santosh --------------69D6AAD56FE38184889DA736 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------69D6AAD56FE38184889DA736-- From owner-ips@ece.cmu.edu Fri Feb 2 17:05:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01494 for ; Fri, 2 Feb 2001 17:05:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f12K2La22853 for ips-outgoing; Fri, 2 Feb 2001 15:02:21 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f12K1fZ22827 for ; Fri, 2 Feb 2001 15:01:42 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f12LBf066810; Fri, 2 Feb 2001 13:11:42 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: , Subject: RE: iSCSI error recovery Date: Fri, 2 Feb 2001 12:00:03 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <0F31E5C394DAD311B60C00E029101A07041014D0@corpmx9.isus.emc.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Although further refinement of how the initiator is expected to use or not use StatSN will not modify complexity involved in recovering from a digest error after some undefined timeout of expected status. The initiator is to guess a sequence hole belongs to some pending SCSI tag? It is to decide if it should apply a CmdSN based on this lack of status for a retry? Is this complexity is to allow non-sequential processing of commands irrespective of delivery failures? As you can see, I remain skeptical. With respect to CRC or Checksums, you could also include a finer subdivision than just header and data. To be more explicit about potential options, there could be static and dynamic fields where to assist handshakes being debated, a separate checksum for these handshakes would have advantages. You could then add routing information as yet another field if this information is to be modified by middle tier equipment. And finally, the tag, CDB and related data and associated vectors. So from my perspective here is a breakdown: 1) Dynamic fields regarding handshakes. (Hopefully obsoleting retry scheme.) 2) Routing fields (LUN). 3) Static fields (All else). 4) SCSI Cmnd (attributes), CDB, Data. Where would you wish to see a separation between 1:2, 2:3, or 3:4 or a single Checksum? Doug > There's been a lot of discussion on the list about this > topic, including the proper use of CmdSN and StatSN > to respond to errors including those detected by CRC. > I hesitate to call consensus on any of this discussion > because it's based on a version of the draft (-03) that > is some combination of incomplete, incorrect, and/or > difficult to comprehend in this area. Based on this > and the length/detail of the discussion, I suspect > that many people on the list are not completely aware > of the issues here, and calling consensus when a large > segment of the WG may not understand the issues is > unlikely to be productive. > > The next version of the draft (-04) SHOULD contain a > much better section on error recovery with explanations > and examples that make it significantly easier to > understand. Consensus calls on error recovery will not > be made before it appears. > > Meanwhile, a few comments on ongoing issues: > - If a CRC error occurs, trying to use any data covered > by that CRC is generally not a good idea in the > absence of other measures (e.g., an error-correcting > code covering the field(s) of interest). > - Given some of the CRC discussion, I think the conclusion > in Orlando to have separate header and data CRCs is > NOT the rough consensus of the WG. We need to go > back to a requirements discussion on this rather than > debating exactly where to put the CRCs. Would those > envisioning middleboxes/gateways/etc. that would > benefit from this sort of CRC separation please post > short use cases/descriptions indicating the basic > functionality of the box and which fields it needs > to change (let's do this with reference to the header > layout in -03 rather than subsequent changes)? As > part of the use case/description, please explain > how/why Fibre Channel's single CRC covering both > the frame header and data causes problems/difficulties. > - Mandating the use of IPsec or TLS solely to handle > CRC-level integrity issues is overkill. > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Fri Feb 2 18:19:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04563 for ; Fri, 2 Feb 2001 18:19:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f12KiOK24795 for ips-outgoing; Fri, 2 Feb 2001 15:44:24 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from main.connectcom.net (ns1.advansys.com [204.247.22.3] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f12KhJZ24741 for ; Fri, 2 Feb 2001 15:43:20 -0500 (EST) Received: from yp_portable (anubis.advansys.com [204.247.22.2]) by main.connectcom.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 11CPQDL2; Fri, 2 Feb 2001 12:43:17 -0800 From: "Y P Cheng" To: "David Robinson" , Subject: RE: iSCSI Data Integrity - Digests Date: Fri, 2 Feb 2001 12:41:09 -0800 Message-ID: <000601c08d58$79254ce0$90c809c0@yp_portable.advansys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <3A7AED08.8DEEB65C@ebay.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > While I understand and can appreciate all the tricks that can be done > with a merged stack that avoids the implementation layer, I strongly > object to this WG allowing standard options that change the standard > TCP wire protocol. Even if both ends agree to do the "special" > processing, other nodes and protocols generally share these > wires and "special" non-standard options can have nasty indirect > effects. If your custom adapter does things that are not changes > in the protocol, like always putting an iSCSI request in a > single segment which allows the other end to fast-path processing, is > an acceptable implementation trick as either end not "knowing" about the > trick will function correctly, although maybe not optimally. > Any changes to the standard TCP must go through end2end, this WG MUST > NOT allow options that circumvent that process. > -David David, Each time when I touched this area, I always felt like walking around a snake pit. It is neither my intent to discuss changes of TCP wire protocol in this WG nor my desire to make such changes. I've been always carefully in using the words "TCP implementation." In fact, after reading a lots of RFC's, I have come to the conclusion that there are ways within TCP that would allow iSCSI work well in 10GB/100Ms Network. The slow TCP transport problem is in the existing implementations that do not have all the new TCP options. For example, you can have 16-bit TCP window-size or 32-bit. Using 16-bit window size, there in no way we can keep the 10Gb/100Ms pipe full. But, the use of 32-bit window-size does not change the TCP protocol. Another example, an iSCSI adapter can always send each iSCSI Command PDU in a separate TCP segment. In so doing, URG pointer is perfect for marking message boundary. While the gurus of TCP can quickly point out that it is impossible for URG pointer to mark the SCSI command boundary in the BSD implementation, there is nothing preventing two iSCSI adapters from using URG pointer when they send command PDUs to each other. In fact, whether two iSCSI adapters using URG pointer in their exchanges, IMHO, is even outside the jurisdiction of this WG. Because the use of URG pointer does not violate TCP protocol. It is just that old TCP implementations not able to keep command/status PDUs in separate segments can not benefit from URG pointer. Therefore, while an iSCSI adapter can interoperate with a client running in TCP of BSD 4.3, it should also be able to interoperate with another state-of-art iSCSI adapter which is much more intelligent. The difference in their interoperation will be decided at login with text messages. I think we don't have to limit ourselves to stone age tools if electrical drill is already invented. Please note that I am not asking the invention of new TCP options here. Y.P. From owner-ips@ece.cmu.edu Fri Feb 2 19:24:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06689 for ; Fri, 2 Feb 2001 19:24:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f12M7Mj28086 for ips-outgoing; Fri, 2 Feb 2001 17:07:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from main.connectcom.net (ns1.advansys.com [204.247.22.3] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f12M6OZ28053 for ; Fri, 2 Feb 2001 17:06:24 -0500 (EST) Received: from yp_portable (anubis.advansys.com [204.247.22.2]) by main.connectcom.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 11CPQDP8; Fri, 2 Feb 2001 14:06:21 -0800 From: "Y P Cheng" To: "Santosh Rao" , Subject: RE: iSCSI error recovery Date: Fri, 2 Feb 2001 14:04:09 -0800 Message-ID: <002401c08d64$1137f5e0$90c809c0@yp_portable.advansys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <3A7B0A5A.47909B63@cup.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > With a single CRC covering both the frame header and payload, when a bad > > frame is thrown away which is the only one in a sequence, the > > only way for detecting the missing frame is timeout. > > Not true for a Data PDU. An I/O timeout only occurs when the Status PDU is > discarded due to a CRC error [or format error]. Discarding a Data > PDU [due to a CRC error or format error] results in I/O underrun, > [a terminology used to describe initiator receiving less data than > sent by target] and can be detected by a count check . > [using a DataSN based count as described by Julian in his > last clarification on this issue.] > > If the Data PDU also contained the Status within, then discarding > such a PDU does cause an I/O timeout. > Santosh Lets try a little more specific: 1. Bad command PDU Thrown away by target Initiator Timeout 2. Bad write data Thrown away by target Target Timeout 3. Bad read data Thrown away by initiator Initiator data underrun 4. Bad status PDU Thrown away by initiator Initiator Timeout In case 1, in receiving another command frame, the target detects a missing CmdSN and decides to wait for a while and then asks initiator to resend. In case 2, the target can detect a missing DataSN except the very last one. Case 3 is the specific case you are refrering to. In case 4, in receiving another status frame, the initiator detects a missing StatSN and decides to wait for a while and then asks target to resend. Y.P. From owner-ips@ece.cmu.edu Fri Feb 2 20:32:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08815 for ; Fri, 2 Feb 2001 20:32:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f12N7NG00384 for ips-outgoing; Fri, 2 Feb 2001 18:07:23 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f12N6iZ00359 for ; Fri, 2 Feb 2001 18:06:44 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f130GZ066952; Fri, 2 Feb 2001 16:16:36 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: "Y P Cheng" , "David Robinson" , Subject: RE: iSCSI Data Integrity - Digests Date: Fri, 2 Feb 2001 15:04:57 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000601c08d58$79254ce0$90c809c0@yp_portable.advansys.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > While the gurus of TCP can quickly point out that it is > impossible for URG pointer to mark the SCSI command boundary in the BSD > implementation, there is nothing preventing two iSCSI adapters from using > URG pointer when they send command PDUs to each other. In fact, > whether two > iSCSI adapters using URG pointer in their exchanges, IMHO, is even outside > the jurisdiction of this WG. Because the use of URG pointer does not > violate TCP protocol. It is just that old TCP implementations not able to > keep command/status PDUs in separate segments can not benefit from URG > pointer. I see a spark of life still lives in hopes of redefining the Urgent pointer. A problem you will see is this pointer is only 16 bits. As it is defined to coalesce should new points become defined, it takes a small backlog in the TCP stack to create a pointer that can not reach a point being defined at the API. To use the Urgent pointer as a message marker, this issue has been decided and, in short, your conclusion about the ability to use the urgent pointer in the manner you wish is re-inventing TCP and not to be done. If you wish such non-standard implementations of TCP, it clearly is outside the benefits of this WG. Doug > Therefore, while an iSCSI adapter can interoperate with a client > running in > TCP of BSD 4.3, it should also be able to interoperate with another > state-of-art iSCSI adapter which is much more intelligent. The difference > in their interoperation will be decided at login with text messages. I > think we don't have to limit ourselves to stone age tools if electrical > drill is already invented. Please note that I am not asking the invention > of new TCP options here. > > Y.P. From owner-ips@ece.cmu.edu Fri Feb 2 20:38:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08880 for ; Fri, 2 Feb 2001 20:38:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1307SM02225 for ips-outgoing; Fri, 2 Feb 2001 19:07:28 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from main.connectcom.net (ns1.advansys.com [204.247.22.3] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1306YZ02192 for ; Fri, 2 Feb 2001 19:06:34 -0500 (EST) Received: from yp_portable (anubis.advansys.com [204.247.22.2]) by main.connectcom.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 11CPQDXN; Fri, 2 Feb 2001 16:06:32 -0800 From: "Y P Cheng" To: "Douglas Otis" , "David Robinson" , Subject: RE: iSCSI Data Integrity - Digests Date: Fri, 2 Feb 2001 16:04:06 -0800 Message-ID: <003801c08d74$d3189420$90c809c0@yp_portable.advansys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I see a spark of life still lives in hopes of redefining the > Urgent pointer. A problem you will see is this pointer is only 16 bits. > As it is defined to coalesce should new points become defined, > it takes a small backlog in the TCP stack to create a pointer that > can not reach a point being defined at the API. To use the Urgent > pointer as a message marker, this issue has been > decided and, in short, your conclusion about the ability to use the urgent > pointer in the manner you wish is re-inventing TCP and not to be done. If > you wish such non-standard implementations of TCP, it clearly is > outside the benefits of this WG. > > Doug Hi, Doug: The Charters of this WG prohibits us discussing any change of TCP protocol and I was not talking about changing any TCP protocol. I am quite familiar with the history why urgent pointer wouldn't work as so many TCP gurus were too quickly to point out. This WG does not recommend the use of urgent pointer nor does it endorse the placement of a command/status PDU in a separate TCP segment. However, for microcode that running in my iSCSI interface chip with my TCP acceleration implementation, I can place each command/status PDU in a separate TCP segment without violating the TCP protocol. Similarly, in the manner I understood about TCP if I turn on the urgent pointer when I send the PDU to another iSCSI chip of which I came to know at login, I don't believe I have altered TCP. Some people in this WG might not like what could be done by each iSCSI interface chip designer. However, this method of doing something special in a SCSI device not available by others gives one a unique advantage and is a common practice by the SCSI industry for many years. I will not be surprised that each iSCSI interface chip will have its own bag of tricks to accelerate its performance and still totally confirm the iSCSI specifications. This is how the technology world is. :-) Y.P. From owner-ips@ece.cmu.edu Sun Feb 4 07:02:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07977 for ; Sun, 4 Feb 2001 07:02:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f14APO310078 for ips-outgoing; Sun, 4 Feb 2001 05:25:24 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f14AOb610052 for ; Sun, 4 Feb 2001 05:24:38 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id LAA77560 for ; Sun, 4 Feb 2001 11:24:31 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id LAA81714 for ; Sun, 4 Feb 2001 11:24:31 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569E9.00392C23 ; Sun, 4 Feb 2001 11:24:28 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Sun, 4 Feb 2001 12:19:57 +0200 Subject: RE: ISCSI: Immediate data extending beyond a single PDU Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Barry, I think that the current draft does not allow you to accept immediate but not unsolicited. You can either allow unsolicited (including immediate) or request always R2T. And yes - if the expected length is larger that what you sent as unsolicited (even if the unsolicited was less than the limit) the target is supposed to send R2T (there is only one unsolicited burst per command). The limit for immediate data is implicit - the max-PDU length and is less-then-or-equal the first burst. Your proposal is interesting but I doubt that it is very useful. Unsolicited data help avoid an RTT on writes but require resources to be allocated (that is why a target may not accept them). Immediate data is an "optimized" form of unsolicited data in which the command and data are collapsed to one unit. Nevertheless the immediate data are unsolicited and require resources to be allocated ahead of time. If you have larger amounts to send than what fits into one PDU the "collapse gain" is minimal and does not justify the added complexity of 2 options. Regards, Julo "Barry Reinhold" on 02/02/2001 21:06:29 Please respond to "Barry Reinhold" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: ISCSI: Immediate data extending beyond a single PDU Julian, I agree with the conceptual idea of immediate data, but further refinement is required. As a receiver, if I have allowed immediate data, but not unsolicited data, and I get a write command with an expected data transfer length that is greater then the amount of data in the command PDU, do I send an R2T or not (or from the sender's point of view does he wait for an R2T to complete the data transfer?) The draft is not clear on this, yet it is an externally visible behavior that needs to be defined for interoperability. I believe that what we need here is a refinement of two distinct concepts, that of immediate data and that of unsolicited data. Here is my take at it: 1. Immediate data - Data that is sent within a single iSCSI SCSI command PDU. Immediate data shall be fully contained within a single iSCSI command PDU, and shall be limitted by the negotiated value of ImmediateData. The size of Immediate data is not subject to the limits of FirstBurst. 2. Unsolicited data - Data that may be transfered to a target without an explicit R2T being sent to request its transfer. Unsolicited data is sent in iSCSI SCSI data PDUs in which the target transfer tag is invalid. The maximum amount of unsolicited data is negotiated between the initiator and target through the FirstBurst key. If unsolicited data is supported by the target, upon receipt of a write command, the target shall not send an R2T until an iSCSI Data PDU with the Final bit set has been received. After reception of an iSCSI Data PDU with the Final bit set R2Ts shall be sent by the target to request transmission of any additional data associated with this command. The initiator shall not send any additional unsolicited data for this command. Interaction between Immediate data and Unsolicited data - Immediate data and Unsolicited data are features that may be selected independently of one another. Support of either is optional. Note: Based on the current specification of FirstBurst, support for unsolicited data is not optional. One must select between a range of 1-65536. I think we would want to make this optional and indicate non support for unsolicited data by setting FirstBurst to 0. >-----Original Message----- >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >julian_satran@il.ibm.com >Sent: Friday, February 02, 2001 6:41 AM >To: ips@ece.cmu.edu >Subject: Re: ISCSI: Immediate data extending beyond a single PDU > > > > >Barry, > >There is a misunderstanding: > >You can send EITHER immediate data OR a sequence of unsolicited PDUs. > >Immediate data was conceived for short writes - for which an initiator does >not want to do >two socket operations or 2 HBA operations. > >Larger unsolicited bursts can be sent with a sequence and then we felt that >you won't gain too much by having the first one glued to the command. > > >Julo > >"Barry Reinhold - Lamprey" on 01/02/2001 22:04:28 > >Please respond to "Barry Reinhold - Lamprey" > >To: Julian Satran/Haifa/IBM@IBMIL >cc: "ISCSI" >Subject: ISCSI: Immediate data extending beyond a single PDU > > > > >Julian, > >My understanding of your email in conjunction with the current draft is: > >The initiator may send zero or more immediate data bytes in the CMD PDU, >and >may send additional unsolicited DATA PDUs with further immediate data, with >the >last PDU having the F bit set. The total amount of immediate data to be >limited >by the value negotiated at login. > >There are two issues I have with this: > >First, the target does not know how much immediate data has being sent. >There >is no indication in the CMD frame to indicate that more immediate data is >to >follow (whether or not the CMD frame contains any immediate data). The >initiator is free to send any amount, from zero up to the negotiated value. >Therefore, the target will likely send an R2T to the host at whatever >boundry >it believes is present - which may cause a retransmission of much or all of >the >immediate data. > >Second, the additional unsolicited PDU's do not contain a target >task/transfer >tag. As such, in the mainline processing, you are perhaps forcing the >target >to >look up the Initiator Task Tag in its list of active i/o's. This may exact >a >heavy performance penalty as optimizing this lookup maybe cost-prohibitive. >The >only other scenarios in which the target had to perform this lookup was in >low-occurance error/abort conditions. > >Are there negative implications to keeping immediate data to a single PDU? > >-- Barry > > >julian_satran@il.ibm.com wrote: > >> Barry, >> >> Immediate data is "attached to the command". If your unsolicited data >(the >> so called initial burst) is larger that what you are ready to commit to a >> single PDU you can send several PDUs with the last having the F bit. >After >> that the target can decide that it wants more and send an R2T or send >> status. >> >> You are no supposed to send both immediate and separate PDU. >> >> I admit that the text is bit confusing (in 1.2.5) and there is an error >> also in the appendix. >> 2.7.1 talk about unsolicited data (not immediate) (the context is data >> PDUs). >> >> The new version of 1.2.5 now reads: >> >> Unsolicited data can be sent as part of an iSCSI command PDU >("immediate >> data") or an in separate iSCSI data PDUs. An initiator may send >> unsolicited data either as immediate (up to the negotiated maximum PDU >> size - DataPDULength - disconnect-reconnect mode page) or in a >separate >> PDU sequence (up to the negotiated limit - FirstBurstSize - >> disconnect-reconnect mode page). All subsequent data have to be >> solicited. The maximum size of an individual data PDU or the >> immediate-part of the initial unsolicited burst as well as the initial >> burst size MAY be negotiated at login. >> >> Thanks, >> Julo >> >> "Barry Reinhold - Lamprey" on 29/01/2001 >16:34:30 >> >> Please respond to "Barry Reinhold - Lamprey" >> >> To: Julian Satran/Haifa/IBM@IBMIL >> cc: "Jon Sreekanth" , "James Smart" >> >> Subject: >> >> Issue: >> >> I am unclear on how to respond to an iSCSI SCSI command PDU when there is >> immediate data but not enough to meet the requirements of the IO >operation >> as given in the expected data transfer length field. Should an R2T be >> issued >> or not? >> >> Background: >> >> Clause 2.7.1 in 03 reads: >> >> "2.7.1 F (Final) bit >> >> This bit is 1 for the last PDU of immediate data or the last PDU of a >> sequence answering a R2T." >> >> This suggests that immediate data can extend beyond the iSCSI SCSI CMD >PDU >> (there is no final bit on the command PDU)but the closet thing we have to >a >> definition for immediate data, which is in clause 1.2.5 below, suggests >> that >> immediate data is limitted to the command PDU: >> >> "Outgoing SCSI data (initiator to target - user data or command >> parameters) will be sent as either solicited data or unsolicited >> data. Solicited data are sent in response to Ready To Transfer (R2T) >> PDUs. Unsolicited data can be part of an iSCSI command PDU >> ("immediate data") or an iSCSI data PDU. An initiator may send >> unsolicited data (immediate or in a separate PDU) up to the >> negotiated limit (initial burst size - mode page 02h). All subsequent >> data have to be solicited. The maximum size of an individual data >> PDU or the immediate-part of the initial unsolicited burst MAY be >> negotiated at login (maximum connect size - mode page 02h)." >> >> Unsolicited data is bounded in a number of ways, but most significant to >> this issue is in the description of the login key useR2t which states: >> >> "Note than only the first >> outgoing data item (either immediate data or a separate PDU) can be >> sent unsolicited by a R2T." >> >> Given the above it is unclear to me if the concept of immediate data is: >> >> 1. Write data that can be sent without an R2T (unsolicited write data)and >> starts in the command PDU. >> 2. Write data that is entirely contained within the command PDU. (my >> initial >> concept of immediate data) >> 3. The non-zero portion of data, in a possible multi-PDU write operation, >> that is contained in the iSCSI SCSI command PDU. Where the remaining PDUs >> of >> the write operation must be solicited with an R2T. >> >> Given the current definition of the Final bit and the current limits on >> unsolicited data it is unclear to me what a target should do when >receiving >> an iSCSI SCSI command PDU that has immediate data in it, but not >sufficient >> data to meet the expected data transfer length specificied in the >command. >> Does an R2T go out of not? >> >> Barry Reinhold >> 603-659-0885 > >Barry Reinhold >603-659-0885 > > > > From owner-ips@ece.cmu.edu Sun Feb 4 07:05:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07988 for ; Sun, 4 Feb 2001 07:05:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f149vOt09534 for ips-outgoing; Sun, 4 Feb 2001 04:57:24 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f149v9609528 for ; Sun, 4 Feb 2001 04:57:10 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id KAA33530 for ; Sun, 4 Feb 2001 10:56:59 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay02.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id KAA51944 for ; Sun, 4 Feb 2001 10:56:55 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569E9.00369C79 ; Sun, 4 Feb 2001 10:56:30 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Sun, 4 Feb 2001 11:52:00 +0200 Subject: Re: Section 4.1 (Login Phase) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk wrong. Julo Santosh Rao on 02/02/2001 18:46:20 Please respond to Santosh Rao To: Julian Satran/Haifa/IBM@IBMIL cc: santoshr@hpcuhe.cup.hp.com (Santosh Rao) Subject: Section 4.1 (Login Phase) Julian, The following sentence : "Login reject with Final bit 0 is a format error." needs to be removed from the draft. I believe the Reject PDU is intended to communicate all format errors on any PDU (?) Regards, Santosh -- ################################# Santosh Rao Software Design Engineer, HP, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################# From owner-ips@ece.cmu.edu Sun Feb 4 16:53:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11997 for ; Sun, 4 Feb 2001 16:53:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f14K1Wf23040 for ips-outgoing; Sun, 4 Feb 2001 15:01:32 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f103.law4.hotmail.com [216.33.149.103]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f14K0j623022 for ; Sun, 4 Feb 2001 15:00:45 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 4 Feb 2001 12:00:39 -0800 Received: from 203.124.2.57 by lw4fd.law4.hotmail.msn.com with HTTP; Sun, 04 Feb 2001 20:00:39 GMT X-Originating-IP: [203.124.2.57] From: "Santosh Rao" To: ips@ece.cmu.edu Subject: Re: Section 4.1 (Login Phase) Date: Sun, 04 Feb 2001 20:00:39 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 04 Feb 2001 20:00:39.0584 (UTC) FILETIME=[25996A00:01C08EE5] Sender: owner-ips@ece.cmu.edu Precedence: bulk

Julian,

Are you saying the Reject is NOT meant to be used for all format errors (?)

How then is the following description of Reject PDU (Section 2.19) to be interpreted :

"It may happen that a target receives a message with a format error
   (inconsistent fields, reserved fields not 0, inexistent LUN etc.) or
   a digest error (invalid payload or header). The target returns the
   header of the message in error as the data of the response.
   
2.20 Reason
   
   The reject Reason is coded as follows:
   
      1 - Format Error
      2 - Header Digest Error
      3 - Payload Digest Error ""

Why are 2 mechanisms required to indicate format errors ? The one in Login response (reject with F=0) seems redundant.

- Santosh

>From: julian_satran@il.ibm.com

>To: ips@ece.cmu.edu
>Subject: Re: Section 4.1 (Login Phase)
>Date: Sun, 4 Feb 2001 11:52:00 +0200
>
>
>
>wrong. Julo
>
>Santosh Rao on 02/02/2001 18:46:20
>
>Please respond to Santosh Rao
>
>To: Julian Satran/Haifa/IBM@IBMIL
>cc: santoshr@hpcuhe.cup.hp.com (Santosh Rao)
>Subject: Section 4.1 (Login Phase)
>
>
>
>
>Julian,
>
>The following sentence :
>
>"Login reject with Final bit 0 is a format error."
>
>needs to be removed from the draft. I believe the
>Reject PDU is intended to communicate all format
>errors on any PDU (?)
>
>Regards,
>Santosh
>
>--
>#################################
>Santosh Rao
>Software Design Engineer,
>HP, Cupertino.
>email : santoshr@cup.hp.com
>Phone : 408-447-3751
>#################################
>
>
>

Get your FREE download of MSN Explorer at http://explorer.msn.com

From owner-ips@ece.cmu.edu Sun Feb 4 16:58:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12030 for ; Sun, 4 Feb 2001 16:58:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f14KdWV24131 for ips-outgoing; Sun, 4 Feb 2001 15:39:32 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f79.law4.hotmail.com [216.33.149.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f14Kcf624095 for ; Sun, 4 Feb 2001 15:38:42 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 4 Feb 2001 12:38:36 -0800 Received: from 203.124.2.57 by lw4fd.law4.hotmail.msn.com with HTTP; Sun, 04 Feb 2001 20:38:35 GMT X-Originating-IP: [203.124.2.57] From: "Santosh Rao" To: ips@ece.cmu.edu Subject: iSCSI : Abort Task "connection allegiance" Date: Sun, 04 Feb 2001 20:38:35 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Feb 2001 20:38:36.0036 (UTC) FILETIME=[72786C40:01C08EEA] Sender: owner-ips@ece.cmu.edu Precedence: bulk >To: ips@ece.cmu.edu Subject: iSCSI-related conclusions from Orlando interim >Meeting From: Black_David@emc.com Date: Fri, 19 Jan 2001 19:29:36 -0500 >(2) Error Recovery >- Abort WARNING will be added to the draft. >- Immediate Delivery of Aborts and similar task management commands > may have unexpected results when multiple TCP connections are in use > because Abort, Clear Task Set, etc. may bypass command(s) to be > aborted/cleared on other TCP connections. >- Ordered Delivery should be used instead when this is a concern. ------------------------------------------------------------------- Julian & All, For the above issue, the Abort Task I/O Error Recovery is udertaken when an I/O times out (O.S. specific SCSI ULP timer has expired). Under such circumstances, it is preferrable to have an expedited error recovery which is not hindered by stalls in its processing due to the target waiting for missing CmdSNs. [which are applicable when the Abort Task is sent with a non-0 CmdSN]. In the interests of keeping I/O timeout recovery quick, the "connection allegiance" policy, currently applicable to all phases of a command, should be extended to the Abort Task for that command as well and the Abort Task be sent with a CmdSN of 0. Regards, Santosh _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-ips@ece.cmu.edu Mon Feb 5 02:50:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02108 for ; Mon, 5 Feb 2001 02:50:54 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f155obm09362 for ips-outgoing; Mon, 5 Feb 2001 00:50:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f155o1609326 for ; Mon, 5 Feb 2001 00:50:01 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id GAA70076 for ; Mon, 5 Feb 2001 06:49:54 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id GAA233362 for ; Mon, 5 Feb 2001 06:49:50 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569EA.002006FC ; Mon, 5 Feb 2001 06:49:49 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Mon, 5 Feb 2001 07:45:16 +0200 Subject: Re: Section 4.1 (Login Phase) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, Norton Antivirus reports a virus in your attachment. You may want to send plain text. Julo "Santosh Rao" on 04/02/2001 22:00:39 Please respond to "Santosh Rao" To: ips@ece.cmu.edu cc: Subject: Re: Section 4.1 (Login Phase) - att1.htm From owner-ips@ece.cmu.edu Mon Feb 5 12:23:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12330 for ; Mon, 5 Feb 2001 12:23:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f15FCkd01613 for ips-outgoing; Mon, 5 Feb 2001 10:12:46 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f15FCK601597 for ; Mon, 5 Feb 2001 10:12:20 -0500 (EST) Received: from breinhold ([65.192.191.129]) by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f15FC6K00140; Mon, 5 Feb 2001 10:12:06 -0500 (EST) From: "Barry Reinhold" To: , Subject: RE: ISCSI: Immediate data extending beyond a single PDU Date: Mon, 5 Feb 2001 10:11:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I think one could carry on a debate about what the draft currently states about the coupling of immediate and unsolicited data - but it is probably more productive to figure out if we want to have both the concept of immediate data and unsolicited data and then worry about the wording in the draft. I am of the opinion that immediate data (data within a single PDU) is a useful distincition from unsolicited data (iSCSI DATA PDU sent without R2T). The reasoning behind this is that there are a number of write IOs that can be satisfied by providing a buffer of 8K or less. If this data is contained in the command PDU the context can be created for the command, and then the data just happens to be sitting there with the context to process it. Thus the target can send the iSCSI response PDU without creating any special context or mechansims - should have nice low latency characteristics for small writes. For devices that don't want to use the initiator task tag for establishing context of an iSCSI DATA PDU, immediate data is a nice thing. An iSCSI DATA PDU without a target task tag may not be such a nice thing. Question here - What would you lose if you supported only immediate data? It seems like this meets some of the common application requirements that I am aware of and is friendly to what I think is the more common approach to target processing of DATA PDUs. >-----Original Message----- >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >julian_satran@il.ibm.com >Sent: Sunday, February 04, 2001 5:20 AM >To: ips@ece.cmu.edu >Subject: RE: ISCSI: Immediate data extending beyond a single PDU > > > > >Barry, > >I think that the current draft does not allow you to accept immediate but >not unsolicited. >You can either allow unsolicited (including immediate) or request always >R2T. > >And yes - if the expected length is larger that what you sent as >unsolicited (even if the unsolicited was less than the limit) the target is >supposed to send R2T (there is only one unsolicited burst per command). > >The limit for immediate data is implicit - the max-PDU length and is >less-then-or-equal the first burst. > >Your proposal is interesting but I doubt that it is very useful. > >Unsolicited data help avoid an RTT on writes but require resources to be >allocated (that is why a target may not accept them). > >Immediate data is an "optimized" form of unsolicited data in which the >command and data are collapsed to one unit. Nevertheless the immediate data >are unsolicited and require resources to be allocated ahead of time. If you >have larger amounts to send than what fits into one PDU the "collapse gain" >is minimal and does not justify the added complexity of 2 options. > >Regards, >Julo > > > >"Barry Reinhold" on 02/02/2001 21:06:29 > >Please respond to "Barry Reinhold" > >To: Julian Satran/Haifa/IBM@IBMIL >cc: >Subject: RE: ISCSI: Immediate data extending beyond a single PDU > > > > >Julian, > I agree with the conceptual idea of immediate data, but further >refinement >is required. As a receiver, if I have allowed immediate data, but not >unsolicited data, and I get a write command with an expected data transfer >length that is greater then the amount of data in the command PDU, do I >send >an R2T or not (or from the sender's point of view does he wait for an R2T >to >complete the data transfer?) The draft is not clear on this, yet it is an >externally visible behavior that needs to be defined for interoperability. > >I believe that what we need here is a refinement of two distinct concepts, >that of immediate data and that of unsolicited data. Here is my take at it: > >1. Immediate data - Data that is sent within a single iSCSI SCSI command >PDU. Immediate data shall be fully contained within a single iSCSI command >PDU, and shall be limitted by the negotiated value of ImmediateData. The >size of Immediate data is not subject to the limits of FirstBurst. > >2. Unsolicited data - Data that may be transfered to a target without an >explicit R2T being sent to request its transfer. Unsolicited data is sent >in >iSCSI SCSI data PDUs in which the target transfer tag is invalid. The >maximum amount of unsolicited data is negotiated between the initiator and >target through the FirstBurst key. If unsolicited data is supported by the >target, upon receipt of a write command, the target shall not send an R2T >until an iSCSI Data PDU with the Final bit set has been received. After >reception of an iSCSI Data PDU with the Final bit set R2Ts shall be sent by >the target to request transmission of any additional data associated with >this command. The initiator shall not send any additional unsolicited data >for this command. > >Interaction between Immediate data and Unsolicited data - > >Immediate data and Unsolicited data are features that may be selected >independently of one another. Support of either is optional. > >Note: Based on the current specification of FirstBurst, support for >unsolicited data is not optional. One must select between a range of >1-65536. I think we would want to make this optional and indicate non >support for unsolicited data by setting FirstBurst to 0. > > >>-----Original Message----- >>From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >>julian_satran@il.ibm.com >>Sent: Friday, February 02, 2001 6:41 AM >>To: ips@ece.cmu.edu >>Subject: Re: ISCSI: Immediate data extending beyond a single PDU >> >> >> >> >>Barry, >> >>There is a misunderstanding: >> >>You can send EITHER immediate data OR a sequence of unsolicited PDUs. >> >>Immediate data was conceived for short writes - for which an initiator >does >>not want to do >>two socket operations or 2 HBA operations. >> >>Larger unsolicited bursts can be sent with a sequence and then we felt >that >>you won't gain too much by having the first one glued to the command. >> >> >>Julo >> >>"Barry Reinhold - Lamprey" on 01/02/2001 >22:04:28 >> >>Please respond to "Barry Reinhold - Lamprey" >> >>To: Julian Satran/Haifa/IBM@IBMIL >>cc: "ISCSI" >>Subject: ISCSI: Immediate data extending beyond a single PDU >> >> >> >> >>Julian, >> >>My understanding of your email in conjunction with the current draft is: >> >>The initiator may send zero or more immediate data bytes in the CMD PDU, >>and >>may send additional unsolicited DATA PDUs with further immediate data, >with >>the >>last PDU having the F bit set. The total amount of immediate data to be >>limited >>by the value negotiated at login. >> >>There are two issues I have with this: >> >>First, the target does not know how much immediate data has being sent. >>There >>is no indication in the CMD frame to indicate that more immediate data is >>to >>follow (whether or not the CMD frame contains any immediate data). The >>initiator is free to send any amount, from zero up to the negotiated >value. >>Therefore, the target will likely send an R2T to the host at whatever >>boundry >>it believes is present - which may cause a retransmission of much or all >of >>the >>immediate data. >> >>Second, the additional unsolicited PDU's do not contain a target >>task/transfer >>tag. As such, in the mainline processing, you are perhaps forcing the >>target >>to >>look up the Initiator Task Tag in its list of active i/o's. This may exact >>a >>heavy performance penalty as optimizing this lookup maybe >cost-prohibitive. >>The >>only other scenarios in which the target had to perform this lookup was in >>low-occurance error/abort conditions. >> >>Are there negative implications to keeping immediate data to a single PDU? >> >>-- Barry >> >> >>julian_satran@il.ibm.com wrote: >> >>> Barry, >>> >>> Immediate data is "attached to the command". If your unsolicited data >>(the >>> so called initial burst) is larger that what you are ready to commit to >a >>> single PDU you can send several PDUs with the last having the F bit. >>After >>> that the target can decide that it wants more and send an R2T or send >>> status. >>> >>> You are no supposed to send both immediate and separate PDU. >>> >>> I admit that the text is bit confusing (in 1.2.5) and there is an error >>> also in the appendix. >>> 2.7.1 talk about unsolicited data (not immediate) (the context is data >>> PDUs). >>> >>> The new version of 1.2.5 now reads: >>> >>> Unsolicited data can be sent as part of an iSCSI command PDU >>("immediate >>> data") or an in separate iSCSI data PDUs. An initiator may send >>> unsolicited data either as immediate (up to the negotiated maximum >PDU >>> size - DataPDULength - disconnect-reconnect mode page) or in a >>separate >>> PDU sequence (up to the negotiated limit - FirstBurstSize - >>> disconnect-reconnect mode page). All subsequent data have to be >>> solicited. The maximum size of an individual data PDU or the >>> immediate-part of the initial unsolicited burst as well as the >initial >>> burst size MAY be negotiated at login. >>> >>> Thanks, >>> Julo >>> >>> "Barry Reinhold - Lamprey" on 29/01/2001 >>16:34:30 >>> >>> Please respond to "Barry Reinhold - Lamprey" >>> >>> To: Julian Satran/Haifa/IBM@IBMIL >>> cc: "Jon Sreekanth" , "James Smart" >>> >>> Subject: >>> >>> Issue: >>> >>> I am unclear on how to respond to an iSCSI SCSI command PDU when there >is >>> immediate data but not enough to meet the requirements of the IO >>operation >>> as given in the expected data transfer length field. Should an R2T be >>> issued >>> or not? >>> >>> Background: >>> >>> Clause 2.7.1 in 03 reads: >>> >>> "2.7.1 F (Final) bit >>> >>> This bit is 1 for the last PDU of immediate data or the last PDU of a >>> sequence answering a R2T." >>> >>> This suggests that immediate data can extend beyond the iSCSI SCSI CMD >>PDU >>> (there is no final bit on the command PDU)but the closet thing we have >to >>a >>> definition for immediate data, which is in clause 1.2.5 below, suggests >>> that >>> immediate data is limitted to the command PDU: >>> >>> "Outgoing SCSI data (initiator to target - user data or command >>> parameters) will be sent as either solicited data or unsolicited >>> data. Solicited data are sent in response to Ready To Transfer (R2T) >>> PDUs. Unsolicited data can be part of an iSCSI command PDU >>> ("immediate data") or an iSCSI data PDU. An initiator may send >>> unsolicited data (immediate or in a separate PDU) up to the >>> negotiated limit (initial burst size - mode page 02h). All subsequent >>> data have to be solicited. The maximum size of an individual data >>> PDU or the immediate-part of the initial unsolicited burst MAY be >>> negotiated at login (maximum connect size - mode page 02h)." >>> >>> Unsolicited data is bounded in a number of ways, but most significant to >>> this issue is in the description of the login key useR2t which states: >>> >>> "Note than only the first >>> outgoing data item (either immediate data or a separate PDU) can be >>> sent unsolicited by a R2T." >>> >>> Given the above it is unclear to me if the concept of immediate data is: >>> >>> 1. Write data that can be sent without an R2T (unsolicited write >data)and >>> starts in the command PDU. >>> 2. Write data that is entirely contained within the command PDU. (my >>> initial >>> concept of immediate data) >>> 3. The non-zero portion of data, in a possible multi-PDU write >operation, >>> that is contained in the iSCSI SCSI command PDU. Where the remaining >PDUs >>> of >>> the write operation must be solicited with an R2T. >>> >>> Given the current definition of the Final bit and the current limits on >>> unsolicited data it is unclear to me what a target should do when >>receiving >>> an iSCSI SCSI command PDU that has immediate data in it, but not >>sufficient >>> data to meet the expected data transfer length specificied in the >>command. >>> Does an R2T go out of not? >>> >>> Barry Reinhold >>> 603-659-0885 >> >>Barry Reinhold >>603-659-0885 >> >> >> >> > > > > From owner-ips@ece.cmu.edu Mon Feb 5 14:40:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15666 for ; Mon, 5 Feb 2001 14:40:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f15HMxY07232 for ips-outgoing; Mon, 5 Feb 2001 12:22:59 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f15HJi607067 for ; Mon, 5 Feb 2001 12:19:44 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id SAA59890 for ; Mon, 5 Feb 2001 18:19:35 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay02.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id SAA76960 for ; Mon, 5 Feb 2001 18:19:33 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569EA.005F2869 ; Mon, 5 Feb 2001 18:19:22 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Mon, 5 Feb 2001 18:50:17 +0200 Subject: RE: ISCSI: Immediate data extending beyond a single PDU Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Barry, You are suggesting support of immediate data as separate from the support for unsolicited data as a target option? That could be accomodated by stating that support for immediate data is not implied by R2T NO. If there are no strong objections on the list I am ready to remove/correct the offending statement in the appendix. However we will maintain only one initial burst per command (either immediate or in several separate PDUs). Regards, Julo "Barry Reinhold" on 05/02/2001 17:11:36 Please respond to "Barry Reinhold" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: ISCSI: Immediate data extending beyond a single PDU Julian, I think one could carry on a debate about what the draft currently states about the coupling of immediate and unsolicited data - but it is probably more productive to figure out if we want to have both the concept of immediate data and unsolicited data and then worry about the wording in the draft. I am of the opinion that immediate data (data within a single PDU) is a useful distincition from unsolicited data (iSCSI DATA PDU sent without R2T). The reasoning behind this is that there are a number of write IOs that can be satisfied by providing a buffer of 8K or less. If this data is contained in the command PDU the context can be created for the command, and then the data just happens to be sitting there with the context to process it. Thus the target can send the iSCSI response PDU without creating any special context or mechansims - should have nice low latency characteristics for small writes. For devices that don't want to use the initiator task tag for establishing context of an iSCSI DATA PDU, immediate data is a nice thing. An iSCSI DATA PDU without a target task tag may not be such a nice thing. Question here - What would you lose if you supported only immediate data? It seems like this meets some of the common application requirements that I am aware of and is friendly to what I think is the more common approach to target processing of DATA PDUs. >-----Original Message----- >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >julian_satran@il.ibm.com >Sent: Sunday, February 04, 2001 5:20 AM >To: ips@ece.cmu.edu >Subject: RE: ISCSI: Immediate data extending beyond a single PDU > > > > >Barry, > >I think that the current draft does not allow you to accept immediate but >not unsolicited. >You can either allow unsolicited (including immediate) or request always >R2T. > >And yes - if the expected length is larger that what you sent as >unsolicited (even if the unsolicited was less than the limit) the target is >supposed to send R2T (there is only one unsolicited burst per command). > >The limit for immediate data is implicit - the max-PDU length and is >less-then-or-equal the first burst. > >Your proposal is interesting but I doubt that it is very useful. > >Unsolicited data help avoid an RTT on writes but require resources to be >allocated (that is why a target may not accept them). > >Immediate data is an "optimized" form of unsolicited data in which the >command and data are collapsed to one unit. Nevertheless the immediate data >are unsolicited and require resources to be allocated ahead of time. If you >have larger amounts to send than what fits into one PDU the "collapse gain" >is minimal and does not justify the added complexity of 2 options. > >Regards, >Julo > > > >"Barry Reinhold" on 02/02/2001 21:06:29 > >Please respond to "Barry Reinhold" > >To: Julian Satran/Haifa/IBM@IBMIL >cc: >Subject: RE: ISCSI: Immediate data extending beyond a single PDU > > > > >Julian, > I agree with the conceptual idea of immediate data, but further >refinement >is required. As a receiver, if I have allowed immediate data, but not >unsolicited data, and I get a write command with an expected data transfer >length that is greater then the amount of data in the command PDU, do I >send >an R2T or not (or from the sender's point of view does he wait for an R2T >to >complete the data transfer?) The draft is not clear on this, yet it is an >externally visible behavior that needs to be defined for interoperability. > >I believe that what we need here is a refinement of two distinct concepts, >that of immediate data and that of unsolicited data. Here is my take at it: > >1. Immediate data - Data that is sent within a single iSCSI SCSI command >PDU. Immediate data shall be fully contained within a single iSCSI command >PDU, and shall be limitted by the negotiated value of ImmediateData. The >size of Immediate data is not subject to the limits of FirstBurst. > >2. Unsolicited data - Data that may be transfered to a target without an >explicit R2T being sent to request its transfer. Unsolicited data is sent >in >iSCSI SCSI data PDUs in which the target transfer tag is invalid. The >maximum amount of unsolicited data is negotiated between the initiator and >target through the FirstBurst key. If unsolicited data is supported by the >target, upon receipt of a write command, the target shall not send an R2T >until an iSCSI Data PDU with the Final bit set has been received. After >reception of an iSCSI Data PDU with the Final bit set R2Ts shall be sent by >the target to request transmission of any additional data associated with >this command. The initiator shall not send any additional unsolicited data >for this command. > >Interaction between Immediate data and Unsolicited data - > >Immediate data and Unsolicited data are features that may be selected >independently of one another. Support of either is optional. > >Note: Based on the current specification of FirstBurst, support for >unsolicited data is not optional. One must select between a range of >1-65536. I think we would want to make this optional and indicate non >support for unsolicited data by setting FirstBurst to 0. > > >>-----Original Message----- >>From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >>julian_satran@il.ibm.com >>Sent: Friday, February 02, 2001 6:41 AM >>To: ips@ece.cmu.edu >>Subject: Re: ISCSI: Immediate data extending beyond a single PDU >> >> >> >> >>Barry, >> >>There is a misunderstanding: >> >>You can send EITHER immediate data OR a sequence of unsolicited PDUs. >> >>Immediate data was conceived for short writes - for which an initiator >does >>not want to do >>two socket operations or 2 HBA operations. >> >>Larger unsolicited bursts can be sent with a sequence and then we felt >that >>you won't gain too much by having the first one glued to the command. >> >> >>Julo >> >>"Barry Reinhold - Lamprey" on 01/02/2001 >22:04:28 >> >>Please respond to "Barry Reinhold - Lamprey" >> >>To: Julian Satran/Haifa/IBM@IBMIL >>cc: "ISCSI" >>Subject: ISCSI: Immediate data extending beyond a single PDU >> >> >> >> >>Julian, >> >>My understanding of your email in conjunction with the current draft is: >> >>The initiator may send zero or more immediate data bytes in the CMD PDU, >>and >>may send additional unsolicited DATA PDUs with further immediate data, >with >>the >>last PDU having the F bit set. The total amount of immediate data to be >>limited >>by the value negotiated at login. >> >>There are two issues I have with this: >> >>First, the target does not know how much immediate data has being sent. >>There >>is no indication in the CMD frame to indicate that more immediate data is >>to >>follow (whether or not the CMD frame contains any immediate data). The >>initiator is free to send any amount, from zero up to the negotiated >value. >>Therefore, the target will likely send an R2T to the host at whatever >>boundry >>it believes is present - which may cause a retransmission of much or all >of >>the >>immediate data. >> >>Second, the additional unsolicited PDU's do not contain a target >>task/transfer >>tag. As such, in the mainline processing, you are perhaps forcing the >>target >>to >>look up the Initiator Task Tag in its list of active i/o's. This may exact >>a >>heavy performance penalty as optimizing this lookup maybe >cost-prohibitive. >>The >>only other scenarios in which the target had to perform this lookup was in >>low-occurance error/abort conditions. >> >>Are there negative implications to keeping immediate data to a single PDU? >> >>-- Barry >> >> >>julian_satran@il.ibm.com wrote: >> >>> Barry, >>> >>> Immediate data is "attached to the command". If your unsolicited data >>(the >>> so called initial burst) is larger that what you are ready to commit to >a >>> single PDU you can send several PDUs with the last having the F bit. >>After >>> that the target can decide that it wants more and send an R2T or send >>> status. >>> >>> You are no supposed to send both immediate and separate PDU. >>> >>> I admit that the text is bit confusing (in 1.2.5) and there is an error >>> also in the appendix. >>> 2.7.1 talk about unsolicited data (not immediate) (the context is data >>> PDUs). >>> >>> The new version of 1.2.5 now reads: >>> >>> Unsolicited data can be sent as part of an iSCSI command PDU >>("immediate >>> data") or an in separate iSCSI data PDUs. An initiator may send >>> unsolicited data either as immediate (up to the negotiated maximum >PDU >>> size - DataPDULength - disconnect-reconnect mode page) or in a >>separate >>> PDU sequence (up to the negotiated limit - FirstBurstSize - >>> disconnect-reconnect mode page). All subsequent data have to be >>> solicited. The maximum size of an individual data PDU or the >>> immediate-part of the initial unsolicited burst as well as the >initial >>> burst size MAY be negotiated at login. >>> >>> Thanks, >>> Julo >>> >>> "Barry Reinhold - Lamprey" on 29/01/2001 >>16:34:30 >>> >>> Please respond to "Barry Reinhold - Lamprey" >>> >>> To: Julian Satran/Haifa/IBM@IBMIL >>> cc: "Jon Sreekanth" , "James Smart" >>> >>> Subject: >>> >>> Issue: >>> >>> I am unclear on how to respond to an iSCSI SCSI command PDU when there >is >>> immediate data but not enough to meet the requirements of the IO >>operation >>> as given in the expected data transfer length field. Should an R2T be >>> issued >>> or not? >>> >>> Background: >>> >>> Clause 2.7.1 in 03 reads: >>> >>> "2.7.1 F (Final) bit >>> >>> This bit is 1 for the last PDU of immediate data or the last PDU of a >>> sequence answering a R2T." >>> >>> This suggests that immediate data can extend beyond the iSCSI SCSI CMD >>PDU >>> (there is no final bit on the command PDU)but the closet thing we have >to >>a >>> definition for immediate data, which is in clause 1.2.5 below, suggests >>> that >>> immediate data is limitted to the command PDU: >>> >>> "Outgoing SCSI data (initiator to target - user data or command >>> parameters) will be sent as either solicited data or unsolicited >>> data. Solicited data are sent in response to Ready To Transfer (R2T) >>> PDUs. Unsolicited data can be part of an iSCSI command PDU >>> ("immediate data") or an iSCSI data PDU. An initiator may send >>> unsolicited data (immediate or in a separate PDU) up to the >>> negotiated limit (initial burst size - mode page 02h). All subsequent >>> data have to be solicited. The maximum size of an individual data >>> PDU or the immediate-part of the initial unsolicited burst MAY be >>> negotiated at login (maximum connect size - mode page 02h)." >>> >>> Unsolicited data is bounded in a number of ways, but most significant to >>> this issue is in the description of the login key useR2t which states: >>> >>> "Note than only the first >>> outgoing data item (either immediate data or a separate PDU) can be >>> sent unsolicited by a R2T." >>> >>> Given the above it is unclear to me if the concept of immediate data is: >>> >>> 1. Write data that can be sent without an R2T (unsolicited write >data)and >>> starts in the command PDU. >>> 2. Write data that is entirely contained within the command PDU. (my >>> initial >>> concept of immediate data) >>> 3. The non-zero portion of data, in a possible multi-PDU write >operation, >>> that is contained in the iSCSI SCSI command PDU. Where the remaining >PDUs >>> of >>> the write operation must be solicited with an R2T. >>> >>> Given the current definition of the Final bit and the current limits on >>> unsolicited data it is unclear to me what a target should do when >>receiving >>> an iSCSI SCSI command PDU that has immediate data in it, but not >>sufficient >>> data to meet the expected data transfer length specificied in the >>command. >>> Does an R2T go out of not? >>> >>> Barry Reinhold >>> 603-659-0885 >> >>Barry Reinhold >>603-659-0885 >> >> >> >> > > > > From owner-ips@ece.cmu.edu Mon Feb 5 14:41:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15727 for ; Mon, 5 Feb 2001 14:41:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f15Hbnx07902 for ips-outgoing; Mon, 5 Feb 2001 12:37:49 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from main.connectcom.net ([204.247.22.3]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f15Hba607890 for ; Mon, 5 Feb 2001 12:37:36 -0500 (EST) Received: from yp_portable (anubis.advansys.com [204.247.22.2]) by main.connectcom.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 11CPQF1Q; Mon, 5 Feb 2001 09:36:05 -0800 From: "Y P Cheng" To: , "Santosh Rao" Cc: "Julian_Satran@Il. Ibm. Com" Subject: RE: iSCSI : Abort Task "connection allegiance" Date: Mon, 5 Feb 2001 09:33:55 -0800 Message-ID: <000101c08f99$d084b460$90c809c0@yp_portable.advansys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh wrote: > For the above issue, the Abort Task I/O Error Recovery is udertaken > when an I/O times out (O.S. specific SCSI ULP timer has expired). Under > such circumstances, it is preferrable to have an expedited error > recovery which is not hindered by stalls in its processing due to the > target waiting for missing CmdSNs. > [which are applicable when the Abort Task is sent with a non-0 CmdSN]. There are two reasons for issuing abort: 1) application software exits and OS needs cleaning up, and 2) a request times out and it needs clean restart. In either cases, we don't want the abort arrives there before the one to be aborted. Hence, using zero CmdSN is unwise. If the abort gets there first, the target will complete the abort quickly and later executes the one to be aborted anyway. > In the interests of keeping I/O timeout recovery quick, the > "connection allegiance" policy, currently applicable to all phases of a > command, should be extended to the Abort Task for that command as well > and the Abort Task be sent with a CmdSN of 0. I don't follow this logic at all. Are you trying to say that if the target gets an abort, it should enter connection allegiance until the one to be aborted arrives? This would real make a mess on the target microcode. How do we even know the aborted request would arrive? IMHO, abort should never have a zero CmdSN. Y.P. From owner-ips@ece.cmu.edu Mon Feb 5 16:31:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18138 for ; Mon, 5 Feb 2001 16:31:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f15JKvr15292 for ips-outgoing; Mon, 5 Feb 2001 14:20:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f15JJm615226 for ; Mon, 5 Feb 2001 14:19:48 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f15KTe073245; Mon, 5 Feb 2001 12:29:40 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: "Y P Cheng" , "David Robinson" , Subject: RE: iSCSI Data Integrity - Digests Date: Mon, 5 Feb 2001 11:18:09 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <003801c08d74$d3189420$90c809c0@yp_portable.advansys.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Hi, Doug: > > The Charters of this WG prohibits us discussing any change of TCP protocol > and I was not talking about changing any TCP protocol. I am > quite familiar > with the history why urgent pointer wouldn't work as so many TCP > gurus were > too quickly to point out. This WG does not recommend the use of urgent > pointer nor does it endorse the placement of a command/status PDU in a > separate TCP segment. > > However, for microcode that running in my iSCSI interface chip with my TCP > acceleration implementation, I can place each command/status PDU in a > separate TCP segment without violating the TCP protocol. > Similarly, in the > manner I understood about TCP if I turn on the urgent pointer when I send > the PDU to another iSCSI chip of which I came to know at login, I don't > believe I have altered TCP. Y.P. You are free to add non-standard TCP and perhaps both server and client may implement the same level of alteration. Change aggressiveness of the TCP congestion algorithm, force framing, implement non-standard definitions of urgent pointers, add special flags, and seldom seen options. View TCP as important in name only or wire only. An alternative to chaos generated by multitudes of such clever creations would be adoption of SCTP to provide options already found within this standard. iSCSI is a good example why transports are not easily developed. If to allow fail-over with iSCSI, even StatSN should be unique across all connections and a strict monotonic sequence should be mandated for both CmdSN or StatSN within every PDU (rename to ClientSN and ServerSN.) Better yet, adopt the SCTP structures within TCP (replace the SCTP ports with a pseudo-frame length and allow padding to fixed intervals for frame recovery.) I fail to see how either client or server knows the state of the other and how to prevent a cascade, and what benefit is derived by the complex process of rediscovery of discarded relationships. Doug > Some people in this WG might not like what could be done by each iSCSI > interface chip designer. However, this method of doing something > special in > a SCSI device not available by others gives one a unique > advantage and is a > common practice by the SCSI industry for many years. I will not be > surprised that each iSCSI interface chip will have its own bag of > tricks to > accelerate its performance and still totally confirm the iSCSI > specifications. This is how the technology world is. :-) > > Y.P. > > From owner-ips@ece.cmu.edu Mon Feb 5 17:56:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19968 for ; Mon, 5 Feb 2001 17:56:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f15LVoo21391 for ips-outgoing; Mon, 5 Feb 2001 16:31:50 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from main.connectcom.net (ns1.advansys.com [204.247.22.3] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f15LVe621378 for ; Mon, 5 Feb 2001 16:31:41 -0500 (EST) Received: from yp_portable (anubis.advansys.com [204.247.22.2]) by main.connectcom.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 11CPQFRW; Mon, 5 Feb 2001 13:31:38 -0800 From: "Y P Cheng" To: "Douglas Otis" , "David Robinson" , Subject: RE: iSCSI Data Integrity - Digests Date: Mon, 5 Feb 2001 13:29:25 -0800 Message-ID: <001701c08fba$b6cc3860$90c809c0@yp_portable.advansys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > You are free to add non-standard TCP and perhaps both server and > client may > implement the same level of alteration. Change aggressiveness of the TCP > congestion algorithm, force framing, implement non-standard definitions of > urgent pointers, add special flags, and seldom seen options. View TCP as > important in name only or wire only. An alternative to chaos generated by > multitudes of such clever creations would be adoption of SCTP to provide > options already found within this standard. Doug, May be I am mistaken, but I don't think what I am suggesting is doing non-standard TCP. What is a non-standard TCP if I follow all the RFCs approved by IETF? What I think you are referring to the non-standard implementation, i.e., not working working with existing TCP stacks. The urgent pointer, 32-bit TCP window, one segment per PDU, even with the addition of SACK are all part of "standard" TCP, just not every TCP implementations are supporting them. This is why option negotiation comes in. I hope I am not mistaken. Y.P. From owner-ips@ece.cmu.edu Mon Feb 5 17:56:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19983 for ; Mon, 5 Feb 2001 17:56:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f15Krn919650 for ips-outgoing; Mon, 5 Feb 2001 15:53:49 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [168.159.208.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f15Krg619640 for ; Mon, 5 Feb 2001 15:53:42 -0500 (EST) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2650.21) id <1DCB9JPA>; Mon, 5 Feb 2001 15:53:33 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A07041014E4@corpmx9.isus.emc.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Security Use Requirements Date: Mon, 5 Feb 2001 15:53:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk In Orlando, I picked up an action item to determine what the requirements are for *use* of security features, as opposed to requirements for *implementation*. I believe the answer to be that it is acceptable to specify security measures weaker than those one would want to use in full generality on a public network, where "weaker" includes no security. There are two important caveats that apply: - Security of the negotiation mechanism becomes very important when this is done, as there's an obvious man-in-the-middle attack on the negotiation mechanism to get the endpoints to negotiate weaker security than they intended. - The weaker security mechanisms need to be documented in terms of their security properties (and lack thereof), as well as environments in which they are appropriate. The "Security Considerations" section of RFC 2338 (VRRP) has been recommended as a good example of this. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Feb 5 20:49:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21912 for ; Mon, 5 Feb 2001 20:49:03 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f15NQu826276 for ips-outgoing; Mon, 5 Feb 2001 18:26:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gate.internaut.com ([64.38.134.108]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f15NQA626243 for ; Mon, 5 Feb 2001 18:26:11 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f15NKJR12957; Mon, 5 Feb 2001 15:20:23 -0800 From: "Bernard Aboba" To: , Cc: "RJ Atkinson" , "Smb@Research. Att. Com" Subject: RE: Security Use Requirements Date: Mon, 5 Feb 2001 15:26:13 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <0F31E5C394DAD311B60C00E029101A07041014E4@corpmx9.isus.emc.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit It is hard for me to see how you could get away with no security services at all (e.g. no per-packet authentication and integrity protection for iSCSI PDUs). After all, we're talking about facilities that are used by the world's major financial institutions. If this data isn't worth protecting, I don't know what is. Do you really want attackers to be able to manipulate the contents of bank accounts at will over the Internet? Furthermore, there really isn't a sound technical argument for dispensing with security. There are chipsets available that can provide IPSEC integrity and authentication services at speeds of 1 Gbps or higher. -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Black_David@emc.com Sent: Monday, February 05, 2001 12:54 PM To: ips@ece.cmu.edu Subject: Security Use Requirements In Orlando, I picked up an action item to determine what the requirements are for *use* of security features, as opposed to requirements for *implementation*. I believe the answer to be that it is acceptable to specify security measures weaker than those one would want to use in full generality on a public network, where "weaker" includes no security. There are two important caveats that apply: - Security of the negotiation mechanism becomes very important when this is done, as there's an obvious man-in-the-middle attack on the negotiation mechanism to get the endpoints to negotiate weaker security than they intended. - The weaker security mechanisms need to be documented in terms of their security properties (and lack thereof), as well as environments in which they are appropriate. The "Security Considerations" section of RFC 2338 (VRRP) has been recommended as a good example of this. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Feb 5 21:46:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23468 for ; Mon, 5 Feb 2001 21:46:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f160jqe29073 for ips-outgoing; Mon, 5 Feb 2001 19:45:52 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f160jB629026 for ; Mon, 5 Feb 2001 19:45:12 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f161t2073475; Mon, 5 Feb 2001 17:55:02 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: "Y P Cheng" , "David Robinson" , Subject: RE: iSCSI Data Integrity - Digests Date: Mon, 5 Feb 2001 16:43:31 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <001701c08fba$b6cc3860$90c809c0@yp_portable.advansys.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Y.P. Forcing frame alignment does little to assist iSCSI if mid-tier equipment removes such framing despite option negotiation. The urgent pointer has a defined behavior within RFC documentation such that to define it as a record boundary is not in keeping with standards. To implement and use an urgent pointer as a record boundary pointer clearly modifies the TCP standard. Requiring modification of all compliant TCP implementations is modifying the standard. There are already several TCP negotiated options such as SACK and no one suggested disallowing use of existing standard options. The urgent pointer as a record boundary marker, as several people have indicated, is not part of the standard, can not be done reliably with existing implementations, and clearly places this concept into the non-standard category. PDU discovery can be done in a number of ways. If the SCTP structures were adopted, then a pseudo-frame could be declared to start at fixed intervals within the TCP byte stream. This could be done without modifying any TCP implementations and as every device could support this mechanism, it could be done in a uniform way. The SCTP structures allow encapsulation of larger structures and could comply with this interval and define handshakes and retries independent of TCP. This becomes required with added digest errors that would need handling above TCP and hopefully below SCSI. I understand the desire to use reserved bits and tweak behavior but with such a sizeable install base, such desires only appear deceivingly simple to realize. The NET-SCSI standard should be independent of the underlying transport. There should be a transport layer added to TCP to provide all needed features demanded by SAN. SCTP does a good job in defining these modern transport requirements and an additional layer could be added to TCP to provide a transport compliant to both SCTP using TCP. In doing so, there would be virtually no difference between the two transports and there would be little doubt about eventual migration. Doug > Doug, > > May be I am mistaken, but I don't think what I am suggesting is doing > non-standard TCP. What is a non-standard TCP if I follow all the RFCs > approved by IETF? What I think you are referring to the non-standard > implementation, i.e., not working working with existing TCP stacks. > > The urgent pointer, 32-bit TCP window, one segment per PDU, even with the > addition of SACK are all part of "standard" TCP, just not every TCP > implementations are supporting them. This is why option negotiation comes > in. I hope I am not mistaken. > > Y.P. > > From owner-ips@ece.cmu.edu Mon Feb 5 21:46:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23469 for ; Mon, 5 Feb 2001 21:46:25 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f161Iqt00379 for ips-outgoing; Mon, 5 Feb 2001 20:18:52 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from main.connectcom.net (ns1.advansys.com [204.247.22.3] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f161IP600362 for ; Mon, 5 Feb 2001 20:18:25 -0500 (EST) Received: from yp_portable (anubis.advansys.com [204.247.22.2]) by main.connectcom.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 11CPQF7Y; Mon, 5 Feb 2001 17:18:23 -0800 From: "Y P Cheng" To: "Douglas Otis" , "David Robinson" , Subject: RE: iSCSI Data Integrity - Digests Date: Mon, 5 Feb 2001 17:16:04 -0800 Message-ID: <003d01c08fda$5ff1d2a0$90c809c0@yp_portable.advansys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Forcing frame alignment does little to assist iSCSI if mid-tier equipment > removes such framing despite option negotiation. I am not aware of any mid-tier box being TCP-aware and repackaging TCP segments. If so, it must also involve in different TCP options including SACK and 32-bit window, not to mention changing the TCP header and recalculating checksum. > The urgent pointer has a defined behavior within RFC documentation > such that to define it as a record boundary is not in keeping > with standards. To implement and use an urgent pointer as a record > boundary pointer clearly modifies the TCP standard. Very interesting argument. Urgent pointer is meant to be a inband signal that can be used for any particular purpose a user has in mind. Saying urgent pointer as a marker for a record or a message being a modification of TCP standard, IMHO, is definitely a stretch. However, I yield the debate to the TCP gurus. From owner-ips@ece.cmu.edu Mon Feb 5 21:47:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23489 for ; Mon, 5 Feb 2001 21:47:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f161Hra00350 for ips-outgoing; Mon, 5 Feb 2001 20:17:53 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f111.law4.hotmail.com [216.33.149.111]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f161Hh600338 for ; Mon, 5 Feb 2001 20:17:43 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 5 Feb 2001 17:17:37 -0800 Received: from 203.200.0.87 by lw4fd.law4.hotmail.msn.com with HTTP; Tue, 06 Feb 2001 01:17:37 GMT X-Originating-IP: [203.200.0.87] From: "Santosh Rao" To: ips@ece.cmu.edu Subject: RE: iSCSI : Abort Task "connection allegiance" Date: Tue, 06 Feb 2001 01:17:37 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Feb 2001 01:17:37.0343 (UTC) FILETIME=[977AE4F0:01C08FDA] Sender: owner-ips@ece.cmu.edu Precedence: bulk >There are two reasons for issuing abort: 1) application software exits and >OS needs cleaning up, and 2) a request times out and it needs clean >restart. >In either cases, we don't want the abort arrives there before the >one to be aborted. Hence, using zero CmdSN is unwise. If the abort gets >there first,the target will complete the abort quickly and later executes >the one to be aborted anyway. YP, "connection allegiance" implies the Abort Task is sent on the same TCP connection as the command. By sending the Abort Task on the same TCP connection, [and since it is sent after the command], the ordering is preserved. The abort will not reach before the command. The only case where the abort would reach before the command would be if the iSCSI layer at the target had discarded the command PDU [due to an iSCSI layer error]. In such a case, since the command will never be active at the target, the target would respond to the Abort Task indicating "No Task Found" or "Function Complete" which should be ok. > > > In the interests of keeping I/O timeout recovery quick, the > > "connection allegiance" policy, currently applicable to all phases > of >a command, should be extended to the Abort Task for that > command as well >and the Abort Task be sent with a CmdSN of 0. > >I don't follow this logic at all. Are you trying to say that if the target >gets an abort, it should enter connection allegiance until the one to be >aborted arrives? This would real make a mess on the target microcode. How >do we even know the aborted request would arrive? IMHO, abort should never >have a zero CmdSN. "Connection Allegiance" is enforced by an initiator [by sending the command and the Abort Task on the same TCP connection.]. (This terminology is curently used in the draft). Connection Allegiance for a target impies all the PDUs for a command, sent from a target to an initiator, should be sent on the same TCP connection on which the command was received. (i.e. READ Data PDUs, R2T, SCSI Response PDU, ..). Regards, Santosh _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-ips@ece.cmu.edu Mon Feb 5 21:48:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23500 for ; Mon, 5 Feb 2001 21:48:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f161MC200562 for ips-outgoing; Mon, 5 Feb 2001 20:22:12 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f24.law4.hotmail.com [216.33.149.24]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f161LI600523 for ; Mon, 5 Feb 2001 20:21:18 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 5 Feb 2001 17:21:08 -0800 Received: from 203.200.0.87 by lw4fd.law4.hotmail.msn.com with HTTP; Tue, 06 Feb 2001 01:21:08 GMT X-Originating-IP: [203.200.0.87] From: "Santosh Rao" To: ips@ece.cmu.edu Subject: Re: Section 4.1 (Login Phase) Date: Tue, 06 Feb 2001 01:21:08 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Feb 2001 01:21:08.0878 (UTC) FILETIME=[159092E0:01C08FDB] Sender: owner-ips@ece.cmu.edu Precedence: bulk Re-sending... Julian, Are you saying the Reject is NOT meant to be used for all format errors (?) How then is the following description of Reject PDU (Section 2.19) to be interpreted : "It may happen that a target receives a message with a format error (inconsistent fields, reserved fields not 0, inexistent LUN etc.) or a digest error (invalid payload or header). The target returns the header of the message in error as the data of the response. 2.20 Reason The reject Reason is coded as follows: 1 - Format Error 2 - Header Digest Error 3 - Payload Digest Error " Why are 2 mechanisms required to indicate format errors ? The one in Login response (reject with F=0) seems redundant. Regards, Santosh _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-ips@ece.cmu.edu Mon Feb 5 23:55:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25647 for ; Mon, 5 Feb 2001 23:55:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f162bsM02990 for ips-outgoing; Mon, 5 Feb 2001 21:37:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f162b0602959 for ; Mon, 5 Feb 2001 21:37:01 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f163ko073556; Mon, 5 Feb 2001 19:46:50 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: "Y P Cheng" , "David Robinson" , Subject: RE: iSCSI Data Integrity - Digests Date: Mon, 5 Feb 2001 18:35:19 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <003d01c08fda$5ff1d2a0$90c809c0@yp_portable.advansys.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Y.P. > > The urgent pointer has a defined behavior within RFC documentation > > such that to define it as a record boundary is not in keeping > > with standards. To implement and use an urgent pointer as a record > > boundary pointer clearly modifies the TCP standard. > > Very interesting argument. Urgent pointer is meant to be a inband signal > that can be used for any particular purpose a user has in mind. Saying > urgent pointer as a marker for a record or a message being a > modification of > TCP standard, IMHO, is definitely a stretch. However, I yield > the debate to > the TCP gurus. The urgent pointer marks urgent data and must coalesce to include additional urgent data. To use the urgent pointer to mark boundaries in close proximity, as close as the next segment as you described, then you will be required to modify TCP to not coalesce. Starving send will not be conducive to accelerated use and not coalescing the pointer is a violation of the TCP standard. Both TCP send and receive coalesce. Yes, the urgent pointer is an inband signal but with these clearly defined limitations. These limitations make it impractical for use as a record marker and likely to thwart TCP Offload Engines as it also requires unique data handling. The urgent pointer is not a general purpose marker. Its devised use is to expedite and only requires a single variable. You are attempting to expand use of the urgent pointer to encompass a greatly revised definition requiring an attribute reserved for every message unit up to one per segment. It is definitely a stretch to consider this not a modification of the TCP standard, IMO. Doug From owner-ips@ece.cmu.edu Mon Feb 5 23:56:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25658 for ; Mon, 5 Feb 2001 23:56:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f162qs003489 for ips-outgoing; Mon, 5 Feb 2001 21:52:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f162q0603455 for ; Mon, 5 Feb 2001 21:52:00 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f1642I073572; Mon, 5 Feb 2001 20:02:19 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: "Santosh Rao" , Subject: RE: iSCSI : Abort Task "connection allegiance" Date: Mon, 5 Feb 2001 18:50:47 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh, > YP, > > "connection allegiance" implies the Abort Task is sent on the same > TCP connection as the command. By sending the Abort Task on the > same TCP connection, [and since it is sent after the command], > the ordering is preserved. The abort will not reach before the > command. > > The only case where the abort would reach before the command > would be if the iSCSI layer at the target had discarded the > command PDU [due to an iSCSI layer error]. In such a case, since > the command will never be active at the target, the target > would respond to the Abort Task indicating "No Task Found" > or "Function Complete" which should be ok. The advantage of multiple connections or multiple homing is removed if connection allegiance is mandated. The ability to recover from a seemingly failed connection may include a request to restart using a different connection. Such request will likely be sent over a different connection if there is a desire to migrate. Connection allegiance was to allow distributed state information to remain isolated. This isolation is problematic and not mandating allegiance ensures there will always be a means to communicate intermediate states between connections. Connection allegiance should only be preferred. Doug From owner-ips@ece.cmu.edu Tue Feb 6 04:11:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10308 for ; Tue, 6 Feb 2001 04:11:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f166xuE13313 for ips-outgoing; Tue, 6 Feb 2001 01:59:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f166xH613287 for ; Tue, 6 Feb 2001 01:59:17 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id HAA10168; Tue, 6 Feb 2001 07:58:54 +0100 From: julian_satran@il.ibm.com Received: from d12mta05.de.ibm.com (d12mta06_cs0 [9.165.222.255]) by d12relay02.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id HAA46874; Tue, 6 Feb 2001 07:58:35 +0100 Received: by d12mta05.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569EB.002652D6 ; Tue, 6 Feb 2001 07:58:35 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: "Bernard Aboba" cc: Black_David@emc.com, ips@ece.cmu.edu, "RJ Atkinson" , "Smb@Research. Att. Com" , biran@il.ibm.com Message-ID: Date: Tue, 6 Feb 2001 08:54:03 +0200 Subject: RE: Security Use Requirements Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Bernard, The enquiry David took upon himself to make is that if we have a strong requirement to have digests that include authentication and integrity as a minimal requirement or if we could work with a sequence (listed here in order "increasing" integrity/security) that looks like: 1-none 2-data integrity(CRC) and/or authentication of the parties at session start 3-full security through TLS and transport-IPSec The answer to this seems to be (as we expected) that as long as the negotiation is done in a proper way eliminating the possibility of getting drawn down to a weak security scheme when at least one of the parties wants a higher level we can go with the outlined sequence of schemes. The additional point we will have to ponder is where we want to draw the line for a "minimal compliant" iSCSI. The current (true for June 2000) consensus between the authors was "implementation - somewhere within 2 and deployment at 1" - with CRCs mandatory to implement (optional to use) and all the rest is optional to use and implement. Considering the spectrum of devices and applications for iSCSI I think that this is a reasonable choice. Regards, Julo "Bernard Aboba" on 06/02/2001 01:26:13 Please respond to "Bernard Aboba" To: Black_David@emc.com, ips@ece.cmu.edu cc: "RJ Atkinson" , "Smb@Research. Att. Com" Subject: RE: Security Use Requirements It is hard for me to see how you could get away with no security services at all (e.g. no per-packet authentication and integrity protection for iSCSI PDUs). After all, we're talking about facilities that are used by the world's major financial institutions. If this data isn't worth protecting, I don't know what is. Do you really want attackers to be able to manipulate the contents of bank accounts at will over the Internet? Furthermore, there really isn't a sound technical argument for dispensing with security. There are chipsets available that can provide IPSEC integrity and authentication services at speeds of 1 Gbps or higher. -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Black_David@emc.com Sent: Monday, February 05, 2001 12:54 PM To: ips@ece.cmu.edu Subject: Security Use Requirements In Orlando, I picked up an action item to determine what the requirements are for *use* of security features, as opposed to requirements for *implementation*. I believe the answer to be that it is acceptable to specify security measures weaker than those one would want to use in full generality on a public network, where "weaker" includes no security. There are two important caveats that apply: - Security of the negotiation mechanism becomes very important when this is done, as there's an obvious man-in-the-middle attack on the negotiation mechanism to get the endpoints to negotiate weaker security than they intended. - The weaker security mechanisms need to be documented in terms of their security properties (and lack thereof), as well as environments in which they are appropriate. The "Security Considerations" section of RFC 2338 (VRRP) has been recommended as a good example of this. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Feb 6 10:48:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18921 for ; Tue, 6 Feb 2001 10:48:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f16DGsU06673 for ips-outgoing; Tue, 6 Feb 2001 08:16:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f16DGZH06656 for ; Tue, 6 Feb 2001 08:16:35 -0500 (EST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id FAA00945; Tue, 6 Feb 2001 05:16:26 -0800 (PST) Received: by internaut.com (NX5.67e/NeXT-3.0) id AA00350; Tue, 6 Feb 01 05:52:53 -0800 Date: Tue, 6 Feb 2001 05:52:52 -0800 (GMT-0800) From: "Bernard D. Aboba" To: julian_satran@il.ibm.com Cc: Black_David@emc.com, ips@ece.cmu.edu, RJ Atkinson , "Smb@Research. Att. Com" , biran@il.ibm.com Subject: RE: Security Use Requirements In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk > deployment at 1" - with CRCs mandatory to implement (optional to use) and > all the rest is optional to use and implement. CRCs only provide integrity protection, but not authentication since they are not keyed. Thus, it provides no protection against spoofing attacks. Even if the CRC is non-linear, it is not hard to build a device that will change packets on the fly without fear of detection. The TCP checksum is non-linear but it can be guessed right about half the time. An example of the kinds of attacks that are possible is found at: http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html. I'm sure the folks at Berkeley will be happy to provide an equivalent analysis for iSCSI. Do you really want to enable attackers to insert or change data destined a SAN disk at will? Even if the iSCSI SAN is using linklocal addressing, and therefore is not accessible from the Internet, there is still risk from internal attack. A more reasonable approach would be to require at least authentication and integrity protection (e.g. IPSEC AH or ESP null). From owner-ips@ece.cmu.edu Tue Feb 6 14:11:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28284 for ; Tue, 6 Feb 2001 14:11:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f16GjrW17862 for ips-outgoing; Tue, 6 Feb 2001 11:45:53 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f16GjWH17837 for ; Tue, 6 Feb 2001 11:45:32 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id RAA109412; Tue, 6 Feb 2001 17:45:14 +0100 From: julian_satran@il.ibm.com Received: from d12mta05.de.ibm.com (d12mta06_cs0 [9.165.222.255]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id RAA93446; Tue, 6 Feb 2001 17:45:02 +0100 Received: by d12mta05.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569EB.005C02D6 ; Tue, 6 Feb 2001 17:45:00 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: "Bernard D. Aboba" cc: Black_David@emc.com, ips@ece.cmu.edu, RJ Atkinson , "Smb@Research. Att. Com" , biran@il.ibm.com Message-ID: Date: Tue, 6 Feb 2001 18:32:20 +0200 Subject: RE: Security Use Requirements Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Bernard, Both IPSec and TLS will be in the standard. As we are talking about speeds that will be in excess of 1GBs even on modest disk controllers we where all hesitant if to make anything in this category mandatory to implement today. We assume that all those who require security beyond CRC and session authentication will pay for and get it. However those that build a Storage Area Newtork within a small enterprise completely isolated from the internet will not have to pay for what they do not need. Regards, Julo "Bernard D. Aboba" on 06/02/2001 15:52:52 Please respond to "Bernard D. Aboba" To: Julian Satran/Haifa/IBM@IBMIL cc: Black_David@emc.com, ips@ece.cmu.edu, RJ Atkinson , "Smb@Research. Att. Com" , Ofer Biran/Haifa/IBM@IBMIL Subject: RE: Security Use Requirements > deployment at 1" - with CRCs mandatory to implement (optional to use) and > all the rest is optional to use and implement. CRCs only provide integrity protection, but not authentication since they are not keyed. Thus, it provides no protection against spoofing attacks. Even if the CRC is non-linear, it is not hard to build a device that will change packets on the fly without fear of detection. The TCP checksum is non-linear but it can be guessed right about half the time. An example of the kinds of attacks that are possible is found at: http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html. I'm sure the folks at Berkeley will be happy to provide an equivalent analysis for iSCSI. Do you really want to enable attackers to insert or change data destined a SAN disk at will? Even if the iSCSI SAN is using linklocal addressing, and therefore is not accessible from the Internet, there is still risk from internal attack. A more reasonable approach would be to require at least authentication and integrity protection (e.g. IPSEC AH or ESP null). From owner-ips@ece.cmu.edu Tue Feb 6 14:12:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28331 for ; Tue, 6 Feb 2001 14:12:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f16GHpx16277 for ips-outgoing; Tue, 6 Feb 2001 11:17:51 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f32.law4.hotmail.com [216.33.149.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f16GGxH16238 for ; Tue, 6 Feb 2001 11:16:59 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Feb 2001 08:16:53 -0800 Received: from 203.200.0.72 by lw4fd.law4.hotmail.msn.com with HTTP; Tue, 06 Feb 2001 16:16:53 GMT X-Originating-IP: [203.200.0.72] From: "Santosh Rao" To: ips@ece.cmu.edu Subject: RE: iSCSI : Abort Task "connection allegiance" Date: Tue, 06 Feb 2001 21:46:53 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Feb 2001 16:16:53.0499 (UTC) FILETIME=[37DAECB0:01C09058] Sender: owner-ips@ece.cmu.edu Precedence: bulk >Santosh, >The advantage of multiple connections or multiple homing is removed if >connection allegiance is mandated. Doug, Section 1.2.5 already mandates connection allegiance for all PDUs of a command. ("For SCSI commands that require data and/or parameter transfer, the (optional) data and the status for a command must be sent over the same TCP connection that was used to deliver the SCSI command (we call this "connection allegiance").") I believe the dis-advantages of sending different PDUs of a command over different connections has already been discussed and discarded due to the various state sharing issues as well as out-of-order issues it causes. So, is the concern expressed about the existing MUST in the above statement in the draft ? Or are the comments directed towards the proposal to extend connection allegiance to the Abort Task as well ? >The ability to recover from a seemingly failed connection may include a >request to restart using a different connection. Such request will likely >be sent over a different connection if there is a desire to migrate. >Connection allegiance was to allow distributed state information to remain >isolated. This isolation is problematic and not mandating allegiance >ensures there will always be a means to communicate intermediate states >between connections. While the "retry" command processing at the target may involve co-operation across multiple NIC instances to fetch the data/status, this should be ok since it is the exception path. We should not attempt to optimize this path and affect the mainline paths. The mainline I/O paths require connection allegiance for a number of reasons that have been previously discussed on the reflector. >Connection allegiance should only be preferred. The lack of connection allegiance for all PDus of a command can cause out-of-order problems, with status PDUs arriving at the initiator ahead of the data PDUs.It also requires sharing I/O state information across NICs for the mainline paths, as compared to the current model where this is only required in exception paths. Regards, Santosh _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-ips@ece.cmu.edu Tue Feb 6 17:06:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03359 for ; Tue, 6 Feb 2001 17:06:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f16J1xC25502 for ips-outgoing; Tue, 6 Feb 2001 14:01:59 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gnat.inet.org (209-9-249-62.sdsl.cais.net [209.9.249.62]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f16GvhH18508 for ; Tue, 6 Feb 2001 11:57:43 -0500 (EST) Received: from mosquito.inet.org (mosquito.inet.org [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 1B1B18264F; Tue, 6 Feb 2001 11:56:12 -0500 (EST) Message-Id: <5.0.0.25.2.20010206114429.009ff9d0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 06 Feb 2001 11:47:49 -0500 To: julian_satran@il.ibm.com From: RJ Atkinson Subject: RE: Security Use Requirements Cc: "Bernard D. Aboba" , Black_David@emc.com, ips@ece.cmu.edu, RJ Atkinson , , biran@il.ibm.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk At 11:32 06/02/01, julian_satran@il.ibm.com wrote: >Bernard, > >Both IPSec and TLS will be in the standard. As we are talking about >speeds that will be in excess of 1GBs even on modest disk controllers we were all hesitant if to make anything in this category mandatory to >implement today. I suspect that failing to make security mandatory-to- implement will tend to prevent the specification(s) from ever becoming IETF standards-track RFC(s). However, the WG can certainly *try* to slide by. As a potential user, I would prefer that security be made mandatory-to-implement. Inevitably stuff intended for private networks ends up on the global Internet by accident or out of expediency. Further, even on private networks there are significant insider security risks. Ran rja@inet.org From owner-ips@ece.cmu.edu Tue Feb 6 17:10:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03498 for ; Tue, 6 Feb 2001 17:10:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f16J6tx25823 for ips-outgoing; Tue, 6 Feb 2001 14:06:55 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f16J5qH25768 for ; Tue, 6 Feb 2001 14:05:52 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f16KGD074692; Tue, 6 Feb 2001 12:16:13 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: "Santosh Rao" , Subject: RE: iSCSI : Abort Task "connection allegiance" Date: Tue, 6 Feb 2001 11:04:43 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh, It is common to have multiple routers providing access over different IPs to the same machine. At an indication of trouble, an alternative path would be employed to prevent any significant service disruption with a path switch the extent of effort. The present scheme only considers multiple connections as a means to modify TCP congestion algorithms in obtaining larger shares of the network bandwidth and ignores issues of reliability and disruption avoidance. To require ULP (higher level protocol) exchange as part of making the path switch on existing connections together with an ULP restart of service is highly disruptive and indicates an unreliable delivery scheme. Already all PDUs are marked with a serial number across all connections. The problems of out-of-order issues occur due to a lack of integrity of this serialization. When this serialization fails, it is hoped TCP provides necessary sequential assurance and is thus imposing a connection restriction as this would then introduce a different underlying TCP sequence. The present handshake already mandates some state sharing across all connections with Exp* and Max*. Allowing fail-over at the transport level is the only means that would have a broader application and would not impose restrictions on the ULP such as SCSI. Such an approach is a means of isolating various layers involved and a means of ensuring there is not a required cooperation of the ULP. Although you express concern about main-line execution of SCSI where to reduce the amount of state information shared between connections, connection allegiance is employed; the means of allowing a transition to a different connection without assistance of SCSI should be allowed for a good design. Any required state information should be transferable automatically. The alternative is highly disruptive. As a performance optimization, indicate preference for allegiance but do not mandate it and repair serialization integrity of the transport to remain viable across multiple connections. To do less will reduce the integrity of the system and impose highly complex scenarios for recovery. Doug > >Santosh, > >The advantage of multiple connections or multiple homing is removed if > >connection allegiance is mandated. > > Doug, > > Section 1.2.5 already mandates connection allegiance for all PDUs of a > command. > ("For SCSI commands that require data and/or parameter > transfer, the (optional) data and the status for a command must be > sent over the same TCP connection that was used to deliver the SCSI > command (we call this "connection allegiance").") > > I believe the dis-advantages of sending different PDUs of a command over > different connections has already been discussed and discarded due to the > various state sharing issues as well as out-of-order issues it causes. > > So, is the concern expressed about the existing MUST in the above > statement > in the draft ? Or are the comments directed towards the proposal > to extend > connection allegiance to the Abort Task as well ? > > >The ability to recover from a seemingly failed connection may include a > >request to restart using a different connection. Such request > will likely > >be sent over a different connection if there is a desire to migrate. > >Connection allegiance was to allow distributed state information > to remain > >isolated. This isolation is problematic and not mandating allegiance > >ensures there will always be a means to communicate intermediate states > >between connections. > > While the "retry" command processing at the target may involve > co-operation > across multiple NIC instances to fetch the data/status, this should be ok > since it is the exception path. We should not attempt to optimize > this path > and affect the mainline paths. The mainline I/O paths require connection > allegiance for a number of reasons that have been previously discussed on > the reflector. > > >Connection allegiance should only be preferred. > > The lack of connection allegiance for all PDus of a command can cause > out-of-order problems, with status PDUs arriving at the initiator > ahead of > the data PDUs.It also requires sharing I/O state information > across NICs for > the mainline paths, as compared to the current model where this is only > required in exception paths. > > Regards, > Santosh > > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > From owner-ips@ece.cmu.edu Tue Feb 6 18:40:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04635 for ; Tue, 6 Feb 2001 18:40:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f16LN3j03816 for ips-outgoing; Tue, 6 Feb 2001 16:23:03 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f16LMjH03801 for ; Tue, 6 Feb 2001 16:22:46 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.132.205]) by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA91072; Tue, 6 Feb 2001 16:06:37 -0500 Received: from f5n70e (d03nm094h.boulder.ibm.com [9.99.140.70]) by westrelay02.boulder.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id OAA153896; Tue, 6 Feb 2001 14:22:08 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: Security Use Requirements To: "Bernard Aboba" Cc: , , "RJ Atkinson" , "Smb@Research. Att. Com" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 6 Feb 2001 13:21:56 -0800 X-MIMETrack: Serialize by Router on D03NM094/03/M/IBM(Release 5.0.6 |December 14, 2000) at 02/06/2001 02:22:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Bernard, I think that Julian addressed this, but, an installation might want only the connection to the local environment, and if so administratively tell the iSCSI ends to not do the encryption etc. Especially if some of the ends are Laptops and Desktops. But all side must implement the features. By the way you might have slightly overstated the IPSec chips going at full gig speed, when you talk about triple Des. And if there are some they are not within the normal costs one would expect for a iSCSI NIC HBA. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Internet address: hufferd@us.ibm.com "Bernard Aboba" @ece.cmu.edu on 02/05/2001 03:26:13 PM Sent by: owner-ips@ece.cmu.edu To: , cc: "RJ Atkinson" , "Smb@Research. Att. Com" Subject: RE: Security Use Requirements It is hard for me to see how you could get away with no security services at all (e.g. no per-packet authentication and integrity protection for iSCSI PDUs). After all, we're talking about facilities that are used by the world's major financial institutions. If this data isn't worth protecting, I don't know what is. Do you really want attackers to be able to manipulate the contents of bank accounts at will over the Internet? Furthermore, there really isn't a sound technical argument for dispensing with security. There are chipsets available that can provide IPSEC integrity and authentication services at speeds of 1 Gbps or higher. -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Black_David@emc.com Sent: Monday, February 05, 2001 12:54 PM To: ips@ece.cmu.edu Subject: Security Use Requirements In Orlando, I picked up an action item to determine what the requirements are for *use* of security features, as opposed to requirements for *implementation*. I believe the answer to be that it is acceptable to specify security measures weaker than those one would want to use in full generality on a public network, where "weaker" includes no security. There are two important caveats that apply: - Security of the negotiation mechanism becomes very important when this is done, as there's an obvious man-in-the-middle attack on the negotiation mechanism to get the endpoints to negotiate weaker security than they intended. - The weaker security mechanisms need to be documented in terms of their security properties (and lack thereof), as well as environments in which they are appropriate. The "Security Considerations" section of RFC 2338 (VRRP) has been recommended as a good example of this. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Feb 6 18:44:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04673 for ; Tue, 6 Feb 2001 18:43:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f16LOwB03928 for ips-outgoing; Tue, 6 Feb 2001 16:24:58 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from main.connectcom.net (ns1.advansys.com [204.247.22.3] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f16LOAH03879 for ; Tue, 6 Feb 2001 16:24:10 -0500 (EST) Received: from yp_portable (anubis.advansys.com [204.247.22.2]) by main.connectcom.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 11CPQG83; Tue, 6 Feb 2001 13:07:20 -0800 From: "Y P Cheng" To: "John Hufferd" Cc: "'Ips@Ece. Cmu. Edu'" Subject: RE: iSCSI Data Integrity - Digests Date: Tue, 6 Feb 2001 13:05:07 -0800 Message-ID: <000901c09080$7bc07d00$90c809c0@yp_portable.advansys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > With my TC Hat on: > YP and others, > It does not matter if you are technically right. We have been over and > over this. Please let it lay. If you are sending something that is > technically TCP/IP but has some extra (legal) trick. That is of course > fine, if you are talking to your own adapter. We here in the IETF would > not like to talk about your tricks to your adapter. We need to have > knowledge that works with other vendors HW and SW Targets. That means we > have to define how to use the tricks, and exploit them. As you know we > have been told Over and Over that the IETF as a whole will NOT accept this > kind of thing in our draft standard, so we should not waste our time and > reflector bandwidth talking about it. > > If you folks just have to talk about it, please take it off the reflector. I apologize for giving you the impression of wanting to talk about something not appropriate on this reflector. As you know, I wrote in responding to comments on non-Standard TCP implementation. The real question is that each time a new TCP option is added, does the old TCP remains as Standard or the new TCP becomes a new Standard. I stated that this WG was prohibited from discussing this topic. But, many people in this WG does not seem to realize that iSCSI chips will have new TCP features and options whether we like it or not. While this reflector doesn't wish to talk about TCP, it certainly could not demand that all new TCP implementations for iSCSI are prohibited. Peace! From owner-ips@ece.cmu.edu Tue Feb 6 18:45:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04700 for ; Tue, 6 Feb 2001 18:45:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f16LKwX03705 for ips-outgoing; Tue, 6 Feb 2001 16:20:58 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gate.internaut.com ([64.38.134.108]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f16LKlH03690 for ; Tue, 6 Feb 2001 16:20:47 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f16LFER20188; Tue, 6 Feb 2001 13:15:15 -0800 From: "Bernard Aboba" To: Cc: , , "RJ Atkinson" , "Smb@Research. Att. Com" , Subject: RE: Security Use Requirements Date: Tue, 6 Feb 2001 13:21:14 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >Both IPSec and TLS will be in the standard. Including *both* IPSEC and TLS as options will probably result in both much higher cost to customers as well as fewer vendors implementing either. Choosing one or the other (IPSEC is my preference) would be a better choice. In general, it is a bad idea to have too many security options in a standard. Options are bad because you have to implement them to be able to interoperate with those people who do, yet you cannot guarantee that the work will be used. In particular, including both IPSEC and TLS would cause vendors to try to implement both on the same NIC, since they could never be sure which security scheme would be used on a given iSCSI target. This would drive up the cost enormously since the acceleration architectures are very different between the protocols. >As we are talking about speeds that will be in excess of 1GBs >even on modest disk controllers we were all hesitant if to make >anything in this category mandatory to implement today. As Ran noted, making implementation mandatory doesn't mean that users have to turn it on. But not making it mandatory will probably ensure that security will not be available in most cases. Given the modest cost of adding IPSEC acceleration hardware (today IPSEC accelerated NICs are available for around $100) it is hard to see how this would be a worthwhile tradeoff. Right now, SSL/TLS acceleration hardware is a lot more expensive than IPSEC accelerators (at least $2000), so I could understand if SSL/TLS were left out of the standard. >We assume that all those who require security beyond CRC CRC provides only integrity protection, but since it is not keyed, there is no per-packet authentication or protection against spoofing or modification. CRC therefore has little or no security value. > session authentication All session authentication does is guarantee the user identity at the beginning of the session. Unless you have per-packet authentication and integrity protection, all bets are off after that. In particular, session authentication provides no protection against TCP session hijacking. >However those that build a Storage Area Newtork within a >small enterprise completely isolated from the >internet will not have to pay for what they do not need. Actually, the decision made above will guarantee that all users will need to pay a huge incremental cost for security, because of the over abundance of security options. In reality, given the projected cost of 1+ Gbps iSCSI accelerated adapters, the incremetal cost of implementing IPSEC security would be minimal. From owner-ips@ece.cmu.edu Tue Feb 6 18:46:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04712 for ; Tue, 6 Feb 2001 18:45:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f16MG2E06790 for ips-outgoing; Tue, 6 Feb 2001 17:16:02 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gnat.inet.org (209-9-249-62.sdsl.cais.net [209.9.249.62]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f16LeOH04789 for ; Tue, 6 Feb 2001 16:40:24 -0500 (EST) Received: from mosquito.inet.org (mosquito.inet.org [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 817ED8264F; Tue, 6 Feb 2001 16:38:00 -0500 (EST) Message-Id: <5.0.0.25.2.20010206162519.009ea9c0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0 X-Priority: 1 (Highest) Date: Tue, 06 Feb 2001 16:29:38 -0500 To: "John Hufferd" From: RJ Atkinson Subject: RE: Security Use Requirements Cc: "Bernard Aboba" , , , "RJ Atkinson" , "Smb@Research. Att. Com" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk At 16:21 06/02/01, John Hufferd wrote: >I think that Julian addressed this, but, an installation might want only >the connection to the local environment, and if so administratively tell >the iSCSI ends to not do the encryption etc. Especially if some of the >ends are Laptops and Desktops. But all side must implement the features. Implement != turn on operationally. The above explains why clever vendors might have a configuration knob to turn off security. The above does NOT make any kind of case for not always *implementing* security. >By the way you might have slightly overstated the IPSec chips going at full >gig speed, when you talk about triple Des. And if there are some they are >not within the normal costs one would expect for a iSCSI NIC HBA. So if you believe the costs are so high, implement single DES. For a lot of threat environments DES-CBC is sufficient and it surely beats the hell out of nothing. By the way, the crypto parts vendors that I'm talking with must be giving me better prices than you, which I find surprising, since by the parts quotes I'm seeing Bernard's math works just fine. Nothing anyone has said here has given any kind of reasonable excuse to not make implementing security mandatory. There has been lots of rationale for making it optional for the user to turn on for a given box, but nothing for making it optional to implement. (Implement in the box != deploy operationally). Ran rja@inet.org From owner-ips@ece.cmu.edu Tue Feb 6 20:35:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05795 for ; Tue, 6 Feb 2001 20:35:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f16NY0x10900 for ips-outgoing; Tue, 6 Feb 2001 18:34:00 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [168.159.208.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f16NWxH10833 for ; Tue, 6 Feb 2001 18:32:59 -0500 (EST) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2650.21) id <1DCB0HJ0>; Tue, 6 Feb 2001 18:32:51 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A07041014F1@corpmx9.isus.emc.com> From: Black_David@emc.com To: rja@inet.org, julian_satran@il.ibm.com Cc: aboba@internaut.com, ips@ece.cmu.edu, biran@il.ibm.com Subject: RE: Security Use Requirements Date: Tue, 6 Feb 2001 18:32:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk Some related clarifications: > I suspect that failing to make security mandatory-to- > implement will tend to prevent the specification(s) from > ever becoming IETF standards-track RFC(s). However, the WG > can certainly *try* to slide by. My original post was about mandatory-to-use, NOT mandatory-to-implement. As for making security not mandatory-to-implement ... NOT on my watch ... and remember that Steve Bellovin is one of the ips WG co-chairs, making me a "good cop" by comparison on this sort of issue ;-). > Another customary IETF position is to work on the basis that > all IETF protocols are likely (in practice) to be deployed over > The Global Internet. So the threat model discussions normally > MUST include those kind of threats and can't be limited to threats > on a private intranet. That is also correct ... and I say that with my WG co-chair hat firmly in place. There is also language to this effect in the ips WG charter. It's unfortunate that Julian focussed only on integrity in his response. Going back to the Pittsburgh (summer 2000) minutes, secure authentication will be mandatory to implement ... so sayeth the AD. I also believe that some form of cryptographically authenticated integrity will likewise be mandatory to implement (otherwise it's too easy to hijack an authenticated connection). This means signed cryptographic checksums, not just CRCs (as Bernard explained). OTOH, it's not clear that confidentiality will be mandatory to implement. The whole point on mandatory-to-implement vs. mandatory-to-use is to adapt available security technologies to the circumstances. One simple example is that confidentiality is NOT mandatory-to-use in IPsec, otherwise AH wouldn't exist ... and 5 demerits to anyone who uses that comment as a jumping off point to open the debate about whether AH should exist at all on this list. I'm not sure that the statement that both IPsec and TLS will be in the spec is the rough consensus of the WG at this point. I also want to caution folks that simply requiring these technologies to be implemented is not sufficient to address all the security issues - one example for iSCSI is that something will need to be said about the relationship of target names to the identities used for IPsec and/or TLS authentication. Let me point everyone to Jeff Schiller's security tutorial from the San Diego IETF meeting at: http://jis.mit.edu/sectutorial/ which covers this and a bunch of related material on security at a level that should be accessible to almost everyone. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Feb 6 20:35:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05806 for ; Tue, 6 Feb 2001 20:35:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f16NZ1t10942 for ips-outgoing; Tue, 6 Feb 2001 18:35:01 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f16NXwH10892 for ; Tue, 6 Feb 2001 18:33:58 -0500 (EST) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2448.0) id ; Tue, 6 Feb 2001 15:33:48 -0800 Message-ID: From: Joshua Tseng To: Bernard Aboba Cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Tue, 6 Feb 2001 15:33:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bernard, > Including *both* IPSEC and TLS as options will probably result > in both much higher cost to customers as well as fewer vendors > implementing either. Choosing one or the other (IPSEC is my > preference) would be a better choice. IPSec and TLS provide different capabilities. While IPSec is easier to implement and hence, as you point out, much cheaper, TLS affords the capability of securely communicating through proxys. On the other hand, IPSec is a real pain to get through firewalls. If we decide that iSCSI doesn't need to go through firewalls, then we could let go of TLS. But the last I remember from reading the IPS charter, it is still a requirement. > > In general, it is a bad idea to have too many security options in > a standard. Options are bad because you have to implement them > to be able to interoperate with those people who do, yet you cannot > guarantee that the work will be used. In particular, including both > IPSEC and TLS would cause vendors to try to implement both on > the same NIC, since they could never be sure which security scheme > would be used on a given iSCSI target. This would drive up the cost > enormously since the acceleration architectures are very different > between the protocols. Why should IPSEC or TLS be mandatory for iSCSI when it isn't for http, dns, and other network protocols? I'm aware of nothing inherent in iSCSI that makes it need special security measures any more than those other protocols. If the security folks intended for all protocols to be secure, wouldn't it be more efficient for the security WG to say it just once, and mandate it for all IP protocols? Josh > > >As we are talking about speeds that will be in excess of 1GBs > >even on modest disk controllers we were all hesitant if to make > >anything in this category mandatory to implement today. > > As Ran noted, making implementation mandatory doesn't mean that > users have to turn it on. But not making it mandatory will probably > ensure that security will not be available in most cases. Given > the modest cost of adding IPSEC acceleration hardware (today > IPSEC accelerated NICs are available for around $100) it is hard > to see how this would be a worthwhile tradeoff. > > Right now, SSL/TLS acceleration hardware is a lot more expensive than > IPSEC accelerators (at least $2000), so I could understand if SSL/TLS > were left out of the standard. > > >We assume that all those who require security beyond CRC > > CRC provides only integrity protection, but since it is not keyed, > there is no per-packet authentication or protection against spoofing > or modification. CRC therefore has little or no security value. > > > session authentication > > All session authentication does is guarantee the user identity > at the beginning of the session. Unless you have per-packet > authentication and integrity protection, all bets are off after > that. In particular, session authentication provides no protection > against TCP session hijacking. > > >However those that build a Storage Area Newtork within a > >small enterprise completely isolated from the > >internet will not have to pay for what they do not need. > > Actually, the decision made above will guarantee that all users > will need to pay a huge incremental cost for security, because > of the over abundance of security options. In reality, given the > projected cost of 1+ Gbps iSCSI accelerated adapters, the incremetal > cost of implementing IPSEC security would be minimal. > From owner-ips@ece.cmu.edu Tue Feb 6 22:25:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08966 for ; Tue, 6 Feb 2001 22:25:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f171N2M15994 for ips-outgoing; Tue, 6 Feb 2001 20:23:02 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f171MwH15988 for ; Tue, 6 Feb 2001 20:22:58 -0500 (EST) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2448.0) id ; Tue, 6 Feb 2001 17:22:48 -0800 Message-ID: From: Joshua Tseng To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Tue, 6 Feb 2001 17:22:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ips@ece.cmu.edu Precedence: bulk David, Question: Does your "mandatory-to-implement" mean "mandatory-to-implement-on-the-same-box", or "mandatory-to-implement-on-the-same-or-different-box"? :-) IPSec security gateways are widely available now, from many different vendors. Are you ruling out their use to fulfill the security requirement? Josh > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Tuesday, February 06, 2001 3:32 PM > To: rja@inet.org; julian_satran@il.ibm.com > Cc: aboba@internaut.com; ips@ece.cmu.edu; biran@il.ibm.com > Subject: RE: Security Use Requirements > > > Some related clarifications: > > > I suspect that failing to make security mandatory-to- > > implement will tend to prevent the specification(s) from > > ever becoming IETF standards-track RFC(s). However, the WG > > can certainly *try* to slide by. > > My original post was about mandatory-to-use, NOT > mandatory-to-implement. As for making security not > mandatory-to-implement ... NOT on my watch ... and > remember that Steve Bellovin is one of the ips WG > co-chairs, making me a "good cop" by comparison on > this sort of issue ;-). > > > Another customary IETF position is to work on the basis that > > all IETF protocols are likely (in practice) to be deployed over > > The Global Internet. So the threat model discussions normally > > MUST include those kind of threats and can't be limited to threats > > on a private intranet. > > That is also correct ... and I say that with my WG co-chair > hat firmly in place. There is also language to this > effect in the ips WG charter. > > It's unfortunate that Julian focussed only on integrity > in his response. Going back to the Pittsburgh (summer > 2000) minutes, secure authentication will be mandatory to > implement ... so sayeth the AD. I also believe that some > form of cryptographically authenticated integrity will > likewise be mandatory to implement (otherwise it's too > easy to hijack an authenticated connection). This means > signed cryptographic checksums, not just CRCs (as Bernard > explained). OTOH, it's not clear that confidentiality > will be mandatory to implement. > > The whole point on mandatory-to-implement vs. mandatory-to-use > is to adapt available security technologies to the circumstances. > One simple example is that confidentiality is NOT mandatory-to-use > in IPsec, otherwise AH wouldn't exist ... and 5 demerits to anyone > who uses that comment as a jumping off point to open the debate > about whether AH should exist at all on this list. > > I'm not sure that the statement that both IPsec and TLS > will be in the spec is the rough consensus of the WG at > this point. I also want to caution folks that simply > requiring these technologies to be implemented is not > sufficient to address all the security issues - one example > for iSCSI is that something will need to be said about > the relationship of target names to the identities used > for IPsec and/or TLS authentication. Let me point everyone > to Jeff Schiller's security tutorial from the San Diego > IETF meeting at: http://jis.mit.edu/sectutorial/ which > covers this and a bunch of related material on security > at a level that should be accessible to almost everyone. > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Wed Feb 7 03:39:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA26724 for ; Wed, 7 Feb 2001 03:39:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f177Y7K01712 for ips-outgoing; Wed, 7 Feb 2001 02:34:07 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d06lmsgate-3.uk.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f177WvH01673 for ; Wed, 7 Feb 2001 02:32:58 -0500 (EST) Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-3.uk.ibm.com (1.0.0) with ESMTP id HAA193328; Wed, 7 Feb 2001 07:24:13 GMT From: julian_satran@il.ibm.com Received: from d06mta03.portsmouth.uk.ibm.com (d06mta03_cs0 [9.180.35.1]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.95) with SMTP id HAA115674; Wed, 7 Feb 2001 07:32:44 GMT Received: by d06mta03.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 802569EC.00297113 ; Wed, 7 Feb 2001 07:32:39 +0000 X-Lotus-FromDomain: IBMIL@IBMDE@IBMGB To: Black_David@emc.com cc: rja@inet.org, aboba@internaut.com, ips@ece.cmu.edu, biran@il.ibm.com Message-ID: <802569EC.00296FDB.00@d06mta03.portsmouth.uk.ibm.com> Date: Wed, 7 Feb 2001 09:28:04 +0200 Subject: RE: Security Use Requirements Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk David, In Orlando the agreement was that authentication digests can be left to specialized protocols (IPsec and TLS) and iSCSI is not mandated to have them specified outside such a protocol. That was what I asked for and there was agreement on that waiting for your input from the security area. That is why I focused on the basic thing we have to specify (rather than refer to) - basic integrity and session authentication. As for mandatory to implement or not the question Josh raised is very much on all our minds - if it is external to our environment (like IPsec) what should we make mandatory to implement. IMHO we can make mandatory to implement the kickoff of a security engine (as we have in the current draft). BTW this is also the way security is implemented in all the widespread protocols today - HTTP has a TLS upgrade command, Telnet and FTP have security kickoffs etc.. NFS has nothing more either. None of them specifies anything beyond that as the security component selected is the one that is dictating what is the minimum and what the module is offering. We choose to include both TLS and IPsec as they have different capabilities (as Josh has stated already). All the above are architectural considerations and I hope we did not make any major blunder there. The issue you raised - can now be translated should we make IPsec or TLS mandatory to implement? I think we should not. Regards, Julo Black_David@emc.com on 07/02/2001 01:32:10 Please respond to Black_David@emc.com To: rja@inet.org, Julian Satran/Haifa/IBM@IBMIL cc: aboba@internaut.com, ips@ece.cmu.edu, Ofer Biran/Haifa/IBM@IBMIL Subject: RE: Security Use Requirements Some related clarifications: > I suspect that failing to make security mandatory-to- > implement will tend to prevent the specification(s) from > ever becoming IETF standards-track RFC(s). However, the WG > can certainly *try* to slide by. My original post was about mandatory-to-use, NOT mandatory-to-implement. As for making security not mandatory-to-implement ... NOT on my watch ... and remember that Steve Bellovin is one of the ips WG co-chairs, making me a "good cop" by comparison on this sort of issue ;-). > Another customary IETF position is to work on the basis that > all IETF protocols are likely (in practice) to be deployed over > The Global Internet. So the threat model discussions normally > MUST include those kind of threats and can't be limited to threats > on a private intranet. That is also correct ... and I say that with my WG co-chair hat firmly in place. There is also language to this effect in the ips WG charter. It's unfortunate that Julian focussed only on integrity in his response. Going back to the Pittsburgh (summer 2000) minutes, secure authentication will be mandatory to implement ... so sayeth the AD. I also believe that some form of cryptographically authenticated integrity will likewise be mandatory to implement (otherwise it's too easy to hijack an authenticated connection). This means signed cryptographic checksums, not just CRCs (as Bernard explained). OTOH, it's not clear that confidentiality will be mandatory to implement. The whole point on mandatory-to-implement vs. mandatory-to-use is to adapt available security technologies to the circumstances. One simple example is that confidentiality is NOT mandatory-to-use in IPsec, otherwise AH wouldn't exist ... and 5 demerits to anyone who uses that comment as a jumping off point to open the debate about whether AH should exist at all on this list. I'm not sure that the statement that both IPsec and TLS will be in the spec is the rough consensus of the WG at this point. I also want to caution folks that simply requiring these technologies to be implemented is not sufficient to address all the security issues - one example for iSCSI is that something will need to be said about the relationship of target names to the identities used for IPsec and/or TLS authentication. Let me point everyone to Jeff Schiller's security tutorial from the San Diego IETF meeting at: http://jis.mit.edu/sectutorial/ which covers this and a bunch of related material on security at a level that should be accessible to almost everyone. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Feb 7 03:39:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA26735 for ; Wed, 7 Feb 2001 03:39:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f176k7K29929 for ips-outgoing; Wed, 7 Feb 2001 01:46:07 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f176jpH29915 for ; Wed, 7 Feb 2001 01:45:51 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id HAA68394; Wed, 7 Feb 2001 07:45:41 +0100 From: julian_satran@il.ibm.com Received: from d12mta05.de.ibm.com (d12mta06_cs0 [9.165.222.255]) by d12relay02.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id HAA89120; Wed, 7 Feb 2001 07:45:23 +0100 Received: by d12mta05.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569EC.00251D92 ; Wed, 7 Feb 2001 07:45:24 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: "Bernard Aboba" cc: Black_David@emc.com, ips@ece.cmu.edu, "RJ Atkinson" , "Smb@Research. Att. Com" , biran@il.ibm.com Message-ID: Date: Wed, 7 Feb 2001 08:08:23 +0200 Subject: RE: Security Use Requirements Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Bernard, This is becoming an interesting thread. The reason we went after TLS is that it can be used for session authentication with stronger schemes than and it is very popular for software implementations. As for the cost of the hardware - the figures you quote are for 100Mbs (and even there the NIC numbers are higher). The low-end iSCSI adapters will cost well under $100 (at 1GBbs). I don't envision all the options becoming necessary for hardware implementations. The pieces we wanted from TLS can be implemented in software. If we where forced to select one I would too go for IPsec (and that is what we have in the current draft) but then we have to specify session authentication on our own and keep updating it as new schemes enter the world. It seems far better to rely on a specialized standard and TLS fits the bill. Regards, Julo "Bernard Aboba" on 06/02/2001 23:21:14 Please respond to "Bernard Aboba" To: Julian Satran/Haifa/IBM@IBMIL cc: Black_David@emc.com, ips@ece.cmu.edu, "RJ Atkinson" , "Smb@Research. Att. Com" , Ofer Biran/Haifa/IBM@IBMIL Subject: RE: Security Use Requirements >Both IPSec and TLS will be in the standard. Including *both* IPSEC and TLS as options will probably result in both much higher cost to customers as well as fewer vendors implementing either. Choosing one or the other (IPSEC is my preference) would be a better choice. In general, it is a bad idea to have too many security options in a standard. Options are bad because you have to implement them to be able to interoperate with those people who do, yet you cannot guarantee that the work will be used. In particular, including both IPSEC and TLS would cause vendors to try to implement both on the same NIC, since they could never be sure which security scheme would be used on a given iSCSI target. This would drive up the cost enormously since the acceleration architectures are very different between the protocols. >As we are talking about speeds that will be in excess of 1GBs >even on modest disk controllers we were all hesitant if to make >anything in this category mandatory to implement today. As Ran noted, making implementation mandatory doesn't mean that users have to turn it on. But not making it mandatory will probably ensure that security will not be available in most cases. Given the modest cost of adding IPSEC acceleration hardware (today IPSEC accelerated NICs are available for around $100) it is hard to see how this would be a worthwhile tradeoff. Right now, SSL/TLS acceleration hardware is a lot more expensive than IPSEC accelerators (at least $2000), so I could understand if SSL/TLS were left out of the standard. >We assume that all those who require security beyond CRC CRC provides only integrity protection, but since it is not keyed, there is no per-packet authentication or protection against spoofing or modification. CRC therefore has little or no security value. > session authentication All session authentication does is guarantee the user identity at the beginning of the session. Unless you have per-packet authentication and integrity protection, all bets are off after that. In particular, session authentication provides no protection against TCP session hijacking. >However those that build a Storage Area Newtork within a >small enterprise completely isolated from the >internet will not have to pay for what they do not need. Actually, the decision made above will guarantee that all users will need to pay a huge incremental cost for security, because of the over abundance of security options. In reality, given the projected cost of 1+ Gbps iSCSI accelerated adapters, the incremetal cost of implementing IPSEC security would be minimal. From owner-ips@ece.cmu.edu Wed Feb 7 05:47:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA27521 for ; Wed, 7 Feb 2001 05:47:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f178tDd04600 for ips-outgoing; Wed, 7 Feb 2001 03:55:13 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f178sMH04570 for ; Wed, 7 Feb 2001 03:54:22 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id JAA90492; Wed, 7 Feb 2001 09:54:15 +0100 From: julian_satran@il.ibm.com Received: from d12mta05.de.ibm.com (d12mta06_cs0 [9.165.222.255]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id JAA70096; Wed, 7 Feb 2001 09:54:11 +0100 Received: by d12mta05.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569EC.0030E748 ; Wed, 7 Feb 2001 09:54:09 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: Glen Turner cc: Black_David@emc.com, rja@inet.org, aboba@internaut.com, ips@ece.cmu.edu, biran@il.ibm.com Message-ID: Date: Wed, 7 Feb 2001 10:49:27 +0200 Subject: Re: Security Use Requirements (and security issue with iSCSI boot deployment) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Glen, You are right and we are specifically considering doing something special (and mandatory to implement -:)) for boot. Regards, Julo Glen Turner on 07/02/2001 10:10:48 Please respond to Glen Turner To: Black_David@emc.com cc: rja@inet.org, Julian Satran/Haifa/IBM@IBMIL, aboba@internaut.com, ips@ece.cmu.edu, Ofer Biran/Haifa/IBM@IBMIL Subject: Re: Security Use Requirements (and security issue with iSCSI boot deployment) Black_David@emc.com wrote: > > The whole point on mandatory-to-implement vs. mandatory-to-use > is to adapt available security technologies to the circumstances. For example, some of us run huge public anonymous FTP/HTTP servers that mirror software. They spend a lot of their time serving Linux CD images. There is a strong performance and usability case for doing this serving using iSCSI. The images are typically GPG-signed by their originators, which addresses the core security issue for the users of the CD image: did someone hack the server and alter the image? The assurance that can be provided iSCSI's security mechanisms simply can't address this question, and thus we may as well take any performance advantage from disabling them and offer the server's users an increased maximum user count. --------------------------------- Note that iSCSI-boot doesn't yet provide a mechanism for end-to-end checking that a disk image is unaltered and thus is particularly prone to serving a hacked boot image when the server has been compromised. At the least it should be noted in Security Considerations that vendors should consider providing a mechanism for vendor-to-booter verification of a boot image. It would be really nice if iSCSI-boot suggested a mechanism, so that it could be built into ROMs by manufacturers that are implementing iSCSI-boot and so that the hardware manufacturer could not use the mechanism to lock out alternative operating systems. Given the random-access nature of iSCSI this could be tricky to implement; GPG-signing each disk block might not be the best for performance :-) Nevertheless, some mechanism would be useful, otherwise iSCSI-boot becomes a neat mechanism with which to implement an enterprise-wide compromise. Glen. From owner-ips@ece.cmu.edu Wed Feb 7 06:02:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27686 for ; Wed, 7 Feb 2001 06:02:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f179eAP06223 for ips-outgoing; Wed, 7 Feb 2001 04:40:10 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f179dnH06208 for ; Wed, 7 Feb 2001 04:39:49 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.132.205]) by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id EAA127624; Wed, 7 Feb 2001 04:24:10 -0500 Received: from f5n70e (d03nm094h.boulder.ibm.com [9.99.140.70]) by westrelay02.boulder.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id CAA57204; Wed, 7 Feb 2001 02:39:47 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: Security Use Requirements To: RJ Atkinson Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Wed, 7 Feb 2001 01:37:05 -0800 X-MIMETrack: Serialize by Router on D03NM094/03/M/IBM(Release 5.0.6 |December 14, 2000) at 02/07/2001 02:39:47 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk RJ, I can not tell, from the obvious intensity of your note, if you agree with me are not. As Julian pointed out the prices were probably for the 100 Mb/s links. In any event. the need is for security is at least 3DES. Also the cost of a Gigabit chip for 3DES, I just found out, is $300 for Samples. If you go from Cost to street price, you will probably have a 3x difference. Now, that is a bit much for only one of the key componets on an iSCSI/TOE HBA that is suppose to be competitive to Fibre Channels. Therefore, I am reconsidering my statements, that we Must Implement. Your opinion might be useful here. I had thought that in the real world, separate box IPSec/ TLS, at the edge of the secure network might be all that is required. Since we must also consider the SW implementations on Desktops and Laptops perhaps IPSec is OK there, since the volume of data will be relatively slow. Now, I am beginning to think that it is reasonable for one of the following approaches to be OK. That is, one of those approaches should meet the requirement for "Must Implement". 1. Only implementing an interface to the external IPSec/TLS box 2, SW implementation of IPSec/TLS 3. HW IPSec/TLS In this case, if the customer wants protection, they either pay for the separate IPSec/TLS box (can be shared by many connections), or the HW IPSec/TLS or accept the overhead and lack of speed in SW implementations. OK folks, lets here all your opinions on this. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Internet address: hufferd@us.ibm.com RJ Atkinson @ece.cmu.edu on 02/06/2001 01:29:38 PM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: "Bernard Aboba" , , , "RJ Atkinson" , "Smb@Research. Att. Com" Subject: RE: Security Use Requirements At 16:21 06/02/01, John Hufferd wrote: >I think that Julian addressed this, but, an installation might want only >the connection to the local environment, and if so administratively tell >the iSCSI ends to not do the encryption etc. Especially if some of the >ends are Laptops and Desktops. But all side must implement the features. Implement != turn on operationally. The above explains why clever vendors might have a configuration knob to turn off security. The above does NOT make any kind of case for not always *implementing* security. >By the way you might have slightly overstated the IPSec chips going at full >gig speed, when you talk about triple Des. And if there are some they are >not within the normal costs one would expect for a iSCSI NIC HBA. So if you believe the costs are so high, implement single DES. For a lot of threat environments DES-CBC is sufficient and it surely beats the hell out of nothing. By the way, the crypto parts vendors that I'm talking with must be giving me better prices than you, which I find surprising, since by the parts quotes I'm seeing Bernard's math works just fine. Nothing anyone has said here has given any kind of reasonable excuse to not make implementing security mandatory. There has been lots of rationale for making it optional for the user to turn on for a given box, but nothing for making it optional to implement. (Implement in the box != deploy operationally). Ran rja@inet.org From owner-ips@ece.cmu.edu Wed Feb 7 08:30:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29018 for ; Wed, 7 Feb 2001 08:30:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17BOAE22246 for ips-outgoing; Wed, 7 Feb 2001 06:24:10 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17BO2H22237 for ; Wed, 7 Feb 2001 06:24:02 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id MAA35922; Wed, 7 Feb 2001 12:23:53 +0100 From: julian_satran@il.ibm.com Received: from d12mta05.de.ibm.com (d12mta06_cs0 [9.165.222.255]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id MAA108428; Wed, 7 Feb 2001 12:23:49 +0100 Received: by d12mta05.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569EC.003E9BB6 ; Wed, 7 Feb 2001 12:23:50 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: "John Hufferd" cc: RJ Atkinson , ips@ece.cmu.edu Message-ID: Date: Wed, 7 Feb 2001 13:19:16 +0200 Subject: RE: Security Use Requirements Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk It would be interesting to findout if the chips support transport IPsec or tunneling IPsec or both. For tunneling IPsec you have to be a "believer" - i.e., you'll have to believe that there is such a think on the wire as iSCSI is oblivious to it. However if provided in an external box it can provide excellent security. The "required to implement" statement - if made by iSCSI - would have only propaganda value as it can't be assessed in a compliance testing suite. Julo "John Hufferd" on 07/02/2001 11:37:05 Please respond to "John Hufferd" To: RJ Atkinson cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements RJ, I can not tell, from the obvious intensity of your note, if you agree with me are not. As Julian pointed out the prices were probably for the 100 Mb/s links. In any event. the need is for security is at least 3DES. Also the cost of a Gigabit chip for 3DES, I just found out, is $300 for Samples. If you go from Cost to street price, you will probably have a 3x difference. Now, that is a bit much for only one of the key componets on an iSCSI/TOE HBA that is suppose to be competitive to Fibre Channels. Therefore, I am reconsidering my statements, that we Must Implement. Your opinion might be useful here. I had thought that in the real world, separate box IPSec/ TLS, at the edge of the secure network might be all that is required. Since we must also consider the SW implementations on Desktops and Laptops perhaps IPSec is OK there, since the volume of data will be relatively slow. Now, I am beginning to think that it is reasonable for one of the following approaches to be OK. That is, one of those approaches should meet the requirement for "Must Implement". 1. Only implementing an interface to the external IPSec/TLS box 2, SW implementation of IPSec/TLS 3. HW IPSec/TLS In this case, if the customer wants protection, they either pay for the separate IPSec/TLS box (can be shared by many connections), or the HW IPSec/TLS or accept the overhead and lack of speed in SW implementations. OK folks, lets here all your opinions on this. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Internet address: hufferd@us.ibm.com RJ Atkinson @ece.cmu.edu on 02/06/2001 01:29:38 PM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: "Bernard Aboba" , , , "RJ Atkinson" , "Smb@Research. Att. Com" Subject: RE: Security Use Requirements At 16:21 06/02/01, John Hufferd wrote: >I think that Julian addressed this, but, an installation might want only >the connection to the local environment, and if so administratively tell >the iSCSI ends to not do the encryption etc. Especially if some of the >ends are Laptops and Desktops. But all side must implement the features. Implement != turn on operationally. The above explains why clever vendors might have a configuration knob to turn off security. The above does NOT make any kind of case for not always *implementing* security. >By the way you might have slightly overstated the IPSec chips going at full >gig speed, when you talk about triple Des. And if there are some they are >not within the normal costs one would expect for a iSCSI NIC HBA. So if you believe the costs are so high, implement single DES. For a lot of threat environments DES-CBC is sufficient and it surely beats the hell out of nothing. By the way, the crypto parts vendors that I'm talking with must be giving me better prices than you, which I find surprising, since by the parts quotes I'm seeing Bernard's math works just fine. Nothing anyone has said here has given any kind of reasonable excuse to not make implementing security mandatory. There has been lots of rationale for making it optional for the user to turn on for a given box, but nothing for making it optional to implement. (Implement in the box != deploy operationally). Ran rja@inet.org From owner-ips@ece.cmu.edu Wed Feb 7 10:51:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02152 for ; Wed, 7 Feb 2001 10:51:27 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17DcCr27444 for ips-outgoing; Wed, 7 Feb 2001 08:38:12 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gnat.inet.org (209-9-249-62.sdsl.cais.net [209.9.249.62]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17DFmH26425 for ; Wed, 7 Feb 2001 08:15:52 -0500 (EST) Received: from mosquito.inet.org (mosquito.inet.org [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 389768264F; Wed, 7 Feb 2001 08:14:15 -0500 (EST) Message-Id: <5.0.0.25.2.20010207080020.009fcd80@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0 X-Priority: 1 (Highest) Date: Wed, 07 Feb 2001 08:05:52 -0500 To: "John Hufferd" From: RJ Atkinson Subject: RE: Security Use Requirements Cc: RJ Atkinson , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk At 04:37 07/02/01, John Hufferd wrote: > In any event. the need is for security is at least 3DES. It is illogical to argue that having NO SECURITY is better than having DES-CBC. Since you appear to be doing precisely this, I must be confused by your words and not following you clearly. Can you kindly clarify ? >Also the cost of a Gigabit chip for 3DES, I just found out, >is $300 for Samples. That's not what I'm seeing, but in any event, I think the discussion of hardware is not terribly on point. >Now, I am beginning to think that it is reasonable for one >of the following approaches to be OK. That is, one of those >approaches should meet the requirement for "Must Implement". >1. Only implementing an interface to the external IPSec/TLS box >2, SW implementation of IPSec/TLS >3. HW IPSec/TLS (1) is a non-starter because it means no security will be widely available to users/operators, IMHO. IETF would never say whether a particular implementation had to be done in hardware or software; that is obviously an implementation detail and product differentiator. So from an IETF perspective (2) and (3) are identical and boil down to putting "must implement security" into the specifications (for whichever security the WG converges on). Ran rja@inet.org From owner-ips@ece.cmu.edu Wed Feb 7 10:51:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02168 for ; Wed, 7 Feb 2001 10:51:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17DrCo28237 for ips-outgoing; Wed, 7 Feb 2001 08:53:12 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17DqDH28185 for ; Wed, 7 Feb 2001 08:52:14 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id IAA22657 for ips@ece.cmu.edu; Wed, 7 Feb 2001 08:51:44 -0500 (EST) Date: Wed, 7 Feb 2001 08:51:44 -0500 (EST) From: Scott Bradner Message-Id: <200102071351.IAA22657@newdev.harvard.edu> To: ips@ece.cmu.edu Subject: RE: Security Use Requirements Sender: owner-ips@ece.cmu.edu Precedence: bulk it should be noted that the IPS working group was not given the option of not having a mandatory to implement security scheme in the standard The IESG will not approve an IPS standard that does not define a specific mandatory to implement security scheme. Scott From owner-ips@ece.cmu.edu Wed Feb 7 10:51:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02169 for ; Wed, 7 Feb 2001 10:51:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17DcER27447 for ips-outgoing; Wed, 7 Feb 2001 08:38:14 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from tiny-teddy.aarnet.edu.au (IDENT:root@tiny-teddy.aarnet.edu.au [203.21.37.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f178B2H03039 for ; Wed, 7 Feb 2001 03:11:03 -0500 (EST) Received: from aarnet.edu.au (bush.aarnet.adelaide.edu.au [129.127.80.130]) by tiny-teddy.aarnet.edu.au (8.9.3/8.9.3) with ESMTP id SAA05454; Wed, 7 Feb 2001 18:40:16 +1030 Message-ID: <3A810307.EF2AA637@aarnet.edu.au> Date: Wed, 07 Feb 2001 18:40:48 +1030 From: Glen Turner Organization: Australian Academic and Research Network X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Black_David@emc.com CC: rja@inet.org, julian_satran@il.ibm.com, aboba@internaut.com, ips@ece.cmu.edu, biran@il.ibm.com Subject: Re: Security Use Requirements (and security issue with iSCSI boot deployment) References: <0F31E5C394DAD311B60C00E029101A07041014F1@corpmx9.isus.emc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Black_David@emc.com wrote: > > The whole point on mandatory-to-implement vs. mandatory-to-use > is to adapt available security technologies to the circumstances. For example, some of us run huge public anonymous FTP/HTTP servers that mirror software. They spend a lot of their time serving Linux CD images. There is a strong performance and usability case for doing this serving using iSCSI. The images are typically GPG-signed by their originators, which addresses the core security issue for the users of the CD image: did someone hack the server and alter the image? The assurance that can be provided iSCSI's security mechanisms simply can't address this question, and thus we may as well take any performance advantage from disabling them and offer the server's users an increased maximum user count. --------------------------------- Note that iSCSI-boot doesn't yet provide a mechanism for end-to-end checking that a disk image is unaltered and thus is particularly prone to serving a hacked boot image when the server has been compromised. At the least it should be noted in Security Considerations that vendors should consider providing a mechanism for vendor-to-booter verification of a boot image. It would be really nice if iSCSI-boot suggested a mechanism, so that it could be built into ROMs by manufacturers that are implementing iSCSI-boot and so that the hardware manufacturer could not use the mechanism to lock out alternative operating systems. Given the random-access nature of iSCSI this could be tricky to implement; GPG-signing each disk block might not be the best for performance :-) Nevertheless, some mechanism would be useful, otherwise iSCSI-boot becomes a neat mechanism with which to implement an enterprise-wide compromise. Glen. From owner-ips@ece.cmu.edu Wed Feb 7 10:57:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02286 for ; Wed, 7 Feb 2001 10:57:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17DpHS28137 for ips-outgoing; Wed, 7 Feb 2001 08:51:17 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mms2.broadcom.com (mms2.broadcom.com [63.70.210.59]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f17DofH28098 for ; Wed, 7 Feb 2001 08:50:41 -0500 (EST) Received: from 63.70.210.33 by mms2.broadcom.com with ESMTP (Broadcom MMS-2 SMTP Relay (MMS v4.7)); Wed, 07 Feb 2001 05:50:34 -0800 X-Server-Uuid: 2a12fa22-b688-11d4-a6a1-00508bfc9626 Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id FAA08551; Wed, 7 Feb 2001 05:50:39 -0800 (PST) Received: from LTSJ000319 ([10.252.12.21]) by mail-sj1-1.sj.broadcom.com (8.8.8/8.8.8/MS01) with SMTP id FAA02325; Wed, 7 Feb 2001 05:50:36 -0800 (PST) From: "Dan Eakins" To: "'John Hufferd'" , "'Bernard Aboba'" cc: ips@ece.cmu.edu, Black_David@emc.com, "'RJ Atkinson'" , "'Smb@Research. Att. Com'" Subject: RE: Security Use Requirements Date: Tue, 6 Feb 2001 18:06:08 -0800 Message-ID: <001201c0910d$090a0d70$0100007f@LTSJ000319> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-WSS-ID: 169F8D2042444-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John and Bernard, I can't agree more with Bernard's comments regarding a single security solution. By implementing a standard like IPsec and leveraging off the volumes of the mainstream market you will achieve the end goal of lowering the cost of adding security to the adapter, plus you will add the likelihood of many silcon vendors implementing a solution which will in turn foster competition and ultimately make the technology more affordable. We have silicon that does 2.4 Gbps IPsec 3DES and MD5 authentication on virtually all packet sizes today, and it is sampling. Our plan is to move this into mainstream PC servers, routers, and switches which will have full duplex Gig Enet ports standard. The way to get affordable silicon is to make big markets for the devices. So to help us engineer silicon solutions to fit this, what is the price target of an iSCSI NIC HBA? What is the market size that a silicon vendor could expect here over a 18-36 month cycle? Over the next 12-18 months the market will see the prices for these solutions drop as the volumes build. As a vendor sitting on the supply side of the equation it would make our job of serving the market easier by leveraging the R&D efforts already expended and aligning yourself with industry roadmaps. In addition the target of hitting 10G IPsec is not so far off as there is a race to develop this techology first as a chip or chipset solution already. From what I see using IPsec here is a safe bet in hitting these objectives - security, performance, scalability, and affordable solutions that can be widely deployed. Daniel Eakins Senior Product Line Manager Broadcom Corp. Security Line of Business -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of John Hufferd Sent: Tuesday, February 06, 2001 1:22 PM To: Bernard Aboba Cc: ips@ece.cmu.edu; Black_David@emc.com; RJ Atkinson; Smb@Research. Att. Com Subject: RE: Security Use Requirements Bernard, I think that Julian addressed this, but, an installation might want only the connection to the local environment, and if so administratively tell the iSCSI ends to not do the encryption etc. Especially if some of the ends are Laptops and Desktops. But all side must implement the features. By the way you might have slightly overstated the IPSec chips going at full gig speed, when you talk about triple Des. And if there are some they are not within the normal costs one would expect for a iSCSI NIC HBA. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Internet address: hufferd@us.ibm.com "Bernard Aboba" @ece.cmu.edu on 02/05/2001 03:26:13 PM Sent by: owner-ips@ece.cmu.edu To: , cc: "RJ Atkinson" , "Smb@Research. Att. Com" Subject: RE: Security Use Requirements It is hard for me to see how you could get away with no security services at all (e.g. no per-packet authentication and integrity protection for iSCSI PDUs). After all, we're talking about facilities that are used by the world's major financial institutions. If this data isn't worth protecting, I don't know what is. Do you really want attackers to be able to manipulate the contents of bank accounts at will over the Internet? Furthermore, there really isn't a sound technical argument for dispensing with security. There are chipsets available that can provide IPSEC integrity and authentication services at speeds of 1 Gbps or higher. -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Black_David@emc.com Sent: Monday, February 05, 2001 12:54 PM To: ips@ece.cmu.edu Subject: Security Use Requirements In Orlando, I picked up an action item to determine what the requirements are for *use* of security features, as opposed to requirements for *implementation*. I believe the answer to be that it is acceptable to specify security measures weaker than those one would want to use in full generality on a public network, where "weaker" includes no security. There are two important caveats that apply: - Security of the negotiation mechanism becomes very important when this is done, as there's an obvious man-in-the-middle attack on the negotiation mechanism to get the endpoints to negotiate weaker security than they intended. - The weaker security mechanisms need to be documented in terms of their security properties (and lack thereof), as well as environments in which they are appropriate. The "Security Considerations" section of RFC 2338 (VRRP) has been recommended as a good example of this. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Feb 7 12:13:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03937 for ; Wed, 7 Feb 2001 12:13:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17EiGc00813 for ips-outgoing; Wed, 7 Feb 2001 09:44:16 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [168.159.208.81]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17EhCH00756 for ; Wed, 7 Feb 2001 09:43:18 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2650.21) id <1FQHGJFF>; Wed, 7 Feb 2001 09:43:32 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A07041014F3@corpmx9.isus.emc.com> From: Black_David@emc.com To: jtseng@NishanSystems.com, Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Wed, 7 Feb 2001 09:42:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk > Question: Does your "mandatory-to-implement" mean > "mandatory-to-implement-on-the-same-box", or > "mandatory-to-implement-on-the-same-or-different-box"? Mandatory-to-implement means "how the protocol behaves on the wire" -- i.e., if one party starts to use a mandatory-to- implement mechanism, the other party must respond appropriately. Whether 1, 5, or 15 boxes are used is not something a protocol spec should care about, although if more than one box is used, whoever assembles those boxes will have to deal with the security issues that arise on the interfaces among the boxes. > IPSec security gateways are widely available now, from > many different vendors. Are you ruling out their use > to fulfill the security requirement? I'm definitely not ruling out such gateways, but I want to make sure everyone understands that there will probably be interactions between such gateways and iSCSI in the area of naming - we are going to have to say something about how IPSec's notion of identities (e.g., X.509 certificates, and in the SAD/SPD) match up with iSCSI's notions (i.e., initiator and target names). If the gateway is completely independent of the iSCSI system, it'll fall to some higher level of management software or possibly manual configuration to make sure that the gateway and the corresponding iSCSI system(s) are configured consistently. > In Orlando the agreement was that authentication digests can be left to > specialized protocols (IPsec and TLS) and iSCSI > is not mandated to have them specified outside such a protocol. Good thing, as there are lots of ways to get authentication protocols and the related integrity digests subtly wrong. > The issue you raised - can now be translated should we make IPsec or TLS > mandatory to implement? That is correct - we are headed in the direction of making at least one of those two mandatory to implement. Note that it will NOT be acceptable to say "implement at least one of these" and let implementers choose which one because then an implementation that chose IPSec will not interoperate with one that chose TLS (which is a wrong answer). --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Feb 7 12:15:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03974 for ; Wed, 7 Feb 2001 12:14:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17FNED02946 for ips-outgoing; Wed, 7 Feb 2001 10:23:14 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17FNBH02941 for ; Wed, 7 Feb 2001 10:23:11 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id KAA23248 for ips@ece.cmu.edu; Wed, 7 Feb 2001 10:23:11 -0500 (EST) Date: Wed, 7 Feb 2001 10:23:11 -0500 (EST) From: Scott Bradner Message-Id: <200102071523.KAA23248@newdev.harvard.edu> To: ips@ece.cmu.edu Subject: RE: Security Use Requirements Sender: owner-ips@ece.cmu.edu Precedence: bulk > That pretty much settles the discussion by assertion. the iesg does impose requirements on working groups from time to time where it feels the security, stability or scaleability of the net is an issue. > Is it acceptable to say that a minimal compliant iSCSI implementation MUST > include either: > > - a minimal tunneling IPsec gateway > - a minimal transport IPsec as a general rule there is a requirement for "a mandatory to implement" so that there is at least one sure to work technology - some working groups have added flexbility by having servers having more than one mandayory to implement where clients can chose one of the set that servers have to implement I think its up to the WG to decide this one Scott From owner-ips@ece.cmu.edu Wed Feb 7 12:15:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03994 for ; Wed, 7 Feb 2001 12:15:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17FCIh02345 for ips-outgoing; Wed, 7 Feb 2001 10:12:18 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17FBYH02289 for ; Wed, 7 Feb 2001 10:11:34 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id QAA106974 for ; Wed, 7 Feb 2001 16:11:20 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id QAA24758 for ; Wed, 7 Feb 2001 16:11:16 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569EC.00536A68 ; Wed, 7 Feb 2001 16:11:07 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu cc: biran@il.ibm.com Message-ID: Date: Wed, 7 Feb 2001 17:06:45 +0200 Subject: RE: Security Use Requirements Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Scott, That pretty much settles the discussion by assertion. Is it acceptable to say that a minimal compliant iSCSI implementation MUST include either: - a minimal tunneling IPsec gateway - a minimal transport IPsec ? Regards, Julo Scott Bradner on 07/02/2001 15:51:44 Please respond to Scott Bradner To: ips@ece.cmu.edu cc: Subject: RE: Security Use Requirements it should be noted that the IPS working group was not given the option of not having a mandatory to implement security scheme in the standard The IESG will not approve an IPS standard that does not define a specific mandatory to implement security scheme. Scott From owner-ips@ece.cmu.edu Wed Feb 7 14:04:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06603 for ; Wed, 7 Feb 2001 14:04:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17GPF406522 for ips-outgoing; Wed, 7 Feb 2001 11:25:15 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17GOoH06499 for ; Wed, 7 Feb 2001 11:24:50 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id LAA23742 for ips@ece.cmu.edu; Wed, 7 Feb 2001 11:24:50 -0500 (EST) Date: Wed, 7 Feb 2001 11:24:50 -0500 (EST) From: Scott Bradner Message-Id: <200102071624.LAA23742@newdev.harvard.edu> To: ips@ece.cmu.edu Subject: RE: Security Use Requirements Sender: owner-ips@ece.cmu.edu Precedence: bulk John asks: > That > is, it could be acceptable to have a gateway box included in the must > implement. how would this deal with the case where the "gateway box" is built into a device? (i.e. no seperate gateway box) Scott From owner-ips@ece.cmu.edu Wed Feb 7 14:07:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06720 for ; Wed, 7 Feb 2001 14:07:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17GKH806258 for ips-outgoing; Wed, 7 Feb 2001 11:20:17 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17GJEH06205 for ; Wed, 7 Feb 2001 11:19:14 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.132.205]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA275084; Wed, 7 Feb 2001 11:12:12 -0500 Received: from f5n70e (d03nm094h.boulder.ibm.com [9.99.140.70]) by westrelay02.boulder.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id JAA165890; Wed, 7 Feb 2001 09:18:55 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: Security Use Requirements To: Scott Bradner Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Wed, 7 Feb 2001 08:17:57 -0800 X-MIMETrack: Serialize by Router on D03NM094/03/M/IBM(Release 5.0.6 |December 14, 2000) at 02/07/2001 09:19:06 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Scott, et.al., Julian's first option below, was perhaps the same as my first option. That is, it could be acceptable to have a gateway box included in the must implement. I believe, with nothing to back it, that there are "driver to Gateway" responses that an implementation can use and therefore be validated that the implementation adheres to the must implement statement. Does this sound right you Scott? For reference here is my previous statement: Now, I am beginning to think that it is reasonable for one of the following approaches to be OK. That is, one of those approaches should meet the requirement for "Must Implement". 1. Only implementing an interface to the external IPSec/TLS box 2, SW implementation of IPSec/TLS 3. HW IPSec/TLS . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 02/07/2001 07:06:45 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Ofer Biran/Haifa/IBM@IBMIL Subject: RE: Security Use Requirements Scott, That pretty much settles the discussion by assertion. Is it acceptable to say that a minimal compliant iSCSI implementation MUST include either: - a minimal tunneling IPsec gateway - a minimal transport IPsec ? Regards, Julo Scott Bradner on 07/02/2001 15:51:44 Please respond to Scott Bradner To: ips@ece.cmu.edu cc: Subject: RE: Security Use Requirements it should be noted that the IPS working group was not given the option of not having a mandatory to implement security scheme in the standard The IESG will not approve an IPS standard that does not define a specific mandatory to implement security scheme. Scott From owner-ips@ece.cmu.edu Wed Feb 7 16:28:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09341 for ; Wed, 7 Feb 2001 16:28:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17IKMQ13294 for ips-outgoing; Wed, 7 Feb 2001 13:20:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17IJBH13212 for ; Wed, 7 Feb 2001 13:19:11 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.132.205]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA233968; Wed, 7 Feb 2001 13:12:00 -0500 Received: from f3n42e (d03nm042h.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id LAA171066; Wed, 7 Feb 2001 11:18:46 -0700 Importance: Normal Subject: Re: Security Use Requirements (and security issue with iSCSI boot deployment) To: "Julian Satran" Cc: Glen Turner , Black_David@emc.com, rja@inet.org, aboba@internaut.com, ips@ece.cmu.edu, "Ofer Biran" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Prasenjit Sarkar" Date: Wed, 7 Feb 2001 10:21:38 -0800 X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 02/07/2001 10:18:49 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Can you explain more about the mechanism for "boot" that you hinted about? Specially, your thoughts on vendor-to-booter boot image verification versus initiator-target mutual authentication/data integrity. Thanks, Prasenjit Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 02/07/2001 12:49:27 AM Sent by: owner-ips@ece.cmu.edu To: Glen Turner cc: Black_David@emc.com, rja@inet.org, aboba@internaut.com, ips@ece.cmu.edu, Ofer Biran/Haifa/IBM@IBMIL Subject: Re: Security Use Requirements (and security issue with iSCSI boot deployment) Glen, You are right and we are specifically considering doing something special (and mandatory to implement -:)) for boot. Regards, Julo Glen Turner on 07/02/2001 10:10:48 Please respond to Glen Turner To: Black_David@emc.com cc: rja@inet.org, Julian Satran/Haifa/IBM@IBMIL, aboba@internaut.com, ips@ece.cmu.edu, Ofer Biran/Haifa/IBM@IBMIL Subject: Re: Security Use Requirements (and security issue with iSCSI boot deployment) Black_David@emc.com wrote: > > The whole point on mandatory-to-implement vs. mandatory-to-use > is to adapt available security technologies to the circumstances. For example, some of us run huge public anonymous FTP/HTTP servers that mirror software. They spend a lot of their time serving Linux CD images. There is a strong performance and usability case for doing this serving using iSCSI. The images are typically GPG-signed by their originators, which addresses the core security issue for the users of the CD image: did someone hack the server and alter the image? The assurance that can be provided iSCSI's security mechanisms simply can't address this question, and thus we may as well take any performance advantage from disabling them and offer the server's users an increased maximum user count. --------------------------------- Note that iSCSI-boot doesn't yet provide a mechanism for end-to-end checking that a disk image is unaltered and thus is particularly prone to serving a hacked boot image when the server has been compromised. At the least it should be noted in Security Considerations that vendors should consider providing a mechanism for vendor-to-booter verification of a boot image. It would be really nice if iSCSI-boot suggested a mechanism, so that it could be built into ROMs by manufacturers that are implementing iSCSI-boot and so that the hardware manufacturer could not use the mechanism to lock out alternative operating systems. Given the random-access nature of iSCSI this could be tricky to implement; GPG-signing each disk block might not be the best for performance :-) Nevertheless, some mechanism would be useful, otherwise iSCSI-boot becomes a neat mechanism with which to implement an enterprise-wide compromise. Glen. From owner-ips@ece.cmu.edu Wed Feb 7 17:01:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09818 for ; Wed, 7 Feb 2001 17:01:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17J4J315914 for ips-outgoing; Wed, 7 Feb 2001 14:04:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17J3pH15893 for ; Wed, 7 Feb 2001 14:03:52 -0500 (EST) Received: from colosus2.cup.hp.com (colosus2.cup.hp.com [15.13.128.145]) by palrel3.hp.com (Postfix) with ESMTP id 0D37985 for ; Wed, 7 Feb 2001 11:03:44 -0800 (PST) Received: from hp.com (IDENT:plabat@pl703521.cup.hp.com [15.13.133.216]) by colosus2.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id LAA26210; Wed, 7 Feb 2001 11:03:42 -0800 (PST) Message-ID: <3A819C49.A1456BAD@hp.com> Date: Wed, 07 Feb 2001 11:04:41 -0800 From: Pierre Labat Organization: Hewlett Packard ATM-SISL X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: ISCSI: Immediate data extending beyond a single PDU References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Barry Reinhold wrote: > Julian, > I think one could carry on a debate about what the draft currently states > about the coupling of immediate and unsolicited data - but it is probably > more productive to figure out if we want to have both the concept of > immediate data and unsolicited data and then worry about the wording in the > draft. > I am of the opinion that immediate data (data within a single PDU) is a > useful distincition from unsolicited data (iSCSI DATA PDU sent without R2T). > The reasoning behind this is that there are a number of write IOs that can > be satisfied by providing a buffer of 8K or less. If this data is contained > in the command PDU the context can be created for the command, and then the > data just happens to be sitting there with the context to process it. Thus > the target can send the iSCSI response PDU without creating any special > context or mechansims - should have nice low latency characteristics for > small writes. > For devices that don't want to use the initiator task tag for establishing > context of an iSCSI DATA PDU, immediate data is a nice thing. An iSCSI DATA > PDU without a target task tag may not be such a nice thing. > Question here - What would you lose if you supported only immediate data? Barry, Initiators that want to use small iSCSI PDUs (less than 8k) cannot send the 8k data as immediate. They have to send it in several small unsolicited data PDUs. It 's why we must keep this alternative to immediate data. Regards, Pierre From owner-ips@ece.cmu.edu Wed Feb 7 17:05:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09899 for ; Wed, 7 Feb 2001 17:05:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17JDJ116457 for ips-outgoing; Wed, 7 Feb 2001 14:13:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17JBxH16389 for ; Wed, 7 Feb 2001 14:12:00 -0500 (EST) Received: from phys-ha10nwka.ebay.sun.com ([129.150.188.210]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26808; Wed, 7 Feb 2001 11:11:54 -0800 (PST) Received: from ebay.sun.com (jetsun [129.150.144.86]) by phys-ha10nwka.ebay.sun.com (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id LAA11043; Wed, 7 Feb 2001 11:11:52 -0800 (PST) Message-ID: <3A819DF8.BF6F39C9@ebay.sun.com> Date: Wed, 07 Feb 2001 11:11:52 -0800 From: David Robinson Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: julian_satran@il.ibm.com CC: Black_David@emc.com, rja@inet.org, aboba@internaut.com, ips@ece.cmu.edu, biran@il.ibm.com Subject: Re: Security Use Requirements References: <802569EC.00296FDB.00@d06mta03.portsmouth.uk.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit julian_satran@il.ibm.com wrote: > BTW this is also the way security is implemented in all the > widespread protocols today - HTTP has a TLS upgrade command, Telnet and FTP > have security kickoffs etc.. NFS has nothing more either. None of them > specifies anything beyond that as the security component selected is the > one that is dictating what is the minimum and what the module is offering. Having gone through the history of NFS standing for No F****** Security has rightfully gone through the exercise of creating a robust and flexible security infrastructure based on GSSAPI. It also mandates to implement two different mechanisms that covers both Enterprise size security concerns (Kerberos V5) and Internet size security (Lipkey). As I espoused back in Pittsburgh, the IPS group would be very short sighted not to make authentication, integrity, and privacy manditory to implement. Even if the IESG let less through, it would result in IPS effectively having no security and condemming it to only the system area network market. I will cite past non-standard attempts to secure NFS as examples. Yes, there are costs and performance implications, but volume and technology will help over the life of the protocol and a customer can always turn security off if they feel they are safe enough. -David From owner-ips@ece.cmu.edu Wed Feb 7 17:52:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11301 for ; Wed, 7 Feb 2001 17:52:27 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17KLhp20719 for ips-outgoing; Wed, 7 Feb 2001 15:21:43 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17KKlH20662 for ; Wed, 7 Feb 2001 15:20:47 -0500 (EST) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2448.0) id ; Wed, 7 Feb 2001 12:13:36 -0800 Message-ID: From: Joshua Tseng To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Wed, 7 Feb 2001 12:13:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ips@ece.cmu.edu Precedence: bulk > > Mandatory-to-implement means "how the protocol behaves > on the wire" -- i.e., if one party starts to use a mandatory-to- > implement mechanism, the other party must respond > appropriately. Whether 1, 5, or 15 boxes are used > is not something a protocol spec should care about, > although if more than one box is used, whoever assembles > those boxes will have to deal with the security issues > that arise on the interfaces among the boxes. The Security WG has invested a lot of time and effort defining "tunnel mode", and its good to see that this can be leveraged for iSCSI. > > I'm definitely not ruling out such gateways, but I want to make > sure everyone understands that there will probably be interactions > between such gateways and iSCSI in the area of naming - we > are going to have to say something about how IPSec's notion > of identities (e.g., X.509 certificates, and in the SAD/SPD) match > up with iSCSI's notions (i.e., initiator and target names). ISAKMP has an optional field for identification, defined in section 3.8 of RFC 2408. IKE uses this to identify the initiator and responder. Here is the text from RFC 2409: IDx is the identification payload for "x". x can be: "ii" or "ir" for the ISAKMP initiator and responder respectively during phase one negotiation; or "ui" or "ur" for the user initiator and responder respectively during phase two. The ID payload format for the Internet DOI is defined in [Pip97]. As far as a host-based IPSec implementation is concerned, we could use this for the WWUI to identify the initiator and target (I don't think its feasible to have external security gateways use WWUI). An IKE negotiation between iSCSI devices could thus use the WWUI to set up the IPSec SA's. However, RFC 2407 section 4.6.2.1 (IPSec DOI) indicates the only identifiers usable (at least at the time of writing of RFC 2407) are FQDN's, IP addresses or subnets, X500 names, or X509 certificates as the identifier. If iSCSI intends to use WWUI, we would need to coordinate with IANA to add in WWUI as another identifier type. But I wonder if this is all really necessary??? Isn't it sufficient to have the IP addresses identify the SA endpoints? Isn't this what most ISAKMP implementations are doing? Is anyone aware of any other application that use something other than IP addresses or FQDN's to negotiate IPSec SA's??? This leads to the original point I was trying to make at the interim meeting, that for all practical purpposes, IPSec SA's really need only be negotiated between IP addresses. Once a connection has been secured between the IP addresses, then WWUI's are used for authorization in the iSCSI login exchange. Sure, if we really wanted we could go in and include the WWUI in the ISAKMP exchange, but I question if this adds any value at all. Josh > If the gateway is completely independent of the iSCSI system, > it'll fall to some higher level of management software or possibly > manual configuration to make sure that the gateway and the > corresponding iSCSI system(s) are configured consistently. > > > In Orlando the agreement was that authentication digests > can be left to > > specialized protocols (IPsec and TLS) and iSCSI > > is not mandated to have them specified outside such a protocol. > > Good thing, as there are lots of ways to get authentication protocols > and the related integrity digests subtly wrong. > > > The issue you raised - can now be translated should we make > IPsec or TLS > > mandatory to implement? > > That is correct - we are headed in the direction of making at > least one of > those two mandatory to implement. Note that it will NOT be > acceptable to > say "implement at least one of these" and let implementers > choose which > one because then an implementation that chose IPSec will not > interoperate > with one that chose TLS (which is a wrong answer). > > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Wed Feb 7 17:53:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11396 for ; Wed, 7 Feb 2001 17:53:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17IuJX15482 for ips-outgoing; Wed, 7 Feb 2001 13:56:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17Iu6H15470 for ; Wed, 7 Feb 2001 13:56:06 -0500 (EST) Received: from colosus2.cup.hp.com (colosus2.cup.hp.com [15.13.128.145]) by palrel3.hp.com (Postfix) with ESMTP id 79359AFF for ; Wed, 7 Feb 2001 10:55:59 -0800 (PST) Received: from hp.com (IDENT:plabat@pl703521.cup.hp.com [15.13.133.216]) by colosus2.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id KAA26112; Wed, 7 Feb 2001 10:55:58 -0800 (PST) Message-ID: <3A819A79.92209522@hp.com> Date: Wed, 07 Feb 2001 10:56:57 -0800 From: Pierre Labat Organization: Hewlett Packard ATM-SISL X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: ISCSI: Immediate data extending beyond a single PDU References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit julian_satran@il.ibm.com wrote: > Barry, > > I think that the current draft does not allow you to accept immediate but > not unsolicited. > You can either allow unsolicited (including immediate) or request always > R2T. > > And yes - if the expected length is larger that what you sent as > unsolicited (even if the unsolicited was less than the limit) the target is > supposed to send R2T (there is only one unsolicited burst per command). Julian, Barry, I think there is a problem, as stated Barry, if the initiator decides to send unsolicited data but less than the Firstburst and the expected length is greater than the Firstburst. In this case the initiator after sending some unsolicited data waits for an R2T to continue and the target waits for a First burst load of data before sending an R2T. Solution ====== To avoid that, it should be explicitely stated (may be it's what is assumed but i can't read it) that when the initiator sends unsolicited non immediate data, it must send unsolicited data up to Firstburst or Expected data length whichever is less. Regards, Pierre From owner-ips@ece.cmu.edu Wed Feb 7 17:53:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11457 for ; Wed, 7 Feb 2001 17:53:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17KLLX20697 for ips-outgoing; Wed, 7 Feb 2001 15:21:21 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17KKcH20648 for ; Wed, 7 Feb 2001 15:20:38 -0500 (EST) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2448.0) id ; Wed, 7 Feb 2001 12:20:23 -0800 Message-ID: From: Joshua Tseng To: RJ Atkinson , John Hufferd Cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Wed, 7 Feb 2001 12:20:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ips@ece.cmu.edu Precedence: bulk Ran, > It is illogical to argue that having NO SECURITY is > better than having DES-CBC. Since you appear to be doing > precisely this, I must be confused by your words and not > following you clearly. Can you kindly clarify ? > It's often been said that the only thing worse than NO SECURITY is the ILLUSION of security. Single DES is known to be cracked. John is correct that 3DES is needed for a system to be "secure". Josh From owner-ips@ece.cmu.edu Wed Feb 7 18:37:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12397 for ; Wed, 7 Feb 2001 18:37:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17MFNw26179 for ips-outgoing; Wed, 7 Feb 2001 17:15:23 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [168.159.208.81]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17MEUH26122 for ; Wed, 7 Feb 2001 17:14:30 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2650.21) id <1PV60KBX>; Wed, 7 Feb 2001 17:14:47 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A07041014F6@corpmx9.isus.emc.com> From: Black_David@emc.com To: jtseng@NishanSystems.com, Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Wed, 7 Feb 2001 17:14:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > As far as a host-based IPSec implementation is concerned, we could use this > for the WWUI to identify the initiator and target (I don't think its > feasible to have external security gateways use WWUI). An IKE negotiation > between iSCSI devices could thus use the WWUI to set up the IPSec SA's. > However, RFC 2407 section 4.6.2.1 (IPSec DOI) indicates the only identifiers > usable (at least at the time of writing of RFC 2407) are FQDN's, IP > addresses or subnets, X500 names, or X509 certificates as the identifier. > If iSCSI intends to use WWUI, we would need to coordinate with IANA to add > in WWUI as another identifier type. Or lay out some guidelines for things that SHOULD or MUST be checked to make sure that the identity used in IPSec is the correct one for the iSCSI initiator or target. This has some implications for iSNS security as well. > But I wonder if this is all really necessary??? Isn't it sufficient to have > the IP addresses identify the SA endpoints? Isn't this what most ISAKMP > implementations are doing? Is anyone aware of any other application that > use something other than IP addresses or FQDN's to negotiate IPSec SA's??? There are definitely people out there using X.509 certificates for this purpose. The most common certificates bind keys to DNS domains, but the domain in the cert need not be the FQDN of the machine using the cert (e.g., www.foo.com may consist of a bunch of machines behind a web load balancer, all of which present the same certificate to browsers - note that this is actually an SSL/TLS example, but the same thing can be done in IPSec). I don't know what else is in common use - Ran or Bernard? > This leads to the original point I was trying to make at the interim > meeting, that for all practical purpposes, IPSec SA's really need only be > negotiated between IP addresses. Once a connection has been secured between > the IP addresses, then WWUI's are used for authorization in the iSCSI login > exchange. Sure, if we really wanted we could go in and include the WWUI in > the ISAKMP exchange, but I question if this adds any value at all. If I understand this correctly, Josh is advocating that there be no required relationship between the IP addresses used to authenticate IPSec SAs and the WWUIs used to authenticate iSCSI login ... allow me to demolish this strawman :-) ... I have at least two significant concerns about this approach: - It opens up a set of attacks based on subverting the mechanism (or lack thereof) used to associate IP addresses with iSCSI targets (and initiators). If iSCSI target T is supposed to be behind IP address foo, and the adversary can convince initiator I to access T by instead opening up a tunnel-mode IPSec SA to a different IP address bar, the absence of any check between IP address and target identity makes the adversary's job significantly easier. FCIP has a similar issue in its tunnel configuration. - It also opens up a set of man-in-the-middle attacks based on the adversary being *between* one of the iSCSI nodes and its IPSec gateway. Many IPSec gateways are located one or more hops from the endpoints that they protect, and it's not in general correct to assume that the network protected by the gateway is inherently secure. Given the choice, I'd much rather lay down a set of rules and guidelines for identity checking than resort to running an end to end authentication and cryptographic integrity protocol inside an IPSec tunnel. With my WG co-chair hat on, I want to clarify the above by stating that I believe that the WG must consider the two classes of attacks/threats that I itemized above, but also that the "Given the choice" sentence above is probably not a comprehensive taxonomy of the possible countermeasures. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Feb 7 18:38:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12420 for ; Wed, 7 Feb 2001 18:38:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17LoM425054 for ips-outgoing; Wed, 7 Feb 2001 16:50:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17Ln4H25000 for ; Wed, 7 Feb 2001 16:49:09 -0500 (EST) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2448.0) id ; Wed, 7 Feb 2001 13:48:58 -0800 Message-ID: From: Joshua Tseng To: RJ Atkinson , Joshua Tseng Cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Wed, 7 Feb 2001 13:48:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ips@ece.cmu.edu Precedence: bulk Ran, > At 15:20 07/02/01, Joshua Tseng wrote: > > >It's often been said that the only thing worse than NO SECURITY > >is the ILLUSION of security. > > Some security keeps the kiddies away, no security doesn't. > I'd much rather have DES-CBC than nothing, because it visibly > increases the work function for the adversary. > > >Single DES is known to be cracked. > > That is a false statement. It hasn't been cracked. The best > attack known in the public literature is Biham-Shamir, which > requires ~O(2^^56) operations and some non-trivial preconditions. > There have been some specific brute-force attacks on DES that worked, > but they weren't real-time attacks and required a significant amount > of computational power. Yes, thank you. Cracked is the wrong word. Brute-forced is the term I meant to use. While we're on the topic of security, my source (Schnieder) indicates that in 1995, it takes 3.5 hrs average to brute-force single DES. They also estimated that by 2000, the CPU power available would reduce that time to an average of 21 minutes. On the other hand, with 128-bit keys (and 3DES has 168-bit keys) would still require on the 10**17 years. This attack doesn't need to happen real-time. All I need is a sniffer, and I could do all the attacks offline. Once I have the key(s), all your data is mine. Regardless, your point is well taken. Some encryption is better than nothing--in MOST cases. Josh > > I'm not arguing against 3DES in preference to DES-CBC, but it > is just wrong to claim either that DES-CBC is cracked or > that running in the clear is better than running with DES-CBC > (assumes reasonable cryptographic authentication in all cases). > Note also that my comments are constrained to what is in the > published literature... > > Ran > rja@inet.org > > > From owner-ips@ece.cmu.edu Wed Feb 7 18:40:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12451 for ; Wed, 7 Feb 2001 18:40:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17LKQV23767 for ips-outgoing; Wed, 7 Feb 2001 16:20:26 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17LJnH23722 for ; Wed, 7 Feb 2001 16:19:53 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f17MT6076251; Wed, 7 Feb 2001 14:29:07 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: "Scott Bradner" , Subject: RE: Security Use Requirements Date: Wed, 7 Feb 2001 13:17:38 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200102071624.LAA23742@newdev.harvard.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Scott, If there is 'required to implement' security that is later found compromised by a man in the middle or through a spoofing mechanism, would such a mandate in the end ensure an open door for those familiar with this 'required to provide' security weakness? Could you recommend a security scheme that is safe from this type of attack? Could security mandates be limited to user authentication and authorization? Compression-Encryptions passes are computationally expensive processes that offer little benefit in many configurations. If there is a mandated security, cryptographic resources should be limited to authentication. Yes, I understand the present thinking is to have the SCSI device report authorization. This brings up the question, how does the SCSI device know and what scheme is it using. It would seem foolish to insist on a security mandate than then level such a major hole in allowing security management. Doug > John asks: > > That > > is, it could be acceptable to have a gateway box included in the must > > implement. > > how would this deal with the case where the "gateway box" is built into > a device? (i.e. no seperate gateway box) > > Scott > From owner-ips@ece.cmu.edu Wed Feb 7 19:57:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13207 for ; Wed, 7 Feb 2001 19:57:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17MeN127337 for ips-outgoing; Wed, 7 Feb 2001 17:40:23 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [168.159.208.81]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17MdbH27294 for ; Wed, 7 Feb 2001 17:39:37 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2650.21) id <1PV60MWA>; Wed, 7 Feb 2001 17:40:03 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A07041014F7@corpmx9.isus.emc.com> From: Black_David@emc.com To: dotis@sanlight.net, sob@harvard.edu, ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Wed, 7 Feb 2001 17:39:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk I'm not Scott, but some of Doug's comments deserve a rather blunt response: > If there is 'required to implement' security that is later found compromised > by a man in the middle or through a spoofing mechanism, would such a mandate > in the end ensure an open door for those familiar with this 'required to > provide' security weakness? Could you recommend a security scheme that is > safe from this type of attack? There's no such thing as a perfect security mechanism that is secure from all attacks for all time. The reason for using off-the-shelf mechanisms like IPSec and TLS is that peer review in the security community has eliminated not only all of the obvious problems, but also all of the non-obvious ones that have turned up. Asking for a mechanism that is guaranteed to be immune from all possible attacks is a veiled argument for no security, and is hence nonsense. Assuming that keys that are supposed to remain secret do remain secret, TLS and IPSec are safe from all of the obvious man-in-the-middle attacks *when properly configured* and are likewise safe from the obvious spoofing attacks provided that the key distribution mechanism used works correctly (which can be a tall assumption). In some cases, other components also need to be secured, for example, if DNS names are used as identities, DNS may have to be secured via something like DNSSEC depending on how DNS is used. Both IPsec and TLS are frameworks into which various encryption and hash algorithms can be inserted, so evolution away from algorithms in which weaknesses are discovered is possible over time (and furthermore is left in the hands of the security experts who are in the best position to make these judgements). > Could security mandates be limited to user authentication and authorization? > Compression-Encryptions passes are computationally expensive processes that > offer little benefit in many configurations. If there is a mandated > security, cryptographic resources should be limited to authentication. Unfortunately, the answer is "no" if the desire is to avoid computationally expensive operations on each message exchanged after connection setup. The problem is that in order to do authentication sufficient for a public network, cryptographic integrity is required on the connection to avoid well known hijack attacks on TCP (after authentication, the adversary hijacks the connection by taking over one end of it - attack scripts are readily available for this). The algorithms for cryptographic integrity (e.g., used to compute HMACs) tend to be computationally expensive (as much as encryption, if not moreso), and my current understanding is that unlike the transition from 3DES to AES/Rijndael that reduces the computational overhead of encryption, no such overhead reduction is in sight for the hash algorithms used for integrity (e.g., SHA-1). --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Feb 7 19:58:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13223 for ; Wed, 7 Feb 2001 19:58:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17N1OT28242 for ips-outgoing; Wed, 7 Feb 2001 18:01:24 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17N1KH28234 for ; Wed, 7 Feb 2001 18:01:20 -0500 (EST) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2448.0) id ; Wed, 7 Feb 2001 15:01:14 -0800 Message-ID: From: Joshua Tseng To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Wed, 7 Feb 2001 15:01:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk David, See below: > There are definitely people out there using X.509 > certificates for this > purpose. > The most common certificates bind keys to DNS domains, but > the domain in > the cert need not be the FQDN of the machine using the cert (e.g., > www.foo.com > may consist of a bunch of machines behind a web load balancer, all of > which present the same certificate to browsers - note that > this is actually > an SSL/TLS example, but the same thing can be done in IPSec). I don't > know what else is in common use - Ran or Bernard? I agree absolutely this is always the case for SSL/TLS. The Cert either has the FQDN or hostname of the machine. I don't know if there are IPSec implementations doing this, although it wouldn't surprise me if there were. > If I understand this correctly, Josh is advocating that there > be no required > relationship between the IP addresses used to authenticate > IPSec SAs and > the WWUIs used to authenticate iSCSI login ... allow me to There is an implied relationship in that once a set of SA's is set up between two IP addresses, each endpoint is completely secure when talking to the other endpoint. This includes spoofing, man-in-middle, eavesdropping, etc... If an iSCSI login comes in from the other endpoint IP address=A, then I KNOW it is coming from IP address=A. If that login from IP address=A says WWUI=XYZ, then I can now take action to allow or disallow WWUI=XYZ. But what if it is really WWUI=PDQ just pretending that it is WWUI=XYZ at IP address=A? Well, then there is already a public key authentication mechanism defined in the current iSCSI draft, which presents a digital signature of the iSCSI login message. Since I have the public key of the real WWUI=XYZ, I can locally regenerate the required digital signature of the REAL WWUI=XYZ. If it doesn't match, then I reject the login. > demolish this > strawman :-) ... I have at least two significant concerns about this > approach: > - It opens up a set of attacks based on subverting the mechanism (or > lack thereof) used to associate IP addresses with iSCSI targets > (and initiators). If iSCSI target T is supposed > to be behind > IP address > foo, and the adversary can convince initiator I to access T > by instead opening up a tunnel-mode IPSec SA to a different > IP address bar, the absence of any check between IP address This could never happen. Remember, initiator I has an SA to IP address foo. It should be able to defeat any spoofing attacks, including those from bar or anywhere else. > and target identity makes the adversary's job > significantly easier. > FCIP has a similar issue in its tunnel configuration. > - It also opens up a set of man-in-the-middle attacks based on the > adversary being *between* one of the iSCSI nodes and its IPSec > gateway. Many IPSec gateways are located one or more hops > from the endpoints that they protect, and it's not in general > correct to assume that the network protected by the gateway > is inherently secure. If the user chooses to deploy gateway-based security, then of course there must be other measures taken to secure against attacks between the iSCSI node and the gateway. However, I believe having the iSCSI node transfer its WWUI to the gateway so that the gateway can set up an WWUI-based SA is not practical. How would you do it? Would you need another IPSec SA to transfer the WWUI between the iSCSI node and the gateway? > Given the choice, I'd much rather lay down a set of rules and > guidelines > for identity checking than resort to running an end to end > authentication > and cryptographic integrity protocol inside an IPSec tunnel. There already is a public key authentication mechanism in iSCSI. I think this is all that is required. Josh > > With my WG co-chair hat on, I want to clarify the above by > stating that > I believe that the WG must consider the two classes of attacks/threats > that I itemized above, but also that the "Given the choice" sentence > above is probably not a comprehensive taxonomy of the possible > countermeasures. > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Wed Feb 7 21:14:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14281 for ; Wed, 7 Feb 2001 21:14:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17NwUV00660 for ips-outgoing; Wed, 7 Feb 2001 18:58:30 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gnat.inet.org (209-9-249-62.sdsl.cais.net [209.9.249.62]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17LCwH23411 for ; Wed, 7 Feb 2001 16:13:12 -0500 (EST) Received: from mosquito.inet.org (mosquito.inet.org [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id AB0CB8264F; Wed, 7 Feb 2001 16:11:16 -0500 (EST) Message-Id: <5.0.0.25.2.20010207155733.00a63d00@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 07 Feb 2001 16:02:51 -0500 To: Joshua Tseng From: RJ Atkinson Subject: RE: Security Use Requirements Cc: ips@ece.cmu.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk At 15:20 07/02/01, Joshua Tseng wrote: >It's often been said that the only thing worse than NO SECURITY >is the ILLUSION of security. Some security keeps the kiddies away, no security doesn't. I'd much rather have DES-CBC than nothing, because it visibly increases the work function for the adversary. >Single DES is known to be cracked. That is a false statement. It hasn't been cracked. The best attack known in the public literature is Biham-Shamir, which requires ~O(2^^56) operations and some non-trivial preconditions. There have been some specific brute-force attacks on DES that worked, but they weren't real-time attacks and required a significant amount of computational power. I'm not arguing against 3DES in preference to DES-CBC, but it is just wrong to claim either that DES-CBC is cracked or that running in the clear is better than running with DES-CBC (assumes reasonable cryptographic authentication in all cases). Note also that my comments are constrained to what is in the published literature... Ran rja@inet.org From owner-ips@ece.cmu.edu Wed Feb 7 21:16:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14297 for ; Wed, 7 Feb 2001 21:16:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f17NxUO00691 for ips-outgoing; Wed, 7 Feb 2001 18:59:30 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gnat.inet.org (209-9-249-62.sdsl.cais.net [209.9.249.62]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f17M8CH25847 for ; Wed, 7 Feb 2001 17:08:12 -0500 (EST) Received: from mosquito.inet.org (mosquito.inet.org [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 523EB8264F; Wed, 7 Feb 2001 17:06:33 -0500 (EST) Message-Id: <5.0.0.25.2.20010207165216.00a60470@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 07 Feb 2001 16:58:07 -0500 To: Joshua Tseng From: RJ Atkinson Subject: RE: Security Use Requirements Cc: ips@ece.cmu.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk At 16:48 07/02/01, Joshua Tseng wrote: >While we're on the topic of security, my source (Schnieder) >indicates that in 1995, it takes 3.5 hrs average to brute-force >single DES. They also estimated that by 2000, the CPU power >available would reduce that time to an average of 21 minutes. >On the other hand, with 128-bit keys (and 3DES has 168-bit keys) >would still require on the 10**17 years. I'm assuming you meant Schneier. It isn't just time; it is both time and capital cost. You omitted the cost portion of the graph (Schneier, 2nd Edition, page 153, table 7.1). For 3.5 hours in 1995, the hardware cost was $1E9. Most folks don't have ready access to hardware with that capital cost. The book estimates (same page, just above the table) that to get to the 3.5 hour mark in 2000, the hardware cost would be around $1E6. There is probably some real data on what the EFF DES box cost and its brute-force rate, but this entire paragraph is mostly sidebar to the main point that some kind of security is needed. >This attack doesn't need to happen real-time. All I need is >a sniffer, and I could do all the attacks offline. Once I have >the key(s), all your data is mine. How often does the key change ? How many keys do you have to break brute-force to get the interesting data ? How much data can you steal with a given key ? Good key management practices are an important part of security. >Regardless, your point is well taken. Some encryption is better >than nothing--in MOST cases. Thanks. Cheers, Ran From owner-ips@ece.cmu.edu Wed Feb 7 21:56:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15527 for ; Wed, 7 Feb 2001 21:56:54 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f180xUM02881 for ips-outgoing; Wed, 7 Feb 2001 19:59:30 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from xchange.zambeel.com ([63.89.188.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f180x2H02861 for ; Wed, 7 Feb 2001 19:59:02 -0500 (EST) Received: by exchange.zambeel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Feb 2001 16:58:54 -0800 Received: from frostback (10.0.1.120 [10.0.1.120]) by xchange.zambeel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CR9GD3Z9; Wed, 7 Feb 2001 16:58:48 -0800 From: Michael Eisler Reply-To: Michael Eisler To: ips@ece.cmu.edu Date: Wed, 7 Feb 2001 16:55:59 -0800 (PST) Subject: RE: Security Use Requirements In-Reply-To: "Your message with ID" <5.0.0.25.2.20010207155733.00a63d00@10.30.15.2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Why use DES, which is slow for software implementations, when AES is there, is fast, and has little dispute about its safety? draft-ietf-ipsec-ciph-aes-cbc-01.txt proposes a means for using AES in IPsec. draft-ietf-tls-ciphersuite-03.txt proposes a means for using AES in TLS. 3DES is really, really slow for software to the point of being impractical. While one can always mandate it for implementation, in practice I doubt any customer using a software 3DES over ips will want to use it. -mre > At 15:20 07/02/01, Joshua Tseng wrote: > > >It's often been said that the only thing worse than NO SECURITY > >is the ILLUSION of security. > > Some security keeps the kiddies away, no security doesn't. > I'd much rather have DES-CBC than nothing, because it visibly > increases the work function for the adversary. > > >Single DES is known to be cracked. > > That is a false statement. It hasn't been cracked. The best > attack known in the public literature is Biham-Shamir, which > requires ~O(2^^56) operations and some non-trivial preconditions. > There have been some specific brute-force attacks on DES that worked, > but they weren't real-time attacks and required a significant amount > of computational power. > > I'm not arguing against 3DES in preference to DES-CBC, but it > is just wrong to claim either that DES-CBC is cracked or > that running in the clear is better than running with DES-CBC > (assumes reasonable cryptographic authentication in all cases). > Note also that my comments are constrained to what is in the > published literature... > > Ran > rja@inet.org > > From owner-ips@ece.cmu.edu Wed Feb 7 21:58:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15551 for ; Wed, 7 Feb 2001 21:58:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f180aPE02044 for ips-outgoing; Wed, 7 Feb 2001 19:36:25 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [168.159.208.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f180a0H02027 for ; Wed, 7 Feb 2001 19:36:00 -0500 (EST) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2650.21) id <1PVWXJGG>; Wed, 7 Feb 2001 19:35:39 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A07041014FC@corpmx9.isus.emc.com> From: Black_David@emc.com To: jtseng@NishanSystems.com, Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Wed, 7 Feb 2001 19:35:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Before I launch into the latest response to Josh, I want to summarize the high level point I'm trying to make: It isn't enough to just point to existing security mechanisms and say "use these". It's necessary to say how to use them with the protocol and what other assumptions must be true in order to achieve the desired security properties - some of these assumptions will be requirements on other components/protocols in the environment. This is particularly true because iSCSI contains a naming architecture that does not match the identities used in existing security mechanisms, resulting in a need to spell out in detail what is being authenticated using what sort of identities, the relationships (if any) among the different sorts of identities, and how those relationships are achieved/ assured. There's nothing in principle wrong with the existing security mechanisms being discussed - the devil is in the details of exactly how they're used. The following set of responses to Josh provide some examples: > There is an implied relationship in that once a set of SA's is set up > between two IP addresses, each endpoint is completely secure when talking to > the other endpoint. This includes spoofing, man-in-middle, eavesdropping, > etc... If an iSCSI login comes > in from the other endpoint IP address=A, then I KNOW it is coming from IP > address=A. If that login from IP address=A says WWUI=XYZ, then I can now > take action to allow or disallow WWUI=XYZ. An important assumption underlying the "implied relationship" is that the SA terminates at the iSCSI endpoints. That's not in general the case for traffic passing through IPSec security gateways and hence is the sort of thing that has to be spelled out if/when this sort of setup is intended. FWIW, "completely" is also not the right word - IPSec can set up SAs that provide integrity but not confidentiality, and hence do not protect against eavesdropping, but I'll bet that was just a poor choice of words on Josh's part. > But what if it is really WWUI=PDQ just pretending that it is WWUI=XYZ at IP > address=A? Well, then there is already a public key authentication > mechanism defined in the current iSCSI draft, which presents a digital > signature of the iSCSI login message. Since I have the public key of the > real WWUI=XYZ, I can locally regenerate the required digital signature of > the REAL WWUI=XYZ. If it doesn't match, then I reject the login. But how do one know that one has the *right* public key? Since certificates aren't required in the current iSCSI draft, and the key distribution mechanism is not specified, all sorts of mischief is possible if naked public keys are being passed around. Needless to say, that's not a particularly intelligent way to do key distribution, but like the previous case, a discussion about what is required to assure that key distribution actually distributes the correct keys (and how to verify that if necessary) is in order. The current iSCSI draft also includes a number of weaker authentication mechanisms that are vulnerable to man-in-the-middle attacks when there is not an end-to-end SA in contrast to public key mechanisms. > > - It opens up a set of attacks based on subverting the mechanism (or > > lack thereof) used to associate IP addresses with iSCSI targets > > (and initiators). If iSCSI target T is supposed to be behind IP address > > foo, and the adversary can convince initiator I to access T > > by instead opening up a tunnel-mode IPSec SA to a different > > IP address bar, the absence of any check between IP address > > This could never happen. Remember, initiator I has an SA to IP address foo. That's not correct. The analogous attacks on DNS are old news. This class of attack targets the configuration/discovery/naming mechanism(s), convincing I to initially contact T at bar rather than foo - once I makes this mistake, it's downhill from there. It's necessary to spell out the base assumptions, some of which will be requirements on configuration/naming/discovery and authentication, and explain how to get from them to the conclusion that this sort of attack can't happen. > If the user chooses to deploy gateway-based security, then of course there > must be other measures taken to secure against attacks between the iSCSI > node and the gateway. And some of those measures will almost certainly be mandatory-to-implement if there are no words in the spec about how the gateway SHOULD/MUST be related to the iSCSI nodes accessed through it. > However, I believe having the iSCSI node transfer its > WWUI to the gateway so that the gateway can set up an WWUI-based SA > is not practical. How would you do it? Would you need another IPSec SA to > transfer the WWUI between the iSCSI node and the gateway? The short answer is configuration of the SPD and related things on the gateway (assuming the gateway can use WWUI identities to set up SAs), but that misses the point. The point is that just saying "use an IPsec gateway" isn't enough. Something more needs to be said about *how* to use the gateway to achieve the desired security properties. For example, a suitably secured iSNS may be one place to put the bindings between WWUIs and IP addresses, which would allow IPSec SAs based on IP address identities to be used to help assure WWUI-based authentication. > There already is a public key authentication mechanism in iSCSI. I think > this is all that is required. The text describing this in the -03 version of the draft needs some significant work. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Feb 7 21:59:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15562 for ; Wed, 7 Feb 2001 21:59:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f181LDY03654 for ips-outgoing; Wed, 7 Feb 2001 20:21:13 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f181K2H03600 for ; Wed, 7 Feb 2001 20:20:03 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f182TW076431; Wed, 7 Feb 2001 18:29:32 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: , , Subject: RE: Security Use Requirements Date: Wed, 7 Feb 2001 17:18:04 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <0F31E5C394DAD311B60C00E029101A07041014F7@corpmx9.isus.emc.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, > There's no such thing as a perfect security mechanism that is secure from > all attacks for all time. The reason for using off-the-shelf mechanisms > like IPSec and TLS is that peer review in the security community has > eliminated not only all of the obvious problems, but also all of the > non-obvious ones that have turned up. Asking for a mechanism that is > guaranteed to be immune from all possible attacks is a veiled argument > for no security, and is hence nonsense. > > Assuming that keys that are supposed to remain secret do remain secret, > TLS and IPSec are safe from all of the obvious man-in-the-middle attacks > *when properly configured* and are likewise safe from the obvious > spoofing attacks provided that the key distribution mechanism used > works correctly (which can be a tall assumption). In some cases, > other components also need to be secured, for example, if DNS > names are used as identities, DNS may have to be secured via > something like DNSSEC depending on how DNS is used. My comment was not a veiled argument for no security but rather an open question. I would wish to argue for only mandating authentication and integrity and make privacy an option. If to follow NFS and use of GSS-API (http://www.ietf.org/rfc/rfc1961.txt) as mentioned by David Robinson, with recommend (Kerberos V5) (http://web.mit.edu/kerberos/www/) and Internet size security (Lipkey) (http://www.ietf.org/rfc/rfc2847.txt for authentication and integrity where perhaps just the dynamic portion of the PDU headers are encrypted as a type of checksum. Privacy seems like an expensive proposition to make mandatory for the entire data payload. System as well as security management is an expensive subject. The use of the SCSI device to indicate authorization implies an undefined interface to this device. Should this WG also consider a specification for informing the SCSI device the system or user authorization. Should such information be considered an aspect of security related to IPS? Doug From owner-ips@ece.cmu.edu Wed Feb 7 22:51:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17076 for ; Wed, 7 Feb 2001 22:51:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f181vRk04821 for ips-outgoing; Wed, 7 Feb 2001 20:57:27 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f181usH04802 for ; Wed, 7 Feb 2001 20:56:54 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f1836Y076472; Wed, 7 Feb 2001 19:06:34 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: , , Subject: RE: Security Use Requirements Date: Wed, 7 Feb 2001 17:55:05 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <0F31E5C394DAD311B60C00E029101A07041014F7@corpmx9.isus.emc.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Opps, Correction: GSS-API (http://www.ietf.org/rfc/rfc2078.txt) It has been updated... Doug From owner-ips@ece.cmu.edu Wed Feb 7 22:58:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17115 for ; Wed, 7 Feb 2001 22:58:09 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f182tUb06904 for ips-outgoing; Wed, 7 Feb 2001 21:55:30 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f182tPH06886 for ; Wed, 7 Feb 2001 21:55:25 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f18450076514; Wed, 7 Feb 2001 20:05:00 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: "Michael Eisler" Cc: , , Subject: RE: Security Use Requirements Date: Wed, 7 Feb 2001 18:53:32 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Michael, Mandating additional resources to implement privacy would not allow this to be a customer made trade-off. Allowing it as product feature option would. Doug > > My comment was not a veiled argument for no security but rather an open > > question. I would wish to argue for only mandating authentication and > > integrity and make privacy an option. If to follow NFS and use > of GSS-API > > (http://www.ietf.org/rfc/rfc1961.txt) as mentioned by David > Robinson, with > > recommend (Kerberos V5) (http://web.mit.edu/kerberos/www/) and > Internet size > > security (Lipkey) (http://www.ietf.org/rfc/rfc2847.txt for > authentication > > and integrity where perhaps just the dynamic portion of the PDU > headers are > > encrypted as a type of checksum. Privacy seems like an expensive > > proposition to make mandatory for the entire data payload. > > Why not allow the customer to make the tradeoff between security and > performance? > > -mre > From owner-ips@ece.cmu.edu Wed Feb 7 22:59:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17155 for ; Wed, 7 Feb 2001 22:59:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f182NSi05720 for ips-outgoing; Wed, 7 Feb 2001 21:23:28 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from xchange.zambeel.com ([63.89.188.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f182NEH05710 for ; Wed, 7 Feb 2001 21:23:15 -0500 (EST) Received: by exchange.zambeel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Feb 2001 18:23:07 -0800 Received: from frostback (10.0.1.120 [10.0.1.120]) by xchange.zambeel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CR9GD39S; Wed, 7 Feb 2001 18:22:57 -0800 From: Michael Eisler Reply-To: Michael Eisler To: Douglas Otis Cc: Black_David@emc.com, sob@harvard.edu, ips@ece.cmu.edu Date: Wed, 7 Feb 2001 18:20:07 -0800 (PST) Subject: RE: Security Use Requirements In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk > My comment was not a veiled argument for no security but rather an open > question. I would wish to argue for only mandating authentication and > integrity and make privacy an option. If to follow NFS and use of GSS-API > (http://www.ietf.org/rfc/rfc1961.txt) as mentioned by David Robinson, with > recommend (Kerberos V5) (http://web.mit.edu/kerberos/www/) and Internet size > security (Lipkey) (http://www.ietf.org/rfc/rfc2847.txt for authentication > and integrity where perhaps just the dynamic portion of the PDU headers are > encrypted as a type of checksum. Privacy seems like an expensive > proposition to make mandatory for the entire data payload. Why not allow the customer to make the tradeoff between security and performance? -mre From owner-ips@ece.cmu.edu Thu Feb 8 00:23:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18126 for ; Thu, 8 Feb 2001 00:23:27 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f183PTg07956 for ips-outgoing; Wed, 7 Feb 2001 22:25:29 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from xchange.zambeel.com ([63.89.188.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f183ORH07906 for ; Wed, 7 Feb 2001 22:24:27 -0500 (EST) Received: by exchange.zambeel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Feb 2001 19:24:19 -0800 Received: from frostback (10.0.1.120 [10.0.1.120]) by xchange.zambeel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CR9GDPBW; Wed, 7 Feb 2001 19:24:08 -0800 From: Michael Eisler Reply-To: Michael Eisler To: Douglas Otis Cc: Michael Eisler , Black_David@emc.com, sob@harvard.edu, ips@ece.cmu.edu Date: Wed, 7 Feb 2001 19:21:16 -0800 (PST) Subject: RE: Security Use Requirements In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk > Mandating additional resources to implement privacy would not allow this to > be a customer made trade-off. Allowing it as product feature option would. Implementors who implement mandatory privacy can choose to allow customers to toggle privacy on or off. This approach allows customers to make the tradeoff. If privacy is not mandatory to implement, then customers will inevitably encounter the situation where a client-side ips product has privacy and the server does not, and vice versa. This removes from the customer the ability to make the trade-off. -mre > > Why not allow the customer to make the tradeoff between security and > > performance? From owner-ips@ece.cmu.edu Thu Feb 8 01:04:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18527 for ; Thu, 8 Feb 2001 01:04:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f184NVA09889 for ips-outgoing; Wed, 7 Feb 2001 23:23:31 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from xchange.zambeel.com ([63.89.188.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f184N7H09877 for ; Wed, 7 Feb 2001 23:23:07 -0500 (EST) Received: by exchange.zambeel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Feb 2001 20:22:59 -0800 Received: from frostback (10.0.1.120 [10.0.1.120]) by xchange.zambeel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CR9GDPDF; Wed, 7 Feb 2001 20:22:53 -0800 From: Michael Eisler Reply-To: Michael Eisler To: Douglas Otis Cc: Black_David@emc.com, sob@harvard.edu, ips@ece.cmu.edu Date: Wed, 7 Feb 2001 20:20:03 -0800 (PST) Subject: RE: Security Use Requirements In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk > If the trade-off is the expense of required physical resources to implement > privacy, then mandating presents of these resources does not allow the What physical resources, a few kilobytes of code? > customer a choice of whether they wish the expense. Should the Not mandating the presence of those resources results in interoperability problems, and impacts customer choice more severely. As Mr. Robinson pointed out, the lack of mandatory to implement security services in NFSv[23] resulted in only a handful of implementations supporting such services. So the customer has no choice about whether to use stronger security flavors that a minority of NFS implementations support, unless he wants to limit his vendor list to a handful. Hence my rhetorical question: "Why not allow the customer to make the tradeoff between security and performance?" The question for the WG should be whether privacy is critical or not. If is critical, then privacy must be mandatory to implement. If it is not then the specification had better make convincing arguments why it isn't critical, otherwise we can expect IESG or the Area Advisor to reject the specification. Been there, done that. I find it hard to believe that privacy in ips is not critical. Much of the data being rendered is rather valuable. -mre From owner-ips@ece.cmu.edu Thu Feb 8 01:05:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18603 for ; Thu, 8 Feb 2001 01:05:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1843TO09217 for ips-outgoing; Wed, 7 Feb 2001 23:03:29 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1842gH09188 for ; Wed, 7 Feb 2001 23:02:42 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f185CB076569; Wed, 7 Feb 2001 21:12:11 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: "Michael Eisler" Cc: , , Subject: RE: Security Use Requirements Date: Wed, 7 Feb 2001 20:00:43 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Michael, If the trade-off is the expense of required physical resources to implement privacy, then mandating presents of these resources does not allow the customer a choice of whether they wish the expense. Should the specification indicate an optional means of enabling data privacy, then should the customer select data privacy and has bore the expense of this feature in their initial selection, the specification would allow privacy. Keeping privacy an option affords the greatest product range. Doug > > Mandating additional resources to implement privacy would not > allow this to > > be a customer made trade-off. Allowing it as product feature > option would. > > Implementors who implement mandatory privacy can choose to allow > customers to > toggle privacy on or off. This approach allows customers to make > the tradeoff. > > If privacy is not mandatory to implement, then customers will inevitably > encounter the situation where a client-side ips product has > privacy and the > server does not, and vice versa. This removes from the customer > the ability to > make the trade-off. > > -mre > > > > Why not allow the customer to make the tradeoff between security and > > > performance? > From owner-ips@ece.cmu.edu Thu Feb 8 02:02:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27046 for ; Thu, 8 Feb 2001 02:02:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f184shf10871 for ips-outgoing; Wed, 7 Feb 2001 23:54:43 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from plan9.cs.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f184rcH10837 for ; Wed, 7 Feb 2001 23:53:38 -0500 (EST) Received: from bell-labs.com ([135.104.50.40]) by plan9; Wed Feb 7 23:53:20 EST 2001 Message-ID: <3A8226E6.50409AF3@bell-labs.com> Date: Wed, 07 Feb 2001 23:56:06 -0500 From: Sean Quinlan X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Black_David@emc.com, ips@ece.cmu.edu Subject: Re: Security Use Requirements References: <0F31E5C394DAD311B60C00E029101A07041014FC@corpmx9.isus.emc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Black_David@emc.com wrote: > > Before I launch into the latest response to Josh, I want to > summarize the high level point I'm trying to make: > > It isn't enough to just point to existing security mechanisms and > say "use these". It's necessary to say how to use them with > the protocol and what other assumptions must be true in order > to achieve the desired security properties - some of these > assumptions will be requirements on other components/protocols > in the environment. > This has been an interesting thread to read. I could not resist adding a few comments of my own. Many posts ago, there was mention of three levels of security for iSCSI 1: none 2: iSCSI authentication 3: tls or IPsec these level seems to correspond to what is in the version 3 draft. The trend in the current discussion seems to be that security must be implemented. Correct me if I am wrong, but I am under the impression that fibre channel currently is used at level 1 (although there is CRC). I was also under the impression that one of the main motivations of iSCSI was the belief that ethernet would win over Fibre Channel as a network technology and hence the desire to send SCSI over ethernet. Assuming this is the case, it would appear that there is a ready market for devices that have no security and are attached by dedicated ethernet based SAN. I would assume that if iSCSI ever becomes the interface to disk drives then the no security option would be popular for such devices with the assumption that the drives are combined within boxes that have security implemented at the outer level. I doubt that drive manufacturers would be very keen to implement IPsec in their devices... the current draft of iSCSI describes a rather large selection of authentication options for both login and per PDU. When reading the text I get the impression that iSCSI will support both login and data authentication, but the draft is missing many details I would expect - for example what is the key to use for hmac-md5-96. The impression I get from the posts is that iSCSI will NOT support data authentication because it is considered too hard to get security right. I agree that getting security correct is tough, but data authentication is well understood and not very tough at all. All the difficulty is in the session authentication and session key generation - which it appears iSCSI will support. In my opinion, iSCSI would be better off with fewer session authentication methods - perhaps just SRP - and with a well defined data authentication method. I know people on this list disagree.. but with a little work I think iSCSI could achieve a high level of data integrity without the complexity of tls or IPsec. Assuming iSCSI will support session authentication, the work required to include data authentication is relatively small. A small aside... at least in software and on modern CPUs, hmac-md5-96 and CRC32 take about the same amount of time to compute. Obviously, iSCSI should be able to take advantage of security methods such as TLS and IPsec. I would suggest that iSCSI would be better off if it left all use of public keys to such protocols and avoid using them in iSCSI authentication. Perhaps the same can be said for all encryption. On the other hand, I think people need to be aware that TLS and IPSEC/IKE are rather massive entities themselves - As a point of reference, OpenSSL - a free version of TLS is over 140K lines of C - by comparison, all of Berkeley TCP/IP is 40K. Just dealing with X509 certificates is a nightmare itself http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt I know you can use TLS and IPsec without buying into the whole Certificate Authority/ Revocation List mess, but then you need to describe what you are planning to use as an alternative. I suspect if iSCSI mandates that iSCSI implementations must also implement IPsec, their will be a lot of products that punt by stating an IPsec gateway must be used... just my two cents... From owner-ips@ece.cmu.edu Thu Feb 8 03:40:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02885 for ; Thu, 8 Feb 2001 03:40:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f186uWk14607 for ips-outgoing; Thu, 8 Feb 2001 01:56:32 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f186uGH14601 for ; Thu, 8 Feb 2001 01:56:17 -0500 (EST) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2448.0) id ; Wed, 7 Feb 2001 22:56:07 -0800 Message-ID: From: Joshua Tseng To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Wed, 7 Feb 2001 22:56:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk David, > > Before I launch into the latest response to Josh, I want to > summarize the high level point I'm trying to make: > > It isn't enough to just point to existing security > mechanisms and > say "use these". It's necessary to say how to use them with > the protocol and what other assumptions must be true in order > to achieve the desired security properties - some of these > assumptions will be requirements on other components/protocols > in the environment. Thanks, and the point I'm trying to make is that iSCSI and IPSec/IKE can pretty much work independently, with no compromise to security. Having IPSec and/or IKE become involved in iSCSI (or vice-versa) will increase complexity while adding little additional value. Note that I'm not necessarily saying the same about TLS. I agree with Julian that TLS may need something from iSCSI, since the SA's are bound to the TCP socket. But I am not as familiar with TLS, so maybe I shouldn't get into this. > > This is particularly true because iSCSI contains a naming architecture > that does not match the identities used in existing security > mechanisms, > resulting in a need to spell out in detail what is being authenticated > using what sort of identities, the relationships (if any) among the > different sorts of identities, and how those relationships > are achieved/ > assured. > > There's nothing in principle wrong with the existing security > mechanisms > being discussed - the devil is in the details of exactly how > they're used. > The following set of responses to Josh provide some examples: > > > There is an implied relationship in that once a set of SA's > is set up > > between two IP addresses, each endpoint is completely > secure when talking > to > > the other endpoint. This includes spoofing, man-in-middle, > eavesdropping, > > etc... If an iSCSI login comes > > in from the other endpoint IP address=A, then I KNOW it is > coming from IP > > address=A. If that login from IP address=A says WWUI=XYZ, > then I can now > > take action to allow or disallow WWUI=XYZ. > > An important assumption underlying the "implied relationship" > is that the SA > terminates at the iSCSI endpoints. That's not in general the case for > traffic passing through IPSec security gateways and hence is > the sort of > thing that has to be spelled out if/when this sort of setup > is intended. Agreed. > > FWIW, "completely" is also not the right word - IPSec can set > up SAs that > provide integrity but not confidentiality, and hence do not > protect against > eavesdropping, but I'll bet that was just a poor choice of words > on Josh's part. > > > But what if it is really WWUI=PDQ just pretending that it > is WWUI=XYZ at > IP > > address=A? Well, then there is already a public key authentication > > mechanism defined in the current iSCSI draft, which > presents a digital > > signature of the iSCSI login message. Since I have the > public key of the > > real WWUI=XYZ, I can locally regenerate the required > digital signature of > > the REAL WWUI=XYZ. If it doesn't match, then I reject the login. > > But how do one know that one has the *right* public key? Since > certificates aren't required in the current iSCSI draft, and the key > distribution mechanism is not specified, all sorts of mischief is > possible if naked public keys are being passed around. Needless > to say, that's not a particularly intelligent way to do key > distribution, > but like the previous case, a discussion about what is required > to assure that key distribution actually distributes the correct > keys (and how to verify that if necessary) is in order. The > current iSCSI draft also includes a number of weaker authentication > mechanisms that are vulnerable to man-in-the-middle attacks when > there is not an end-to-end SA in contrast to public key mechanisms. In this example, the public key comes from the X.509 certificate obtained either from the iSNS or manually configured. This certificate supposedly can be bound to the WWUI and can be verified through the certificate authority. The iSNS spec describes this (section 5.5.16). But note that this is only one method of iSCSI authentication. Others include the challenge handshake, shared secret password, kerberos, etc...see the iSCSI spec. The point is that IPSec provides the PER PACKET data integrity/authentication and if desired, encryption. The iSCSI login process provides authentication AND authorization of the communicating entities. What more do you need? > > > > - It opens up a set of attacks based on subverting the > mechanism (or > > > lack thereof) used to associate IP addresses with iSCSI targets > > > (and initiators). If iSCSI target T is supposed > to be behind > IP address > > > foo, and the adversary can convince initiator I to access T > > > by instead opening up a tunnel-mode IPSec SA to a different > > > IP address bar, the absence of any check between IP address > > > > This could never happen. Remember, initiator I has an SA > to IP address > foo. > > That's not correct. The analogous attacks on DNS are old news. > This class of attack targets the configuration/discovery/naming > mechanism(s), convincing I to initially contact T at bar > rather than foo - > once I makes this mistake, it's downhill from there. It's necessary > to spell out the base assumptions, some of which will be requirements > on configuration/naming/discovery and authentication, and explain > how to get from them to the conclusion that this sort of attack can't > happen.h For this attack to succeed, an attacker would have to penetrate the iSNS and substitute T2 at IP addr 2 for the real target of T1 at IP addr 1. It would then also have to forge a public/private key pair and have it signed by the "trusted" certificate authority. And then it would have to get initiator I to replace the real certificate of T1 with the forged certificate containing the public key of T2. I count at least 3 lines of defense, but the only one that really matters IMO is the "trusted" certificate authority. The difference between DNS and iSCSI is that DNS doesn't have an equivalent to the iSCSI login message. I think the combination of IPSec and iSCSI login process to make the possibility of success for this attack extremely unlikely against iSCSI. If initiator I were to somehow talk to the wrong target at the wrong IP address, more than likely this will be caught in the iSCSI login, through either the public key authentication or one of the other authentication mechanisms described in the current iSCSI draft. > > > If the user chooses to deploy gateway-based security, then > of course there > > must be other measures taken to secure against attacks > between the iSCSI > > node and the gateway. > > And some of those measures will almost certainly be > mandatory-to-implement if there are no words in the spec > about how the gateway SHOULD/MUST be related to the > iSCSI nodes accessed through it. The security measures I have in mind have more to do with physical security. I do not believe the security gateway needs to be iSCSI (or WWUI) aware, nor do I believe it would add significant security value if it were. Remember that even if the standalone gateway was aware of iSCSI and WWUI, it must make a decision to ingress traffic through the appropriate SA on a PER PACKET basis, according to RFC 2401. The WWUI only exists in the initial iSCSI login PDU. Therefore, the gateway must make a decision based upon what exists and is visible in every packet (i.e., each individual TCP segment). This includes the Source and Dest IP addr, and source and dest TCP port. Therefore, physical security is required anyway, regardless of whether the gateway is WWUI-aware, because the established TCP connection (based on the initial iSCSI login PDU) can be hijacked. The only real difference between a standalone gateway IPSec implementation and an imbedded one is that physical security is pretty much assured, since both IPSec and iSCSI exist on the same box. And the only additional capability I can think of from making the IPSec implementation iSCSI and WWUI-aware (for both gateway and embedded implementations) is a capability to specify more than one security policy to the same destination IP address. Thus, if target A and B shared the same IP address (or exist behind the same security gateway), you could say ESP/3DES to target A, and AH/SHA-1 or no security to target B. While that might be an admirable capability in some settings, I certainly don't believe it should be required. Much implementation headache can be averted by simply saying 3DES to everyone at IP address=A. Yes, you would waste processing power in this case if there were 50 targets sharing the same IP address (or security gateway), and only one of them needed 3DES, but since you can't configure a policy per WWUI, then all traffic to all 50 targets at that IP address would have to be encrypted 3DES. But once again, this will not hurt security. Josh > > > However, I believe having the iSCSI node transfer its > > WWUI to the gateway so that the gateway can set up an WWUI-based SA > > is not practical. How would you do it? Would you need > another IPSec SA > to > > transfer the WWUI between the iSCSI node and the gateway? > > The short answer is configuration of the SPD and related things on > the gateway (assuming the gateway can use WWUI identities to set > up SAs), but that misses the point. The point is that just saying > "use an IPsec gateway" isn't enough. Something more needs to be > said about *how* to use the gateway to achieve the desired security > properties. For example, a suitably secured iSNS may be one > place to put the bindings between WWUIs and IP addresses, which > would allow IPSec SAs based on IP address identities to be used > to help assure WWUI-based authentication. > > > There already is a public key authentication mechanism in > iSCSI. I think > > this is all that is required. > > The text describing this in the -03 version of the draft needs some > significant work. > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Thu Feb 8 03:40:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02896 for ; Thu, 8 Feb 2001 03:40:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f186ZaP14069 for ips-outgoing; Thu, 8 Feb 2001 01:35:36 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f186ZBH14033 for ; Thu, 8 Feb 2001 01:35:11 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id HAA45046 for ; Thu, 8 Feb 2001 07:35:03 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay02.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id HAA23284 for ; Thu, 8 Feb 2001 07:34:54 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569ED.002426C8 ; Thu, 8 Feb 2001 07:34:52 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Thu, 8 Feb 2001 08:30:30 +0200 Subject: Re: ISCSI: Immediate data extending beyond a single PDU Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Pierre, I am not sure I see where the problem is. Both today and with Barry's suggested addition you can send EITHER immediate or a regular unsolicited burst. In case you choose to do the later the end is marked by the F bit. In case you choose immediate it is only 1 PDU. Expected Data Length is for the whole operation (not only the first burst). Barry suggested that we restrict also, at target choice, the type of unsolicited data to immediate (we either let UseR2T:yes and ImmediateData:yes mean only immediate data or better UseR2T:no ImmediateData:ONLY) for the convenience of some targets. In all the cases the target knows when the FirstBurst is over (now and with Barry's proposed change). Am I missing something? Regards, Julo Pierre Labat on 07/02/2001 20:56:57 Please respond to Pierre Labat To: ips@ece.cmu.edu cc: Subject: Re: ISCSI: Immediate data extending beyond a single PDU julian_satran@il.ibm.com wrote: > Barry, > > I think that the current draft does not allow you to accept immediate but > not unsolicited. > You can either allow unsolicited (including immediate) or request always > R2T. > > And yes - if the expected length is larger that what you sent as > unsolicited (even if the unsolicited was less than the limit) the target is > supposed to send R2T (there is only one unsolicited burst per command). Julian, Barry, I think there is a problem, as stated Barry, if the initiator decides to send unsolicited data but less than the Firstburst and the expected length is greater than the Firstburst. In this case the initiator after sending some unsolicited data waits for an R2T to continue and the target waits for a First burst load of data before sending an R2T. Solution ====== To avoid that, it should be explicitely stated (may be it's what is assumed but i can't read it) that when the initiator sends unsolicited non immediate data, it must send unsolicited data up to Firstburst or Expected data length whichever is less. Regards, Pierre From owner-ips@ece.cmu.edu Thu Feb 8 11:23:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12144 for ; Thu, 8 Feb 2001 11:23:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f18EHeK08103 for ips-outgoing; Thu, 8 Feb 2001 09:17:40 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f18EGkH08067 for ; Thu, 8 Feb 2001 09:16:46 -0500 (EST) Received: from hpindlm.cup.hp.com (hpindlm.cup.hp.com [15.13.95.89]) by palrel3.hp.com (Postfix) with ESMTP id A1D3F448; Thu, 8 Feb 2001 06:16:45 -0800 (PST) Received: from mk731913.cup.hp.com (mk731912.cup.hp.com [15.8.80.111]) by hpindlm.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id GAA24887; Thu, 8 Feb 2001 06:19:31 -0800 (PST) Message-Id: <5.0.2.1.2.20010208061424.00a8a428@hpindlm.cup.hp.com> X-Sender: krause@hpindlm.cup.hp.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 08 Feb 2001 06:16:27 -0800 To: Michael Eisler From: Michael Krause Subject: RE: Security Use Requirements Cc: ips@ece.cmu.edu In-Reply-To: References: <"Your message with ID" <5.0.0.25.2.20010207155733.00a63d00@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk At 04:55 PM 2/7/2001 -0800, Michael Eisler wrote: >Why use DES, which is slow for software implementations, when AES >is there, is fast, and has little dispute about its safety? > >draft-ietf-ipsec-ciph-aes-cbc-01.txt proposes a means >for using AES in IPsec. > >draft-ietf-tls-ciphersuite-03.txt proposes a means for >using AES in TLS. > >3DES is really, really slow for software to the point of being impractical. >While one can always mandate it for implementation, in practice I doubt any >customer using a software 3DES over ips will want to use it. How fast is AES in hardware? 3DES is link-rate in hardware today and in wide use by many products. While software implementations are interesting / value to some, most high-speed implementations, e.g. 1 / 10 GbE, will require hardware acceleration and thus the preference is to focus on hardware friendly solutions wherever possible. Mike From owner-ips@ece.cmu.edu Thu Feb 8 11:26:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12204 for ; Thu, 8 Feb 2001 11:26:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f18EYmg08847 for ips-outgoing; Thu, 8 Feb 2001 09:34:48 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [168.159.208.81]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f18EY0H08817 for ; Thu, 8 Feb 2001 09:34:00 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2650.21) id <1PV7BN87>; Thu, 8 Feb 2001 09:34:26 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A07041014FF@corpmx9.isus.emc.com> From: Black_David@emc.com To: seanq@bell-labs.com, Black_David@emc.com, ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Thu, 8 Feb 2001 09:33:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk > Many posts ago, there was mention of three levels of security for iSCSI > > 1: none > 2: iSCSI authentication > 3: tls or IPsec > > these level seems to correspond to what is in the version 3 draft. > > The trend in the current discussion seems to be that security must be implemented. > Correct me if I am wrong, but I am under the impression that fibre channel currently > is used at level 1 (although there is CRC). I was also under the impression that > one of the main motivations of iSCSI was the belief that ethernet would win over > Fibre Channel as a network technology and hence the desire to send SCSI over ethernet. Oh, I wish Sean hadn't gone there. Fibre Channel has some rather weak authentication and access control mechanisms, but the current state of Fibre Channel security would never have made it past an IETF Area Director, let alone out as a standards-track RFC. Small scale Fibre Channel SANs provide valid arguments for choosing not to use security in some cases - larger scale Fibre Channel deployments are providing much stronger arguments for why security implementation should be mandatory, and there's quite a bit of work going on in the Fibre Channel world to do something about security after the fact. In other words, Fibre Channel is not a valid analogy to argue about whether security should be mandatory to implement. Beyond that, Sean is correct that there are a lot of details are missing from the security section of the -03 draft, and that in general, specifying fewer mechanisms is preferable. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Feb 8 12:16:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13579 for ; Thu, 8 Feb 2001 12:16:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f18F0d109966 for ips-outgoing; Thu, 8 Feb 2001 10:00:39 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [168.159.208.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f18F0GH09923 for ; Thu, 8 Feb 2001 10:00:16 -0500 (EST) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2650.21) id <1PVWXWJJ>; Thu, 8 Feb 2001 10:00:02 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A0704101500@corpmx9.isus.emc.com> From: Black_David@emc.com To: jtseng@NishanSystems.com, Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Thu, 8 Feb 2001 09:59:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk > > It isn't enough to just point to existing security mechanisms and > > say "use these". It's necessary to say how to use them with > > the protocol and what other assumptions must be true in order > > to achieve the desired security properties - some of these > > assumptions will be requirements on other components/protocols > > in the environment. > > Thanks, and the point I'm trying to make is that iSCSI and IPSec/IKE can > pretty much work independently, with no compromise to security. Having > IPSec and/or IKE become involved in iSCSI (or vice-versa) will increase > complexity while adding little additional value. I think Josh and I are in violent agreement on this. In particular, I don't see any need to put WWUIs into IPSec/IKE or X.509 certificates. Mechanisms like iSNS can handle the mapping between the various sort of identities, provided that iSNS is suitably secure. OTOH, there's a lot of work needed on the security text in the current iSCSI draft -- for example, Josh describes certificates and iSNS as being able to prevent certain attacks on key distribution, but the current iSCSI draft is basically silent on both subjects, and in particular does not describe how one party in an iSCSI authentication interaction gets its hands on the other's certificate to check it (which is generally a good thing to be able to do when certificates are used). The specific answer to: > The point is that IPSec provides the PER PACKET data > integrity/authentication and if desired, encryption. The iSCSI login > process provides authentication AND authorization of the communicating > entities. What more do you need? is that it's necessary to ensure that there isn't a gap between iSCSI authentication and IPSec authentication/integrity/confidentiality that would allow the communication to be attacked without breaking IPSec. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Feb 8 13:23:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15660 for ; Thu, 8 Feb 2001 13:23:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f18GEgB13271 for ips-outgoing; Thu, 8 Feb 2001 11:14:42 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [168.159.208.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f18GEGH13252 for ; Thu, 8 Feb 2001 11:14:17 -0500 (EST) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2650.21) id <1PVWXZJ6>; Thu, 8 Feb 2001 11:13:17 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A0704101501@corpmx9.isus.emc.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: FCIP - Orlando Interim Summary Date: Thu, 8 Feb 2001 11:13:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk With profuse apologies for the delays in getting this out, here's the summary of the FCIP portion of the Orlando interim meeting in January. If anyone objects to any of the conclusions here, please do so quickly so that the official minutes that will be sent to the IETF Secretariat early next week will reflect the current state of the WG. Thanks, --David 1) Ralph Weber verbally presented some changes to the FCIP draft, specifically dealing with framing, header and timestamps. A formal proposal, in the form of a draft, will be submitted in February. 2) SOF/EOF encodings. The current draft uses the same SOF/EOF encodings as are in the FC-BB specification. While that draft lists a number of encodings, only a subset are required by that document. Discussions about the various encodings have lead to the conclusion that the subset should be the only SOF/EOF encodings specified in the FCIP document. That subset is restricted to class 2 and class 3 support. The other encodings are either not defined in FC-FS (framing and signaling), are Class 1 specific (which is not currently used in the industry) or class 4 (which is not yet defined). 3) Figure 4 in the document needs to be updated. It currently implies that the FC header will immediately follow the TCP header. Misleading, in that it appears to be at a fixed offset and does not indicate that optional TCP headers may be in place between the TCP and FC headers. In particular, put a box with ellipses in it to make this clearer. 4) David provided input on QoS. Need to avoid specifying a specific code point and instead specify expected performance criteria. 5) Error recovery is still a major issue in the current specification, in particular the handling of the FC and TCP timeouts and their correlation. Ralph Weber's discussion earlier in the session applicable here. Really need more input on this from the FC switch vendors. To be discussed at the T11 meeting, to see how this can be addressed. 6) Security -- Authentication a must. IPSec and TLS the logical choices here. TLS may be the better choice of the two. iSCSI facing the same issues. FCIP should take iSCSI decisions/considerations into account and try to align with iSCSI if possible. 7) Clarification needed to the document indicating that E_Ports are supported by this document. While not prohibited by the current document, not clear that this is supported either. --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Feb 8 13:24:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15681 for ; Thu, 8 Feb 2001 13:24:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f18GMdI13627 for ips-outgoing; Thu, 8 Feb 2001 11:22:39 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from csapuntz-u1.cisco.com (play-doh.Stanford.EDU [128.12.131.42]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f18GMMH13608 for ; Thu, 8 Feb 2001 11:22:22 -0500 (EST) Received: by csapuntz-u1.cisco.com (Postfix, from userid 500) id 7D5818D5D; Thu, 8 Feb 2001 08:21:53 -0800 (PST) To: ips@ece.cmu.edu Subject: Re: Security Use Requirements [specifically: hardware] References: <0F31E5C394DAD311B60C00E029101A0704101500@corpmx9.isus.emc.com> Cc: csapuntz@cisco.com X-csapuntz: outbox Content-Type: text/plain; charset=US-ASCII From: csapuntz@cisco.com Date: 08 Feb 2001 08:21:53 -0800 In-Reply-To: Black_David@emc.com's message of "Thu, 8 Feb 2001 09:59:54 -0500" Message-ID: Lines: 8 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) MIME-Version: 1.0 Sender: owner-ips@ece.cmu.edu Precedence: bulk "Mandatory to implement" for authentication/encryption (AE) may not imply "mandatory to run at wire rate". An iSCSI endpoint's throughput could significantly slow when AE is turned on and still be compliant. That slower throughput may still be valuable for some customers (e.g. network boot). -Costa From owner-ips@ece.cmu.edu Thu Feb 8 15:36:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18869 for ; Thu, 8 Feb 2001 15:36:13 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f18Hsja18174 for ips-outgoing; Thu, 8 Feb 2001 12:54:45 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from xchange.zambeel.com ([63.89.188.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f18HsDH18150 for ; Thu, 8 Feb 2001 12:54:13 -0500 (EST) Received: by exchange.zambeel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Feb 2001 09:54:05 -0800 Received: from frostback (10.0.1.121 [10.0.1.121]) by xchange.zambeel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CR9GDP7L; Thu, 8 Feb 2001 09:54:00 -0800 From: Michael Eisler Reply-To: Michael Eisler To: Michael Krause Cc: ips@ece.cmu.edu Date: Thu, 8 Feb 2001 09:51:11 -0800 (PST) Subject: RE: Security Use Requirements In-Reply-To: "Your message with ID" <5.0.2.1.2.20010208061424.00a8a428@hpindlm.cup.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk > At 04:55 PM 2/7/2001 -0800, Michael Eisler wrote: > >Why use DES, which is slow for software implementations, when AES > >is there, is fast, and has little dispute about its safety? > > > >draft-ietf-ipsec-ciph-aes-cbc-01.txt proposes a means > >for using AES in IPsec. > > > >draft-ietf-tls-ciphersuite-03.txt proposes a means for > >using AES in TLS. > > > >3DES is really, really slow for software to the point of being impractical. > >While one can always mandate it for implementation, in practice I doubt any > >customer using a software 3DES over ips will want to use it. > > How fast is AES in hardware? 3DES is link-rate in hardware today and in > wide use by many products. While software implementations are interesting > / value to some, most high-speed implementations, e.g. 1 / 10 GbE, will > require hardware acceleration and thus the preference is to focus on > hardware friendly solutions wherever possible. One of the major criteria for NIST selecting the AES algorithm was hardware friendliness. I'd like to see a reference to 3DES hardware that encrypts at 10 gigabit/sec in feedback mode. http://bass.gmu.edu/crypto/AES_non_feedback.PDF compares AES (Riijndael) to other AES candidates and 3DES on FPGAs. In feedback mode, AES did 414.2 mbit/sec, vs. 59.1 mbit/sec for 3DES. In anoher paper, the same authors say http://ece.gmu.edu/crypto/AES_survey.pdf that AES can do 1950 mbits/sec with an ASIC (page 27). -mre From owner-ips@ece.cmu.edu Fri Feb 9 02:41:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12284 for ; Fri, 9 Feb 2001 02:41:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f195u1Z18530 for ips-outgoing; Fri, 9 Feb 2001 00:56:01 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gate.internaut.com ([64.38.134.108]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f195tqH18519 for ; Fri, 9 Feb 2001 00:55:52 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f195o7R11925; Thu, 8 Feb 2001 21:50:08 -0800 From: "Bernard Aboba" To: "Joshua Tseng" Cc: Subject: RE: Security Use Requirements Date: Thu, 8 Feb 2001 21:56:25 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >TLS affords the capability of securely communicating through >proxys. I think you mean NATs, no? Not sure how you'd proxy SSL without terminating a TCP connection. >On the other hand, IPSec is a real pain to get through >firewalls. If you're talking strictly about a firewall, not a NAT, I'm not sure why there'd be a difference. For IPSEC you need to open up protocols 50/51, and UDP 500. For SSL/TLS you need to open up a single TCP port for the application. Either way, you probably need to restrict communication to iSCSI targets with appropriate negotiation policies installed. >If we decide that iSCSI doesn't need to go through >firewalls, then we could let go of TLS. BTW, I'd note that the IPSEC WG is currently taking up the issue of IPSEC address dependencies and that several proposals have been put forward. So I wouldn't rule out being able to traverse NATs with IPSEC at some point in the future. Unfortunately however, all of those proposals interfere with the ability to do HW acceleration :( From owner-ips@ece.cmu.edu Fri Feb 9 02:42:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12302 for ; Fri, 9 Feb 2001 02:42:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f195k0418229 for ips-outgoing; Fri, 9 Feb 2001 00:46:00 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gate.internaut.com ([64.38.134.108]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f195jUH18209 for ; Fri, 9 Feb 2001 00:45:30 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f195dbR11315; Thu, 8 Feb 2001 21:39:38 -0800 From: "Bernard Aboba" To: "Glen Turner" , Cc: , , , Subject: RE: Security Use Requirements (and security issue with iSCSI boot deployment) Date: Thu, 8 Feb 2001 21:45:55 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3A810307.EF2AA637@aarnet.edu.au> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >At the least it should be noted in Security Considerations that vendors >should consider providing a mechanism for vendor-to-booter verification >of a boot image. Such a thing already exists. It's part of the PXE specification and involves storing on the PC a public key that is used to sign the boot image. >It would be really nice if iSCSI-boot suggested a mechanism, so that >it could be built into ROMs by manufacturers that are implementing >iSCSI-boot and so that the hardware manufacturer could not use the >mechanism to lock out alternative operating systems. This capability is already built into PXE-compliant boot ROMs. In fact, you may already have purchased a NIC that implements PXE! I should note that there are some interesting issues that arise when using PXE to do secure iSCSI boot, but I'll leave that issue to another discussion. From owner-ips@ece.cmu.edu Fri Feb 9 02:42:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12327 for ; Fri, 9 Feb 2001 02:42:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f196B1S18978 for ips-outgoing; Fri, 9 Feb 2001 01:11:01 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gate.internaut.com ([64.38.134.108]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f196ADH18925 for ; Fri, 9 Feb 2001 01:10:13 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1964RR12720; Thu, 8 Feb 2001 22:04:27 -0800 From: "Bernard Aboba" To: Cc: , , "RJ Atkinson" , "Smb@Research. Att. Com" , Subject: RE: Security Use Requirements Date: Thu, 8 Feb 2001 22:10:45 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >The reason we went after TLS is that it can be used for session >authentication with stronger schemes than >and it is very popular for software implementations. SSL/TLS has many nice features, including better API support in most cases, more flexible certificate policies, and lightweight ciphers (e.g. RC4) This often makes it an attractive choice for applications requiring ~ 100 Mbps throughput (e.g. your average web server). >As for the cost of the hardware - the figures you quote are for 100Mbs (and >even there the NIC numbers are higher). The low-end iSCSI adapters will >cost well under $100 (at 1GBbs). Really? Mind if I order a few thousand to use as ordinary Gigabit Ethernet NICs? Our server farms need an inexpensive upgrade for the 100 Mbps adapters ;) >I don't envision all the options becoming necessary for hardware >implementations. The pieces we wanted from TLS can be implemented in >software. Well, if you only have a few sessions per card, you can do session establishment in software. However, even though RC4 is very light weight, it is very hard to get close to 1 Gbps throughput on it, even with a 1 Ghz processor. So you will be likely to bottleneck at relatively low interface utilization unless you have more than one CPU to throw at it. >If we where forced to select one I would too go for >IPsec (and that is what we have in the current draft) > but then we have to specify session authentication > on our own and keep updating it as new schemes enter >the world. Not sure why this would be necessary. Doesn't IKE (either with Certs or shared secrets) give you the necessary authentication/integrity protection? From owner-ips@ece.cmu.edu Fri Feb 9 02:54:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12285 for ; Fri, 9 Feb 2001 02:41:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f195f1s18086 for ips-outgoing; Fri, 9 Feb 2001 00:41:01 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gate.internaut.com ([64.38.134.108]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f195ebH18068 for ; Fri, 9 Feb 2001 00:40:37 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f195YlR11081; Thu, 8 Feb 2001 21:34:51 -0800 From: "Bernard Aboba" To: "RJ Atkinson" , "John Hufferd" Cc: Subject: RE: Security Use Requirements Date: Thu, 8 Feb 2001 21:41:05 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <5.0.0.25.2.20010207080020.009fcd80@10.30.15.2> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > In any event. the need is for security is at least 3DES. First you said that you didn't need anything. Now you seem to imply that you need confidentiality, integrity, and authentication and that even 3DES may not be enough. There are gradations between these two extremes. As Ran said, even DES will get you something. And there are circumstances where you might be willing to live with integrity and authentication alone. >Also the cost of a Gigabit chip for 3DES, I just found out, >is $300 for Samples. Well, the cost of a Gigabit NIC is pretty high today in quantity one, but I don't expect that to be the case in 18-24 months. You need to factor in time and volume into your calculation. >Now, I am beginning to think that it is reasonable for one >of the following approaches to be OK. That is, one of those >approaches should meet the requirement for "Must Implement". >1. Only implementing an interface to the external IPSec/TLS box >2, SW implementation of IPSec/TLS >3. HW IPSec/TLS Problem with approach 1 is that the total cost will be *much* higher than it would be if you build capability on the NIC. Problem with SW implementation of TLS is that you won't be able to go much above 200 Mbps if that, even with a 1 Ghz processor. IPSEC 3DES in SW is much worse. Trust me, a task oriented crypto co-processor is the way to go in this application. In my opinion, HW IPSEC is the best choice. I expect costs for 1 Gbps chips to approximate current costs for 100 Mbps in the next 18-24 months. HW TLS is a lot harder because you typically have to terminate TCP sessions on the card. That means lots of memory, which is what we've been trying to avoid with RDMA. So cost will be a good deal higher and the approach won't readily be extensible to 10 Gbps. Don't go there. From owner-ips@ece.cmu.edu Fri Feb 9 03:42:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12688 for ; Fri, 9 Feb 2001 03:42:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f19713d20371 for ips-outgoing; Fri, 9 Feb 2001 02:01:03 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gate.internaut.com ([64.38.134.108]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1970CH20315 for ; Fri, 9 Feb 2001 02:00:13 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f196sRR15400; Thu, 8 Feb 2001 22:54:27 -0800 From: "Bernard Aboba" To: , Cc: Subject: RE: Security Use Requirements Date: Thu, 8 Feb 2001 23:00:45 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <0F31E5C394DAD311B60C00E029101A0704101500@corpmx9.isus.emc.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >is that it's necessary to ensure that there isn't a gap between iSCSI >authentication and IPSec authentication/integrity/confidentiality that >would allow the communication to be attacked without breaking IPSec. I think you're basically asking to make sure that an given IPSEC-protected iSCSI packet originated from the same entity that completed the iSCSI authentication, no? In IPSEC there is a similar issue in that you want to make sure that a given IPSEC packet originated from the same entity with which you negotiated the IKE MM and QM SAs. The packet identity is tied back to the IKE-provided identity via the IP header and SPI, and the claim of identity is proven by verifying the integrity/authenticity of the packet, thereby verifying that the entity has posession of the key previously negotiated within IKE. So, in the case of iSCSI authentication, you have a claim of identity, and a proof of identity. To link this to an IPSEC packet, you have a few choices: 1. Somehow link the identity claimed in the iSCSI authentication to information exchanged within the IKE negotiation. If you can link the iSCSI authentication to the IKE MM and QM SAs, you will have a link to the IPSEC packet via the IP header and SPI. Note that "information exchanged" may constitute more than just the claimed IKE identity. It could include information within the cert, for example. It is best to accomplish this without trying to invent new identity payloads within IKE. 2. Somehow link the proof of identity within iSCSI authentication to the proof of identity made within IKE. For example, if a key is generated within iSCSI authentication, then this key can be used as a shared secret within IKE. However, in order to make this work, you will also need to link the iSCSI authentication claim of identity to the claim of identity made within IKE. Note that this does not mean that the claims are identical -- merely that they can be bound in a secure way. From owner-ips@ece.cmu.edu Fri Feb 9 03:43:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12700 for ; Fri, 9 Feb 2001 03:43:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f196Z1b19673 for ips-outgoing; Fri, 9 Feb 2001 01:35:01 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gate.internaut.com ([64.38.134.108]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f196Y2H19655 for ; Fri, 9 Feb 2001 01:34:02 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f196SDR13952; Thu, 8 Feb 2001 22:28:13 -0800 From: "Bernard Aboba" To: , Cc: Subject: RE: Security Use Requirements Date: Thu, 8 Feb 2001 22:34:31 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <0F31E5C394DAD311B60C00E029101A07041014F6@corpmx9.isus.emc.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >Or lay out some guidelines for things that SHOULD or MUST be checked to >make sure that the identity used in IPSec is the correct one for the iSCSI >initiator or target. This has some implications for iSNS security as well. I think it might help to explicitly define what you mean by "correct". For example, it might be possible for the iSCSI target to control access to LUNs based on characteristics of the certs negotiated in IKE, and characteristics of the IPSEC SA. However, I wouldn't suggest that something like this (which requires more advanced APIs than are generally available) is required or even generally useful. A thought: if you want to do access control based on the source IP address, you will need to be using AH, rather than ESP, since the former's MIC covers the IP header whereas the latter does not. >Isn't it sufficient to have the IP addresses identify the >SA endpoints? Isn't this what most ISAKMP implementations are doing? In practice, this is what implementations do, yes. >There are definitely people out there using X.509 certificates for this >purpose. The most common certificates bind keys to DNS domains, >but the domain in the cert need not be the FQDN of the machine >using the cert (e.g., www.foo.com may consist of a bunch of machines >behind a web load balancer, all of which present the same certificate to >browsers I think you're confusing IPSEC and TLS. In the case of our IPSEC implementation, we use a machine certificate that includes the machine name. The machine cert is obtained after domain auto-enrollment, after the machine key and name have been generated. So in practice, the machine name and therefore the machine cert used by IPSEC will be unique. Note that the machine cert used for IPSEC may *not* be the same as the cert used for SSL/TLS. From owner-ips@ece.cmu.edu Fri Feb 9 04:59:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13190 for ; Fri, 9 Feb 2001 04:59:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f197E2D20702 for ips-outgoing; Fri, 9 Feb 2001 02:14:02 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f197DwH20697 for ; Fri, 9 Feb 2001 02:13:58 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.132.205]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id CAA216534; Fri, 9 Feb 2001 02:07:00 -0500 Received: from f3n42e (d03nm042h.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id AAA49200; Fri, 9 Feb 2001 00:13:55 -0700 Importance: Normal Subject: RE: Security Use Requirements (and security issue with iSCSI boot deployment) To: "Bernard Aboba" Cc: "Glen Turner" , , , "Julian Satran" , , "Ofer Biran" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Prasenjit Sarkar" Date: Thu, 8 Feb 2001 23:16:45 -0800 X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 02/08/2001 11:13:56 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk One should note that iSCSI-boot does not use PXE during the actual boot process - PXE may be used to load the minimum iSCSI initiator software necessary for the boot process. The iSCSI booting process, given its raw block access to a disk as opposed to a specified image in BOOTP variants, may involved the sequential loading of multiple images whose identities are known only at run time. For example, in a PC boot you dont know whether the first image you are loading is lilo or ntldr until you examine the boot disk. Short of digitally signing every block, a practical way out is to for each loaded image to verify the integrity of the subsequent image to be loaded (if any). Another way may be Julian's solution but I am unware of the details. Comments appreciated, ----------------------------------------------------------------------------------------------------------------------------------------------------------------- >At the least it should be noted in Security Considerations that vendors >should consider providing a mechanism for vendor-to-booter verification >of a boot image. Such a thing already exists. It's part of the PXE specification and involves storing on the PC a public key that is used to sign the boot image. >It would be really nice if iSCSI-boot suggested a mechanism, so that >it could be built into ROMs by manufacturers that are implementing >iSCSI-boot and so that the hardware manufacturer could not use the >mechanism to lock out alternative operating systems. This capability is already built into PXE-compliant boot ROMs. In fact, you may already have purchased a NIC that implements PXE! I should note that there are some interesting issues that arise when using PXE to do secure iSCSI boot, but I'll leave that issue to another discussion. From owner-ips@ece.cmu.edu Fri Feb 9 05:11:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13302 for ; Fri, 9 Feb 2001 05:11:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f197p2p21726 for ips-outgoing; Fri, 9 Feb 2001 02:51:02 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gate.internaut.com ([64.38.134.108]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f197oRH21708 for ; Fri, 9 Feb 2001 02:50:27 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f19759R16058; Thu, 8 Feb 2001 23:05:09 -0800 From: "Bernard Aboba" To: "Michael Eisler" , "Michael Krause" Cc: Subject: RE: Security Use Requirements Date: Thu, 8 Feb 2001 23:11:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >I'd like to see a reference to 3DES hardware that encrypts at 10 gigabit/sec >in feedback mode. In general, my understanding is that 10 Gbps AES is so much closer to reality than 10 Gbps 3DES, that it is hardly worthwhile to put much effort into developing a 3DES chipset to operate at those speeds. The 3DES chipset would cost significantly more and the customers probably wouldn't want to pay the increment. Better to update the ciphersuites to include AES and negotiate that instead. From owner-ips@ece.cmu.edu Fri Feb 9 11:49:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23029 for ; Fri, 9 Feb 2001 11:49:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f19Dvbl11885 for ips-outgoing; Fri, 9 Feb 2001 08:57:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [168.159.208.81]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f19DvIZ11873 for ; Fri, 9 Feb 2001 08:57:18 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2650.21) id <1S52F9ZD>; Fri, 9 Feb 2001 08:57:45 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A0704101505@corpmx9.isus.emc.com> From: Black_David@emc.com To: aboba@internaut.com, Black_David@emc.com, jtseng@NishanSystems.com Cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Fri, 9 Feb 2001 08:57:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk > I think it might help to explicitly define what you mean by "correct". > For example, it might be possible for the iSCSI target to control > access to LUNs based on characteristics of the certs negotiated > in IKE, and characteristics of the IPSEC SA. However, I wouldn't > suggest that something like this (which requires more advanced > APIs than are generally available) is required or even > generally useful. The more important problem is one level closer to the network. iSCSI envisions and allows multiple targets behind a single IP address and TCP port. The targets are named (via WWUIs) in a fashion that neither IPsec nor TLS can be expected to understand natively (and I strongly agree with the comment about not changing IKE being the preferred course). Bernard's comments about linking iSCSI identity or proof of identity to IPSec are along the lines of what needs to be done here. We should stay away from individual LUN access issues, for two reasons: (1) They're in T10's domain and T10 is working on them. (2) There really aren't any standard ways to do this sort of thing currently deployed in the Fibre Channel world, yet. Some words on how to accomplish this by using a (virtual) target per initiator or group of initiators whose access privileges need to be distinguished would be worth including as an example, but such an approach probably should not be required. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Feb 9 13:08:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26956 for ; Fri, 9 Feb 2001 13:08:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f19GihU19088 for ips-outgoing; Fri, 9 Feb 2001 11:44:43 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gate.internaut.com ([64.38.134.108]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f19Gi7Z19042 for ; Fri, 9 Feb 2001 11:44:07 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f19Gc9R15175; Fri, 9 Feb 2001 08:38:09 -0800 From: "Bernard Aboba" To: "Prasenjit Sarkar" Cc: "Glen Turner" , , , "Julian Satran" , , "Ofer Biran" Subject: RE: Security Use Requirements (and security issue with iSCSI boot deployment) Date: Fri, 9 Feb 2001 08:44:30 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >Short of digitally signing every block, a practical way out is to for each >loaded image to verify the integrity of the subsequent image to be loaded (if any). The PXE approach is to sign the entire boot image, and verify the signature using a public key that was pre-loaded into the PC, typically by the OEM (on the customer's behalf). If you need this kind of code signing from the start, then you'll need to include that capability in the initial boot image that you retrieve via PXE. As you've stated, that initial boot image should include iSCSI driver support. From owner-ips@ece.cmu.edu Fri Feb 9 13:09:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26972 for ; Fri, 9 Feb 2001 13:09:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f19Fcdd15939 for ips-outgoing; Fri, 9 Feb 2001 10:38:39 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f19FcYZ15930 for ; Fri, 9 Feb 2001 10:38:34 -0500 (EST) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2448.0) id ; Fri, 9 Feb 2001 07:38:29 -0800 Message-ID: From: Joshua Tseng To: Bernard Aboba Cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Fri, 9 Feb 2001 07:38:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bernard, > > >TLS affords the capability of securely communicating through > >proxys. > > I think you mean NATs, no? Not sure how you'd proxy SSL > without terminating a TCP connection. You would proxy SSL by having the proxy terminate the TCP connection and map the TCP stream from the old connection to the new one. The proxy doesn't have to look inside the TCP stream, which of course is encrypted. > > >On the other hand, IPSec is a real pain to get through > >firewalls. > > If you're talking strictly about a firewall, not a NAT, I'm > not sure why there'd be a difference. For IPSEC you need to > open up protocols 50/51, and UDP 500. For SSL/TLS you need > to open up a single TCP port for the application. Either way, > you probably need to restrict communication to iSCSI targets > with appropriate negotiation policies installed. The difference between IPSec and TLS/SSL is that IPSec protects at the datagram level, while TLS/SSL protects at the TCP stream level. Passing through a firewall boundary will most likely involve changing the IP datagram itself (at least in the inbound direction), such as to perform NAT. Because IPSec protects the datagram, NAT and NAPT involves changing a portion of the IPSec protected data. Because TLS only encrypts the TCP stream and has no knowledge of the IP datagram, it can be safely repackaged into different datagrams without modifying the TCP stream and affecting TLS. There are two choices to getting IPSec data through a firewall boundary: 1) terminate the IPSec SA at the firewall and re-start a new SA on the other side. 2) Cut a hole through the firewall. The first alternative is prohibitive since the firewall is doing a lot of processing already, and it would be an administrative nightmare to set up since its a bottleneck supporting many users. The second choice is also an administrative nightmare because after a while, your firewall will look like swiss cheese. Its also a security issue because an observant attacker doing a port scan will notice that protocol 50/51 and UDP 500 can get through for various IP addresses. Josh > > >If we decide that iSCSI doesn't need to go through > >firewalls, then we could let go of TLS. > > BTW, I'd note that the IPSEC WG is currently taking up the > issue of IPSEC address dependencies and that several proposals > have been put forward. So I wouldn't rule out being able to > traverse NATs with IPSEC at some point in the future. > Unfortunately however, all of those proposals > interfere with the ability to do HW acceleration :( > From owner-ips@ece.cmu.edu Fri Feb 9 13:14:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27121 for ; Fri, 9 Feb 2001 13:13:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f19GYmX18573 for ips-outgoing; Fri, 9 Feb 2001 11:34:48 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f19FJRZ15075 for ; Fri, 9 Feb 2001 10:19:27 -0500 (EST) Received: from thor.brocade.com (thor [192.168.126.45]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id HAA28808; Fri, 9 Feb 2001 07:10:59 -0800 (PST) Received: by thor.brocadecomm.com with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Feb 2001 07:10:58 -0800 Message-ID: From: Robert Snively To: Pierre Labat , ips@ece.cmu.edu Subject: RE: ISCSI: Immediate data extending beyond a single PDU Date: Fri, 9 Feb 2001 07:10:47 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ips@ece.cmu.edu Precedence: bulk I do not see any reason to create the constraint that Pierre suggests. The goal is to negotiate a maximum acceptable buffer space always available for unsolicited data up to the length Firstburst. If the initiator chooses not to send that much data in the first transfer for reasons of its own, it should be allowed to. The performance penalty for the affected transfer is small and does not affect over-all throughput. There should be no architectural limitation demanding that the first burst of a transfer greater than Firstburst in length is always equal to Firstburst. In particular, if it isn't, what are you going to do about it, post an error? Bob > julian_satran@il.ibm.com wrote: > > > Barry, > > > > I think that the current draft does not allow you to > accept immediate but > > not unsolicited. > > You can either allow unsolicited (including immediate) or > request always > > R2T. > > > > And yes - if the expected length is larger that what you sent as > > unsolicited (even if the unsolicited was less than the > limit) the target is > > supposed to send R2T (there is only one unsolicited burst > per command). > Pierre Labat replied: > > I think there is a problem, as stated Barry, if the > initiator decides to > send unsolicited data but less than the Firstburst and > the expected length is greater than the Firstburst. In this > case the initiator > > after sending some unsolicited data waits for an R2T to continue > and the target waits for a First burst load of data before sending > an R2T. > > Solution > ====== > To avoid that, it should be explicitely stated (may be it's what > is assumed but i can't read it) that when the initiator sends > unsolicited non immediate data, it must send unsolicited data > up to Firstburst or Expected data length whichever is less. > > Regards, > > Pierre > > > > > From owner-ips@ece.cmu.edu Fri Feb 9 13:19:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27449 for ; Fri, 9 Feb 2001 13:19:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f19Gth819702 for ips-outgoing; Fri, 9 Feb 2001 11:55:43 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f19Gt8Z19651 for ; Fri, 9 Feb 2001 11:55:09 -0500 (EST) Received: from colosus2.cup.hp.com (colosus2.cup.hp.com [15.13.128.145]) by palrel1.hp.com (Postfix) with ESMTP id EDE43692 for ; Fri, 9 Feb 2001 08:55:06 -0800 (PST) Received: from hp.com (IDENT:plabat@pl703521.cup.hp.com [15.13.133.216]) by colosus2.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id IAA12553; Fri, 9 Feb 2001 08:55:05 -0800 (PST) Message-ID: <3A842125.D8A2193E@hp.com> Date: Fri, 09 Feb 2001 08:56:05 -0800 From: Pierre Labat Organization: Hewlett Packard ATM-SISL X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: ISCSI: Immediate data extending beyond a single PDU References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Robert Snively wrote: > I do not see any reason to create the constraint that Pierre > suggests. The goal is to negotiate a maximum acceptable buffer > space always available for unsolicited data up to the length Firstburst. > If the initiator chooses not to send that much data in the first > transfer for reasons of its own, it should be allowed to. The > performance penalty for the affected transfer is small and does not > affect over-all throughput. > > There should be no architectural limitation demanding that the first > burst of a transfer greater than Firstburst in length is always equal > to Firstburst. In particular, if it isn't, what are you going to do about > it, post an error? > > Bob > Julian, Robert, I missed the "F" bit in the data PDU. With that, the target knows when to send the R2T if the unsolicited data is less than the FirstBurst. Hence, as Julian said there is no problem for that. However on the other point, i am against the removal of the possibility to send unsolicited DATA PDU (and use only immediate data for unsolicited) because in the case where small iSCSI PDUs are used, it may not be possible to send all the unsolicited data in the command PDU. Regards, Pierre From owner-ips@ece.cmu.edu Fri Feb 9 13:37:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28083 for ; Fri, 9 Feb 2001 13:37:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f19GWmF18439 for ips-outgoing; Fri, 9 Feb 2001 11:32:48 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gate.internaut.com ([64.38.134.108]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f19GW0Z18403 for ; Fri, 9 Feb 2001 11:32:00 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f19GQAR14495; Fri, 9 Feb 2001 08:26:10 -0800 From: "Bernard Aboba" To: , Cc: Subject: RE: Security Use Requirements Date: Fri, 9 Feb 2001 08:32:31 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <0F31E5C394DAD311B60C00E029101A0704101505@corpmx9.isus.emc.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >iSCSI envisions and allows multiple targets behind a single IP >address and TCP port. The targets are named (via WWUIs) in a >fashion that neither IPsec nor TLS can be expected to understand Let me make sure I understand this. You will have multiple SCSI authentications to the same target IP address and port. Does the initiator port vary between them or is that the same too? If the same initiator port is used, I think there will be a problem. How would the conversants know which IPSEC QM SA to use to send a particular transaction? On outbound, from the point of view of the IPSEC driver, it sees a packet come down with a given IP and transport header. Based on this information, it decides which IKE QM SA the packet belongs to, if any. So the driver has no notion of WWUIs, and needs to make its decision purely based on the IP and transport headers. If there isn't anything in there that is different between the QM SAs, the driver will pick one, but it might not be the right one. From owner-ips@ece.cmu.edu Fri Feb 9 13:38:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28100 for ; Fri, 9 Feb 2001 13:38:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f19Frk716640 for ips-outgoing; Fri, 9 Feb 2001 10:53:46 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f19FqnZ16601 for ; Fri, 9 Feb 2001 10:52:49 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id QAA61696; Fri, 9 Feb 2001 16:51:19 +0100 From: julian_satran@il.ibm.com Received: from d12mta05.de.ibm.com (d12mta06_cs0 [9.165.222.255]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id QAA82202; Fri, 9 Feb 2001 16:51:07 +0100 Received: by d12mta05.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569EE.005713E8 ; Fri, 9 Feb 2001 16:51:07 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: "Bernard Aboba" cc: Black_David@emc.com, ips@ece.cmu.edu, "RJ Atkinson" , "Smb@Research. Att. Com" , biran@il.ibm.com Message-ID: Date: Fri, 9 Feb 2001 17:24:23 +0200 Subject: RE: Security Use Requirements Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Bernard, 1- I stand by the numbers($) I quoted - not today however -:) 2-We wanted TLS to get iSCSI "thinner" and move out of it session-authentication. IKE is not as flexible today. If we are forced to mandate something on the channel - we would prefer it to be IPsec. 3-TLS during the session is also less attractive as it gets into the way of other mechanisms (1.8 in the current draft). David (Black), You said - But how do one know that one has the *right* public key? Since certificates aren't required in the current iSCSI draft, and the key distribution mechanism is not specified, all sorts of mischief is possible if naked public keys are being passed around. Needless to say, that's not a particularly intelligent way to do key distribution, but like the previous case, a discussion about what is required to assure that key distribution actually distributes the correct keys (and how to verify that if necessary) is in order. The current iSCSI draft also includes a number of weaker authentication mechanisms that are vulnerable to man-in-the-middle attacks when there is not an end-to-end SA in contrast to public key mechanisms. Current iSCSI has a single mechanism that could be used for key distribution - Kerberos. What I am trying to do is completely remove any need to deal with this subject within iSCSI and to defer to specialized standards. There many obvious reasons to do that. Even if we go for IPSec only I still think we should remove from this draft all session authentication mechanisms beyond Kerberos and perhaps SRP. Regards, Julo "Bernard Aboba" on 09/02/2001 08:10:45 Please respond to "Bernard Aboba" To: Julian Satran/Haifa/IBM@IBMIL cc: Black_David@emc.com, ips@ece.cmu.edu, "RJ Atkinson" , "Smb@Research. Att. Com" , Ofer Biran/Haifa/IBM@IBMIL Subject: RE: Security Use Requirements >The reason we went after TLS is that it can be used for session >authentication with stronger schemes than >and it is very popular for software implementations. SSL/TLS has many nice features, including better API support in most cases, more flexible certificate policies, and lightweight ciphers (e.g. RC4) This often makes it an attractive choice for applications requiring ~ 100 Mbps throughput (e.g. your average web server). >As for the cost of the hardware - the figures you quote are for 100Mbs (and >even there the NIC numbers are higher). The low-end iSCSI adapters will >cost well under $100 (at 1GBbs). Really? Mind if I order a few thousand to use as ordinary Gigabit Ethernet NICs? Our server farms need an inexpensive upgrade for the 100 Mbps adapters ;) >I don't envision all the options becoming necessary for hardware >implementations. The pieces we wanted from TLS can be implemented in >software. Well, if you only have a few sessions per card, you can do session establishment in software. However, even though RC4 is very light weight, it is very hard to get close to 1 Gbps throughput on it, even with a 1 Ghz processor. So you will be likely to bottleneck at relatively low interface utilization unless you have more than one CPU to throw at it. >If we where forced to select one I would too go for >IPsec (and that is what we have in the current draft) > but then we have to specify session authentication > on our own and keep updating it as new schemes enter >the world. Not sure why this would be necessary. Doesn't IKE (either with Certs or shared secrets) give you the necessary authentication/integrity protection? From owner-ips@ece.cmu.edu Fri Feb 9 14:49:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00184 for ; Fri, 9 Feb 2001 14:49:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f19HZhn21592 for ips-outgoing; Fri, 9 Feb 2001 12:35:43 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f19HYeZ21514 for ; Fri, 9 Feb 2001 12:34:40 -0500 (EST) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2448.0) id ; Fri, 9 Feb 2001 09:34:38 -0800 Message-ID: From: Joshua Tseng To: Bernard Aboba Cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Fri, 9 Feb 2001 09:34:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bernard, See below: > > >is that it's necessary to ensure that there isn't a gap between iSCSI > >authentication and IPSec > authentication/integrity/confidentiality that > >would allow the communication to be attacked without breaking IPSec. > > I think you're basically asking to make sure that an given > IPSEC-protected > iSCSI packet originated from the same entity that completed the > iSCSI authentication, no? > > In IPSEC there is a similar issue in that you want to make sure that a > given IPSEC packet originated from the same entity with which you > negotiated the IKE MM and QM SAs. The packet identity is tied > back to the > IKE-provided identity via the IP header and SPI, and the claim of > identity is proven by verifying the integrity/authenticity of the > packet, thereby verifying that the entity has posession of the > key previously negotiated within IKE. > I think there is a much easier way than the two methods you describe below. If the iSCSI authentication is taking place using the SA negotiated by IKE, then you have an implicit relationship between IKE and iSCSI authentication, right? Just layer the iSCSI authentication on top of IPSec. Have IKE set up the IPSec SA used to secure that communication channel between the two IP addresses. Then have iSCSI login process use that channel to authenticate and authorize the communicating entities. No need to have iSCSI and IKE/IPSec communicate with each other or in any way be aware of each other. This allows you to use any generic IPSec security gateway, or even to take an off-the-shelf BITS (bump-in-the-stack) IPSec implementation and just stick it in there somewhere underneath TCP in the iSCSI stack. Josh > So, in the case of iSCSI authentication, you have a claim of identity, > and a proof of identity. To link this to an IPSEC packet, you have > a few choices: > > 1. Somehow link the identity claimed in the iSCSI authentication to > information exchanged within the IKE negotiation. > > If you can link the iSCSI authentication to the IKE MM and QM SAs, > you will have a link to the IPSEC packet via the IP header and SPI. > > Note that "information exchanged" may constitute more than just > the claimed IKE identity. It could include information within the > cert, for example. > > It is best to accomplish this without trying to invent new > identity payloads within IKE. > > 2. Somehow link the proof of identity within iSCSI authentication > to the proof of identity made within IKE. For example, if a key > is generated within iSCSI authentication, then this key can be > used as a shared secret within IKE. > > However, in order to make this work, you will also need to link > the iSCSI authentication claim of identity to the claim of > identity made within IKE. Note that this does not mean that > the claims are identical -- merely that they can be bound in > a secure way. > From owner-ips@ece.cmu.edu Fri Feb 9 15:41:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01216 for ; Fri, 9 Feb 2001 15:41:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f19Idfc24470 for ips-outgoing; Fri, 9 Feb 2001 13:39:41 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gate.internaut.com ([64.38.134.108]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f19IdLZ24453 for ; Fri, 9 Feb 2001 13:39:21 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f19IXaR21546; Fri, 9 Feb 2001 10:33:36 -0800 From: "Bernard Aboba" To: "Joshua Tseng" Cc: Subject: RE: Security Use Requirements Date: Fri, 9 Feb 2001 10:39:57 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >I think there is a much easier way than the two methods you describe below. >If the iSCSI authentication is taking place using the SA negotiated by IKE, >then you have an implicit relationship between IKE and iSCSI authentication, >right? That would be fine if there is only one iSCSI authentication per IKE QM SA. Is that realistic? From owner-ips@ece.cmu.edu Fri Feb 9 15:54:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01563 for ; Fri, 9 Feb 2001 15:54:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f19J2i725585 for ips-outgoing; Fri, 9 Feb 2001 14:02:44 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f19J25Z25555 for ; Fri, 9 Feb 2001 14:02:05 -0500 (EST) Received: from phys-ha10nwka.ebay.sun.com ([129.150.140.210]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA09972; Fri, 9 Feb 2001 11:02:04 -0800 (PST) Received: from ebay.sun.com (dsl197-15.Eng.Sun.COM [129.146.197.15]) by phys-ha10nwka.ebay.sun.com (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id LAA16355; Fri, 9 Feb 2001 11:01:49 -0800 (PST) Message-ID: <3A843EA3.62EBFCCC@ebay.sun.com> Date: Fri, 09 Feb 2001 11:01:55 -0800 From: David Robinson X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba CC: Black_David@emc.com, jtseng@NishanSystems.com, ips@ece.cmu.edu Subject: Re: Security Use Requirements References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > >iSCSI envisions and allows multiple targets behind a single IP > >address and TCP port. The targets are named (via WWUIs) in a > >fashion that neither IPsec nor TLS can be expected to understand > > Let me make sure I understand this. You will have multiple > SCSI authentications to the same target IP address and port. > Does the initiator port vary between them or is that the > same too? I haven't heard anyone strongly request this. Hopefully another body will handle this within the SCSI layer. If there is demand I would suggest looking at how the NFSv4 WG handled this using GSSAPI. But I personally think that is overkill for iSCSI. -David From owner-ips@ece.cmu.edu Fri Feb 9 16:52:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02885 for ; Fri, 9 Feb 2001 16:52:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f19JChf26028 for ips-outgoing; Fri, 9 Feb 2001 14:12:43 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f19JC5Z26000 for ; Fri, 9 Feb 2001 14:12:05 -0500 (EST) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2448.0) id ; Fri, 9 Feb 2001 11:12:00 -0800 Message-ID: From: Joshua Tseng To: Bernard Aboba Cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Fri, 9 Feb 2001 11:11:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > > >I think there is a much easier way than the two methods you > describe below. > >If the iSCSI authentication is taking place using the SA > negotiated by IKE, > >then you have an implicit relationship between IKE and iSCSI > authentication, > >right? > > That would be fine if there is only one iSCSI authentication > per IKE QM > SA. Is that realistic? > Yes, you have a point in that multiple iSCSI devices MAY exist behind the same IP address, and each device would be sharing the same IKE SA if they were talking to the same peer IP address. This would be the case for a storage device that had multiple WWUI's. It could also happen if the IP address/IKE endpoint was a security gateway, and there was a network behind it supporting multiple iSCSI devices. As I mentioned before, physical security is needed to handle each of these cases, to ensure a hostile entity can't use the same IP address that was authenticated by IKE. In the former case, physical security is pretty much assured, since both IKE/IPSec and the multiple iSCSI WWUI's share not only the same physical box, but also the same TCP stack. In the latter, yes of course additional measures MUST be taken to ensure there are no hostile entities living behind a security gateway. Sure, an implementation geared to the paranoid user could do what you prescribed in your previous message (but your suggestions only make sense for a native iSCSI device). But I don't think these measures should be a MUST. Physical security is a non-negotiable requirement in both cases, and especially in the standalone security gateway scenario, this is a quite well understood requirement in the security architecture document RFC 2401 when it describes tunnel mode. Josh From owner-ips@ece.cmu.edu Fri Feb 9 19:46:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05272 for ; Fri, 9 Feb 2001 19:46:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f19MHkh06567 for ips-outgoing; Fri, 9 Feb 2001 17:17:46 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f19MH4Z06538 for ; Fri, 9 Feb 2001 17:17:04 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id XAA10582; Fri, 9 Feb 2001 23:16:53 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay02.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id XAA67580; Fri, 9 Feb 2001 23:16:38 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569EE.007A5FD8 ; Fri, 9 Feb 2001 23:16:39 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: Pierre Labat cc: ips@ece.cmu.edu Message-ID: Date: Sat, 10 Feb 2001 00:12:02 +0200 Subject: Re: ISCSI: Immediate data extending beyond a single PDU Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Pierre, Barry did not ask for unsolicited data to be eliminated - he rather asked for immediate to be enabled independent of enabling unsolicited (i.e., you can have either both - not in the same command obviously - or only immediate). Do you object to this too? Regards, Julo Pierre Labat on 09/02/2001 18:56:05 Please respond to Pierre Labat To: ips@ece.cmu.edu cc: Subject: Re: ISCSI: Immediate data extending beyond a single PDU Robert Snively wrote: > I do not see any reason to create the constraint that Pierre > suggests. The goal is to negotiate a maximum acceptable buffer > space always available for unsolicited data up to the length Firstburst. > If the initiator chooses not to send that much data in the first > transfer for reasons of its own, it should be allowed to. The > performance penalty for the affected transfer is small and does not > affect over-all throughput. > > There should be no architectural limitation demanding that the first > burst of a transfer greater than Firstburst in length is always equal > to Firstburst. In particular, if it isn't, what are you going to do about > it, post an error? > > Bob > Julian, Robert, I missed the "F" bit in the data PDU. With that, the target knows when to send the R2T if the unsolicited data is less than the FirstBurst. Hence, as Julian said there is no problem for that. However on the other point, i am against the removal of the possibility to send unsolicited DATA PDU (and use only immediate data for unsolicited) because in the case where small iSCSI PDUs are used, it may not be possible to send all the unsolicited data in the command PDU. Regards, Pierre From owner-ips@ece.cmu.edu Fri Feb 9 19:56:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05369 for ; Fri, 9 Feb 2001 19:56:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f19N7qv09083 for ips-outgoing; Fri, 9 Feb 2001 18:07:52 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f19N7gZ09055 for ; Fri, 9 Feb 2001 18:07:42 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f1A0Fr079273; Fri, 9 Feb 2001 16:15:53 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: "David Robinson" , "Bernard Aboba" Cc: , , Subject: RE: Security Use Requirements Date: Fri, 9 Feb 2001 15:04:30 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3A843EA3.62EBFCCC@ebay.sun.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, The GSS-API supports efforts promoted by Julian. Privacy at the SAN level will be expensive and, if done in software, appear broken. A compression-encryption then signed with a digest will be very computationally intensive and increase latency. Just a signature would provide integrity. There are many mediums and applications that can provide privacy as an add-on feature at the file level usable as required without impacting the entire operation of the SAN. If the media provides protection, then adding privacy at the SAN becomes redundant and may run into export restrictions. A SAN in Germany will not be useable by someone in Spain because the fiber travels through France. With all of this security, we have yet to discuss the back door. How is the user authorized? The SCSI controller tells the user but where does the controller discovery this information? Who holds the key for the back door and how does one go about changing the locks. Most people still have windows in their homes at the cost of privacy. If it becomes important, there are curtains that can be drawn over the window and the sound of breaking glass is a bad signature. Privacy applications, curtains, can work on any drive and not just network drives. Doug > Bernard Aboba wrote: > > >iSCSI envisions and allows multiple targets behind a single IP > > >address and TCP port. The targets are named (via WWUIs) in a > > >fashion that neither IPsec nor TLS can be expected to understand > > > > Let me make sure I understand this. You will have multiple > > SCSI authentications to the same target IP address and port. > > Does the initiator port vary between them or is that the > > same too? > > I haven't heard anyone strongly request this. Hopefully > another body will handle this within the SCSI layer. If > there is demand I would suggest looking at how the NFSv4 WG > handled this using GSSAPI. But I personally think that is > overkill for iSCSI. > > -David > From owner-ips@ece.cmu.edu Fri Feb 9 23:08:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09205 for ; Fri, 9 Feb 2001 23:08:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1A1Spj15174 for ips-outgoing; Fri, 9 Feb 2001 20:28:51 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from xchange.zambeel.com ([63.89.188.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1A1SBZ15148 for ; Fri, 9 Feb 2001 20:28:12 -0500 (EST) Received: by exchange.zambeel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Feb 2001 17:28:02 -0800 Received: from frostback (10.0.1.120 [10.0.1.120]) by xchange.zambeel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CR9GDSZF; Fri, 9 Feb 2001 17:27:57 -0800 From: Michael Eisler Reply-To: Michael Eisler To: Douglas Otis Cc: David Robinson , Bernard Aboba , Black_David@emc.com, jtseng@NishanSystems.com, ips@ece.cmu.edu Date: Fri, 9 Feb 2001 17:25:06 -0800 (PST) Subject: RE: Security Use Requirements In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk > If the media provides protection, > then adding privacy at the SAN becomes redundant and may run into export > restrictions. Concern about export controls is a syntax area with respect to the IETF. RFC 1984. > A SAN in Germany will not be useable by someone in Spain > because the fiber travels through France. My understanding is that France has relaxed its domestic use control due to concerns about the the US/UK/Canada/Australia spying on Fench domestic communications. I've exported 56 bit privacy products to France, albeit with the degree of red tape that makes the NSA look reasonable by comparision. -mre From owner-ips@ece.cmu.edu Fri Feb 9 23:11:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09245 for ; Fri, 9 Feb 2001 23:11:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1A2Vqi17735 for ips-outgoing; Fri, 9 Feb 2001 21:31:52 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gate.internaut.com ([64.38.134.108]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1A2UwZ17703 for ; Fri, 9 Feb 2001 21:30:58 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1A2P8R14865; Fri, 9 Feb 2001 18:25:08 -0800 From: "Bernard Aboba" To: "David Robinson" Cc: , , Subject: RE: Security Use Requirements Date: Fri, 9 Feb 2001 18:31:32 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3A843EA3.62EBFCCC@ebay.sun.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> >iSCSI envisions and allows multiple targets behind a single IP >> >address and TCP port. The targets are named (via WWUIs) in a >> >fashion that neither IPsec nor TLS can be expected to understand > >> Let me make sure I understand this. You will have multiple >> SCSI authentications to the same target IP address and port. >> Does the initiator port vary between them or is that the >> same too? >I haven't heard anyone strongly request this. Hopefully >another body will handle this within the SCSI layer. If >there is demand I would suggest looking at how the NFSv4 WG >handled this using GSSAPI. But I personally think that is >overkill for iSCSI. Are you saying that we *don't* need to worry about multiple SCSI authentications to the same target IP address and port? That would certainly simplify things. From owner-ips@ece.cmu.edu Sat Feb 10 04:21:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24828 for ; Sat, 10 Feb 2001 04:21:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1A7Rvl29399 for ips-outgoing; Sat, 10 Feb 2001 02:27:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1A7RcZ29379 for ; Sat, 10 Feb 2001 02:27:38 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id IAA111368; Sat, 10 Feb 2001 08:27:26 +0100 From: julian_satran@il.ibm.com Received: from d12mta05.de.ibm.com (d12mta06_cs0 [9.165.222.255]) by d12relay02.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id IAA92754; Sat, 10 Feb 2001 08:27:10 +0100 Received: by d12mta05.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569EF.0028F604 ; Sat, 10 Feb 2001 08:27:24 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: Joshua Tseng cc: Bernard Aboba , ips@ece.cmu.edu Message-ID: Date: Sat, 10 Feb 2001 09:22:50 +0200 Subject: RE: Security Use Requirements Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Josh, The connections are disjoint allways and the IPSec context is per connection. There is no issue here. iSCSI does not allow 1 session to several targets. The target sellector is used only at connection setup and the connections to different targets are disjoint (even if they use the same target port - the initiator address+port has to be distinct in this case). Regards, Julo Joshua Tseng on 09/02/2001 21:11:54 Please respond to Joshua Tseng To: Bernard Aboba cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements > > >I think there is a much easier way than the two methods you > describe below. > >If the iSCSI authentication is taking place using the SA > negotiated by IKE, > >then you have an implicit relationship between IKE and iSCSI > authentication, > >right? > > That would be fine if there is only one iSCSI authentication > per IKE QM > SA. Is that realistic? > Yes, you have a point in that multiple iSCSI devices MAY exist behind the same IP address, and each device would be sharing the same IKE SA if they were talking to the same peer IP address. This would be the case for a storage device that had multiple WWUI's. It could also happen if the IP address/IKE endpoint was a security gateway, and there was a network behind it supporting multiple iSCSI devices. As I mentioned before, physical security is needed to handle each of these cases, to ensure a hostile entity can't use the same IP address that was authenticated by IKE. In the former case, physical security is pretty much assured, since both IKE/IPSec and the multiple iSCSI WWUI's share not only the same physical box, but also the same TCP stack. In the latter, yes of course additional measures MUST be taken to ensure there are no hostile entities living behind a security gateway. Sure, an implementation geared to the paranoid user could do what you prescribed in your previous message (but your suggestions only make sense for a native iSCSI device). But I don't think these measures should be a MUST. Physical security is a non-negotiable requirement in both cases, and especially in the standalone security gateway scenario, this is a quite well understood requirement in the security architecture document RFC 2401 when it describes tunnel mode. Josh From owner-ips@ece.cmu.edu Sat Feb 10 04:21:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24839 for ; Sat, 10 Feb 2001 04:21:25 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1A7Mu429202 for ips-outgoing; Sat, 10 Feb 2001 02:22:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1A7MVZ29187 for ; Sat, 10 Feb 2001 02:22:31 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA191506; Sat, 10 Feb 2001 08:22:25 +0100 From: julian_satran@il.ibm.com Received: from d12mta05.de.ibm.com (d12mta06_cs0 [9.165.222.255]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id IAA94990; Sat, 10 Feb 2001 08:22:15 +0100 Received: by d12mta05.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569EF.00287F0C ; Sat, 10 Feb 2001 08:22:19 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: "Bernard Aboba" cc: "Joshua Tseng" , ips@ece.cmu.edu Message-ID: Date: Sat, 10 Feb 2001 09:17:44 +0200 Subject: RE: Security Use Requirements Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk I think there is only one per connection. But by carefull handling at both ends the connection should be able to share the same context. Regards, Julo "Bernard Aboba" on 09/02/2001 20:39:57 Please respond to "Bernard Aboba" To: "Joshua Tseng" cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements >I think there is a much easier way than the two methods you describe below. >If the iSCSI authentication is taking place using the SA negotiated by IKE, >then you have an implicit relationship between IKE and iSCSI authentication, >right? That would be fine if there is only one iSCSI authentication per IKE QM SA. Is that realistic? From owner-ips@ece.cmu.edu Sat Feb 10 04:30:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24856 for ; Sat, 10 Feb 2001 04:30:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1A7BuD28820 for ips-outgoing; Sat, 10 Feb 2001 02:11:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1A7AtZ28785 for ; Sat, 10 Feb 2001 02:10:55 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id IAA77764; Sat, 10 Feb 2001 08:10:48 +0100 From: julian_satran@il.ibm.com Received: from d12mta05.de.ibm.com (d12mta06_cs0 [9.165.222.255]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id IAA121432; Sat, 10 Feb 2001 08:10:38 +0100 Received: by d12mta05.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569EF.00276E7F ; Sat, 10 Feb 2001 08:10:41 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: "Bernard Aboba" cc: Black_David@emc.com, jtseng@NishanSystems.com, ips@ece.cmu.edu Message-ID: Date: Sat, 10 Feb 2001 09:06:06 +0200 Subject: RE: Security Use Requirements Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Bernard, No the initiator port is different (the TCP connections are disjoint). However this brings with it another issue. Separate connections (even within the same session) can have different security - and this is not a useless feature e.g., a private link with a backup public link. In other environments you have links with similar needs. Does IPSec provide a replication mechanism for security contexts? Regards, Julo "Bernard Aboba" on 09/02/2001 18:32:31 Please respond to "Bernard Aboba" To: Black_David@emc.com, jtseng@NishanSystems.com cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements >iSCSI envisions and allows multiple targets behind a single IP >address and TCP port. The targets are named (via WWUIs) in a >fashion that neither IPsec nor TLS can be expected to understand Let me make sure I understand this. You will have multiple SCSI authentications to the same target IP address and port. Does the initiator port vary between them or is that the same too? If the same initiator port is used, I think there will be a problem. How would the conversants know which IPSEC QM SA to use to send a particular transaction? On outbound, from the point of view of the IPSEC driver, it sees a packet come down with a given IP and transport header. Based on this information, it decides which IKE QM SA the packet belongs to, if any. So the driver has no notion of WWUIs, and needs to make its decision purely based on the IP and transport headers. If there isn't anything in there that is different between the QM SAs, the driver will pick one, but it might not be the right one. From owner-ips@ece.cmu.edu Sat Feb 10 15:08:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27545 for ; Sat, 10 Feb 2001 15:08:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1AIB6X02076 for ips-outgoing; Sat, 10 Feb 2001 13:11:06 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1AIA4Z02016 for ; Sat, 10 Feb 2001 13:10:04 -0500 (EST) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2448.0) id ; Sat, 10 Feb 2001 10:10:00 -0800 Message-ID: From: Joshua Tseng To: julian_satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Sat, 10 Feb 2001 10:09:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hmmmm, Yes, you are right Julian. I was thinking about IPSec implementations that use only the IP address and not the TCP port as a selector. But yes, IPSec can use source & destination TCP port as a selector, in addition to IP address. If that is the case, then there can only be one iSCSI Login per IKE negotiation. Thanks! I believe that wraps up the case that IKE/IPSec and iSCSI can be completely independent of each other. If we layer iSCSI sessions on top of IKE/IPSec, there should be no loss of security. Josh > > Josh, > > The connections are disjoint allways and the IPSec context is per > connection. > There is no issue here. iSCSI does not allow 1 session to > several targets. > The target sellector is used only at connection setup and the > connections > to different targets are disjoint (even if they use the same > target port - > the initiator address+port has to be distinct in this case). > > Regards, > Julo > > Joshua Tseng on 09/02/2001 21:11:54 > > Please respond to Joshua Tseng > > To: Bernard Aboba > cc: ips@ece.cmu.edu > Subject: RE: Security Use Requirements > > > > > > > > >I think there is a much easier way than the two methods you > > describe below. > > >If the iSCSI authentication is taking place using the SA > > negotiated by IKE, > > >then you have an implicit relationship between IKE and iSCSI > > authentication, > > >right? > > > > That would be fine if there is only one iSCSI authentication > > per IKE QM > > SA. Is that realistic? > > > > Yes, you have a point in that multiple iSCSI devices MAY > exist behind the > same IP address, and each device would be sharing the same > IKE SA if they > were talking to the same peer IP address. This would be the > case for a > storage device that had multiple WWUI's. It could also > happen if the IP > address/IKE endpoint was a security gateway, and there was a > network behind > it supporting multiple iSCSI devices. > > As I mentioned before, physical security is needed to handle > each of these > cases, to ensure a hostile entity can't use the same IP > address that was > authenticated by IKE. In the former case, physical security > is pretty much > assured, since both IKE/IPSec and the > multiple iSCSI WWUI's share not only the same physical box, > but also the > same TCP stack. In the latter, yes of course additional > measures MUST be > taken to ensure there are no hostile entities living behind a security > gateway. > > Sure, an implementation geared to the paranoid user could do what you > prescribed in your previous message (but your suggestions > only make sense > for a native iSCSI device). But I don't think these measures > should be a > MUST. Physical security is a non-negotiable requirement in > both cases, and > especially in the standalone security gateway scenario, this > is a quite > well > understood requirement in the security architecture document > RFC 2401 when > it describes tunnel mode. > > Josh > > > From owner-ips@ece.cmu.edu Sat Feb 10 15:09:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27572 for ; Sat, 10 Feb 2001 15:09:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1AHv9f01480 for ips-outgoing; Sat, 10 Feb 2001 12:57:09 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1AHulZ01465 for ; Sat, 10 Feb 2001 12:56:47 -0500 (EST) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2448.0) id ; Sat, 10 Feb 2001 09:56:41 -0800 Message-ID: From: Joshua Tseng To: "'=SMTP:julian_satran@il.ibm.com'"@ece.cmu.edu Cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Sat, 10 Feb 2001 09:56:39 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hmmmm, Yes, you are right Julian. I was thinking about IPSec implementations that use only the IP address and not the TCP port as a selector. But yes, IPSec can use source & destination TCP port as a selector, in addition to IP address. If that is the case, then there can only be one iSCSI Login per IKE negotiation. Thanks! I believe that wraps up the case that IKE/IPSec and iSCSI can be completely independent of each other. If we layer iSCSI sessions on top of IKE/IPSec, there should be no loss of security. Josh > > Josh, > > The connections are disjoint allways and the IPSec context is per > connection. > There is no issue here. iSCSI does not allow 1 session to > several targets. > The target sellector is used only at connection setup and the > connections > to different targets are disjoint (even if they use the same > target port - > the initiator address+port has to be distinct in this case). > > Regards, > Julo > > Joshua Tseng on 09/02/2001 21:11:54 > > Please respond to Joshua Tseng > > To: Bernard Aboba > cc: ips@ece.cmu.edu > Subject: RE: Security Use Requirements > > > > > > > > >I think there is a much easier way than the two methods you > > describe below. > > >If the iSCSI authentication is taking place using the SA > > negotiated by IKE, > > >then you have an implicit relationship between IKE and iSCSI > > authentication, > > >right? > > > > That would be fine if there is only one iSCSI authentication > > per IKE QM > > SA. Is that realistic? > > > > Yes, you have a point in that multiple iSCSI devices MAY > exist behind the > same IP address, and each device would be sharing the same > IKE SA if they > were talking to the same peer IP address. This would be the > case for a > storage device that had multiple WWUI's. It could also > happen if the IP > address/IKE endpoint was a security gateway, and there was a > network behind > it supporting multiple iSCSI devices. > > As I mentioned before, physical security is needed to handle > each of these > cases, to ensure a hostile entity can't use the same IP > address that was > authenticated by IKE. In the former case, physical security > is pretty much > assured, since both IKE/IPSec and the > multiple iSCSI WWUI's share not only the same physical box, > but also the > same TCP stack. In the latter, yes of course additional > measures MUST be > taken to ensure there are no hostile entities living behind a security > gateway. > > Sure, an implementation geared to the paranoid user could do what you > prescribed in your previous message (but your suggestions > only make sense > for a native iSCSI device). But I don't think these measures > should be a > MUST. Physical security is a non-negotiable requirement in > both cases, and > especially in the standalone security gateway scenario, this > is a quite > well > understood requirement in the security architecture document > RFC 2401 when > it describes tunnel mode. > > Josh > > > From owner-ips@ece.cmu.edu Sun Feb 11 04:42:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07597 for ; Sun, 11 Feb 2001 04:42:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1B7VGW02987 for ips-outgoing; Sun, 11 Feb 2001 02:31:16 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1B7UPZ02950 for ; Sun, 11 Feb 2001 02:30:25 -0500 (EST) Received: from phys-ha10nwka.ebay.sun.com ([129.150.142.210]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA24763; Sat, 10 Feb 2001 23:30:22 -0800 (PST) Received: from ebay.sun.com (dsl197-15.Eng.Sun.COM [129.146.197.15]) by phys-ha10nwka.ebay.sun.com (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id XAA18834; Sat, 10 Feb 2001 23:30:21 -0800 (PST) Message-ID: <3A863F8E.C5B578B9@ebay.sun.com> Date: Sat, 10 Feb 2001 23:30:22 -0800 From: David Robinson X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba , ips@ece.cmu.edu CC: Black_David@emc.com, jtseng@NishanSystems.com Subject: Re: Security Use Requirements References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > >I haven't heard anyone strongly request this. Hopefully > >another body will handle this within the SCSI layer. If > >there is demand I would suggest looking at how the NFSv4 WG > >handled this using GSSAPI. But I personally think that is > >overkill for iSCSI. > > Are you saying that we *don't* need to worry about multiple > SCSI authentications to the same target IP address and port? > That would certainly simplify things. I can easily see a design that has multiple authentications on the same connection. But I am going to argue that we resist it strongly. Unlike NFS where there are multiple principals on a node muxed over a single connection, SCSI tends to have just one principal (the node) over a connection. While I think that the SCSI community would like to move towards the more complex model, they will have to come up with a common model that will map to all the various transports which I hope will be above the transport layer. iSCSI can then just focus on securing the connection between two nodes and let SCSI deal with multiple authentications. I am curious if anyone else thinks we should try and tackle the much harder problem at the iSCSI layer? -David From owner-ips@ece.cmu.edu Sun Feb 11 13:53:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11681 for ; Sun, 11 Feb 2001 13:53:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1BGehG01871 for ips-outgoing; Sun, 11 Feb 2001 11:40:43 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gate.internaut.com ([64.38.134.108]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1BGeCZ01831 for ; Sun, 11 Feb 2001 11:40:12 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1BGXuR13257; Sun, 11 Feb 2001 08:33:56 -0800 From: "Bernard Aboba" To: Cc: , , Subject: RE: Security Use Requirements Date: Sun, 11 Feb 2001 08:40:31 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >No the initiator port is different (the TCP connections are disjoint). That is a good thing because it means that you can distinguish between the IPSEC QM SAs. >However this brings with it another issue. Separate connections (even >within the same session) can have different security - and this is not a >useless feature e.g., a private link with a backup public link. >In other environments you have links with similar needs. Does IPSec >provide a replication mechanism for security contexts? It is possible to open multiple IKE QM SAs between the target and the initiator. For example, you could decide that the backup public link requires ESP 3DES while the private link can live with AH. As long as the connections are distinct (e.g. different initiator port) then the target and initiator can figure out which QM SA corresponds to which traffic, and everything will be fine. It is also possible to negotiate multiple IKE MM SAs between two nodes, although this is rarely done. This might be useful if the initiator wants to use a different certificate for authentication than in a previous IKE MM SA. For example, the set of trusted roots might need to be different, etc. Again, as long as IKE QM SAs derived from that MM SA are distinguishable from other QM SAs derived from other MM SAs, everything will work fine. From owner-ips@ece.cmu.edu Sun Feb 11 13:56:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11718 for ; Sun, 11 Feb 2001 13:56:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1BGiha02012 for ips-outgoing; Sun, 11 Feb 2001 11:44:43 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gate.internaut.com ([64.38.134.108]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1BGieZ02005 for ; Sun, 11 Feb 2001 11:44:40 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1BGcgR13493; Sun, 11 Feb 2001 08:38:42 -0800 From: "Bernard Aboba" To: Cc: "Joshua Tseng" , Subject: RE: Security Use Requirements Date: Sun, 11 Feb 2001 08:45:18 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>I think there is a much easier way than the two methods you describe below. >>>If the iSCSI authentication is taking place using the SA negotiated by IKE, >>>then you have an implicit relationship between IKE and iSCSI authentication, >>>right? >>That would be fine if there is only one iSCSI authentication per IKE QM >>SA. Is that realistic? >I think there is only one per connection. >But by carefull handling at both ends the connection should be able to >share the same context. If each iSCSI authentication corresponds to a different initiator port number, then there is indeed only one per connection (IKE QM SA). The IP header and IPSEC SPI then link back to the IKE QM SA which in turn has a link to the IKE MM SA. Thus it is possible to link a given packet back to the identity used in the IKE MM negotiation. This implies that a given WWUI is authorized for use on only one 5-tuple, and iSCSI needs to enforce this restriction. If a packet for the wrong WWUI arrives on a 5-tuple then iSCSI needs to discard it. In effect, this results in a hard mapping of WWUI to 5-tuple. IPSEC can then be relied upon to make sure that traffic on a 5-tuple is integrity protected (and confidential if requested) and was sent by the entity that negotiated the IKE MM and QM SAs under which it was sent. Does this meet your needs? From owner-ips@ece.cmu.edu Mon Feb 12 04:11:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02917 for ; Mon, 12 Feb 2001 04:11:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1C6vLV06841 for ips-outgoing; Mon, 12 Feb 2001 01:57:21 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1C6u7Z06804 for ; Mon, 12 Feb 2001 01:56:07 -0500 (EST) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2448.0) id ; Sun, 11 Feb 2001 22:56:00 -0800 Message-ID: From: Joshua Tseng To: Bernard Aboba Cc: ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Sun, 11 Feb 2001 22:55:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bernard, > >I think there is only one per connection. > >But by carefull handling at both ends the connection should > be able to > >share the same context. > > If each iSCSI authentication corresponds to a different initiator port > number, then there is indeed only one per connection (IKE QM SA). The > IP header and IPSEC SPI then link back to the IKE QM SA which in turn > has a link to the IKE MM SA. Thus it is possible to link a given > packet back to the identity used in the IKE MM negotiation. > > This implies that a given WWUI is authorized for use on only one > 5-tuple, and iSCSI needs to enforce this restriction. If a packet > for the wrong WWUI arrives on a 5-tuple then iSCSI needs to discard > it. In effect, this results in a hard mapping of WWUI to 5-tuple. I think the WWUI only exists on the iSCSI login PDU, right?. As far as I know, that is the only place it shows up. If this is correct, then it is neither a practical nor efficient use of resources to for iSCSI to cross-check the WWUI with the IKE SA. I think it is fine enough for IKE to initiate a new IKE SA (let the implementor decide if it's MM or QM) every time it detects a new TCP connection (which implicitly means a new iSCSI login). But I question that even this should be MANDATORY, because most IPSec/IKE implementations are triggered and keyed only by destination IP address. If an implementor wants to put all their iSCSI sessions on the same IPSec SA, I think they should have that liberty. Josh > IPSEC can then be relied upon to make sure that traffic on a 5-tuple > is integrity protected (and confidential if requested) and was sent > by the entity that negotiated the IKE MM and QM SAs under which it > was sent. > > Does this meet your needs? > > From owner-ips@ece.cmu.edu Mon Feb 12 04:12:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02928 for ; Mon, 12 Feb 2001 04:12:27 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1C6hKU06304 for ips-outgoing; Mon, 12 Feb 2001 01:43:20 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [168.159.208.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1C6hDZ06296 for ; Mon, 12 Feb 2001 01:43:14 -0500 (EST) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2650.21) id <1PVWZMJ9>; Mon, 12 Feb 2001 01:43:07 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A070410150C@corpmx9.isus.emc.com> From: Black_David@emc.com To: aboba@internaut.com, julian_satran@il.ibm.com Cc: jtseng@NishanSystems.com, ips@ece.cmu.edu Subject: RE: Security Use Requirements Date: Mon, 12 Feb 2001 01:43:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk > This implies that a given WWUI is authorized for use on only one > 5-tuple, and iSCSI needs to enforce this restriction. If a packet > for the wrong WWUI arrives on a 5-tuple then iSCSI needs to discard > it. In effect, this results in a hard mapping of WWUI to 5-tuple. > IPSEC can then be relied upon to make sure that traffic on a 5-tuple > is integrity protected (and confidential if requested) and was sent > by the entity that negotiated the IKE MM and QM SAs under which it > was sent. > > Does this meet your needs? No, but it's close. The 5-tuple actually has to link to an pair of WWUIs because iSCSI has to support one initiator accessing multiple targets, and likewise for multiple initiators accessing the same target. There's the additional complication of multiple TCP connections between the same initiator and target, although there should be no harm in those using either the same SA or different SAs, depending on which is more convenient to deal with the fact that the initiator port numbers will be different. It would certainly be reasonable to require different initiators at the same IP address to use different SAs, and likewise for different targets at the same IP address. The reason offered for support of multiple iSCSI entities at the same IP address and TCP port has been easier passage through firewalls (only one port need be opened up, rather than one per target). FWIW, my inclination is similar to David Robinson's - one target per seems to simplify things, but there have been strong opinions expressed about the need for multiple targets at a single for firewall reasons. Also, Julian wrote: > Current iSCSI has a single mechanism that could be used for > key distribution - Kerberos. What I am trying to do is completely > remove any need to deal with this subject within iSCSI > and to defer to specialized standards. > > There many obvious reasons to do that. I think that's the right direction and consistent with the direction that we agreed to in Orlando. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Feb 12 06:55:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03850 for ; Mon, 12 Feb 2001 06:55:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1C9jK712879 for ips-outgoing; Mon, 12 Feb 2001 04:45:20 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1C9jFZ12864 for ; Mon, 12 Feb 2001 04:45:15 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.132.205]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id EAA225322 for ; Mon, 12 Feb 2001 04:37:52 -0500 Received: from f5n70e (d03nm094h.boulder.ibm.com [9.99.140.70]) by westrelay02.boulder.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id CAA63884 for ; Mon, 12 Feb 2001 02:44:42 -0700 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: Security Enviornments To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 12 Feb 2001 01:41:44 -0800 X-MIMETrack: Serialize by Router on D03NM094/03/M/IBM(Release 5.0.6 |December 14, 2000) at 02/12/2001 02:44:42 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk OK Team, it seems to me that we need to talk about what environments we are trying Secure. Because, I think we need to sort out which environments need what type of Security mechanism. The following are a list of environments that we need to support with iSCSI 1. A Local LAN Environment, in a small organization, which is not open to outsiders. Mostly Desktops and Laptop Systems, and want to pool storage (but not with FC). iSCSI initiators (and maybe targets) are provided via SW TCP/IP and iSCSI. 2. A Local LAN Environment that is isolated from outsiders via a firewall, has no storage access to, or from, anyone outside the Firewall. Mostly Desktops and Laptops, may be a local Server or two. They want to pool storage, (but not with FC). The non Server Systems will have SW TCP/IP and iSCSI HBA implementations, and the Others will have iSCSI and TCP/IP provided by SW. 3. A remote office that has a VPN (Virtual Private Network) and Firewall to a main IT organization. Accessing Servers (at the central IT location) with normal Client Server and Web Browser applications. They want to access iSCSI storage at the central IT location. iSCSI initiators are provided via SW TCP/IP and iSCSI, however, if any Servers need to access the remote iSCSI Storage, they will probably be using HW iSCSI HBAs. 4. A Central IT organization that has Desktops and Laptops on their Intranet, on their company campus. They want the Host on the Campus to have access to the iSCSI storage located at various places within the campus. They will have both iSCSI HBAs in Servers, and iSCSI SW in the Desktops and Laptops. 5. Several Remote IT locations that have VPNs in/out and Firewalls, and proxies, used for Client Server actions and Web Browsing (in and out). They want to have iSCSI access to Storage at each other locations. Each Site has Desktops, Laptops, and Servers that need to access local and remote Storage. IT organization have local FC, and iSCSI Storage. (Note: can also use FCIP here as well as iFCP, but lets keep the discussion to iSCSI for now.) The various Servers have iSCSI HW (with TOEs), and the Desktops/Laptops use SW for the iSCSI implementation. 6. A SSP (Storage Service Provider) wants to offer its storage for use by various different customers, across the Internet. The SSP will have an iSCSI HW HBAs that handle the protocols. I think it would be very useful, if we could talk about our "solutions" to the security need in terms of the above environments. There may be more, but lets first work on the above. The remote offices and the IT organizations have physical security between the IPSec Firewall and the Host, or Storage Device. We need to understand why we need IPSec/TLS, in each of the above environments, as a function in SW and/or in a HW adapter. That is, we need to understand when just Session Authentication & Authorization are sufficient, or when we should accept the privacy provided by IPSec in the VPN/Firewall, vrs the need to have on HBA or SW IPSec/TLS. Up until now this has not been clear to me. We need to understand if an IPSec function in the HBA or SW, would be a problem since the Firewall is likely to also be a NAT, in several of the above environments. Why would an organization want to bypass their Firewall and go straight to the Internet just because they had IPSec on the HBA. What is gained by that? If the installation had a Firewall with NAT and they wanted to stay behind that Firewall, wouldn't the IPSec on the HBA or SW be problematical? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon Feb 12 17:48:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23364 for ; Mon, 12 Feb 2001 17:48:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1CK4uq22155 for ips-outgoing; Mon, 12 Feb 2001 15:04:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1CK3KZ22077 for ; Mon, 12 Feb 2001 15:03:20 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f1CLDP085589; Mon, 12 Feb 2001 13:13:25 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: "John Hufferd" , Subject: RE: iSCSI: Security Enviornments Date: Mon, 12 Feb 2001 12:02:09 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John, Consider aspects of management. If the SCSI controller responds to client with lists of accessible devices, how is the SCSI controller informed? How is access managed in a uniform manner? If VPN is used, privacy is not needed within the SCSI transport. Is TLS secure for a SAN? Switches offer privacy if the LAN is physically secure resulting in little difference between FC and Ethernet. If the device is for a mobile notebook, as example, authentication offers adequate security. If the SCSI transport is implemented in software, is privacy practical? With many applications not requiring privacy, why mandate privacy? Even a software only implementation will require additional memory. Doug > OK Team, it seems to me that we need to talk about what > environments we are > trying Secure. Because, I think we need to sort out which environments > need what type of Security mechanism. > > The following are a list of environments that we need to support > with iSCSI > > 1. A Local LAN Environment, in a small organization, which is not open to > outsiders. Mostly Desktops and Laptop Systems, and want to pool storage > (but not with FC). iSCSI initiators (and maybe targets) are provided via > SW TCP/IP and iSCSI. > > 2. A Local LAN Environment that is isolated from outsiders via a > firewall, > has no storage access to, or from, anyone outside the Firewall. Mostly > Desktops and Laptops, may be a local Server or two. They want to pool > storage, (but not with FC). The non Server Systems will have SW TCP/IP and > iSCSI HBA implementations, and the Others will have iSCSI and TCP/IP > provided by SW. > > 3. A remote office that has a VPN (Virtual Private Network) and Firewall > to a main IT organization. Accessing Servers (at the central IT location) > with normal Client Server and Web Browser applications. They want to > access iSCSI storage at the central IT location. iSCSI initiators are > provided via SW TCP/IP and iSCSI, however, if any Servers need to access > the remote iSCSI Storage, they will probably be using HW iSCSI HBAs. > > 4. A Central IT organization that has Desktops and Laptops on their > Intranet, on their company campus. They want the Host on the Campus to > have access to the iSCSI storage located at various places within the > campus. They will have both iSCSI HBAs in Servers, and iSCSI SW in the > Desktops and Laptops. > > 5. Several Remote IT locations that have VPNs in/out and Firewalls, and > proxies, used for Client Server actions and Web Browsing (in and out). > They want to have iSCSI access to Storage at each other locations. Each > Site has Desktops, Laptops, and Servers that need to access local and > remote Storage. IT organization have local FC, and iSCSI Storage. (Note: > can also use FCIP here as well as iFCP, but lets keep the discussion to > iSCSI for now.) The various Servers have iSCSI HW (with TOEs), and the > Desktops/Laptops use SW for the iSCSI implementation. > > 6. A SSP (Storage Service Provider) wants to offer its storage > for use by > various different customers, across the Internet. The SSP will have an > iSCSI HW HBAs that handle the protocols. > > I think it would be very useful, if we could talk about our "solutions" to > the security need in terms of the above environments. There may be more, > but lets first work on the above. > > The remote offices and the IT organizations have physical security between > the IPSec Firewall and the Host, or Storage Device. > > We need to understand why we need IPSec/TLS, in each of the above > environments, as a function in SW and/or in a HW adapter. That is, we > need to understand when just Session Authentication & Authorization are > sufficient, or when we should accept the privacy provided by IPSec in > the VPN/Firewall, vrs the need to have on HBA or SW IPSec/TLS. > Up until > now this has not been clear to me. > > We need to understand if an IPSec function in the HBA or SW, > would be a > problem since the Firewall is likely to also be a NAT, in > several of the > above environments. > > Why would an organization want to bypass their Firewall and go straight > to the Internet just because they had IPSec on the HBA. What is gained > by that? > > If the installation had a Firewall with NAT and they wanted to stay > behind that Firewall, wouldn't the IPSec on the HBA or SW be > problematical? > > > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Internet address: hufferd@us.ibm.com > > From owner-ips@ece.cmu.edu Tue Feb 13 01:12:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA00756 for ; Tue, 13 Feb 2001 01:12:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1D3qJC16223 for ips-outgoing; Mon, 12 Feb 2001 22:52:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [168.159.208.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1D3pxZ16204 for ; Mon, 12 Feb 2001 22:51:59 -0500 (EST) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2650.21) id <1PVW5QW4>; Mon, 12 Feb 2001 22:51:53 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A0704101516@corpmx9.isus.emc.com> From: Black_David@emc.com To: dotis@sanlight.net, ips@ece.cmu.edu Subject: RE: iSCSI: Security Enviornments Date: Mon, 12 Feb 2001 22:51:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk > Consider aspects of management. If the SCSI controller responds to client > with lists of accessible devices, how is the SCSI controller informed? How > is access managed in a uniform manner? I'd recommend not discussing security of management right now beyond that necessary to ensure that iSCSI identities and authentication work as intended/ required. Significant pieces of this are also outside the scope of the working group, for example, how a target gets the information required to respond to a REPORT LUNS command is in T10's space, not the ips WG, and the same is true of SCSI-level access controls. Beyond that, a properly configured TLS should be adequately secure for a SAN. Doug's opinion that privacy should not be mandatory to implement is hereby officially noted (i.e., he can stop repeatedly reminding us of it), and I would point out that this was also the rough consensus at the WG meeting in Pittsburgh, which I believe remains the rough consensus of the WG. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Feb 13 01:16:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01175 for ; Tue, 13 Feb 2001 01:16:50 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1D4TKY17738 for ips-outgoing; Mon, 12 Feb 2001 23:29:20 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1D4SSZ17700 for ; Mon, 12 Feb 2001 23:28:28 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f1D5cP085958; Mon, 12 Feb 2001 21:38:26 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: , Subject: RE: iSCSI: Security Enviornments Date: Mon, 12 Feb 2001 20:27:10 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <0F31E5C394DAD311B60C00E029101A0704101516@corpmx9.isus.emc.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, > > Consider aspects of management. If the SCSI controller > > responds to client with lists of accessible devices, how > > is the SCSI controller informed? How is access managed > > in a uniform manner? > > I'd recommend not discussing security of management right now beyond that > necessary to ensure that iSCSI identities and authentication work as > intended/required. Significant pieces of this are also outside the scope > of the working group, for example, how a target gets the information > required to respond to a REPORT LUNS command is in T10's space, not the > ips WG, and the same is true of SCSI-level access controls. I understand that Report LUNS is a SCSI command and outside the scope of the WG. Security has two aspects regardless of the mechanisms used to inform the drivers, authentication and authorization. These to aspects go hand in hand. As it is structured currently, there is only some nebulous concept that authentication is tied in some indirect fashion to an associated authorization. As there is going to be extensive efforts in obtaining the authentication, it also make sense that there be some means to assess and express the associated authorization. How do you expect that aspect to be managed? Would you not expect the server that provides authentication to also contain the authorization or at least some means of expressing this aspect of security? One could hardly make any meaningful tool to manage security without ability to control both authentication and authorization. Would it not be to the benefit of the WG to consider this topic more fully than to just say that authorization is outside the scope whereas authentication is not. These are not independent topics. Leaving out a standard means of controlling both aspects found in any security scheme ensures only vendor unique tools for management will be possible. Doug From owner-ips@ece.cmu.edu Wed Feb 14 00:02:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08513 for ; Wed, 14 Feb 2001 00:02:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1E2Fu526403 for ips-outgoing; Tue, 13 Feb 2001 21:15:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sphmraaa.compuserve.com (hs-img-rel-1.compuserve.com [149.174.177.156]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1E2FaZ26388 for ; Tue, 13 Feb 2001 21:15:36 -0500 (EST) Received: (from mailgate@localhost) by sphmraaa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id VAA01417 for ips@ece.cmu.edu; Tue, 13 Feb 2001 21:15:31 -0500 (EST) Received: from compuserve.com (dal-tgn-tvo-vty43.as.wcom.net [206.175.229.43]) by sphmraaa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id VAA01353 for ; Tue, 13 Feb 2001 21:15:19 -0500 (EST) Message-ID: <3A89EB0B.E8068A89@compuserve.com> Date: Tue, 13 Feb 2001 20:18:51 -0600 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: iSCSI Mode Page for CRN References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I just unearthed the gem below in my ips mail. Julian is probably way ahead of me on this, but just in case ... Mode page 18h is the "Protocol specific LUN page", which means that the last bullet in David's Orlando meeting notes applies. Sorry for the gigantic delay constant. Ralph... David Peterson wrote: > > The SCSI command reference number is negotiated via the logical unit control > page (18h). > Dave > > > - SCSI has defined a new (optional) SCSI Command Ref Number > > - iSCSI will use byte #2 in iSCSI header (currently Reserved) to > > transport this > > - This is not the ideal solution, but matches the level of support > > in FCP. > > - We have to check where mode page is to negotiate this > > - If it's on a transport-specific mode page, iSCSI will > > use a text key to negotiate this instead > > From owner-ips@ece.cmu.edu Wed Feb 14 03:10:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24740 for ; Wed, 14 Feb 2001 03:10:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1E5s2N02871 for ips-outgoing; Wed, 14 Feb 2001 00:54:02 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1E5rRZ02858 for ; Wed, 14 Feb 2001 00:53:40 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id GAA100732; Wed, 14 Feb 2001 06:53:20 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id GAA95116; Wed, 14 Feb 2001 06:53:02 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569F3.00204D5D ; Wed, 14 Feb 2001 06:52:49 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: "Lee, WanHuiHendra" cc: ips@ece.cmu.edu Message-ID: Date: Wed, 14 Feb 2001 07:48:37 +0200 Subject: Re: iSCSI: P-bit & F-bit location Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Lee, There is no Final bit with Data In - The Poll was meant to request acknowledgement but it is going to disappear from Data-IN. 04 is going to appear in less than a week (hopefully). Regards, Julo "Lee, WanHuiHendra" on 13/02/2001 22:04:12 Please respond to "Lee, WanHuiHendra" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: iSCSI: P-bit & F-bit location Hi Julian, I have a couple of questions: 1. In draft-ietf-ips-iscsi-03.txt page 36. SCSI Data packet for READ (from target to initiator). In the DATA PDU header layout, bit7 of byte 1 is P (Poll) bit Where is F(Final) bit location defined in section 2.7.1 ? Is there any correction/updates made in this section ? 2. When is the expected time for 04.txt to be made available ? Thanks & Regards, Wan-Hui From owner-ips@ece.cmu.edu Thu Feb 15 11:25:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22310 for ; Thu, 15 Feb 2001 11:25:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1FDlUx06310 for ips-outgoing; Thu, 15 Feb 2001 08:47:30 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from spdmraaa.compuserve.com (ds-img-rel-1.compuserve.com [149.174.206.140]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1FDksZ06280 for ; Thu, 15 Feb 2001 08:46:54 -0500 (EST) Received: (from mailgate@localhost) by spdmraaa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id IAA18762 for ips@ece.cmu.edu; Thu, 15 Feb 2001 08:46:48 -0500 (EST) Received: from compuserve.com (dal-tgn-tko-vty37.as.wcom.net [216.192.227.37]) by spdmraaa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id IAA18716 for ; Thu, 15 Feb 2001 08:46:37 -0500 (EST) Message-ID: <3A8BDE4A.5D7F4BCA@compuserve.com> Date: Thu, 15 Feb 2001 07:48:58 -0600 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: FCIP: draft-weber-fcip-encaps-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit An internet draft titled " FCIP Frame Encapsulation Enhancement Proposals" is available at: http://www.ietf.org/internet-drafts/draft-weber-fcip-encaps-00.txt The abstract is as follows: This draft is for consideration by the FCIP team in the IPS working group. Improvements to Fibre Channel Over TCP/IP (FCIP) [2] frame encapsulation mechanisms are proposed. The objectives of the improvements are two fold: increasing the reliability of Fibre Channel frame detection, and assisting with the handling of Fibre Channel E_D_TOV and R_A_TOV time-out processing. Since the ID was submitted a technical error was discovered in section 3.2, Time Stamp, it says that the integer word in the time stamp is "the time in seconds relative to the epoch, 00:00:00 January 1,1990." This is a transcription from the T11 proposal on which the usage of this time format is based (01-052v0). However, 01-052v0 is based on SNTP (RFC 2030) and RFC 2030 says that the base epoch is "00:00:00 January 1,1900", that is 1900 not 1990. I have been informed that 01-052v0 did not intend to revise RFC 2030 and that the encapsulation proposal should use 1900 not 1990. FYI Ralph Weber representing Brocade Communications From owner-ips@ece.cmu.edu Thu Feb 15 20:58:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04068 for ; Thu, 15 Feb 2001 20:58:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1FNWCZ10493 for ips-outgoing; Thu, 15 Feb 2001 18:32:12 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1FNVD910431 for ; Thu, 15 Feb 2001 18:31:13 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f1G0f2007950; Thu, 15 Feb 2001 16:41:03 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: , "IPS Reflector" Subject: RE: FCIP: draft-weber-fcip-encaps-00.txt Date: Thu, 15 Feb 2001 15:29:47 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3A8BDE4A.5D7F4BCA@compuserve.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, As an alternative to byte stuffing, creating a pseudo-frame within TCP would be an alternative. Here is an example of using SCTP within TCP using a fixed interval alignment of a pseudo-frame allowing frame recovery where padding is inserted should the pseudo-frame be smaller than the predefined interval. This interval could be negotiated at 4096 or 8192 as example. If used within SCTP, the real Ethernet frame becomes the interval. The SCTP Data Chunk would contain the FCIP Header and FC frame. Digest error handling and acknowledgement would be done at the pseudo-frame using the SCTP SACK chunk. Encapsulating FCIP within SCTP within TCP has advantages with the addition of all the interesting features of SCTP such as multi-homing, session recovery, anti-spoofing, defined negotiations, and years of effort creating a well defined transport. By using Adler-32 over the entire frame, much of the repeated values can be removed from your specifications as well. Constructing the pseudo-frame should represent little additional overhead than that required to process byte stuffing. You could require all FC frames to be contained within a single pseudo-frame, but if SCTP is actually used, constructing the FC frame should be an additional step. Once SCTP is used directly, the additional secondary overhead to process digest errors is removed and FC related data becomes aligned with the Ethernet frame. Something you should consider in any transport, is the handshake to allow error recovery. SCTP covers those questions as well as adds many interesting advantages. FCIP is but one of the many possible encapsulation possible with SCTP. SCTP can be placed on TCP (less flow control), UDP, and of course as SCTP itself. The general purpose structure of SCTP allows interesting opportunities for encapsulation including the encapsulation of the entire network connection between machines as example. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ 0| Rev | Reserved | Pseudo-Frame Word Length | +---------------+---------------+---------------+---------------+ 4| Validation Tag | +---------------+---------------+---------------+---------------+ 8| Checksum (Adler32) | +---------------+---------------+---------------+---------------+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12| Type = 0 | Reserved|U|B|E| Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16| TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20| Stream Identifier S | Stream Sequence Number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 24| Payload Protocol Identifier (IANA FCIP Op) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 28| VER. |HDR Len| Reserved | +-------+-------+---------------------------+-------------------+ 32| Time Integer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 36| Time Fraction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 40\ \ / FC encapsulation (seq n of Stream S) / \ \ Doug > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Ralph Weber > Sent: Thursday, February 15, 2001 5:49 AM > To: IPS Reflector > Subject: FCIP: draft-weber-fcip-encaps-00.txt > > > An internet draft titled " FCIP Frame Encapsulation Enhancement > Proposals" is available at: > > http://www.ietf.org/internet-drafts/draft-weber-fcip-encaps-00.txt > > The abstract is as follows: > > This draft is for consideration by the FCIP team in the IPS working > group. Improvements to Fibre Channel Over TCP/IP (FCIP) [2] frame > encapsulation mechanisms are proposed. The objectives of the > improvements are two fold: increasing the reliability of Fibre > Channel frame detection, and assisting with the handling of Fibre > Channel E_D_TOV and R_A_TOV time-out processing. > > Since the ID was submitted a technical error was discovered in > section 3.2, Time Stamp, it says that the integer word in the > time stamp is "the time in seconds relative to the epoch, > 00:00:00 January 1,1990." This is a transcription from the > T11 proposal on which the usage of this time format is based > (01-052v0). > > However, 01-052v0 is based on SNTP (RFC 2030) and RFC 2030 says > that the base epoch is "00:00:00 January 1,1900", that is 1900 > not 1990. > > I have been informed that 01-052v0 did not intend to revise > RFC 2030 and that the encapsulation proposal should use 1900 > not 1990. > > FYI > > Ralph Weber > representing > Brocade Communications > > > From owner-ips@ece.cmu.edu Fri Feb 16 04:54:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25582 for ; Fri, 16 Feb 2001 04:54:54 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1G7wII08404 for ips-outgoing; Fri, 16 Feb 2001 02:58:18 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [168.159.208.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1G7vY908366 for ; Fri, 16 Feb 2001 02:57:34 -0500 (EST) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2650.21) id <1PVW0NRA>; Fri, 16 Feb 2001 02:57:28 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A0704101527@corpmx9.isus.emc.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iFCP work in the IPS WG Date: Fri, 16 Feb 2001 02:57:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk After quite a bit of consultation and consideration of comments both from the mailing list and those sent directly to Steve Bellovin and myself, the two of us along with the Transport Area Directors have reached the following decision on the subject of working on iFCP within the IP Storage Working Group ... There is both sufficient technical merit in iFCP and interest within the ips WG in working on iFCP to justify adding iFCP to the official work items of the WG. Hence iFCP will be added to the list of protocols that the WG is working on -- the following directions and conditions apply: - iFCP is subject to the directions, scope, constraints, etc. in the IPS WG's charter, as is the case for all work in the WG. This includes requirements for good transport and security designs. - FCIP and iFCP are to use a common encapsulation format, so that there is one way to encode a Fibre Channel (FC-2) frame for transmission over an IP network. The header must be extensible as needed by protocols that use it (e.g., iFCP requires protocol-specific extensions in some cases) and the header must incorporate a protocol number to distinguish FCIP, iFCP, and any future protocols that use it so that a recipient of an encapsulated FC frame can unambiguously determine which protocol is being used. - The existing WG rough consensus that iFCP and FCIP should not be merged is to be respected. The result should be three related specifications - the common encapsulation format, and specifications for how each of iFCP and FCIP employ it. - T11.3's role as the authority on Fibre Channel and Fibre Channel architecture is to be recognized and respected. Fibre Channel work in the ips WG, including iFCP, will endeavor to respect and follow T11.3's guidance in a fashion similar to iSCSI work following T10's analogous guidance on SCSI. A specific area in which T11.3 should be consulted is iFCP's modifications to the S_ID and D_ID fields in Fibre Channel frames. The next steps from here are: - Addition of iFCP milestone(s) to the charter. While we're at it, we'll add iSNS milestone(s). Guesstimates from the various document authors would be appreciated. - Appointment of an iFCP technical coordinator. Send suggestions/nominations to me directly. - Submission of new FC encapsulation, iFCP and FCIP drafts in accordance with the above. From a procedural standpoint, this decision is not open to debate on the mailing list, although clarification questions are welcome, as I continue to discover that I don't always write the clearest text despite my best efforts. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Feb 16 04:55:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25609 for ; Fri, 16 Feb 2001 04:55:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1G7OJb06692 for ips-outgoing; Fri, 16 Feb 2001 02:24:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [168.159.208.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1G7Nt906662 for ; Fri, 16 Feb 2001 02:23:56 -0500 (EST) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2650.21) id <1PVW0NJL>; Fri, 16 Feb 2001 02:23:49 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A0704101525@corpmx9.isus.emc.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: RE: iSCSI: Security Enviornments Date: Fri, 16 Feb 2001 02:23:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk At the risk of further encouraging Doug ... > > I'd recommend not discussing security of management right now beyond that > > necessary to ensure that iSCSI identities and authentication work as > > intended/required. Significant pieces of this are also outside the scope > > of the working group, for example, how a target gets the information > > required to respond to a REPORT LUNS command is in T10's space, not the > > ips WG, and the same is true of SCSI-level access controls. > > I understand that Report LUNS is a SCSI command and outside the scope of the > WG. Security has two aspects regardless of the mechanisms used to inform > the drivers, authentication and authorization. These to aspects go hand in > hand. As it is structured currently, there is only some nebulous concept > that authentication is tied in some indirect fashion to an associated > authorization. That's not the only piece of the current security text that is "nebulous". In any case, the relationship should be that iSCSI sets up or runs over a suitably secure initiator-target connection in a fashion that whatever access control mechanisms T10 specifies for SCSI initiator-target sessions work in a fashion that can be sufficiently relied upon. > As there is going to be extensive efforts in obtaining the > authentication, it also make sense that there be some means to assess and > express the associated authorization. How do you expect that aspect to be > managed? Would you not expect the server that provides authentication to > also contain the authorization or at least some means of expressing this > aspect of security? I can think of a number of examples in which the authentication server plays essentially no direct role in authorization. For example, access control lists are usually not stored on authentication servers for some fairly obvious scalability reasons. The general structure here is that things are implemented/structured in a fashion that the authenticated identity can be relied on for authorization even though the authentication and authorization mechanisms are separate. The passing of SCSI LUN access control information over an authenticated secure iSCSI channel described above would be another example as long as the SCSI and iSCSI identities were linked in some fashion. > One could hardly make any meaningful tool to manage > security without ability to control both authentication and authorization. And a "meaningful tool" should certainly be capable of accessing multiple interfaces to get its job done. > Would it not be to the benefit of the WG to consider this topic more fully > than to just say that authorization is outside the scope whereas > authentication is not. These are not independent topics. Leaving out a > standard means of controlling both aspects found in any security scheme > ensures only vendor unique tools for management will be possible. Doug's managed to totally twist what I wrote, and make at least two major mistakes in the process: - Authorization is not completely out of scope. Providing mechanisms to determine which iSCSI initiators may access which iSCSI targets is definitely in scope, and I believe iSNS does or will do this in its "zoning" support. - The fact that something is out of scope for this WG does not prevent it from being standardized. I would suggest that T10 is the appropriate forum in which to pursue a standard interface for configuring SCSI LUN access controls being defined by T10. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Feb 16 19:32:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12262 for ; Fri, 16 Feb 2001 19:32:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1GLIVh06522 for ips-outgoing; Fri, 16 Feb 2001 16:18:31 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1GLIB906495 for ; Fri, 16 Feb 2001 16:18:11 -0500 (EST) Received: from tot-ntc-tc.proxy.aol.com (tot-ntc-tc.proxy.aol.com [198.81.17.1]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id QAA23107 for ; Fri, 16 Feb 2001 16:17:47 -0500 (EST) Received: from vaio (ACB4BE3B.ipt.aol.com [172.180.190.59]) by tot-ntc-tc.proxy.aol.com (8.10.0/8.10.0) with SMTP id f1GLHkg29189 for ; Fri, 16 Feb 2001 13:17:46 -0800 (PST) From: "Sriram Rupanagunta" To: "IPS Reflector" Subject: RE: FCIP: draft-weber-fcip-encaps-00.txt Date: Fri, 16 Feb 2001 15:17:14 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3A8BDE4A.5D7F4BCA@compuserve.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Apparently-From: Yeseswini@aol.com Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Few comments on the new proposal for FCIP changes: - Section 3.2: It is not entirely clear how the FCIP devices would synchronize clocks across the IP network. There is mention of using NTP or SNTP - would that mean they operate independent of Fibre channel time services, operating as a IP service ? I would imagine this to be the case, but not sure if this is mentioned clearly enough. - Section 3.2: The mention of time stamps for time out error recovery needs to be more specific, IMO. It says that "if too much time elapses, the FC frame should be dropped", which is not precise. I believe it should specify how it relates to the two FC timeouts. - Section 5.1: The reason for additional checksum is not clear enough. If this is solely for the purpose of re-synchronization, would it justify the additional overhead for every FCIP frame ? - Both the original ID and this proposal leave out the part about aborted TCP connections, but talk about re-synchronization during data transfer phase, in the face of packet loss, congestion etc. I would imagine the re-sync to be more critical "after" a connection is reset, since there is data in transit and in the receiver queue. Do the authors believe that the new proposal would be sufficient to address the TCP connection resets ? Regards, Sriram From owner-ips@ece.cmu.edu Sat Feb 17 02:41:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01733 for ; Sat, 17 Feb 2001 02:41:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1H5LaV04048 for ips-outgoing; Sat, 17 Feb 2001 00:21:36 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [168.159.208.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1H5Kh904011 for ; Sat, 17 Feb 2001 00:20:43 -0500 (EST) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2650.21) id ; Sat, 17 Feb 2001 00:20:36 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A070410152C@corpmx9.isus.emc.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: IPS WG @ 50th IETF Date: Sat, 17 Feb 2001 00:20:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk The IPS WG is currently scheduled to meet as follows: MONDAY, March 19, 2001 0900-1130 Morning Sessions WEDNESDAY, March 21, 2001 0900-1130 Morning Sessions Please note the usual caveat that this is SUBJECT TO CHANGE until the agenda becomes final. With luck we'll get the whole 5 hours this time. Also, please note the deadlines for submission of Internet-Drafts: February 23 - Internet Draft Cut-off for initial document (-00) submission at 17:00 ET March 2 - Internet Draft final submission cutoff date at 1700 ET 1700 ET, means 5pm EASTERN TIME - those in other time zones should plan accordingly. Also, there's often an enormous load of drafts submitted close to the deadline that can take many days to clear - submission of drafts by Wednesday of the week of the Friday deadline will usually yield a prompter response. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Sat Feb 17 09:23:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04368 for ; Sat, 17 Feb 2001 09:23:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1HCPfS03628 for ips-outgoing; Sat, 17 Feb 2001 07:25:41 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from spdmraab.compuserve.com (ds-img-rel-2.compuserve.com [149.174.206.155]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1HCP5903572 for ; Sat, 17 Feb 2001 07:25:05 -0500 (EST) Received: (from mailgate@localhost) by spdmraab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id HAA14247 for ips@ece.cmu.edu; Sat, 17 Feb 2001 07:24:59 -0500 (EST) Received: from compuserve.com (dal-tgn-tvo-vty18.as.wcom.net [206.175.229.18]) by spdmraab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id HAA14237 for ; Sat, 17 Feb 2001 07:24:51 -0500 (EST) Message-ID: <3A8E6E68.E0C0E94D@compuserve.com> Date: Sat, 17 Feb 2001 06:28:25 -0600 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: Re: FCIP: draft-weber-fcip-encaps-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Douglas, Even though there are worked examples of your proposal, it involves more knowledge of TCP/IP than I am willing to undertake. Thanks. Ralph... From owner-ips@ece.cmu.edu Sat Feb 17 20:48:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09231 for ; Sat, 17 Feb 2001 20:48:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1HNNXG07790 for ips-outgoing; Sat, 17 Feb 2001 18:23:33 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from latte.2xtreme.net (latte.2xtreme.net [209.63.222.34]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f1HNNK107774 for ; Sat, 17 Feb 2001 18:23:20 -0500 (EST) Received: (qmail 4162 invoked from network); 17 Feb 2001 23:23:16 -0000 Received: from p111.oak2.2xtreme.net (HELO ljoy) (209.63.215.111) by latte.2xtreme.net with SMTP; 17 Feb 2001 23:23:16 -0000 From: "Douglas Otis" To: , Subject: RE: iSCSI: Security Enviornments Date: Sat, 17 Feb 2001 15:22:09 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <0F31E5C394DAD311B60C00E029101A0704101525@corpmx9.isus.emc.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Thank you for the information. You have made it clear you view iSNS is to be the source of authorization. I fail to understand what limitation exists using LDAP directly versus this rehash of DNS and LDAP, but you should understand the importance of asking such dumb questions. Although the SCSI target can be programmed to respond with authorization and this is clearly within the scope of the T10 group, security management must be able to endure device failure. This implies security is placed safely somewhere which contains both authentication and authorization information. Forgive my ignorance, but being a network storage protocol, I assumed maintenance of this security scheme would also be network based and outside the scope of T10. Telling the device about these settings would be within their domain. Security can be seen as good as the weakest link in the chain. In this case, iSNS is the weak link. Again, thank you for enduring these dumb questions and as you may have guessed, I am neither encouraged or discouraged, simply confused. Doug > At the risk of further encouraging Doug ... > > > > I'd recommend not discussing security of management right now beyond > that > > > necessary to ensure that iSCSI identities and authentication work as > > > intended/required. Significant pieces of this are also outside the > scope > > > of the working group, for example, how a target gets the information > > > required to respond to a REPORT LUNS command is in T10's > space, not the > > > ips WG, and the same is true of SCSI-level access controls. > > > > I understand that Report LUNS is a SCSI command and outside the scope of > the > > WG. Security has two aspects regardless of the mechanisms used > to inform > > the drivers, authentication and authorization. These to aspects go hand > in > > hand. As it is structured currently, there is only some > nebulous concept > > that authentication is tied in some indirect fashion to an associated > > authorization. > > That's not the only piece of the current security text that > is "nebulous". In any case, the relationship should be that > iSCSI sets up or runs over a suitably secure initiator-target > connection in a fashion that whatever access control mechanisms > T10 specifies for SCSI initiator-target sessions work in a > fashion that can be sufficiently relied upon. > > > As there is going to be extensive efforts in obtaining the > > authentication, it also make sense that there be some means to > assess and > > express the associated authorization. How do you expect that > aspect to be > > managed? Would you not expect the server that provides > authentication to > > also contain the authorization or at least some means of expressing this > > aspect of security? > > I can think of a number of examples in which the > authentication server plays essentially no direct role > in authorization. For example, access control lists > are usually not stored on authentication servers for > some fairly obvious scalability reasons. The general > structure here is that things are implemented/structured > in a fashion that the authenticated identity can be > relied on for authorization even though the authentication > and authorization mechanisms are separate. The passing > of SCSI LUN access control information over an authenticated > secure iSCSI channel described above would be another > example as long as the SCSI and iSCSI identities were > linked in some fashion. > > > One could hardly make any meaningful tool to manage > > security without ability to control both authentication and > authorization. > > And a "meaningful tool" should certainly be capable of > accessing multiple interfaces to get its job done. > > > Would it not be to the benefit of the WG to consider this topic > more fully > > than to just say that authorization is outside the scope whereas > > authentication is not. These are not independent topics. Leaving out a > > standard means of controlling both aspects found in any security scheme > > ensures only vendor unique tools for management will be possible. > > Doug's managed to totally twist what I wrote, and make > at least two major mistakes in the process: > - Authorization is not completely out of scope. Providing > mechanisms to determine which iSCSI initiators may access > which iSCSI targets is definitely in scope, and I believe > iSNS does or will do this in its "zoning" support. > - The fact that something is out of scope for this WG > does not prevent it from being standardized. I would > suggest that T10 is the appropriate forum in which to > pursue a standard interface for configuring SCSI > LUN access controls being defined by T10. > > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Sun Feb 18 14:51:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11374 for ; Sun, 18 Feb 2001 14:51:25 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1IHHqo08524 for ips-outgoing; Sun, 18 Feb 2001 12:17:52 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from spdmraac.compuserve.com (ds-img-rel-3.compuserve.com [149.174.206.154]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1IHH9108487 for ; Sun, 18 Feb 2001 12:17:09 -0500 (EST) Received: (from mailgate@localhost) by spdmraac.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id GAA29042 for ips@ece.cmu.edu; Sun, 18 Feb 2001 06:39:35 -0500 (EST) Received: from compuserve.com (dal-tgn-tlv-vty5.as.wcom.net [216.192.236.5]) by spdmraac.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id GAA28970; Sun, 18 Feb 2001 06:39:15 -0500 (EST) Message-ID: <3A8FB53B.DD1594BD@compuserve.com> Date: Sun, 18 Feb 2001 05:42:52 -0600 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: iSCSI: About CA, ACA, and AutoSense Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I keep getting requests to sort out CA (Contingent Allegiance), ACA (Auto Contingent Allegiance) and AutoSense. Since what I do mostly is write articles for the ENDL Letter, I've taken these repeated requests as a suggestion that an article dedicated to the subject be cobbled together. The ENDL Letter publisher, I. Dal Allan, and I have produced the article reproduced below in the belief that it will prove useful to everyone who is wresting with porting SCSI to IP. As you peruse the article you will find some pretty deep history on the topic of CA, ACA, and AutoSense. The ENDL Letter has been published since 1984. If you are interested in subscribing to the ENDL Letter please contact me directly. Thanks. Ralph Weber Editor ENDL Letter - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Distributed with Permission of the Publisher ENDL Inc. grants the right to distribute the article entitled "WHERE IS YOUR ALLEGIANCE" to the IETF (Internet Engineering Task Force). Reproduction of the contents in any published form shall attribute ENDL as the source. ENDL Inc. specializes in marketing and engineering consultation on interface issues, systems architecture and storage technology. The ENDL Letter provides subscribing clients with detailed coverage of industry activities in a style that is suited to both marketing and engineering personnel. The ENDL Letter is published monthly by ENDL Inc. The article which follows was prepared by ENDL Letter editor Ralph Weber of ENDL Texas and edited by I. Dal Allan of ENDL. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (C) Copyright 2001 ENDL WHERE IS YOUR ALLEGIANCE Several times in recent months there have been discussions about Contingent Allegiance, Auto Contingent Allegiance, and AutoSense. While most of these exchanges have originated from IPS (IP Storage) folks trying to learn the SCSI ropes, the level of confusion indicates that a review might be helpful to our readers. History In the beginning there was CA (Contingent Allegiance) and though everybody did not like it, there was no doubt that CA was a fact of SCSI-2 life. The event that forced CA into existence was the decision to separate telling the initiator an error had occurred from telling the initiator what kind of error it was that occurred. o First, tell the initiator that an error occurred (Check Condition status) o Second, if the initiator asks, tell the initiator what the error was (the Request Sense command and returned Request Sense data) Since the earliest days of SCSI there were those who believed it would be best to send both Check Condition status and the Request Sense data in the same Status phase. There was opposition though, primarily from those who believed that by including the controller in the device there would be no errors and providing sense data would be so exceptional it should be done as a separate action. And as for those who believed so sincerely. Why list names, when we can be politically incorrect and stamp a stereotype? Disk drive vendors dominated the SCSI committee then, as they do now, and as a group there is little or no appreciation of the complexities involved in error recovery of different device types. History repeated itself when Fibre Channel development fell into the same trap, and designed around disks in the PLDA (Private Loop Direct Attach) Technical Report. PLDA is why FCP-2 (Fibre Channel Protocol) was needed, to add a whole new way of doing error recovery in order to handle tape drives. There was one memorable convert from the side of separate actions. It was nowhere near as dramatic a conversion as on the road to Damascus, but when Paul Nitza (then with Emulex) declared war on Request Sense during SCSI-2, he shocked the members. Paul had always been a target kind of guy, but when he was assigned to write initiator drivers he discovered just how the lack of AutoSense made life miserable for the host. Charged with zeal, Paul came armed with enough fire- power to convince the committee to incorporate his ideas into at least one of the draft revisions. SCSI WORKING GROUP MARCH 18-20 1987 Bundled into Paul Nitza's command queuing proposal was AutoSense; a method which allows the target to automatically return Sense Data upon a Check Condition. If an error occurs during execution the target follows the procedure of: Status Phase Check Condition Data In Phase Sense Data Message In Phase Command Complete Message Harlan Andrews (Apple) had serious reservations about this sequence because a Data In phase could mislead initiators (host bus adapters) into transferring the Sense Data into the host system memory behind the completed data transfer. Paul's justification for including AutoSense as part of command queuing is that he does not want the target forced to retain all the status associated with queued commands. At present, SCSI requires that sense be retained until the next command but in a command queued environment, sense would have to be retained until a tag was re-used. Bob Snively (then Adaptec now Brocade) felt retaining one byte of sense per tag was a minor burden as it does not require much buffer storage. Unfortunately for SCSI users, Paul decided to leave Southern California and left Emulex to head East to Ohio and set up his shingle as a consultant. No client came along to support/subsidize his continued participation in the committee, and without Paul as champion, the initiative faltered and died. SCSI WORKING GROUP JANUARY 6-8 1988 Jim McGrath (Quantum) nominated himself as leader of the AEN (Asynchronous Event Notification) expunge task force by declaring similar distaste for AutoSense, and adding that to his campaign. His rationale is that the AutoSense justification is based on performance, yet the number of errors in a disk system are so low it cannot possibly make any difference. "AutoSense adds one more mechanism to an already over-burdened, complex structure to handle an event that might happen only once a week." X3T9.2 SCSI MEETING FEBRUARY 22-23, 1988 AutoSense died, and is to be removed from SCSI-2. There were no protests from anyone in the tape area. Request Sense remained as a burr in the side of progress, because command queuing brought with it the attendant problem of how to make sure Request Sense data hung around long enough to be collected by Request Sense. Assume two commands in the queue get errors, what then? You have to get inventive, so CA was spawned to make the target stop doing things which might produce more errors whenever it has to send a Check Condition to the initiator. CA begins when the Check Condition is sent, and stays in force until the next command arrives from the initiator to which the Check Condition was sent. Basically, the initiator gets exactly one chance to send the Request Sense command and learn what error caused delivery of the Check Condition. A number of factors kept AutoSense alive in the waning year of SCSI-2, and CA was one of the primary reasons. SCSI WORKING GROUP JANUARY 9-11 1989 Steve Goldman (then DPT) had left the X3T9.2 plenary in December vowing to return in another attempt to obtain Terminate Immediate. Return he did, with a thick document and Paul Nitza's (then OTL) support: obtained by coupling Terminate Immediate with AutoSense. A historical note here, AutoSense had been proposed by Paul early in SCSI-2, and it had been removed after he left Emulex, stopped being an editor, and missed several meetings..... When Paul wanted to know why AutoSense had been removed from earlier SCSI-2 revisions he sparked a debate on the merits of AutoSense saving any time. Actually, little is saved as far as the target is concerned. The target may save a little on responding to selection plus parsing of a Request Sense command; but this is not the right place to focus on time savings. Paul struck on part of the problem: a long initiator delay if beaten out on bus arbitration by a higher priority device. This is likely to happen only on heavily-used systems and did not seem to concern too many members. Gary Stephens (IBM) mentioned the time it takes an initiator to re-dispatch another command to Request Sense, but it seemed to be regarded as being of even less importance than Paul's comment. NOTE: Dispatch time can be a big number in many operating system environments, and can easily fall into the 2-8 msec range. Debate ended with AutoSense being made a SCSI-3 item. Resistance appears to be based more on emotion and target microcode than on system considerations. Six months later there still had been no final, irrevocable decision on what to do with AutoSense. SCSI WORKING GROUP JULY 10-11 1989 As John Lohmeyer (NCR) worked his way down the list of "oldies," he asked: "If everybody keeps asking for AutoSense, how come we keep voting it out?" Despite several attempts over the last two years, AutoSense has never made it, and the conclusion was that nobody had thoroughly thought through the problems of integrating AutoSense in a backwards-compatible manner. Gary Stephens (then IBM now FSI) suggested extending Status phase to include Sense Data... The reticence to incorporate AutoSense left all the eggs in the CA basket. While a CA is in force the target is prohibited from doing more work on the commands in its queue. This restriction is not to be nice to the initiator, it is to make sure the target does not do something that might generate a second Check Condition and corrupt the original Request Sense data. While the CA is in force, the target is prohibited from accepting commands from an initiator other than the one to which the Check Condition status was sent. All such commands get returned with a Busy status, and again the goal is to prevent the target from getting into a spot where the original Sense data becomes corrupted. When the initiator to whom the Check Condition status was sent finally sends a command, the CA is cleared and all proceeds according to the rules defined by the Control mode page settings. Typically, everything proceeds as if the CA had never happened. Request Sense provides the details about the cause of the Check Condition and the initiator deals with the error. What if the command sent by the initiator is not a Request Sense? Say bye bye, because the Request Sense data is sent to the bit bucket and everything continues on as if the CA had never happened. The initiator has one and only one shot to retrieve the Request Sense data (use it or lose it). These rules are simple, ironclad, and easy to follow but things took their first twist for the complicated when Gary Stephens (then IBM, now FSI) had an idea. "Why can't we have a CA that lasts until the initiator says to return to normal?" "That way if complex error recovery is required in response to the Request Sense data, the target will stay in a CA-like state until the recovery is all completed." Thus was born ECA (Extended Contingent Allegiance). The major beneficiary was intended to be tapes, so processing at end of reel could be accomplished under an ECA state with the yet-to-be-completed writes held in the queue until the new reel was mounted and ready to receive more data. ECA was always optional with the initiator using a Control Mode Page bit to tell the target that ECA was to be used instead of CA for handling Check Conditions. When ECA was in effect, the target told the initiator that ECA was being entered by sending an Initiate Recovery message and the initiator told the target to exit the ECA state by sending a Release Recovery message. Between the time those two messages were sent the CA-like state was extended to become ECA, with the initiator being able to send as many new untagged commands as it liked while the ECA was in effect. And how important was ECA in the greater scheme of things? Let's be generous here and say that one or two companies implemented ECA because they thought it was a great idea, another one or two implemented it because a customer or supplier told them to, but otherwise ECA was generally unloved. The combination of CA and ECA was livable for the SCSI-2 parallel bus but times changed dramatically when Fibre Channel and its other serial protocol brethren came along. Serial SCSI stirred the murky waters into a veritable froth of confusion. All was not well in parallel land either. George Penokie (then IBM and now Tivoli) entered stage left to tilt at one of the longest spinning windmills in SCSI history. George clarified the queuing model, and gave it a new coat of polish to carry it forward into the IU (Information Unit) world of Fibre Channel. Nailing this task down took a whopping 18 revisions of the proposal and nearly two years of monthly multi-hour excursions to the front of some meeting room somewhere to be pummeled by proponents of this or that. ECA proponent Gary Stephens was convinced his day had come. "With IUs in transit in both directions, you're going to have to use ECA to block new commands until the initiator can find out that it's got to send a Request Sense command to get the data." "CA will not be good enough because a command in flight will look to the target like it should be the Request Sense command needed to collect the sense data, but it's really just the wrong command at the wrong time." The packetized protocol of Fibre Channel had no low level messaging between target and initiator which could carry the Initiate Recovery message. A new invention was required, and thus was born ACA (Auto Contingent Allegiance). ACA was one part CA, one part ECA, and one part entirely different. o Like CA, ACA happened automatically upon delivery of a Check Condition status. o Like ECA, ACA stayed in force until the initiator said uncle by sending a Clear ACA task management function (which translated to a new message on the parallel bus or a magic bit in a Fibre Channel IU). o Unlike either of its progenitors ACA created a totally task attribute (or queue tag) to mark commands that would be allowed to execute during an ACA state, cleverly called the ACA attribute. For a while there, it looked like ACA was actually going to get used in the Fibre Channel world as it was the only game in town to preserve the Request Sense data until an ACA tagged Request Sense command could be sent to get the details of why the Check Condition occurred. As things turned out, ECA inventor Gary Stephens was the unwitting killer of ACA. This might be hard to explain without some background so here goes with another flashback to earlier pages of the Happenings to set the stage. SCSI FORUM MARCH 13-15 1991 Gary Stephens' (IBM) opening was like a pitch for a new breakfast cereal. "Introducing! New High Fibre SCSI." Gary was talking about the SPP (SCSI-3 Packetized Protocol), a new twist from the same folks who brought us SCSI-1 and SCSI-2........ "Most of the logical elements remain familiar to SCSI fans. The Message system, Command Descriptor Blocks, Command Parameter Data, Command Response Data and Logical Block Data are all present. Regular Status plus a new element, AutoSense are there." "I lost my bid for AutoSense in SCSI-2, but now it's back." Gary had several flow charts of transfers between Initiator and Target to demonstrate the logic of SPP. He complemented this with configurations that showed how Fiber Channel can be configured Point-to-Point, Switched Multi-Point or as a Ring. "SCSI via the Fibre Channel will be the next revolution in peripherals attachment technology." Gary opened up the floodgates. o In October 1992, Ed Gardner (then DEC now Ophidian Designs) proposed that an AutoSense capability be added to the 1394 SBP (Serial Bus Protocol). o Despite opposition earlier in the year, by September 1993, AutoSense had been integrated into SSA (Serial Storage Architecture) SSP (Serial SCSI-3 Protocol). AutoSense soon came to be perceived as a solution to nasty situations which required ACA, as illustrated by this quotation from Bob Snively (then Sun Microsystems now Brocade) from the SCSI Working Group in May 1994. "AutoSense is a better solution for non-interlocked protocols than ACA, and all the serial protocols provide it." Bob took the necessary steps to make ACA optional, and so far as ENDL knows, it is unused (to no one's surprise). The ultimate triumph of AutoSense came when George Penokie and Jeff Williams (then Hewlett Packard now Seagate) brought a new generation Packetized Prot- ocol for parallel SCSI to committee. Here is a key point made in the April 1998 Happenings. The really important thing about the SPI Status IU is that it contains sense data, thus giving SCSI parallel its first AutoSense capability. Long and Short of It Given the twisted history of how ACA and AutoSense grew out of ECA and CA, and because 'Auto' is the first word in both AutoSense and ACA, there is a lot of folklore around which feature does what and why. Most of it borders on mythology, and here is the ENDL slice and dice of reality. There are two general problems to be solved: o Getting the Request Sense data to the initiator o Blocking target activity until the initiator has been able to do every- thing needed to recover from an error The matrix of problems and solutions looks like this. +--------------------+ | Solution | +---------------------+--------+-----------+ | Problem | SCSI-2 | SCSI-3 | +---------------------+--------+-----------+ | Getting the Request | CA | AutoSense | | Sense data | | | +---------------------+--------+-----------+ | Blocking activity | ECA | ACA | +---------------------+--------+-----------+ o CA makes sure an initiator can get Request Sense data by blocking activ- ity for an extremely limited period of time i.e. until the next command. o AutoSense makes sure the initiator gets Request Sense data the way some folks always thought it should be done, by co-locating the Request Sense data with the Check Condition status. Despite the commonality of names, ACA is not a special case of CA, ACA is the SCSI-3 version of ECA. Once you accept this it comes as no surprise to learn that ACA is implemented with about the same lack of enthusiasm as ECA. (C) Copyright 2000 ENDL From owner-ips@ece.cmu.edu Sun Feb 18 17:39:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12138 for ; Sun, 18 Feb 2001 17:39:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1IL0u620427 for ips-outgoing; Sun, 18 Feb 2001 16:00:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [168.159.208.81]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1IL0h120415 for ; Sun, 18 Feb 2001 16:00:43 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2650.21) id <15YQ8KDD>; Sun, 18 Feb 2001 16:00:37 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A0704101538@corpmx9.isus.emc.com> From: Black_David@emc.com To: dotis@sanlight.net, ips@ece.cmu.edu Subject: RE: iSCSI: Security Enviornments Date: Sun, 18 Feb 2001 16:00:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk > Thank you for the information. You have made it clear you view iSNS is to > be the source of authorization. I fail to understand what limitation exists > using LDAP directly versus this rehash of DNS and LDAP, but you should > understand the importance of asking such dumb questions. iSNS is by no means the only possible source of this sort of information. If someone wants to use LDAP, they should write up and submit a draft on how to use it. > security management must be able to > endure device failure. This implies security is placed safely somewhere > which contains both authentication and authorization information. The implication is incorrect. The ability to run the security management application on more than one host to manage access control lists in persistent storage on the device is a counterexample. Most access control lists are stored at the point of access rather than obtained from an external source. I think it's up to the WG to decide whether to store authorization information at the target vs. obtaining it externally. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Sun Feb 18 17:39:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12149 for ; Sun, 18 Feb 2001 17:39:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1IKFts17962 for ips-outgoing; Sun, 18 Feb 2001 15:15:55 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [168.159.208.81]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1IKFC117902 for ; Sun, 18 Feb 2001 15:15:12 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2650.21) id <15YQ821S>; Sun, 18 Feb 2001 15:15:06 -0500 Message-ID: <0F31E5C394DAD311B60C00E029101A070792743F@corpmx9.isus.emc.com> From: Black_David@emc.com To: minutes@ietf.org Cc: ips@ece.cmu.edu, mankin@east.isi.edu Subject: Official IPS Orlando interim minutes Date: Sun, 18 Feb 2001 15:15:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk IPW Working Group Orlando Interim Meeting Minutes, January 16-17, 2001 ---------------------------------------------------- These minutes report conclusions reached at the meeting with comments on subsequent action on the mailing list where appropriate. -- iSCSI and related items (January 16th, plus about an hour on the morning of January 17th) (1) Framing - The iSCSI draft will be revised to add a formal iSCSI interface to framing - This will support the current marker approach, SCTP, and SCTP-like chunking for TCP. - The existing description of markers will be moved to an appendix as an example. -The WARP group working on RDMA will write a draft on using SCTP-like chunking for iSCSI without RDMA (2) Error Recovery - Terminology Changes - "Reference Number" and "RN" are used only for SCSI -iSCSI uses "Sequence Number" and "SN" instead - "AER" is used only for SCSI - iSCSI communication of asynchronous events is through a mechanism that is now called "Asynchronous Messages" - iSCSI uses these to implement AER - If a SCSI initiator has disabled AER, iSCSI does not send the corresponding Asynchronous Messages, but may still send iSCSI to iSCSI Asynchronous Messages that do not cause AER events visible to SCSI. - CmdSN (formerly CmdRN) is mandatory in all cases to simplify things. - This includes single connection sessions - SCSI has defined a new (optional) SCSI Command Ref Number - iSCSI will use byte #2 in the iSCSI header (currently Reserved) to transport the SCSI CRN when it is present. - This is not the ideal solution, but matches the level of support in FCP. - SCSI uses a transport-specific mode page to negotiate CRN usage, therefore iSCSI will use a text key to handle this negotiation (updated based on investigation after the meeting). - DataSN (formerly DataRN) functionality will be removed. Error recovery is now at the granularity of commands, not within a command. - There will be a significant connection recovery write-up, including details, procedures and examples added to the draft. - Ping/NOP issues - A description of intended usage will be added to the draft as advice to implementers. - A ping is intended to check whether the corresponding protocol is alive - NOP responses are not permitted to request further responses in order to avoid NOP loops - Abort WARNING will be added to the draft. - Immediate Delivery of Aborts and similar task management commands may have unexpected results when multiple TCP connections are in use in a single iSCSI session because Abort, Clear Task Set, etc. may bypass command(s) to be aborted/cleared on other TCP connections. - Ordered Delivery should be used instead when this is a concern. (3) CRC - [[iSCSI will use separate CRCs on header and data to make header modification easier for systems that need to do that.]] NOTE: This meeting conclusion was *rejected* on the mailing list and hence remains an open issue. - Using the same CRC algorithm on header and data is simpler - in particular the idea of using a 16-bit CRC on the header was discarded. NOTE: This conclusion to not use 16-bit CRC algorithms remains the WG consensus. - One CRC should cover both the fixed header and optional extensions. NOTE: This is part of the separate CRCs conclusion that was rejected on the list, and hence this issue is open. - Sense of the room on CRC Algorithms - CRC-32 is the obvious first/default choice. - There is some interest in investigating both weaker (Adler-32) and stronger (CRC-64) CRCs (CRC-64 may not be appropriate for header, and is still a research topic). - CRCs are MUST implement - Open issue: whether CRC use is negotiable - Default: Use CRCs - Limiting the amount of data per CRC - Probability of undetected error rises with amount of data covered by one CRC. - There will be at most one data CRC per PDU - This limit SHOULD be enforced limit by fragmenting large data blocks into Multiple Data PDUs - Julian Satran will look for the reference that suggests CRC-32 should not be used on data blocks significantly larger than about 8-10k. (4) Security - Current iSCSI security digests will be removed in favor of IPsec and/or TLS - Only reason for digests is data integrity (i.e., CRCs) - Open issue: How does iSCSI negotiate or detect presence of lower level security? - Open issue: What is minimum security required to be used (authentication/integrity) by IETF? Resolution: IETF requires implementation of strong security sufficient for public networks, but permits negotiation down to weaker (or even no security), *provided that* the negotiation is secure (e.g., against man in the middle attack to force negotiation of "no security". - SRP and Kerberos login authentication will remain in the iSCSI draft. (5) Naming - UTF-8 will be used instead of ASCII for text strings in iSCSI login and text commands, naming, discovery, etc. - Binary values will be translated to text strings [further discussion on the list indicated a preference for hex (0xnnn format) and decimal representations] and encoded in UTF-8 rather than adding type/length support to send them natively. - Localization of iSCSI text is forbidden on the wire for interoperability reasons (e.g., keys/values in login and text commands are the same byte strings, no matter what the locale). -- FCIP and related items (January 17th) 1) Ralph Weber verbally presented some changes to the FCIP draft, specifically dealing with framing, header and timestamps. A formal proposal, in the form of a draft, has been submitted in mid-February. 2) SOF/EOF encodings. The current draft uses the same SOF/EOF encodings as are in the FC-BB specification. While that draft lists a number of encodings, only a subset are required by that document. Discussions about the various encodings have lead to the conclusion that the subset should be the only SOF/EOF encodings specified in the FCIP document. That subset is restricted to class 2 and class 3 support. The other encodings are either not defined in FC-FS (framing and signaling), are Class 1 specific (which is not currently used in the industry) or class 4 (which is not yet defined). 3) Figure 4 in the document needs to be updated. It currently implies that the FC header will immediately follow the TCP header. Misleading, in that it appears to be at a fixed offset and does not indicate that optional TCP headers may be in place between the TCP and FC headers. In particular, put a box with ellipses in it to make this clearer. 4) David Black provided input on QoS (David is a coauthor of the Differentiated Services header and architecture RFCs). The FCIP draft should be revised to avoid specifying a specific Differentiated Services Code Point (DSCP) and should instead specify expected/required performance criteria. 5) Error recovery is still a major issue in the current specification, in particular the handling of the FC and TCP timeouts and their correlation. Ralph Weber's discussion earlier in the session applicable here. We really need more input on this from the FC switch vendors. This will be discussed in the FC-BB2 meeting at T11 to solicit their input. 6) Security -- Authentication a must. IPSec and TLS are the logical choices here. TLS may be the better choice of the two. iSCSI facing the same issues. FCIP should take iSCSI decisions/considerations into account and try to align with iSCSI if possible. 7) Clarification needed to the document indicating that E_Ports are supported by this document. While not prohibited by the current document, not clear that this is supported either. IETF IP Storage (ips) WG Interim Meeting Attendees Orlando, Florida - January 16, 2001 ----------------------------------- David Black black_david@emc.com John Hufferd hufferd@us.ibm.com Jack Harwood jharwood@emc.com David Peterson dap@cisco.com Julian Satran Julian_Satran@il.ibm.com Costa Sapuntzakis csapuntz@cisco.com Steve DeGroote sdegroote@cisco.com Mark Bakke mbakke@cisco.com Naoki Watanabe naoki.wtanabe@hds.com Neil Wanamaker ntw@crossroads.com Donald Getty donald_getty@ti.com Larry Lamers LJLAMERS@ieee.org Jim Hafner hafner@almaden.ibm.com Bob Nixon bob.nixon@emulex.com Ken Moe kenneth.moe@sun.com Mark Edwards medwards@eurologic.com Wayland Jeong wayland@troikanetworks.com Bill Terrell terrell@troikanetworks.com Bob Snively rsnively@brocade.com Ralph Weber roweber@acm.org Stephen Ostrowski sostrowski@giganet.com Jim Williams jimw@giganet.com Mike Mesnier michael.mesnier@intel.com Randy Haagens randy_haagens@hp.com Bill Lynn bill-lynn@corp.adaptec.com Rob Haydt robhay@microsoft.com Vit Novak vit.novak@sun.com Albert Chang albert.chang@compaq.com Roger Cummings roger.cummings@veritas.com Howard Hall howard@pirus.com John Scheible Dal Allan Mike Fitzpatrick mfitzpatrick@fcpa.fujitsu.com Jon Sreekanth jon.sreekanth@trebia.com Elizabeth Rodriguez egrodriguez@lucent.com Joe Steinmetz joe_steinmetz@agilent.com Matt Wakeley matt_wakeley@agilent.com Luciano Dalle Ore luciano.dalle.ore@quantum.com Kevin Gibbons kgibbons@nishansystems.com Josh Tseng jtseng@nishansystems.com Charles Monia cmonia@nishansystems.com Henry Yang Henry.Yang@mcdata.com Paul Congdon paul_congdon@hp.com Vi Chau vchau@gadzoox.com Gaby Hecht ghecht@gadzoox.com Pierre Labat pierre_labat@hp.com James Pinkerton jpink@microsoft.com Terry Gibbons terry.gibbons@lsil.com Craig Carlson cwc@ancor.com John Vrabel j.vrabel@san.com Somesh Gupta somesh_gupta@ieee.org IETF IP Storage (ips) WG Interim Meeting Attendees Orlando, Florida - January 17, 2001 ----------------------------------- Elizabeth Rodriguez egrodriguez@lucent.com David Black black_david@emc.com Murali Rajgopal muralir@lightsand.com Craig Carlson craig.carlson@qlogic.com David Peterson dap@cisco.com Josh Tseng jtseng@nishansystems.com Kevin Gibbons kgibbons@nishansystems.com John Vrabel j.vrabel@san.com Albert Chang albert.chang@compaq.com Bob Nixon bob.nixon@emulex.com Jon Sreekanth jon.sreekanth@trebia.com Mike Fitzpatrick mfitzpatrick@fcpa.fujitsu.com Donald Getty donald_getty@ti.com Jack Harwood jharwood@emc.com Wayland Jeong wayland@troikanetworks.com Mark Edwards medwards@eurologic.com Henry Yang Henry.Yang@mcdata.com Paul Congdon paul_congdon@hp.com Steve Degroote sdegroote@cisco.com Vi Chau vchau@gadzoox.com Gaby Hecht ghecht@gadzoox.com Venkat Rangan venkat@rhapsodynetworks.com Howard Hall howard@pirus.com Larry Lamers LJLAMERS@ieee.org Lucian Dalle Ore Luciano.Dalle.Ore@quantum.com From owner-ips@ece.cmu.edu Mon Feb 19 08:47:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03962 for ; Mon, 19 Feb 2001 08:47:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1JBaF914212 for ips-outgoing; Mon, 19 Feb 2001 06:36:15 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1JBZD114146 for ; Mon, 19 Feb 2001 06:35:13 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id MAA133580; Mon, 19 Feb 2001 12:35:00 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id MAA174258; Mon, 19 Feb 2001 12:34:28 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569F8.003F8C0A ; Mon, 19 Feb 2001 12:34:06 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu cc: ENDL_TX@computer.org Message-ID: Date: Mon, 19 Feb 2001 12:34:06 +0200 Subject: Re: iSCSI: About CA, ACA, and AutoSense Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Ralph, Thanks a lot for shading light on the history of Autosense and ACA. It will certainly help clarify the recovery discussion thread within IPS. Regards, Julo From owner-ips@ece.cmu.edu Mon Feb 19 11:25:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08018 for ; Mon, 19 Feb 2001 11:25:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1JEBJi22027 for ips-outgoing; Mon, 19 Feb 2001 09:11:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1JEAn121994 for ; Mon, 19 Feb 2001 09:10:49 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id PAA163934 for ; Mon, 19 Feb 2001 15:10:42 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay02.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id PAA67528 for ; Mon, 19 Feb 2001 15:09:53 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569F8.004DCED6 ; Mon, 19 Feb 2001 15:09:52 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Mon, 19 Feb 2001 16:10:54 +0200 Subject: RE: iSCSI: Security Enviornments Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk On subject of authorization - I think we would be ill advised to start something - there is a considerable body of work being done in the security area under the name GAA (like GSS) and we might want to use it when ready. We can provide them with input and/or help. Julo Black_David@emc.com on 18/02/2001 23:00:35 Please respond to Black_David@emc.com To: dotis@sanlight.net, ips@ece.cmu.edu cc: Subject: RE: iSCSI: Security Enviornments > Thank you for the information. You have made it clear you view iSNS is to > be the source of authorization. I fail to understand what limitation exists > using LDAP directly versus this rehash of DNS and LDAP, but you should > understand the importance of asking such dumb questions. iSNS is by no means the only possible source of this sort of information. If someone wants to use LDAP, they should write up and submit a draft on how to use it. > security management must be able to > endure device failure. This implies security is placed safely somewhere > which contains both authentication and authorization information. The implication is incorrect. The ability to run the security management application on more than one host to manage access control lists in persistent storage on the device is a counterexample. Most access control lists are stored at the point of access rather than obtained from an external source. I think it's up to the WG to decide whether to store authorization information at the target vs. obtaining it externally. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Feb 19 17:28:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16483 for ; Mon, 19 Feb 2001 17:28:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1JJdU014490 for ips-outgoing; Mon, 19 Feb 2001 14:39:30 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1JJcv114453 for ; Mon, 19 Feb 2001 14:38:57 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f1JKmb015694; Mon, 19 Feb 2001 12:48:39 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: , Subject: RE: iSCSI: Security Enviornments Date: Mon, 19 Feb 2001 11:37:30 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <0F31E5C394DAD311B60C00E029101A0704101538@corpmx9.isus.emc.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, By persistent storage, you mean network accessible storage if suggesting being able to manage IPS security over the network. Even the iSNS implies some of its information may be stored using LDAP, one possible form of secure persistent network accessible storage. Is there a desire within this WG to define an LDAP schema? Otherwise, every manufacturer will devise their own methods of persistent security storage. It seems like a directory user agent is a small amount of code to add to a storage device providing security. It would make initializing these devices a simpler matter in that you point them to an authoritive LDAP server. LDAP already provides features needed for security and extensibility and places management up a few steps on the evolutionary ladder. Doug > > Thank you for the information. You have made it clear you view > iSNS is to > > be the source of authorization. I fail to understand what limitation > exists > > using LDAP directly versus this rehash of DNS and LDAP, but you should > > understand the importance of asking such dumb questions. > > iSNS is by no means the only possible source of this sort of information. > If someone wants to use LDAP, they should write up and submit a draft > on how to use it. > > > security management must be able to > > endure device failure. This implies security is placed safely somewhere > > which contains both authentication and authorization information. > > The implication is incorrect. The ability to run the security management > application on more than one host to manage access control lists in > persistent storage on the device is a counterexample. > > Most access control lists are stored at the point of access rather than > obtained from an external source. I think it's up to the WG to decide > whether to store authorization information at the target vs. obtaining it > externally. > > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Mon Feb 19 19:44:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18941 for ; Mon, 19 Feb 2001 19:44:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1JMRYM25877 for ips-outgoing; Mon, 19 Feb 2001 17:27:34 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1JMQc125823 for ; Mon, 19 Feb 2001 17:26:39 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f1JNaO015819; Mon, 19 Feb 2001 15:36:25 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: , Subject: RE: iSCSI: Security Enviornments Date: Mon, 19 Feb 2001 14:25:17 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, Security at the storage device over various native transports can be seen as a subset of the security required for an IPS device. IPS employs security foreign to storage and this entails a new set of tools required to maintain these systems, hopefully in an industry consistent manner. Understanding security needs of the underlying devices is important in the development of the information base that will be required, but this information is not complete on its own as it must be coupled with security needed by IPS. It makes sense to devise a means of managing this information using network based tools and then apply this information within IPS protocols as a means of preventing vendor unique methods being the only solution. I would suspect, when it comes to network security, work done by GAA and GSS will act as a framework of the solution, but the information structures and their storage will fall to IPS. http://www.ietf.org/internet-drafts/draft-ietf-cat-gaa-cbind-05.txt The Generic Authorization and Access-control (GAA) API is an IETF draft (it is not a ratified IETF standard) for adding authorization to applications. It really consists of two parts: 1) a standard way of describing authorization policies, and 2) a standard API for checking such policies against the security credentials that come from an authentication process such as GSS-API. http://www-itg.lbl.gov/security/Akenti/ http://www-itg.lbl.gov/Akenti/docs/servers.html#CA Doug > On subject of authorization - I think we would be ill advised to start > something - there is a considerable body of work being done in > the security > area under the name GAA (like GSS) and we might want to use it when ready. > We can provide them with input and/or help. > > Julo > > > Black_David@emc.com on 18/02/2001 23:00:35 > > Please respond to Black_David@emc.com > > To: dotis@sanlight.net, ips@ece.cmu.edu > cc: > Subject: RE: iSCSI: Security Enviornments > > > > > > Thank you for the information. You have made it clear you view iSNS is > to > > be the source of authorization. I fail to understand what limitation > exists > > using LDAP directly versus this rehash of DNS and LDAP, but you should > > understand the importance of asking such dumb questions. > > iSNS is by no means the only possible source of this sort of information. > If someone wants to use LDAP, they should write up and submit a draft > on how to use it. > > > security management must be able to > > endure device failure. This implies security is placed safely somewhere > > which contains both authentication and authorization information. > > The implication is incorrect. The ability to run the security management > application on more than one host to manage access control lists in > persistent storage on the device is a counterexample. > > Most access control lists are stored at the point of access rather than > obtained from an external source. I think it's up to the WG to decide > whether to store authorization information at the target vs. obtaining it > externally. > > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > > > From owner-ips@ece.cmu.edu Wed Feb 21 22:26:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18316 for ; Wed, 21 Feb 2001 22:26:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1M0WiC12933 for ips-outgoing; Wed, 21 Feb 2001 19:32:44 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1M0WS112914 for ; Wed, 21 Feb 2001 19:32:28 -0500 (EST) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Feb 2001 16:32:21 -0800 Message-ID: From: Joshua Tseng To: ips@ece.cmu.edu, julian_satran@il.ibm.com Subject: iSCSI: ExpStatRN Date: Wed, 21 Feb 2001 16:32:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, I am confused by section 2.3.4 where it says "Command responses up to ExpStatRN-1 (mod 2**32) have been received (acknowledges status) on the connection." First of all, can't a target execute the commands in a different order from the order in which the commands were received? If so, then won't the StatSN coming back NOT be in sequential order? The initiator needs to scoreboard responses from the target, and a single cumulative acknowledgement counter won't do the job. Who chooses the StatSN value for each response? Section 2.4.7 says the target generates this value on a per-connection basis. But the name "ExpStatSN", which is sent by the initiator, implies that the initiator generates this value. If the initiator generates this value, then how can multiple commands be in flight if the value ExpStatSN-1 has already been received by the initiator? If the target generates this value, then "ExpStatSN" is an inapproporiate and misleading name for this field. It implies that the StatSN for the corresponding response should be the same as the ExpStatSN generated by the initiator for the original outgoing command. Josh From owner-ips@ece.cmu.edu Thu Feb 22 05:14:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06737 for ; Thu, 22 Feb 2001 05:14:35 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1M7ush05600 for ips-outgoing; Thu, 22 Feb 2001 02:56:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1M7uC105569 for ; Thu, 22 Feb 2001 02:56:15 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA96636 for ; Thu, 22 Feb 2001 08:56:05 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id IAA96438 for ; Thu, 22 Feb 2001 08:55:32 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569FB.002B7DAE ; Thu, 22 Feb 2001 08:55:02 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Thu, 22 Feb 2001 09:56:14 +0200 Subject: Re: iSCSI: ExpStatRN Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Josh, You have probably seen it by yourself by now... but anyhow. Statuses are numbered as issued (no relation to command numbering) and are counted per connection. When they disapear (digest error, dropped connection) the initiator will be able to tell and the target will be able to resend. Julo Joshua Tseng on 22/02/2001 02:32:21 Please respond to Joshua Tseng To: ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL cc: Subject: iSCSI: ExpStatRN Julian, I am confused by section 2.3.4 where it says "Command responses up to ExpStatRN-1 (mod 2**32) have been received (acknowledges status) on the connection." First of all, can't a target execute the commands in a different order from the order in which the commands were received? If so, then won't the StatSN coming back NOT be in sequential order? The initiator needs to scoreboard responses from the target, and a single cumulative acknowledgement counter won't do the job. Who chooses the StatSN value for each response? Section 2.4.7 says the target generates this value on a per-connection basis. But the name "ExpStatSN", which is sent by the initiator, implies that the initiator generates this value. If the initiator generates this value, then how can multiple commands be in flight if the value ExpStatSN-1 has already been received by the initiator? If the target generates this value, then "ExpStatSN" is an inapproporiate and misleading name for this field. It implies that the StatSN for the corresponding response should be the same as the ExpStatSN generated by the initiator for the original outgoing command. Josh From owner-ips@ece.cmu.edu Fri Feb 23 02:35:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23915 for ; Fri, 23 Feb 2001 02:35:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1N5ALu29492 for ips-outgoing; Fri, 23 Feb 2001 00:10:21 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from clyde.stargateip.com ([209.237.5.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1N5A1129458 for ; Fri, 23 Feb 2001 00:10:01 -0500 (EST) Received: from yellowstone (yellowstone.stargateip.com [209.237.5.90]) by clyde.stargateip.com (8.9.1/8.9.1) with ESMTP id VAA03525; Thu, 22 Feb 2001 21:05:26 -0800 (PST) From: "Srini V.Raman" To: "IPS Reflector" Cc: Subject: RE: FCIP: draft-weber-fcip-encaps-00.txt Date: Thu, 22 Feb 2001 21:12:32 -0800 Message-ID: <006b01c09d57$39c1ed60$5a05edd1@yellowstone.stargateip.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <3A8BDE4A.5D7F4BCA@compuserve.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, Some comments on the recent "FCIP Frame Encapsulation Enhancement Proposals" Section 3.2: Timeout suggestion is a good is well taken. Timeout extensions that have been suggested in the proposal to deal with keeping TCP retransmit timeouts within the E_D_TOV and R_A_TOV requirements is a good one. Section 2: Currently we have four different mechanisms to protect the data integrity . They are ... 1. Data Link layer (either Ether Framer or the HDLC framer) has CRC/FCS protection, Which is reasonably strong protection against data corruption. 2. TCP checksum provides an end to end data integrity check against the corruptions in both TCP payload (FCIP header and FC payload) and TCP header. 3. FCIP header (as proposed in the Enhancement draft) has both length and inverse length information to detect corruption in the FCIP length. 4. An additional paranoid check can be done against SOF and EOF fields to verify the data integrity in case of length field being a suspect. The recent document suggests inserting delimiters and data stuffing to provide additional check for the FCIP boundaries/length. In the instances where delimiter gets corrupted, the only protection we have is FCIP checksum, which is no different from TCP checksum. The point of having additional delimiters doesn't make any additional guarantee against the data corruption other than complicating the FCIP implementations, whether it be a software or an hardware implementation. Section 5: An additional checksum (as proposed) in the FCIP layer is a redundant checksum. If need be, a checksum can be made only for the FCIP header (4 bytes of length, 8 bytes of timestamp). -- Srini > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Ralph Weber > Sent: Thursday, February 15, 2001 5:49 AM > To: IPS Reflector > Subject: FCIP: draft-weber-fcip-encaps-00.txt > > > An internet draft titled " FCIP Frame Encapsulation Enhancement > Proposals" is available at: > > http://www.ietf.org/internet-drafts/draft-weber-fcip-encaps-00.txt > > The abstract is as follows: > > This draft is for consideration by the FCIP team in the IPS working > group. Improvements to Fibre Channel Over TCP/IP (FCIP) [2] frame > encapsulation mechanisms are proposed. The objectives of the > improvements are two fold: increasing the reliability of Fibre > Channel frame detection, and assisting with the handling of Fibre > Channel E_D_TOV and R_A_TOV time-out processing. > > Since the ID was submitted a technical error was discovered in > section 3.2, Time Stamp, it says that the integer word in the > time stamp is "the time in seconds relative to the epoch, > 00:00:00 January 1,1990." This is a transcription from the > T11 proposal on which the usage of this time format is based > (01-052v0). > > However, 01-052v0 is based on SNTP (RFC 2030) and RFC 2030 says > that the base epoch is "00:00:00 January 1,1900", that is 1900 > not 1990. > > I have been informed that 01-052v0 did not intend to revise > RFC 2030 and that the encapsulation proposal should use 1900 > not 1990. > > FYI > > Ralph Weber > representing > Brocade Communications > > > From owner-ips@ece.cmu.edu Fri Feb 23 05:51:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26393 for ; Fri, 23 Feb 2001 05:51:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1N8iM309393 for ips-outgoing; Fri, 23 Feb 2001 03:44:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1N8hj109363 for ; Fri, 23 Feb 2001 03:43:45 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id JAA160976 for ; Fri, 23 Feb 2001 09:43:33 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay02.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id JAA29248 for ; Fri, 23 Feb 2001 09:42:34 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569FC.002FD717 ; Fri, 23 Feb 2001 09:42:32 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Fri, 23 Feb 2001 10:43:03 +0200 Subject: iSCSI 04.txt is out Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear colleagues, I've just submitted to the Internet-Drafts repository and to our list archive (at CMU) a new version of the draft. You can find the new document at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-04.txt It includes many changes and a brief summary of them follows: - it includes a first attempt at synchronization with the ND team - text and login are explained in more detail and the login phase is complete - the new PDU format (you had a preview on the list) - recovery has a new help PDU - the SACK - We have removed the data ack mechanism (as agreed in Orlando) but we had to leave data sequence in to enable detection of missed pieces of data (not necessarily recovery) without resorting to a very "unSCSI" scoreboarding technique -the recovery chapter is rewritten and has now two complementary threads - errors and recovery -Security - here is a short summary for the main security changes: 1. Public key, password and challenge authentication methods are removed. All public key related stuff is removed. Public key mechanism for iSCSI can be implemented at the IPSEC level, or as a propriety authentication method (that is still allowed!) 2. The defined authentication methods are now none, KERB5 and srp. 3. The header and data digests remain and can be negotiated to none, CRC or KERB5-based digests. The motivation for KERB5-based digests is that after KERB5 authentication (mutual or initiator-only) both parties have actually built a security context with symmetric session key, and it makes sense to enable its usage for digests with real security significance. Moreover, this follows the typical usage of KERB5 through GSSAPI (rfc-1964) and the KERB5 digests were defined according to the three GSS_getMIC() options for digests. 4. The only CRCs left are CRC32Q (a new and supposedly far better CRC with a 10**-4 lower probability of undetected errors) and CRC64. The memo we are working on about block lengths will be out soon. CRC64 is open (but CRC32Q makes the need for it less stringent for a while). 4. About security MUST and MAY for iSCSI implementation as it appears now: - It MUST provide means of authentication and data integrity. - it MAY provide means of data privacy (encryption). - Both statements can be satisfied by using IPSEC. - When not using IPSEC iSCSI implementation MUST provide the KERB5 authentication and data integrity or other propriety method for authentication and data integrity - and those can be software solutions. We gave up on TLS (it can still be used as a "proprietary option") for two reasons; -it does make framing and RDMA more difficult (an additional layer of chunking!) -it is more expensive in terms of performance than the mechanisms that we decided to keep - although it offers features far beyond our minimal needs Regards, Julo From owner-ips@ece.cmu.edu Fri Feb 23 13:02:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11932 for ; Fri, 23 Feb 2001 13:02:02 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1NFgUd11118 for ips-outgoing; Fri, 23 Feb 2001 10:42:30 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1MC3P125918 for ; Thu, 22 Feb 2001 07:03:26 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07458; Thu, 22 Feb 2001 07:03:24 -0500 (EST) Message-Id: <200102221203.HAA07458@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-ifcp-00.txt Date: Thu, 22 Feb 2001 07:03:24 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iFCP - A Protocol for Internet Fibre Channel Storage Networking Author(s) : C. Monia et al. Filename : draft-ietf-ips-ifcp-00.txt Pages : 48 Date : 21-Feb-01 This document specifies iFCP, a gateway-to-gateway protocol for the implementation of a Fibre Channel fabric in which TCP/IP switching and routing elements replace Fibre Channel components. The protocol enables the attachment of existing Fibre Channel storage products to an IP network by supporting the subset of fabric services required by such devices. The encapsulation described in this version of the document is obsolete. It will be replaced by an encapsulation format which will be common to both the iFCP and FCIP protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-ifcp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-ifcp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010221145027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-ifcp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-ifcp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010221145027.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Fri Feb 23 13:02:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11943 for ; Fri, 23 Feb 2001 13:02:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1NG5b112725 for ips-outgoing; Fri, 23 Feb 2001 11:05:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1NG5M112692 for ; Fri, 23 Feb 2001 11:05:22 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f1NHEw021438; Fri, 23 Feb 2001 09:14:58 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: "Srini V.Raman" , "IPS Reflector" Cc: Subject: RE: FCIP: draft-weber-fcip-encaps-00.txt Date: Fri, 23 Feb 2001 08:03:56 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <006b01c09d57$39c1ed60$5a05edd1@yellowstone.stargateip.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Srini, If SCTP structures within TCP is employed, then you benefit from an Adler-32 frame check and have a mechanism for retrying the failed frame. The FCIP Enhancement does not describe any technique for recovering a bad frame found by a digest error. SCTP already has the mechanism in place for this type of recovery even if placed on top of TCP. The other benefit is byte stuffing is not needed. To encapsulate within TCP, simply create a pseudo-frame and allow the SCTP structures to conform to this pseudo-frame placed at fixed intervals rather than at the real Ethernet frame. If SCTP is used directly, the real Ethernet frame can be used. Doug > Ralph, > > Some comments on the recent "FCIP Frame Encapsulation Enhancement > Proposals" > > Section 3.2: > > Timeout suggestion is a good is well taken. Timeout extensions that > have been suggested in the proposal to deal with keeping TCP retransmit > timeouts within the E_D_TOV and R_A_TOV requirements is a good one. > > Section 2: > > Currently we have four different mechanisms to protect the data > integrity . > They are ... > > 1. Data Link layer (either Ether Framer or the HDLC framer) has CRC/FCS > protection, Which is reasonably strong protection against data corruption. > 2. TCP checksum provides an end to end data integrity check against the > corruptions in both TCP payload (FCIP header and FC payload) and > TCP header. > 3. FCIP header (as proposed in the Enhancement draft) has both length and > inverse length information to detect corruption in the FCIP length. > 4. An additional paranoid check can be done against SOF and EOF fields to > verify the data integrity in case of length field being a suspect. > > The recent document suggests inserting delimiters and data stuffing to > provide additional check for the FCIP boundaries/length. In the instances > where delimiter gets corrupted, the only protection we have is FCIP > checksum, which is no different from TCP checksum. > > The point of having additional delimiters doesn't make any additional > guarantee against the data corruption other than complicating the FCIP > implementations, whether it be a software or an hardware implementation. > > Section 5: > An additional checksum (as proposed) in the FCIP layer is a redundant > checksum. If need be, a checksum can be made only for the FCIP header (4 > bytes of length, 8 bytes of timestamp). > > -- Srini > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Ralph Weber > > Sent: Thursday, February 15, 2001 5:49 AM > > To: IPS Reflector > > Subject: FCIP: draft-weber-fcip-encaps-00.txt > > > > > > An internet draft titled " FCIP Frame Encapsulation Enhancement > > Proposals" is available at: > > > > http://www.ietf.org/internet-drafts/draft-weber-fcip-encaps-00.txt > > > > The abstract is as follows: > > > > This draft is for consideration by the FCIP team in the IPS working > > group. Improvements to Fibre Channel Over TCP/IP (FCIP) [2] frame > > encapsulation mechanisms are proposed. The objectives of the > > improvements are two fold: increasing the reliability of Fibre > > Channel frame detection, and assisting with the handling of Fibre > > Channel E_D_TOV and R_A_TOV time-out processing. > > > > Since the ID was submitted a technical error was discovered in > > section 3.2, Time Stamp, it says that the integer word in the > > time stamp is "the time in seconds relative to the epoch, > > 00:00:00 January 1,1990." This is a transcription from the > > T11 proposal on which the usage of this time format is based > > (01-052v0). > > > > However, 01-052v0 is based on SNTP (RFC 2030) and RFC 2030 says > > that the base epoch is "00:00:00 January 1,1900", that is 1900 > > not 1990. > > > > I have been informed that 01-052v0 did not intend to revise > > RFC 2030 and that the encapsulation proposal should use 1900 > > not 1990. > > > > FYI > > > > Ralph Weber > > representing > > Brocade Communications > > > > > > > > From owner-ips@ece.cmu.edu Fri Feb 23 16:56:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23620 for ; Fri, 23 Feb 2001 16:56:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1NJ6Wn24470 for ips-outgoing; Fri, 23 Feb 2001 14:06:32 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1NJ62124429 for ; Fri, 23 Feb 2001 14:06:02 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f1NKFl021568 for ; Fri, 23 Feb 2001 12:15:47 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: "Ips" Subject: iSCSI Rev 4 Date: Fri, 23 Feb 2001 11:04:20 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, Page 11: "Status numbering is per connection and is used to enable recovery in case of connection failure." Status number is not used to recover a connection failure. It is used to recover from a communication error on a connection but not for the case of a connection failure. The SCSI tag is used to recover a connection failure. Page 11: "Commands in transit from the initiator SCSI layer to the SCSI target layer are numbered by iSCSI and the number is carried by the iSCSI PDU as CmdSN (Command-Sequence-Number). The numbering is session- wide. All iSCSI PDUs that have a task association carry this number. CmdSNs are allocated by the initiator iSCSI within a 32 bit unsigned counter (modulo 2**32). The value 0 is reserved and used to mean immediate delivery. Comparisons and arithmetic on CmdSN SHOULD use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32. The means by which the SCSI layer may request immediate delivery for a command or by which iSCSI will decide by itself to mark a PDU for immediate delivery are outside the scope of this document. Using immediate delivery with some commands may have unexpected side effects. If used with Task Management commands those may get to the SCSI task manager at the target before the tasks they where suppose to act upon. Whenever those effects are undesirable connection allegiance or ordered delivery MAY be used." Do you see a paradox with immediate delivery identified with a zero sequence and then saying ordered delivery should be used for immediate delivery if sequencing matters? Connection allegiance does not ensure ordered delivery on immediate commands unless you call a hold on all commands pending resolution of a communication error. How should immediate delivery confine task attributes? Page 12: "CmdSNs are significant only during command delivery to the target. Once the device serving part of the target SCSI has received a command, CmdSN ceases to be significant. During command delivery to the target, the allocated numbers are unique session wide. The iSCSI target layer MUST deliver the commands to the SCSI target layer in the order specified by CmdSN." Could you more clearly define delivery to the target. Could you say "Upon command order having been checked and processed on a session basis, CmdSN is discarded?" If there is little communication between network adapters, at no point is there an ability to know when to drop the CmdSN except at some higher level. The concept of delivery is vague. This sentence seems to be assuming a structure not clearly defined. Perhaps you should elaborate what is implied by this statement. Page 16: "A target SHOULD NOT silently discard data and request retransmission through R2T. Initiators MUST NOT perform any score boarding for data and the residual count calculation is to be performed by the targets. Incoming data is always implicitly solicited. SCSI Data packets are matched to their corresponding SCSI commands by using Tags that are specified in the protocol." Here again the meaning is a bit vague so could you elaborate what is meant by score boarding. I assume tracking a data sequence is still required? If there are any errors within a data transfer, the entire transfer is repeated via a reissue of command with a different CmdSN? How would you maintain sequential processing upon a data error? See comment for Page 84. Page 18: "- IPv4 address, in dotted decimal notation. Assumed if the name contains exactly four numbers, separated by dots (.), where each number is in the range 0..255. - IPv6 address, in dotted decimal notation. Assumed if the name contains more than four, but at most 16 numbers, separated by dots (.), where each number is in the range 0..255. - Fully Qualified Domain Name (FQDN - host name). Assumed if the is neither an IPv4 nor an IPv6 address." As an alternative to 16 decimal to binary conversions for IPv6, the use of square brackets as a convention together with hexadecimal representations would reduce the overhead associated with processing these IP values. See RFC 2373. Both could be done for IPv4 and IPv6 to allow immediate recognition of either an IP address or a domain name. Page 84: "At initiator, the following cases lend themselves to within- connection recovery: (1)Lost iSCSI numbered Response recognized by either receiving it with a data digest error or receiving a Response PDU with a higher StatSN than expected. The initiator MAY request the missing responses through SACK, in which case the target MUST reissue them. (2)Requests not acknowledged for a long time. Requests are acknowledged explicitly through ExpCmdSN or implicitly by receiving data and/or status. The initiator MAY reissue non- acknowledged commands. The reissued, non-acknowledged commands MUST carry their original CmdSN and the X (retry) flag set to 1. Please note that this is the only case in which the reissued command will carry the same CmdSN. N.B. While the original connection for a command is still "active" (has not been logged-out or restarted), any command MUST be retried only on the original connection. After logging out the original connection, commands can be retried on a different connection, but must still carry the original CmdSN." A long time is vague and why is a timeout out of scope? This goes to the comment I made for immediate delivery. Of course only commands sequenced can be acknowledged via ExpCmdSN. Once a command has been acknowledged, there is no means to maintain sequence upon a transport error that requires retransmission of the command as a means of recovery. It is possible to create a transport that allows recovery without loss of sequence. Already, iSCSI is layered under a framing/TCP/WN/PDU. You have three layers above your PDUs but still no PDU sequence integrity. Doug From owner-ips@ece.cmu.edu Fri Feb 23 22:36:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01368 for ; Fri, 23 Feb 2001 22:36:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1O0kgb15014 for ips-outgoing; Fri, 23 Feb 2001 19:46:42 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1O0jd114959 for ; Fri, 23 Feb 2001 19:45:39 -0500 (EST) Received: from ordern.demon.co.uk ([158.152.10.215]) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 14WSq9-000CC7-0V for ips@ece.cmu.edu; Sat, 24 Feb 2001 00:45:37 +0000 Received: from localhost(rook.ordern.com[192.168.1.1]) (958 bytes) by ordern.demon.co.uk via smtpd with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Sat, 24 Feb 2001 00:45:36 +0000 (GMT) (Smail-3.2.0.108 1999-Sep-19 #7 built 2000-Feb-18) To: ips@ece.cmu.edu Subject: iSCSI 04 queries X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (GTK) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010224004536O.markb@ordern.com> Date: Sat, 24 Feb 2001 00:45:36 GMT From: Mark Burton X-Dispatcher: imput version 20000228(IM140) Lines: 17 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I would be very grateful if anyone can supply answers to these questions (prompted by my reading of draft-ietf-ips-iSCSI-04): 1 - Why is the cmdSN field required in the iSCSI TEXT PDU? 2 - Section 2.7.5 (SCSI Data) talks about a P bit, but that bit isn't shown in the PDU diagram, what's wrong? 3 - There doesn't seem to be an the appropriate error code to return when an initiator provides invalid values for TSID, ISID or CID? Thanks, Mark From owner-ips@ece.cmu.edu Sat Feb 24 14:13:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21571 for ; Sat, 24 Feb 2001 14:13:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1OGpxb09517 for ips-outgoing; Sat, 24 Feb 2001 11:51:59 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1OGpf109499 for ; Sat, 24 Feb 2001 11:51:41 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA96500 for ; Sat, 24 Feb 2001 17:51:33 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay02.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id RAA33436 for ; Sat, 24 Feb 2001 17:50:30 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569FD.005C848E ; Sat, 24 Feb 2001 17:50:32 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Sat, 24 Feb 2001 18:51:46 +0200 Subject: Re: iSCSI 04 queries Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, 1-cmdSN is there in the Text command because (at least in theory) you may want to have it reach the target in order - and some of the key=value pair may have an active semantic (there is one that I missed already - and it is called SendTargets that is be being proposed by the ND team for target discovery ) 2 - Mea culpa! It is a residue from 03 that I missed after three passes - just ignore the b7 - the new meaning is specified above in 2.7.1 and it is now significant as final for both input and output. THANX 3. I would say that format error is good enough (the same goes for a wrong LUN, a wrong tag etc.). Julo Mark Burton on 24/02/2001 02:45:36 Please respond to Mark Burton To: ips@ece.cmu.edu cc: Subject: iSCSI 04 queries Hi, I would be very grateful if anyone can supply answers to these questions (prompted by my reading of draft-ietf-ips-iSCSI-04): 1 - Why is the cmdSN field required in the iSCSI TEXT PDU? 2 - Section 2.7.5 (SCSI Data) talks about a P bit, but that bit isn't shown in the PDU diagram, what's wrong? 3 - There doesn't seem to be an the appropriate error code to return when an initiator provides invalid values for TSID, ISID or CID? Thanks, Mark From owner-ips@ece.cmu.edu Sat Feb 24 15:04:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21949 for ; Sat, 24 Feb 2001 15:04:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1OHr0d12523 for ips-outgoing; Sat, 24 Feb 2001 12:53:00 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1OHq0112476 for ; Sat, 24 Feb 2001 12:52:00 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.132.205]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA72978 for ; Sat, 24 Feb 2001 11:46:03 -0600 Received: from f3n41e (d03nm041h.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id KAA86376 for ; Sat, 24 Feb 2001 10:50:41 -0700 Importance: Normal Subject: iSCSI: Naming and Discovery Draft To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Kaladhar Voruganti" Date: Sat, 24 Feb 2001 17:50:40 +0000 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.6 |December 14, 2000) at 02/24/2001 09:50:41 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk The following iSCSI naming and discovery draft has been submitted to IETF. This naming and discovery draft has been produced by the iSCSI naming and discovery team. The draft contains the iSCSI naming and discovery details. http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-name-disc-00.txt Kaladhar Voruganti Computing Science Department IBM Almaden Research Lab San Jose, CA From owner-ips@ece.cmu.edu Mon Feb 26 11:00:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13597 for ; Mon, 26 Feb 2001 11:00:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1QDvAc08495 for ips-outgoing; Mon, 26 Feb 2001 08:57:10 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1QDuJ108445 for ; Mon, 26 Feb 2001 08:56:19 -0500 (EST) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA28229 for ; Mon, 26 Feb 2001 08:56:13 -0500 (EST) Message-ID: <3A9A60A9.5ADEC25C@cisco.com> Date: Mon, 26 Feb 2001 07:56:57 -0600 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: iSCSI: Discovery with SLP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit A draft on using the Service Location Protocol (SLP) to discover iSCSI targets and name servers has been submitted to IETF. This draft is related to the naming and discovery document, which I strongly recommend reading first. A copy of the draft is located at http://www.haifa.il.ibm.com/satran/ips/draft-bakke-iscsi-slp-00.txt -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Feb 26 11:01:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13668 for ; Mon, 26 Feb 2001 11:01:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1QDvD408500 for ips-outgoing; Mon, 26 Feb 2001 08:57:13 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1QDuN108453 for ; Mon, 26 Feb 2001 08:56:23 -0500 (EST) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA28302 for ; Mon, 26 Feb 2001 08:56:17 -0500 (EST) Message-ID: <3A9A60AD.5ED60BB0@cisco.com> Date: Mon, 26 Feb 2001 07:57:01 -0600 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: iSCSI: URN format for WWUI Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit A draft registering a Uniform Resource Name (URN) namespace for use with iSCSI World-Wide Unique Identifiers (WWUI) has been submitted to the IETF. This draft is related to the naming and discovery draft, which I strongly recommend reading first. A copy of the draft is located at http://www.haifa.il.ibm.com/satran/ips/draft-bakke-iscsi-wwui-urn-00.txt -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Feb 26 13:16:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19704 for ; Mon, 26 Feb 2001 13:16:07 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1QGKIB17670 for ips-outgoing; Mon, 26 Feb 2001 11:20:18 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1QGK3117639 for ; Mon, 26 Feb 2001 11:20:03 -0500 (EST) Received: from ahganemw2k (dhcp-161-44-68-121.cisco.com [161.44.68.121]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA22347 for ; Mon, 26 Feb 2001 11:19:57 -0500 (EST) From: "Ayman Ghanem" To: Subject: iSCSI-04: WN field Date: Mon, 26 Feb 2001 10:18:42 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Since the common case is likely to be a Basic Header Segment (BHS) followed by either a data segment or no data, wouldn't be simpler to have bit-7 of the WN field be defaulted to zero for the common case, and set it to 1 if we have additional header segments?. -Ayman From owner-ips@ece.cmu.edu Mon Feb 26 13:16:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19715 for ; Mon, 26 Feb 2001 13:16:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1QG4UY16496 for ips-outgoing; Mon, 26 Feb 2001 11:04:30 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f1QG44116456 for ; Mon, 26 Feb 2001 11:04:04 -0500 (EST) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Mon Feb 26 11:03:38 EST 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Mon Feb 26 11:03:38 EST 2001 Received: from lucent.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90]) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id LAA08661 for ; Mon, 26 Feb 2001 11:03:38 -0500 (EST) Message-ID: <3A9A7E59.BE323B22@lucent.com> Date: Mon, 26 Feb 2001 11:03:37 -0500 From: Sandeep Joshi X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: iscsi.04 comments Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, A few questions/comments.. 1) The following suggestion seems to be missing from this draft http://ips.pdl.cs.cmu.edu/mail/msg03273.html 2) There is a WN before the BHS and every AHS. So what are the WN bits (6-4) for a BHS ? Right now, there is 0=ext_cdb, 1=bidi, 2=longdata. All the other values (3-7) seem to be reserved. 3) Section 2.17 R2T - see statement before the fig. "outstanding R2T MUST be fulfilled by the initiator in the order they were received". Is this _within_ a command or connection or session. I presume its not within a session. Could you please qualify and disambiguate? 4) In Section 2.5 & Sec 2.6 for TaskMgmt commands the RefTaskTag, if reserved, is to be set to zero. In other commands (e.g. NOP-OUT), an invalid task tag is indicated by 0xffffffff. How about making it uniform throughout as 0xff... (or maybe this is an oversight) -Sandeep From owner-ips@ece.cmu.edu Mon Feb 26 14:06:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21829 for ; Mon, 26 Feb 2001 14:06:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1QH0GG20211 for ips-outgoing; Mon, 26 Feb 2001 12:00:16 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1QGxF120151 for ; Mon, 26 Feb 2001 11:59:16 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id RAA165386 for ; Mon, 26 Feb 2001 17:59:05 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay02.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id RAA126176 for ; Mon, 26 Feb 2001 17:57:55 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569FF.005D30A1 ; Mon, 26 Feb 2001 17:57:52 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Mon, 26 Feb 2001 18:59:17 +0200 Subject: Re: iSCSI-04: WN field Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Well to me it looks the same - 0, 1? Regards, Julo "Ayman Ghanem" on 26/02/2001 18:18:42 Please respond to "Ayman Ghanem" To: ips@ece.cmu.edu cc: Subject: iSCSI-04: WN field Since the common case is likely to be a Basic Header Segment (BHS) followed by either a data segment or no data, wouldn't be simpler to have bit-7 of the WN field be defaulted to zero for the common case, and set it to 1 if we have additional header segments?. -Ayman From owner-ips@ece.cmu.edu Mon Feb 26 14:09:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21990 for ; Mon, 26 Feb 2001 14:09:03 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1QH4NC20513 for ips-outgoing; Mon, 26 Feb 2001 12:04:23 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from anti_vir1.rad.co.il ([192.116.244.108]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1QH3F120432 for ; Mon, 26 Feb 2001 12:03:15 -0500 (EST) Received: from anti_vir1.rad.co.il (localhost [127.0.0.1]) by anti_vir1.rad.co.il (8.9.3+Sun/8.9.3) with ESMTP id TAA28220 for ; Mon, 26 Feb 2001 19:02:08 +0200 (IST) Received: from radmail.rad.co.il (radmail [192.114.26.108]) by anti_vir1.rad.co.il (8.9.3+Sun/8.9.3) with ESMTP id TAA28216 for ; Mon, 26 Feb 2001 19:02:08 +0200 (IST) Received: from yaron ([172.17.200.73]) by radmail.rad.co.il (Post.Office MTA v3.5.3 release 223 ID# 0-69802U1300L1200S0V35) with SMTP id il for ; Mon, 26 Feb 2001 18:05:57 +0200 Reply-To: From: "Yaron Klein" To: Subject: Draft 04 remarks Date: Mon, 26 Feb 2001 17:03:19 -0000 Message-ID: <000001c0a016$06cff2f0$49c811ac@sanrad.co.il> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by ece.cmu.edu id f1QH4ND20513 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA21990 Julian, Some remarks (protocol and typos) for version 04: Section 1.2.3 says: “Any message except login and text reaching a target on a TCP connection before the full feature phase MUST be silently ignored by the target.” However, the reject message state the possibility for “full feature phase before login (15)” in section 2.20.1. I suggest changing it to: Any message except login and text reaching a target on a TCP connection before the full feature phase MAY be silently ignored by the target, or reported to the initiator by a reject message. Section 2.2 says “Each segment is preceded by a 4 byte Next-Qualifier.” Should be: Each Header Segment”. Data segment doesn’t need a qualifier. In section 2.4, the SCSI response scheme states the sense data as part of the BHS. It should be part of the AHS or the data segment. Section 2.4.2 says: “If a SCSI device error is detected while data from the initiator are still expected (the command PDU did not contain all the data and the target has not received a Data PDU with the final bit Set) the target MUST wait until it receives the a Data PDU with the F bit set before sending the Response PDU.” This means that any outstanding R2Ts must be closed before issuing a bad response. How can one set a timer for the end of data transfer in such a situation? The target might wait forever if it must wait for the data PDU before issuing a response. Besides, why wait for redundant data to reach the target when the target already knows that it is going to fail the command? In 2.4.2, a response status code is “3 - Unsolicited data rejected”. However, chapter 1 instructs a target to terminate the session if it experiences an initiator violating the agreed upon values for unsolicited data. Section 2.4.5: SR-length states the sense data length. However, if it is a data segment, it should be in the data length field in the WN. Section 2.7.3 says: “...or by the Target Task Tag and LUN (for data solicited through R2T).” Should clarify that the DataSN starts from 0 for each R2T. Section 2.7.5 says: “b7 P (poll)”, should be F bit - P was removed. Section 2.8.3 says: “If the Text Response does not contain a key that was requested, the initiator must assume that the key was not understood by the target”. In previous chapter it was determined that not responding equal none. The phrase should combine these. 2.10.5 says that “CIDs MUST NOT be reused during the life of a session (every connection ever used in a session MUST have a unique CID)” but a Login Command with the retry bit, allows using the same CID. Section 2.11.4, redirections, says: “...All of the 3 status class”. Should be: “all of the Status-Detail responses MUST …”. In section 2.11.5, “A 0 in the returned TSID indicates that either the target supports only a single connection or that the ISID has already been used as a leading ISID.” Since we already have error codes (Status-Class/Status-Detail) it is much better to add the error using them instead of encoding it in the TSID field. Besides, this is an Initiator Error (class = 2) but we do not have a matching Status-Detail code. In section 2.12.2, “The LUN field MUST be set whenever the Target Transfer Tag is set”. This is a ping command, there are no LUNs in here. In 2.12.4, “The NOP-Out MUST have the Target Tag set only if it issued in response to a NOP-In or a Data-IN...”. Data In was removed, should only be for NOP In. And then “When the Target Transfer Tag is set the LUN field must have the correct value for the task.” Again, no LUNs required here. In section 2.14, “.On sessions with a single connection, this might imply opening a second connection with the sole purpose of cleaning-up the first.” This means that the logout command is sent on the same connection that is to be loged out. But the connection is bad (isn’t this the reason for closing it) so how can we send a command on a bad connection? Another thing is if we first logout the connection it means that the session has no connections hence it must be terminated. I think that since Login Command with a retry has been suggested this should be the only way to replace a connection. Section 1.2.3 says: “The target indicates a successful authentication and authorization by sending a login response with "login accept". Otherwise, it sends a response with a "login reject", indicating a session is not established.” Should be updated to the new statuses. Section 2.3.4 says”... this field will contain the last input DataSN number seen by the initiator”. If the initiator received packets 1,2 and 5, it should acknowledge just number 2 and not 5. Otherwise 3 and 4 will be considered as acked. Should be “the last DataSN in a sequence”. Also in 2.4.7. In 2.11, login response code should be 0x43 and not 0x83. Also says: “The Login Response indicates the end of the login phase.” Can also be partial response, so it does not necessary indicates the end of the phase. Section 2.4.8 says: “For responses sent because of retry the StatSN used MUST be the same as the first time the PDU was sent unless the connection was restarted since then.” This implies that a retry can be send on the same connection. However, this is what we have SACK now. Therefore, the protocol should define SACK for this purpose. Yaron From owner-ips@ece.cmu.edu Mon Feb 26 14:11:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22106 for ; Mon, 26 Feb 2001 14:11:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1QH1TE20318 for ips-outgoing; Mon, 26 Feb 2001 12:01:29 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1QH0t120274 for ; Mon, 26 Feb 2001 12:00:55 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id SAA33512 for ; Mon, 26 Feb 2001 18:00:47 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id SAA115640 for ; Mon, 26 Feb 2001 18:00:05 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569FF.005D264A ; Mon, 26 Feb 2001 17:57:26 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Mon, 26 Feb 2001 18:57:11 +0200 Subject: Re: iscsi.04 comments Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Sandeep, 1) - quote from the 2.8.3 Some basic key=value pairs are described in Appendix A & D. All these keys except the X- extension formatted MUST be supported by iSCSI initiators and targets. 2)the WN is allways for the next - BHS by itself does not need a WN - it is allways the first and you know what it is and how long it is (44 bytes) 3)I will qualify it with within a connection (I thought it was obvious but probably it is not). 4)It is not ambiguous but I see your point - I will try to make it uniform (either all 0 or all 0x'ffffffff') Thanks, Julo Sandeep Joshi on 26/02/2001 18:03:37 Please respond to Sandeep Joshi To: ips@ece.cmu.edu cc: Subject: iscsi.04 comments Julian, A few questions/comments.. 1) The following suggestion seems to be missing from this draft http://ips.pdl.cs.cmu.edu/mail/msg03273.html 2) There is a WN before the BHS and every AHS. So what are the WN bits (6-4) for a BHS ? Right now, there is 0=ext_cdb, 1=bidi, 2=longdata. All the other values (3-7) seem to be reserved. 3) Section 2.17 R2T - see statement before the fig. "outstanding R2T MUST be fulfilled by the initiator in the order they were received". Is this _within_ a command or connection or session. I presume its not within a session. Could you please qualify and disambiguate? 4) In Section 2.5 & Sec 2.6 for TaskMgmt commands the RefTaskTag, if reserved, is to be set to zero. In other commands (e.g. NOP-OUT), an invalid task tag is indicated by 0xffffffff. How about making it uniform throughout as 0xff... (or maybe this is an oversight) -Sandeep From owner-ips@ece.cmu.edu Mon Feb 26 16:19:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27988 for ; Mon, 26 Feb 2001 16:19:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1QIsMk27726 for ips-outgoing; Mon, 26 Feb 2001 13:54:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1QIrR127664 for ; Mon, 26 Feb 2001 13:53:28 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f1QK32028005; Mon, 26 Feb 2001 12:03:03 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: , Subject: RE: Draft 04 remarks Date: Mon, 26 Feb 2001 10:52:06 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <000001c0a016$06cff2f0$49c811ac@sanrad.co.il> Sender: owner-ips@ece.cmu.edu Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by ece.cmu.edu id f1QIsMl27726 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA27988 Yaron, You would need to include CID within SACK as a means of jumping connections as StatSN is not unique session wide. Doug > Section 2.4.8 says: “For responses sent because of retry the StatSN used > MUST be the same as the first time the PDU was sent unless the connection > was restarted since then.” This implies that a retry can be send > on the same > connection. However, this is what we have SACK now. Therefore, > the protocol > should define SACK for this purpose. > > Yaron > From owner-ips@ece.cmu.edu Mon Feb 26 16:24:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27987 for ; Mon, 26 Feb 2001 16:19:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1QJVMo00256 for ips-outgoing; Mon, 26 Feb 2001 14:31:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1QJUT100196 for ; Mon, 26 Feb 2001 14:30:30 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id UAA197248 for ; Mon, 26 Feb 2001 20:30:18 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id UAA34742 for ; Mon, 26 Feb 2001 20:29:36 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569FF.006B0A9F ; Mon, 26 Feb 2001 20:29:10 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu cc: Dafna_Sheinwald@il.ibm.com Message-ID: Date: Mon, 26 Feb 2001 21:30:36 +0200 Subject: iSCSI CRC considerations Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear colleagues, Dafna Sheinwald and myself have prepared a draft detailing some considerations for selecting a CRC and it's relation to the iSCSI data PDU lengths. We will submit it to the I-D as soon as opens again. Meanwhile you can read it at: http://www.haifa.il.ibm.com/satran/ips/draft-sheinwald-iSCSI-CRC-00.txt Formulas look a bit strange - but that's all we knew how to do with pure ASCII text. Julo From owner-ips@ece.cmu.edu Mon Feb 26 18:20:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03474 for ; Mon, 26 Feb 2001 18:20:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1QKkNo05410 for ips-outgoing; Mon, 26 Feb 2001 15:46:23 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1QKjg105366 for ; Mon, 26 Feb 2001 15:45:42 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id VAA35216 for ; Mon, 26 Feb 2001 21:45:35 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id VAA57334 for ; Mon, 26 Feb 2001 21:44:54 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569FF.0071EC65 ; Mon, 26 Feb 2001 21:44:20 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Mon, 26 Feb 2001 22:45:47 +0200 Subject: Re: Draft 04 remarks Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=GCmSGqPM9h5D0Smo2x8AH44BibTM5pBb9RBbT7d9naQWrnAqD0Rlb32K" Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk --0__=GCmSGqPM9h5D0Smo2x8AH44BibTM5pBb9RBbT7d9naQWrnAqD0Rlb32K Content-type: text/plain; charset=us-ascii Content-Disposition: inline Comments in text - Julo Thanks, Julo "Yaron Klein" on 26/02/2001 19:03:19 Please respond to klein@sanrad.com To: ips@ece.cmu.edu cc: Subject: Draft 04 remarks --0__=GCmSGqPM9h5D0Smo2x8AH44BibTM5pBb9RBbT7d9naQWrnAqD0Rlb32K Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Julian, Some remarks (protocol and typos) for version 04: Section 1.2.3 says: ?Any message except login and text reaching a targe= t on a TCP connection before the full feature phase MUST be silently ignored= by the target.? However, the reject message state the possibility for ?full feature pha= se before login (15)? in section 2.20.1. I suggest changing it to: Any message except login and text reaching a target on a TCP connection= before the full feature phase MAY be silently ignored by the target, or= reported to the initiator by a reject message. +++ in fact it MUST be rejected - that is a slip - it stayed over from= older versions +++ Section 2.2 says ?Each segment is preceded by a 4 byte Next-Qualifier.?= Should be: Each Header Segment?. Data segment doesn?t need a qualifier.= +++ OK +++ In section 2.4, the SCSI response scheme states the sense data as part = of the BHS. It should be part of the AHS or the data segment. +++ if you are refering to the figure - the digests remove the ambiguit= y if there is one. And BTW today we don't have any AHS on responses +++ Section 2.4.2 says: ?If a SCSI device error is detected while data from= the initiator are still expected (the command PDU did not contain all the d= ata and the target has not received a Data PDU with the final bit Set) the target MUST wait until it receives the a Data PDU with the F bit set be= fore sending the Response PDU.? This means that any outstanding R2Ts must be closed before issuing a ba= d response. How can one set a timer for the end of data transfer in such = a situation? The target might wait forever if it must wait for the data P= DU before issuing a response. Besides, why wait for redundant data to reac= h the target when the target already knows that it is going to fail the comma= nd? +++ the intent is a device error discovered - and the meaning of the ph= rase is to keep the status until all the data have arrived. If in addition t= o the device error you have also a channel error then you will have to timeout and take more drastic optio= n. Again the statement is to mandate sending the status only after the cha= nnel is clear. If that rule is not enforced and tags are reused some bad things may ha= ppen ++++ In 2.4.2, a response status code is ?3 - Unsolicited data rejected?. However, chapter 1 instructs a target to terminate the session if it experiences an initiator violating the agreed upon values for unsolicit= ed data. ++++ after sending a reject +++ Section 2.4.5: SR-length states the sense data length. However, if it i= s a data segment, it should be in the data length field in the WN. +++ correct - this is an overlook - SR-length will be removed+++ Section 2.7.3 says: ?...or by the Target Task Tag and LUN (for data solicited through R2T).? Should clarify that the DataSN starts from 0 f= or each R2T. +++ It says so but I'll rephrase for clarity as follows: For output (write) data PDUs, the DataSN is the data PDU number (starti= ng with 0) within the current output sequence. The current output sequence= is identified by the Initiator Task Tag (for unsolicited data) or by the Target Task Tag and LUN (for data solicited through R2T). Section 2.7.5 says: ?b7 P (poll)?, should be F bit - P was removed. +++ was raised already and corrected +++ Section 2.8.3 says: ?If the Text Response does not contain a key that w= as requested, the initiator must assume that the key was not understood by= the target?. In previous chapter it was determined that not responding equa= l none. The phrase should combine these. +++ OK +++ 2.10.5 says that ?CIDs MUST NOT be reused during the life of a session (every connection ever used in a session MUST have a unique CID)? but a= Login Command with the retry bit, allows using the same CID. +++ will correct +++ Section 2.11.4, redirections, says: ?...All of the 3 status class?. Sho= uld be: ?all of the Status-Detail responses MUST ??. +++ it looks like an inversion - "all of the stauts class 3 responses" = will do +++ In section 2.11.5, ?A 0 in the returned TSID indicates that either the target supports only a single connection or that the ISID has already b= een used as a leading ISID.? Since we already have error codes (Status-Class/Status-Detail) it is mu= ch better to add the error using them instead of encoding it in the TSID field. Besides, this is an Initiator Error (class =3D 2) but we do not have a matching Status-Detail code. +++ Initiator | 0206 | 1 | Invalid ISID or single connection SID error | | | | | | ++++ corrected! In section 2.12.2, ?The LUN field MUST be set whenever the Target Trans= fer Tag is set?. This is a ping command, there are no LUNs in here. +++ If the target is using it it can use LUN 0 - the mistake is in NOP = in where it is missing++ In 2.12.4, ?The NOP-Out MUST have the Target Tag set only if it issued = in response to a NOP-In or a Data-IN...?. Data In was removed, should only= be for NOP In. And then ?When the Target Transfer Tag is set the LUN field must have t= he correct value for the task.? Again, no LUNs required here. +++ see above +++ In section 2.14, ?.On sessions with a single connection, this might imp= ly opening a second connection with the sole purpose of cleaning-up the first.? This means that the logout command is sent on the same connection that = is to be loged out. But the connection is bad (isn?t this the reason for clos= ing it) so how can we send a command on a bad connection? Another thing is = if we first logout the connection it means that the session has no connection= s hence it must be terminated. I think that since Login Command with a re= try has been suggested this should be the only way to replace a connection.= +++ logout can be sent on connection a to logout connection b +++ Section 1.2.3 says: ?The target indicates a successful authentication a= nd authorization by sending a login response with "login accept". Otherwis= e, it sends a response with a "login reject", indicating a session is not established.? +++1.2.3 explains login in broad terms - details follow later +++ Should be updated to the new statuses. Section 2.3.4 says?... this field will contain the last input DataSN nu= mber seen by the initiator?. If the initiator received packets 1,2 and 5, it should acknowledge just= number 2 and not 5. Otherwise 3 and 4 will be considered as acked. Shou= ld be ?the last DataSN in a sequence?. Also in 2.4.7. +++ will rephrase +++ In 2.11, login response code should be 0x43 and not 0x83. +++ will correct +++ Also says: ?The Login Response indicates the end of the login phase.? C= an also be partial response, so it does not necessary indicates the end of= the phase. +++ will rephrase +++ Section 2.4.8 says: ?For responses sent because of retry the StatSN use= d MUST be the same as the first time the PDU was sent unless the connecti= on was restarted since then.? This implies that a retry can be send on the= same connection. However, this is what we have SACK now. Therefore, the prot= ocol should define SACK for this purpose. +++ If there is no activity and the command is not acked the initiator = may try to retry it. If the task was completed (no data) this will result in the status bein= g resent +++ Yaron = --0__=GCmSGqPM9h5D0Smo2x8AH44BibTM5pBb9RBbT7d9naQWrnAqD0Rlb32K-- From owner-ips@ece.cmu.edu Mon Feb 26 19:55:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07336 for ; Mon, 26 Feb 2001 19:55:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1QMkUV13419 for ips-outgoing; Mon, 26 Feb 2001 17:46:30 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1QMk1113375 for ; Mon, 26 Feb 2001 17:46:02 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f1QNtZ028171; Mon, 26 Feb 2001 15:55:35 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: , Cc: Subject: RE: iSCSI CRC considerations Date: Mon, 26 Feb 2001 14:44:30 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, Page 14: "Adler [RFC1150] demands the expensive modulo operation with a very large prime, for the processing of each byte, or some test to indicate the necessity in that operation. Fletcher [FITS] only demands an addition, and can work on 16-bit at a time." Correction not RFC-1150 but these RFCs reference use of Adler-32: RFC-1950, RFC-1951, RFC-1952, RFC-1979, RFC-2394, RFC-2960. Your description of Adler-32 is incorrect with respect to implementation. #define BASE 65521 ... s1 += *buf++; if (s1 >= BASE) s1 -= BASE; s2 += s1; if (s2 >= BASE) s2 -= BASE; ... This can be done with without table lookup and the speed of calculation is faster than CRC. There is NO expensive modulo instruction for Adler-32. Doug From owner-ips@ece.cmu.edu Tue Feb 27 02:59:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01169 for ; Tue, 27 Feb 2001 02:59:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1R5qfK05986 for ips-outgoing; Tue, 27 Feb 2001 00:52:41 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1R5qX105976 for ; Tue, 27 Feb 2001 00:52:33 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id GAA32700 for ; Tue, 27 Feb 2001 06:52:30 +0100 From: julian_satran@il.ibm.com Received: from d12mta05.de.ibm.com (d12mta06_cs0 [9.165.222.255]) by d12relay02.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id GAA47170 for ; Tue, 27 Feb 2001 06:51:19 +0100 Received: by d12mta05.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A00.002044B9 ; Tue, 27 Feb 2001 06:52:27 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: "Douglas Otis" cc: ips@ece.cmu.edu, Dafna_Sheinwald@il.ibm.com Message-ID: Date: Tue, 27 Feb 2001 07:52:38 +0200 Subject: RE: iSCSI CRC considerations Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk thanks - Julo From owner-ips@ece.cmu.edu Tue Feb 27 08:33:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07678 for ; Tue, 27 Feb 2001 08:33:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RC1ij02365 for ips-outgoing; Tue, 27 Feb 2001 07:01:44 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1RC0j102311 for ; Tue, 27 Feb 2001 07:00:45 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id NAA64004 for ; Tue, 27 Feb 2001 13:00:41 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id MAA209470 for ; Tue, 27 Feb 2001 12:59:58 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A00.0041DC20 ; Tue, 27 Feb 2001 12:59:21 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Tue, 27 Feb 2001 14:00:50 +0200 Subject: Re: How should a target respond if it receives a TEXT command before a LOGIN? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk 1. A text command before the login... what for? In the normal sequence of events it could happen only if the Login command is dropped - and it is hard to see how this can happen. The login phase is a long linked set of commands (there can't be several outstanding) that have one singe Initiator task tag. Text before login is an error. 2. If I'll see another vote for a 0,1 flip in the WN - I'll change it (1 and 0 have equal weight with me and with many of the implementers close to me) -:) Julo Mark Burton on 27/02/2001 13:31:56 Please respond to Mark Burton To: ips@ece.cmu.edu cc: Subject: How should a target respond if it receives a TEXT command before a LOGIN? The choice seems to be one of: 1 - reject with format error -- not really true as the TEXT command may actually contain valid information 2 - reject with full feature phase error -- again, not really true as TEXT commands are allowed in the login phase 3 - just ignore -- unhelpful Any ideas? BTW - I second the proposal that the sense of the what-comes-next-is-a-data-segment bit in the WN word should be inverted. Regards, Mark From owner-ips@ece.cmu.edu Tue Feb 27 08:34:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07750 for ; Tue, 27 Feb 2001 08:34:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RBWlj01069 for ips-outgoing; Tue, 27 Feb 2001 06:32:47 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1RBW1101033 for ; Tue, 27 Feb 2001 06:32:01 -0500 (EST) Received: from ordern.demon.co.uk ([158.152.10.215]) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 14XiMI-000AOJ-0K for ips@ece.cmu.edu; Tue, 27 Feb 2001 11:31:59 +0000 Received: from localhost(rook.ordern.com[192.168.1.1]) (1002 bytes) by ordern.demon.co.uk via smtpd with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Tue, 27 Feb 2001 11:31:57 +0000 (GMT) (Smail-3.2.0.108 1999-Sep-19 #7 built 2000-Feb-18) To: ips@ece.cmu.edu Subject: How should a target respond if it receives a TEXT command before a LOGIN? X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (GTK) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010227113156Q.markb@ordern.com> Date: Tue, 27 Feb 2001 11:31:56 GMT From: Mark Burton X-Dispatcher: imput version 20000228(IM140) Lines: 21 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The choice seems to be one of: 1 - reject with format error -- not really true as the TEXT command may actually contain valid information 2 - reject with full feature phase error -- again, not really true as TEXT commands are allowed in the login phase 3 - just ignore -- unhelpful Any ideas? BTW - I second the proposal that the sense of the what-comes-next-is-a-data-segment bit in the WN word should be inverted. Regards, Mark From owner-ips@ece.cmu.edu Tue Feb 27 10:35:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12740 for ; Tue, 27 Feb 2001 10:35:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RCgjh04187 for ips-outgoing; Tue, 27 Feb 2001 07:42:45 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1RCgA104164 for ; Tue, 27 Feb 2001 07:42:10 -0500 (EST) Received: from ordern.demon.co.uk ([158.152.10.215]) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 14XjSC-000A2s-0B for ips@ece.cmu.edu; Tue, 27 Feb 2001 12:42:08 +0000 Received: from localhost(rook.ordern.com[192.168.1.1]) (961 bytes) by ordern.demon.co.uk via smtpd with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Tue, 27 Feb 2001 12:42:08 +0000 (GMT) (Smail-3.2.0.108 1999-Sep-19 #7 built 2000-Feb-18) To: ips@ece.cmu.edu Subject: logout command X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (GTK) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010227124207S.markb@ordern.com> Date: Tue, 27 Feb 2001 12:42:07 GMT From: Mark Burton X-Dispatcher: imput version 20000228(IM140) Lines: 19 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello again, A couple of issues re the logout command (section 2.14 of 04) > An initiator MAY use a logout command to remove a connection from a > session or to close an entire session. How is the entire session closed? there doesn't seem to be any option in the PDU that says "zap all the connections in this session" > This is the ExpStatSN for the connection to be closed. I don't understand the need for this, please explain. many thanks, Mark From owner-ips@ece.cmu.edu Tue Feb 27 11:26:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15537 for ; Tue, 27 Feb 2001 11:26:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1REPlB10215 for ips-outgoing; Tue, 27 Feb 2001 09:25:47 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1REPG110159 for ; Tue, 27 Feb 2001 09:25:25 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id PAA72276 for ; Tue, 27 Feb 2001 15:25:02 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id PAA153552 for ; Tue, 27 Feb 2001 15:24:09 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A00.004F0E59 ; Tue, 27 Feb 2001 15:23:30 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Tue, 27 Feb 2001 16:14:56 +0200 Subject: Re: logout command Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, 2.14.3 reason code 0 I will rephrase it to be more specific (like: 0 - closing the session ExpStaSN - when the connection is closed for recovery it tells the target what was the last StatSN it has seen as the target might not have seen previous acks and the initiator may think the target has seen them (this issue was raised a while ago by Pierre Labat. Julo Mark Burton on 27/02/2001 14:42:07 Please respond to Mark Burton To: ips@ece.cmu.edu cc: Subject: logout command Hello again, A couple of issues re the logout command (section 2.14 of 04) > An initiator MAY use a logout command to remove a connection from a > session or to close an entire session. How is the entire session closed? there doesn't seem to be any option in the PDU that says "zap all the connections in this session" > This is the ExpStatSN for the connection to be closed. I don't understand the need for this, please explain. many thanks, Mark From owner-ips@ece.cmu.edu Tue Feb 27 11:26:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15607 for ; Tue, 27 Feb 2001 11:26:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RDtmj08331 for ips-outgoing; Tue, 27 Feb 2001 08:55:48 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1RDtU108309 for ; Tue, 27 Feb 2001 08:55:31 -0500 (EST) Received: from ordern.demon.co.uk ([158.152.10.215]) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 14Xkb8-000DB3-0A for ips@ece.cmu.edu; Tue, 27 Feb 2001 13:55:26 +0000 Received: from localhost(rook.ordern.com[192.168.1.1]) (1668 bytes) by ordern.demon.co.uk via smtpd with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Tue, 27 Feb 2001 13:55:26 +0000 (GMT) (Smail-3.2.0.108 1999-Sep-19 #7 built 2000-Feb-18) Cc: ips@ece.cmu.edu Subject: Re: How should a target respond if it receives a TEXT command before a LOGIN? In-Reply-To: References: X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (GTK) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010227135526C.markb@ordern.com> Date: Tue, 27 Feb 2001 13:55:26 GMT From: Mark Burton X-Dispatcher: imput version 20000228(IM140) Lines: 32 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit From: julian_satran@il.ibm.com Subject: Re: How should a target respond if it receives a TEXT command before a LOGIN? Date: Tue, 27 Feb 2001 14:00:50 +0200 > > > 1. A text command before the login... what for? > > In the normal sequence of events it could happen only if the Login command > is dropped - and > it is hard to see how this can happen. > > The login phase is a long linked set of commands (there can't be several > outstanding) that have one singe Initiator task tag. > Text before login is an error. I realise that it is an error, what I want to know is, what is the "approved" error response that the target should produce if this situation occurs? IMHO, a robust iSCSI implementation must be able to respond appropriately to an out of order command that has been sent to it by an initiator. It's no good saying that it should never occur because the specification disallows it. Remember, if it is possible for something bad to happen then it WILL happen. Regards, Mark From owner-ips@ece.cmu.edu Tue Feb 27 13:52:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23540 for ; Tue, 27 Feb 2001 13:52:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RGcof18932 for ips-outgoing; Tue, 27 Feb 2001 11:38:50 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f1P4k1116161 for ; Sat, 24 Feb 2001 23:46:02 -0500 (EST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Sat Feb 24 23:45:58 EST 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Sat Feb 24 23:45:58 EST 2001 Received: (from sandeepj@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id XAA11105 for ips@ece.cmu.edu; Sat, 24 Feb 2001 23:45:57 -0500 (EST) Date: Sat, 24 Feb 2001 23:45:57 -0500 (EST) Message-Id: <200102250445.XAA11105@aura.research.bell-labs.com> From: sandeepj@research.bell-labs.com (Sandeep Joshi) To: ips@ece.cmu.edu Subject: 04 draft comments Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Julian, A few questions/comments.. 1) The following suggestion seems to be missing from the draft http://ips.pdl.cs.cmu.edu/mail/msg03273.html 2) There is a WN before the BHS and every AHS. So what are the WN bits 6-4 for a BHS ? Right now, there is 0=ext_cdb, 1=bidi, 2=longdata. All the other values seem to be reserved. 3) Section 2.17 R2T - see statement before the fig. "outstanding R2T MUST be fulfilled by the initiator in the order they were received". Is this _within_ a command or connection or session. I presume its not within a session. Could you please qualify and disambiguate? 4) In Section 2.5 & Sec 2.6 for TaskMgmt commands the RefTaskTag, if reserved, is to be set to zero. In other commands (e.g. NOP-OUT), an invalid task tag is indicated by 0xffffffff. How about making it uniform throughout as 0xff... (maybe this is an oversight) 5) statSN seems to be missing at byte 20 in R2T (Sec 2.17) Any particular reason? 6) In Section 2.8.1, a minor correction "When set to 1 it indicates that his is the last.." ^^^ lets make that "this" for a gender-neutral protocol :-) -Sandeep From owner-ips@ece.cmu.edu Tue Feb 27 13:53:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23641 for ; Tue, 27 Feb 2001 13:53:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RGfs519160 for ips-outgoing; Tue, 27 Feb 2001 11:41:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1QC5P102894 for ; Mon, 26 Feb 2001 07:05:25 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04470; Mon, 26 Feb 2001 07:05:23 -0500 (EST) Message-Id: <200102261205.HAA04470@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-04.txt Date: Mon, 26 Feb 2001 07:05:22 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Author(s) : J. Satran et al. Filename : draft-ietf-ips-iscsi-04.txt Pages : 114 Date : 23-Feb-01 The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. This memo describes a transport protocol for SCSI that operates on top of TCP. The iSCSI protocol aims to be fully compliant with the requirements laid out in the SCSI Architecture Model - 2 [SAM2] document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010223130627.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010223130627.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Feb 27 13:54:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23683 for ; Tue, 27 Feb 2001 13:54:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RGdpg18996 for ips-outgoing; Tue, 27 Feb 2001 11:39:51 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f1PLxj112300 for ; Sun, 25 Feb 2001 16:59:46 -0500 (EST) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Sun Feb 25 16:57:48 EST 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Sun Feb 25 16:59:31 EST 2001 Received: (from sandeepj@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id QAA03423 for ips@ece.cmu.edu; Sun, 25 Feb 2001 16:59:30 -0500 (EST) Date: Sun, 25 Feb 2001 16:59:30 -0500 (EST) Message-Id: <200102252159.QAA03423@aura.research.bell-labs.com> From: sandeepj@research.bell-labs.com (Sandeep Joshi) To: ips@ece.cmu.edu Subject: 04 draft comments Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, A few questions/comments.. 1) The following suggestion on seems to be missing from the draft http://ips.pdl.cs.cmu.edu/mail/msg03273.html 2) There is a WN before the BHS and every AHS. So what are the WN bits (6-4) for a BHS ? Right now, there is 0=ext_cdb, 1=bidi, 2=longdata. All the other values (3-7) seem to be reserved. 3) Section 2.17 R2T - see statement before the fig. "outstanding R2T MUST be fulfilled by the initiator in the order they were received". Is this _within_ a command or connection or session. I presume its not within a session. Could you please qualify and disambiguate? 4) In Section 2.5 & Sec 2.6 for TaskMgmt commands the RefTaskTag, if reserved, is to be set to zero. In other commands (e.g. NOP-OUT), an invalid task tag is indicated by 0xffffffff. How about making it uniform throughout as 0xff... (or maybe this is an oversight) -Sandeep From owner-ips@ece.cmu.edu Tue Feb 27 15:34:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28341 for ; Tue, 27 Feb 2001 15:34:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RIAqV25020 for ips-outgoing; Tue, 27 Feb 2001 13:10:52 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f1RIA5124950 for ; Tue, 27 Feb 2001 13:10:06 -0500 (EST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Tue Feb 27 13:08:45 EST 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Tue Feb 27 13:08:44 EST 2001 Received: from lucent.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90]) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id NAA26783 for ; Tue, 27 Feb 2001 13:08:44 -0500 (EST) Message-ID: <3A9BED2C.45AC5B03@lucent.com> Date: Tue, 27 Feb 2001 13:08:44 -0500 From: Sandeep Joshi X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iscsi.04 comments Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > 1) - quote from the 2.8.3 > > Some basic key=value pairs are described in Appendix A & D. All these > keys except the X- extension formatted MUST be supported by iSCSI > initiators and targets. oops. missed that.. > > 2)the WN is allways for the next - BHS by itself does not need a WN - it > is allways the first and you know what it is and how long it is (44 > bytes) Btw, there is a WN before the BHS in Sec 2.2 in the figure named "Overall structure of PDU". That caused the confusion. Some more notes: 1) Yaron Klein pointed out that the Login Response code was wrong. Similar typos exist in the PDU outlines shown for many other target messages : Nop-In (0x80), R2T(0x90), Logout Response, AsyncMessage and Reject. These opcodes dont match with Sec 2.2.4.2 2) Sec 2.7 - typical PDU for read at byte 20 has (statSN OR reserved) For reads, the statSN field would always be present so reserved can be removed from this example. The field is shown reserved in the write data PDU. 3) Have we decided/mandated which Text parameters are going to be connection-specific ? I may have missed a reference to this in the draft. 4) Furthermore, if an existing connection (full-feature mode) is used for recovering a failed connection, is the initiator allowed to negotiate ANY list(TextCmd) parameters during the login restart ? I guess the two connections (old & new) have to be compatible with respect to certain parameters, otherwise command restarts or data PDU acks may have a problem (since maxR2T, immediateData limits, etc could be different) -Sandeep > > > > To: ips@ece.cmu.edu > > cc: > > Subject: iscsi.04 comments > > > > Julian, > > > > A few questions/comments.. > > > > 1) The following suggestion seems to be missing from > > this draft > > http://ips.pdl.cs.cmu.edu/mail/msg03273.html > > > > 2) There is a WN before the BHS and every AHS. > > So what are the WN bits (6-4) for a BHS ? > > Right now, there is 0=ext_cdb, 1=bidi, 2=longdata. > > All the other values (3-7) seem to be reserved. > > > > 3) Section 2.17 R2T - see statement before the fig. > > "outstanding R2T MUST be fulfilled by the initiator > > in the order they were received". > > Is this _within_ a command or connection or session. > > I presume its not within a session. > > Could you please qualify and disambiguate? > > > > 4) In Section 2.5 & Sec 2.6 for TaskMgmt commands the > > RefTaskTag, if reserved, is to be set to zero. > > In other commands (e.g. NOP-OUT), an invalid task tag is > > indicated by 0xffffffff. How about making it uniform > > throughout as 0xff... (or maybe this is an oversight) > > > > -Sandeep > > From owner-ips@ece.cmu.edu Tue Feb 27 15:34:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28374 for ; Tue, 27 Feb 2001 15:34:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RIgxE27181 for ips-outgoing; Tue, 27 Feb 2001 13:42:59 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1RIgD127131 for ; Tue, 27 Feb 2001 13:42:14 -0500 (EST) Received: from catalina.almaden.ibm.com (catalina.almaden.ibm.com [9.1.24.58]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id KAA24150; Tue, 27 Feb 2001 10:42:00 -0800 Received: (from dfsmith@localhost) by catalina.almaden.ibm.com (AIX4.3/8.9.3/8.7) id KAA25656; Tue, 27 Feb 2001 10:42:07 -0800 From: Daniel Smith Message-Id: <200102271842.KAA25656@catalina.almaden.ibm.com> Subject: Re: How should a target respond if it receives a TEXT command To: markb@ordern.com (Mark Burton) Date: Tue, 27 Feb 2001 10:42:07 -0800 (PST) Cc: ips@ece.cmu.edu In-Reply-To: <20010227135526C.markb@ordern.com> from "Mark Burton" at Feb 27, 2001 01:55:26 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark Burton wrote: > > I realise that it is an error, what I want to know is, what is the > "approved" error response that the target should produce if this > situation occurs? If I were the target, I'd drop the TCP connection because the initiator is obviously not talking iSCSI. (On the premise that dropping the connection is probably better than sending back something that could be misinterpreted.) -- IBM Almaden Research Center, 650 Harry Road, San Jose, CA 95120-6099, USA From owner-ips@ece.cmu.edu Tue Feb 27 15:34:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28429 for ; Tue, 27 Feb 2001 15:34:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RJ5v628611 for ips-outgoing; Tue, 27 Feb 2001 14:05:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1RJ5a128589 for ; Tue, 27 Feb 2001 14:05:36 -0500 (EST) Received: from ordern.demon.co.uk ([158.152.10.215]) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 14XpRG-000GEB-0W for ips@ece.cmu.edu; Tue, 27 Feb 2001 19:05:35 +0000 Received: from localhost(rook.ordern.com[192.168.1.1]) (1517 bytes) by ordern.demon.co.uk via smtpd with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Tue, 27 Feb 2001 19:05:34 +0000 (GMT) (Smail-3.2.0.108 1999-Sep-19 #7 built 2000-Feb-18) to: ips@ece.cmu.edu Subject: Re: How should a target respond if it receives a TEXT command In-Reply-To: <200102271842.KAA25656@catalina.almaden.ibm.com> References: <20010227135526C.markb@ordern.com> <200102271842.KAA25656@catalina.almaden.ibm.com> X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (GTK) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010227190534L.markb@ordern.com> Date: Tue, 27 Feb 2001 19:05:34 GMT From: Mark Burton X-Dispatcher: imput version 20000228(IM140) Lines: 25 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit From: Daniel Smith Subject: Re: How should a target respond if it receives a TEXT command Date: Tue, 27 Feb 2001 10:42:07 -0800 (PST) > Mark Burton wrote: > > > > I realise that it is an error, what I want to know is, what is the > > "approved" error response that the target should produce if this > > situation occurs? > > If I were the target, I'd drop the TCP connection because the initiator is > obviously not talking iSCSI. (On the premise that dropping the connection > is probably better than sending back something that could be > misinterpreted.) > -- > IBM Almaden Research Center, 650 Harry Road, San Jose, CA 95120-6099, USA > That sounds reasonable to me. If the initiator is broken enough to send a TEXT before a LOGIN then it deserves to be ditched. Thanks, Mark From owner-ips@ece.cmu.edu Tue Feb 27 15:38:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28547 for ; Tue, 27 Feb 2001 15:38:25 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RIcrj26895 for ips-outgoing; Tue, 27 Feb 2001 13:38:53 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1RIc5126836 for ; Tue, 27 Feb 2001 13:38:06 -0500 (EST) Received: from colosus2.cup.hp.com (colosus2.cup.hp.com [15.13.128.145]) by palrel3.hp.com (Postfix) with ESMTP id 6089CDE2 for ; Tue, 27 Feb 2001 10:37:45 -0800 (PST) Received: from hp.com (IDENT:plabat@pl703521.cup.hp.com [15.13.133.216]) by colosus2.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id KAA09312; Tue, 27 Feb 2001 10:37:43 -0800 (PST) Message-ID: <3A9BF422.33500A41@hp.com> Date: Tue, 27 Feb 2001 10:38:26 -0800 From: Pierre Labat Organization: Hewlett Packard ATM-SISL X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: iSCSI: naming/LUN views Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark (Bakke), After going through the naming/discovery drafts, a question came to my mind: Does several connections flowing through several portals but using the same initiator WWUI and target WWUI will see the same thing on the target? I mean by same thing: same LUs associated to the same LUNs. I guess that the initiator WWUI acts as an transportID (SCSI access control) and gives the same LUs view independently of the portal used. Is it the case? If it is not the case, the entity that creates multiconnections sessions will need out of band information to know if the 2 portals can be used for a same session or will have to do the painfull job to compare the LU views from the two portals with no guarantee that the views could not change in the future. Regards, Pierre From owner-ips@ece.cmu.edu Tue Feb 27 15:38:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28559 for ; Tue, 27 Feb 2001 15:38:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RJ62N28621 for ips-outgoing; Tue, 27 Feb 2001 14:06:02 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1RJ4s128524 for ; Tue, 27 Feb 2001 14:04:55 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.132.205]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA47574; Tue, 27 Feb 2001 13:57:33 -0500 Received: from f3n42e (d03nm042h.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id MAA185432; Tue, 27 Feb 2001 12:04:38 -0700 Importance: Normal Subject: Re: iSCSI: naming/LUN views To: Pierre Labat Cc: ips@ece.cmu.edu From: "Jim Hafner" Date: Tue, 27 Feb 2001 11:04:36 -0800 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 02/27/2001 11:04:38 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Pierre, In my view, one should get the same LU view in your situation because there is effectively no other information by which the target might present a different view. Namely, the target (that creates/enforces the view) is the entity scoped by the TargetWWUI. It uses the Initiator WWUI to construct that LU view. That might be constructed by rules established via SCSI access controls (and yes, the InitiatorWWUI is the right mapping to TransportID though that has not been formalized anywhere yet). This has some interesting implications. Within the context of a single SESSION established through multiple connections, there is only the one I_T nexus. But we can also establish multiple sessions between the same InitiatorWWUI and TargetWWUI. As far as access controls are concerned, the views should be identical. As for other properties of I_T nexus', e.g., reservations, the jury is still out. Jim Hafner Pierre Labat @ece.cmu.edu on 02-27-2001 10:38:26 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI: naming/LUN views Mark (Bakke), After going through the naming/discovery drafts, a question came to my mind: Does several connections flowing through several portals but using the same initiator WWUI and target WWUI will see the same thing on the target? I mean by same thing: same LUs associated to the same LUNs. I guess that the initiator WWUI acts as an transportID (SCSI access control) and gives the same LUs view independently of the portal used. Is it the case? If it is not the case, the entity that creates multiconnections sessions will need out of band information to know if the 2 portals can be used for a same session or will have to do the painfull job to compare the LU views from the two portals with no guarantee that the views could not change in the future. Regards, Pierre From owner-ips@ece.cmu.edu Tue Feb 27 17:13:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02359 for ; Tue, 27 Feb 2001 17:13:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RK0vO02287 for ips-outgoing; Tue, 27 Feb 2001 15:00:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1RK0L102245 for ; Tue, 27 Feb 2001 15:00:21 -0500 (EST) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA06601; Tue, 27 Feb 2001 15:00:06 -0500 (EST) Message-ID: <3A9C076E.F52834D4@cisco.com> Date: Tue, 27 Feb 2001 14:00:46 -0600 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Jim Hafner CC: Pierre Labat , ips@ece.cmu.edu Subject: Re: iSCSI: naming/LUN views References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pierre- Sorry I took so long to reply; for some reason, I didn't receive your original message from the reflector. I agree with all of Jim's comments, but would state this one more strongly: A TargetWWUI MUST present exactly the same LU view to an InitiatorWWUI regardless of the portal on which it is accessed. This means that we have a method of identification at the target level, which we were missing (at least as a standard) from FC and parallel SCSI. This was our intent, and would solve the problem you stated of having to compare views. Perhaps we should add this statement to the document. -- Mark Jim Hafner wrote: > > Pierre, > > In my view, one should get the same LU view in your situation because there > is effectively no other information by which the target might present a > different view. Namely, the target (that creates/enforces the view) is the > entity scoped by the TargetWWUI. It uses the Initiator WWUI to construct > that LU view. That might be constructed by rules established via SCSI > access controls (and yes, the InitiatorWWUI is the right mapping to > TransportID though that has not been formalized anywhere yet). > > This has some interesting implications. Within the context of a single > SESSION established through multiple connections, there is only the one I_T > nexus. But we can also establish multiple sessions between the same > InitiatorWWUI and TargetWWUI. As far as access controls are concerned, the > views should be identical. As for other properties of I_T nexus', e.g., > reservations, the jury is still out. > > Jim Hafner > > Pierre Labat @ece.cmu.edu on 02-27-2001 10:38:26 AM > > Sent by: owner-ips@ece.cmu.edu > > To: ips@ece.cmu.edu > cc: > Subject: iSCSI: naming/LUN views > > Mark (Bakke), > > After going through the naming/discovery drafts, > a question came to my mind: > > Does several connections flowing through > several portals but using the same initiator WWUI > and target WWUI will see the same thing on the target? > I mean by same thing: same LUs associated to the same LUNs. > > I guess that the initiator WWUI acts as an transportID (SCSI access > control) > and gives the same LUs view independently of the portal used. > Is it the case? > > If it is not the case, the entity that creates multiconnections > sessions > will need out of band information to know if the 2 portals can be used > for a same session or will have to do the painfull job to compare the > LU views > from the two portals with no guarantee that the views could not change > in the future. > > Regards, > > Pierre -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Feb 27 17:14:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02370 for ; Tue, 27 Feb 2001 17:14:07 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RKhtj05106 for ips-outgoing; Tue, 27 Feb 2001 15:43:55 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1RKhg105088 for ; Tue, 27 Feb 2001 15:43:42 -0500 (EST) Received: from ordern.demon.co.uk ([158.152.10.215]) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 14XqyC-000BGW-0V for ips@ece.cmu.edu; Tue, 27 Feb 2001 20:43:40 +0000 Received: from localhost(rook.ordern.com[192.168.1.1]) (990 bytes) by ordern.demon.co.uk via smtpd with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Tue, 27 Feb 2001 20:43:39 +0000 (GMT) (Smail-3.2.0.108 1999-Sep-19 #7 built 2000-Feb-18) To: ips@ece.cmu.edu Subject: yet another login question X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (GTK) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010227204339D.markb@ordern.com> Date: Tue, 27 Feb 2001 20:43:39 GMT From: Mark Burton X-Dispatcher: imput version 20000228(IM140) Lines: 18 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello again, sorry to be a pest but I have another query re the login command: If an initiator opens a new connection and subsequently submits a login pdu that identifies an existing session that is already supporting the maximum number of connections, what error code should be returned to the initiator? Perhaps "target conflict", or maybe a new code yet to be defined like "No free connections". Apologies if this is covered in the spec but I have missed it. Thanks, Mark From owner-ips@ece.cmu.edu Tue Feb 27 18:43:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05159 for ; Tue, 27 Feb 2001 18:43:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RLpw209471 for ips-outgoing; Tue, 27 Feb 2001 16:51:58 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1RLpE109427 for ; Tue, 27 Feb 2001 16:51:14 -0500 (EST) Received: from colosus2.cup.hp.com (colosus2.cup.hp.com [15.13.128.145]) by palrel3.hp.com (Postfix) with ESMTP id 800C5E0A for ; Tue, 27 Feb 2001 13:49:30 -0800 (PST) Received: from hp.com (IDENT:plabat@pl703521.cup.hp.com [15.13.133.216]) by colosus2.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id NAA10776; Tue, 27 Feb 2001 13:43:29 -0800 (PST) Message-ID: <3A9C1FAB.8FB62A35@hp.com> Date: Tue, 27 Feb 2001 13:44:11 -0800 From: Pierre Labat Organization: Hewlett Packard ATM-SISL X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: naming/LUN views References: <3A9C076E.F52834D4@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark,Jim, Mark Bakke wrote: > Pierre- > > Sorry I took so long to reply; for some reason, I didn't receive > your original message from the reflector. > > I agree with all of Jim's comments, but would state this one > more strongly: > > A TargetWWUI MUST present exactly the same LU view to an > InitiatorWWUI regardless of the portal on which it is accessed. > > This means that we have a method of identification at the target > level, which we were missing (at least as a standard) from FC and > parallel SCSI. Perfect. > > > This was our intent, and would solve the problem you stated of > having to compare views. Perhaps we should add this statement > to the document. Yes, i think it has to be said explicitely. Regards, Pierre > > > -- > Mark > > Jim Hafner wrote: > > > > Pierre, > > > > In my view, one should get the same LU view in your situation because there > > is effectively no other information by which the target might present a > > different view. Namely, the target (that creates/enforces the view) is the > > entity scoped by the TargetWWUI. It uses the Initiator WWUI to construct > > that LU view. That might be constructed by rules established via SCSI > > access controls (and yes, the InitiatorWWUI is the right mapping to > > TransportID though that has not been formalized anywhere yet). > > > > This has some interesting implications. Within the context of a single > > SESSION established through multiple connections, there is only the one I_T > > nexus. But we can also establish multiple sessions between the same > > InitiatorWWUI and TargetWWUI. As far as access controls are concerned, the > > views should be identical. As for other properties of I_T nexus', e.g., > > reservations, the jury is still out. > > > > Jim Hafner > > > > Pierre Labat @ece.cmu.edu on 02-27-2001 10:38:26 AM > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: ips@ece.cmu.edu > > cc: > > Subject: iSCSI: naming/LUN views > > > > Mark (Bakke), > > > > After going through the naming/discovery drafts, > > a question came to my mind: > > > > Does several connections flowing through > > several portals but using the same initiator WWUI > > and target WWUI will see the same thing on the target? > > I mean by same thing: same LUs associated to the same LUNs. > > > > I guess that the initiator WWUI acts as an transportID (SCSI access > > control) > > and gives the same LUs view independently of the portal used. > > Is it the case? > > > > If it is not the case, the entity that creates multiconnections > > sessions > > will need out of band information to know if the 2 portals can be used > > for a same session or will have to do the painfull job to compare the > > LU views > > from the two portals with no guarantee that the views could not change > > in the future. > > > > Regards, > > > > Pierre > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 From owner-ips@ece.cmu.edu Tue Feb 27 18:45:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05201 for ; Tue, 27 Feb 2001 18:45:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RLavB08497 for ips-outgoing; Tue, 27 Feb 2001 16:36:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1RLaH108461 for ; Tue, 27 Feb 2001 16:36:17 -0500 (EST) Received: from ljoy ([10.0.0.18]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f1RMje029570; Tue, 27 Feb 2001 14:45:40 -0800 (PST) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: Cc: Subject: RE: iSCSI CRC considerations Date: Tue, 27 Feb 2001 13:34:46 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dafna, I simply said reference (by means of source libraries containing Adler-32) with respect to Deflate et. al. This protection is not for serial bursts as this is already detected by CRC-32. There is a trade-off with respect to performance. Types of errors within a network are influenced by gaps in current protection. If using software, then Adler-32 offers advantages in performance that could be suitable for remaining errors. Doug > Doug, > > We explicitly said that either modulo (as originally in RFC1950) or some > test (as you showed) is necessary. > (In fact, there is even a better tradeoff between (1) calculating > a maximal > number of additions that can be > made for sure before the modulo needs to be addressed at all, and (2) > taking the test for each input > char). > > RCF1951 and RFC1952 describe the popular DEFLATE format used in Gzip and > PKZIP, to which Adler > contributed valuably. They do not mention the Adler-32 checksum. The same > goes to RFC 1979 and RFC 2394. > > We agree that CRC is slower in software implementation than Adler-32. > But, Adler can detect much less errors, as we pointed out, than CRC. > There are too simple error patterns that are missed by Adler. > > Dafna Sheinwald. > > > > From owner-ips@ece.cmu.edu Tue Feb 27 20:28:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08483 for ; Tue, 27 Feb 2001 20:28:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RNUDY15643 for ips-outgoing; Tue, 27 Feb 2001 18:30:13 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1RAiI128841 for ; Tue, 27 Feb 2001 05:44:19 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id LAA60446; Tue, 27 Feb 2001 11:44:09 +0100 From: dafna@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id LAA84302; Tue, 27 Feb 2001 11:43:19 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A00.003ADA21 ; Tue, 27 Feb 2001 11:42:49 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: dotis@sanlight.net cc: ips@ece.cmu.edu Message-ID: Date: Tue, 27 Feb 2001 12:43:44 +0200 Subject: RE: iSCSI CRC considerations Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Doug, We explicitly said that either modulo (as originally in RFC1950) or some test (as you showed) is necessary. (In fact, there is even a better tradeoff between (1) calculating a maximal number of additions that can be made for sure before the modulo needs to be addressed at all, and (2) taking the test for each input char). RCF1951 and RFC1952 describe the popular DEFLATE format used in Gzip and PKZIP, to which Adler contributed valuably. They do not mention the Adler-32 checksum. The same goes to RFC 1979 and RFC 2394. We agree that CRC is slower in software implementation than Adler-32. But, Adler can detect much less errors, as we pointed out, than CRC. There are too simple error patterns that are missed by Adler. Dafna Sheinwald. From owner-ips@ece.cmu.edu Tue Feb 27 20:28:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08494 for ; Tue, 27 Feb 2001 20:28:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RNXMf15864 for ips-outgoing; Tue, 27 Feb 2001 18:33:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f1QJ22128208 for ; Mon, 26 Feb 2001 14:02:02 -0500 (EST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Mon Feb 26 14:01:59 EST 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Mon Feb 26 14:01:59 EST 2001 Received: from lucent.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90]) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id OAA22853 for ; Mon, 26 Feb 2001 14:01:58 -0500 (EST) Message-ID: <3A9AA826.FDDDFB50@lucent.com> Date: Mon, 26 Feb 2001 14:01:58 -0500 From: Sandeep Joshi X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iscsi.04 comments Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Sandeep, > > > 1) - quote from the 2.8.3 > > Some basic key=value pairs are described in Appendix A & D. All these > keys except the X- extension formatted MUST be supported by iSCSI > initiators and targets. missed that..! > > 2)the WN is allways for the next - BHS by itself does not need a WN - it > is allways the first and you know what it is and how long it is (44 > bytes) > the figure in sec 2.2 shows a WN before BHS. maybe that needs to be removed ? From owner-ips@ece.cmu.edu Tue Feb 27 20:28:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08505 for ; Tue, 27 Feb 2001 20:28:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RNPF715378 for ips-outgoing; Tue, 27 Feb 2001 18:25:15 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1RNOl115352 for ; Tue, 27 Feb 2001 18:24:47 -0500 (EST) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA10448 for ; Tue, 27 Feb 2001 18:24:41 -0500 (EST) Message-ID: <3A9C36FA.F9B7806F@cisco.com> Date: Tue, 27 Feb 2001 17:23:38 -0600 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: iSCSI: WN Field (draft -04) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian: Some questions on the WN field in draft -04. wrt. the bits used to encode the digest types on the header and/or data segment: 1. Why are these needed since the use of the digests is negotiated? 2. What should they be set to if one of the Kerberos digests are used? When a proprietary digest is used? Perhaps they could be changed to two one bit fields to indicate whether the digest is simply present or not. Also, I would also suggest inverting the meaning of the next header type bit (bit 7). Regards, Steve Senum From owner-ips@ece.cmu.edu Tue Feb 27 20:31:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08573 for ; Tue, 27 Feb 2001 20:31:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1RNhFJ16447 for ips-outgoing; Tue, 27 Feb 2001 18:43:15 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1RNgB116386 for ; Tue, 27 Feb 2001 18:42:15 -0500 (EST) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA05590 for ; Tue, 27 Feb 2001 18:42:04 -0500 (EST) Message-ID: <3A9C3B0D.7A7F8A5D@cisco.com> Date: Tue, 27 Feb 2001 17:41:01 -0600 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: iSCSI: Use of SRP (draft -04) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian: With respect to use of the SRP protocol for authentication, I think the current draft is incomplete. The SRP spec requires that values for the Prime Modulus value 'N' and the Generator value 'g' be sent by the authenticating entity as well as 's' and 'B' (or known through some other method). Look at RFC 2944 to see how telnet handles this. Also, if both Initiator and Target choose to authenticate with SRP, or if InitAuth=KERB5 and TargetAuth=srp, the same key names will be needed by both sides at the same time, resulting in the same key name appearing twice in the same text message. This will make it difficult for the receiver to know which key names goes with which authentication process, since there can be two going on at one time. Regards, Steve Senum From owner-ips@ece.cmu.edu Wed Feb 28 06:36:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01836 for ; Wed, 28 Feb 2001 06:36:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1S9USV14596 for ips-outgoing; Wed, 28 Feb 2001 04:30:28 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1S9U3114546 for ; Wed, 28 Feb 2001 04:30:03 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id KAA38268 for ; Wed, 28 Feb 2001 10:29:54 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id KAA83770 for ; Wed, 28 Feb 2001 10:29:09 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A01.00340BF7 ; Wed, 28 Feb 2001 10:28:29 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Wed, 28 Feb 2001 11:29:50 +0200 Subject: Re: logout command Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, Will - fix text - Julo Mark Burton on 27/02/2001 20:59:37 Please respond to Mark Burton To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: logout command Julo, Sorry to be dim, but can you please confirm that when a target receives a logout PDU with a reason code of 0 (closing the session) it should kill all of the connections associated with the session that receives the logout PDU (and kill the session as well). If that is true, the CID does not need to be specified when reason is 0. Also, the spec says "after logout the TCP connection must be closed at both ends". Please confirm that this means the TCP connection for the connection that was logged out is closed (which is not necessarily the same as the connection used to deliver the Logout request). Thanks, Mark --------------- From: julian_satran@il.ibm.com Subject: Re: logout command Date: Tue, 27 Feb 2001 16:14:56 +0200 > > > Mark, > > 2.14.3 reason code 0 > > I will rephrase it to be more specific (like: > > 0 - closing the session > > ExpStaSN - when the connection is closed for recovery it tells the target > what was the last > StatSN it has seen as the target might not have seen previous acks and the > initiator may think the target has seen them (this issue was raised a while > ago by Pierre Labat. > > Julo > > > Mark Burton on 27/02/2001 14:42:07 > > Please respond to Mark Burton > > To: ips@ece.cmu.edu > cc: > Subject: logout command > > > > > > Hello again, > > A couple of issues re the logout command (section 2.14 of 04) > > > An initiator MAY use a logout command to remove a connection from a > > session or to close an entire session. > > How is the entire session closed? there doesn't seem to be any option > in the PDU that says "zap all the connections in this session" > > > This is the ExpStatSN for the connection to be closed. > > I don't understand the need for this, please explain. > > many thanks, > > Mark > > > > From owner-ips@ece.cmu.edu Wed Feb 28 06:37:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01847 for ; Wed, 28 Feb 2001 06:37:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1S9IRj14080 for ips-outgoing; Wed, 28 Feb 2001 04:18:27 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1S9IJ114071 for ; Wed, 28 Feb 2001 04:18:19 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id KAA62908 for ; Wed, 28 Feb 2001 10:18:08 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id KAA64950 for ; Wed, 28 Feb 2001 10:17:24 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A01.0032FB26 ; Wed, 28 Feb 2001 10:16:50 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Wed, 28 Feb 2001 11:18:04 +0200 Subject: Re: iscsi.04 comments Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Sandeep, comments in text - Thanks,Julo Sandeep Joshi on 27/02/2001 20:08:44 Please respond to Sandeep Joshi To: ips@ece.cmu.edu cc: Subject: Re: iscsi.04 comments > > 1) - quote from the 2.8.3 > > Some basic key=value pairs are described in Appendix A & D. All these > keys except the X- extension formatted MUST be supported by iSCSI > initiators and targets. oops. missed that.. > > 2)the WN is allways for the next - BHS by itself does not need a WN - it > is allways the first and you know what it is and how long it is (44 > bytes) Btw, there is a WN before the BHS in Sec 2.2 in the figure named "Overall structure of PDU". That caused the confusion. +++ The WN before BHS refers to the next - as BHS is always there and is fixed in length +++ Some more notes: 1) Yaron Klein pointed out that the Login Response code was wrong. Similar typos exist in the PDU outlines shown for many other target messages : Nop-In (0x80), R2T(0x90), Logout Response, AsyncMessage and Reject. These opcodes dont match with Sec 2.2.4.2 +++ Thanks +++ 2) Sec 2.7 - typical PDU for read at byte 20 has (statSN OR reserved) For reads, the statSN field would always be present so reserved can be removed from this example. The field is shown reserved in the write data PDU. +++ No StatSN is set only if the S bit is 1. I will specify. 3) Have we decided/mandated which Text parameters are going to be connection-specific ? I may have missed a reference to this in the draft. +++ I would say that some are and some not. Out of thoseoutlined only the Markers are connection specific. I will add this - thanks. +++ 4) Furthermore, if an existing connection (full-feature mode) is used for recovering a failed connection, is the initiator allowed to negotiate ANY list(TextCmd) parameters during the login restart ? I guess the two connections (old & new) have to be compatible with respect to certain parameters, otherwise command restarts or data PDU acks may have a problem (since maxR2T, immediateData limits, etc could be different) +++There is a statement saying that only the leading connection can do this - I'll make it more specific as it relates to renegotiation also+++ -Sandeep > > > > To: ips@ece.cmu.edu > > cc: > > Subject: iscsi.04 comments > > > > Julian, > > > > A few questions/comments.. > > > > 1) The following suggestion seems to be missing from > > this draft > > http://ips.pdl.cs.cmu.edu/mail/msg03273.html > > > > 2) There is a WN before the BHS and every AHS. > > So what are the WN bits (6-4) for a BHS ? > > Right now, there is 0=ext_cdb, 1=bidi, 2=longdata. > > All the other values (3-7) seem to be reserved. > > > > 3) Section 2.17 R2T - see statement before the fig. > > "outstanding R2T MUST be fulfilled by the initiator > > in the order they were received". > > Is this _within_ a command or connection or session. > > I presume its not within a session. > > Could you please qualify and disambiguate? > > > > 4) In Section 2.5 & Sec 2.6 for TaskMgmt commands the > > RefTaskTag, if reserved, is to be set to zero. > > In other commands (e.g. NOP-OUT), an invalid task tag is > > indicated by 0xffffffff. How about making it uniform > > throughout as 0xff... (or maybe this is an oversight) > > > > -Sandeep > > From owner-ips@ece.cmu.edu Wed Feb 28 10:02:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08398 for ; Wed, 28 Feb 2001 10:02:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1SCsWg03487 for ips-outgoing; Wed, 28 Feb 2001 07:54:32 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1SCrV103449 for ; Wed, 28 Feb 2001 07:53:31 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id NAA108988 for ; Wed, 28 Feb 2001 13:53:21 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id NAA107062 for ; Wed, 28 Feb 2001 13:52:37 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A01.0046B04D ; Wed, 28 Feb 2001 13:52:06 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Wed, 28 Feb 2001 14:53:37 +0200 Subject: Re: yet another login question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark - you don't have to apologize. The 0300 (2.11.4) response is supposed to cover this type of error. If you and others feel that we have to be more specific - speak out loudly. Regards, Julo Mark Burton on 27/02/2001 22:43:39 Please respond to Mark Burton To: ips@ece.cmu.edu cc: Subject: yet another login question Hello again, sorry to be a pest but I have another query re the login command: If an initiator opens a new connection and subsequently submits a login pdu that identifies an existing session that is already supporting the maximum number of connections, what error code should be returned to the initiator? Perhaps "target conflict", or maybe a new code yet to be defined like "No free connections". Apologies if this is covered in the spec but I have missed it. Thanks, Mark From owner-ips@ece.cmu.edu Wed Feb 28 12:23:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14876 for ; Wed, 28 Feb 2001 12:23:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1SFjbg13133 for ips-outgoing; Wed, 28 Feb 2001 10:45:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1SFjD113087 for ; Wed, 28 Feb 2001 10:45:13 -0500 (EST) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA14388 for ; Wed, 28 Feb 2001 10:45:07 -0500 (EST) Message-ID: <3A9D1D2A.C9B2F832@cisco.com> Date: Wed, 28 Feb 2001 09:45:46 -0600 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: Fwd: I-D ACTION:draft-bakke-iscsi-wwui-urn-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : A URN Namespace for iSCSI World-Wide Unique > Identifiers > Author(s) : M. Bakke et al. > Filename : draft-bakke-iscsi-wwui-urn-00.txt > Pages : 6 > Date : 23-Feb-01 > > The iSCSI protocol provides a way for hosts to access SCSI devices > over an IP network. This document describes a Uniform Resource Name > (URN) namespace for naming iSCSI initiators and targets. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bakke-iscsi-wwui-urn-00.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-bakke-iscsi-wwui-urn-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-bakke-iscsi-wwui-urn-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Feb 28 12:25:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14957 for ; Wed, 28 Feb 2001 12:25:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1SF9e610710 for ips-outgoing; Wed, 28 Feb 2001 10:09:40 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1SD6C104005 for ; Wed, 28 Feb 2001 08:06:12 -0500 (EST) Received: from src-news.pa.dec.com (src-news.pa.dec.com [16.4.16.111]) by mail1.digital.com (8.9.2/8.9.3/WV2.0h) with ESMTP id FAA16044 for ; Wed, 28 Feb 2001 05:06:11 -0800 (PST) Received: by src-news.pa.dec.com; id FAA21432; Wed, 28 Feb 2001 05:04:55 -0800 (PST) Path: pa.dec.com!owner-ietf-redist From: Internet-Drafts@ietf.org Newsgroups: dec.mail.lists.ietf Subject: I-D ACTION:draft-ietf-ips-iscsi-name-disc-00.txt Date: 28 Feb 2001 05:04:54 -0800 Organization: Systems Research Center, Compaq Computer Corporation Lines: 80 Distribution: dec Message-ID: <200102281155.GAA02089@ietf.org> To: IETF-Announce:;;;;;;@pa.dec.com;;;;;;@pa.dec.com;;;;;;;;;;;;;;;;;;;;;;;;@pa.dec.com;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Cc: ips@ece.cmu.edu In-Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" X-Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id ED0863645 for ; Wed, 28 Feb 2001 08:04:46 -0500 (EST) Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Naming and Discovery Requirements Author(s) : M. Bakke et al. Filename : draft-ietf-ips-iscsi-name-disc-00.txt Pages : 32 Date : 27-Feb-01 This document describes the iSCSI [7] naming and discovery requirements. The requirements presented in this document have been agreed to by the members of the iSCSI naming and discovery team. This document complements the iSCSI IETF draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name-disc-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-name-disc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-name-disc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010227123316.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-name-disc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-name-disc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010227123316.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Feb 28 12:25:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14973 for ; Wed, 28 Feb 2001 12:25:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1SFhas12995 for ips-outgoing; Wed, 28 Feb 2001 10:43:36 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1SFhV112989 for ; Wed, 28 Feb 2001 10:43:31 -0500 (EST) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA12217 for ; Wed, 28 Feb 2001 10:43:25 -0500 (EST) Message-ID: <3A9D1CC4.D16DBD24@cisco.com> Date: Wed, 28 Feb 2001 09:44:04 -0600 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: Fwd: I-D ACTION:draft-bakke-iscsi-slp-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Finding iSCSI Targets and Name Servers Using SLP > Author(s) : M. Bakke et al. > Filename : draft-bakke-iscsi-slp-00.txt > Pages : 17 > Date : 23-Feb-01 > > The iSCSI protocol provides a way for hosts to access SCSI devices > over an IP network. This document defines the use of the Service > Location Protocol (SLP) by iSCSI hosts, devices, and name services, > along with the SLP service type templates that describe the services > they provide. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bakke-iscsi-slp-00.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-bakke-iscsi-slp-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-bakke-iscsi-slp-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Feb 28 13:12:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17146 for ; Wed, 28 Feb 2001 13:12:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1SG8dx14946 for ips-outgoing; Wed, 28 Feb 2001 11:08:39 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1SBtN100930 for ; Wed, 28 Feb 2001 06:55:23 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02089; Wed, 28 Feb 2001 06:55:22 -0500 (EST) Message-Id: <200102281155.GAA02089@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-name-disc-00.txt Date: Wed, 28 Feb 2001 06:55:22 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Naming and Discovery Requirements Author(s) : M. Bakke et al. Filename : draft-ietf-ips-iscsi-name-disc-00.txt Pages : 32 Date : 27-Feb-01 This document describes the iSCSI [7] naming and discovery requirements. The requirements presented in this document have been agreed to by the members of the iSCSI naming and discovery team. This document complements the iSCSI IETF draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name-disc-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-name-disc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-name-disc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010227123316.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-name-disc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-name-disc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010227123316.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Feb 28 13:12:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17168 for ; Wed, 28 Feb 2001 13:12:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1SGDcP15390 for ips-outgoing; Wed, 28 Feb 2001 11:13:38 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1SGCf115330 for ; Wed, 28 Feb 2001 11:12:41 -0500 (EST) Received: from ordern.demon.co.uk ([158.152.10.215]) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 14Y9DU-0002gn-0B; Wed, 28 Feb 2001 16:12:40 +0000 Received: from localhost(rook.ordern.com[192.168.1.1]) (3204 bytes) by ordern.demon.co.uk via smtpd with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Wed, 28 Feb 2001 16:12:39 +0000 (GMT) (Smail-3.2.0.108 1999-Sep-19 #7 built 2000-Feb-18) To: julian_satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: max connections exceeded (was yet another login question) In-Reply-To: References: X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (GTK) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010228161239J.markb@ordern.com> Date: Wed, 28 Feb 2001 16:12:39 GMT From: Mark Burton X-Dispatcher: imput version 20000228(IM140) Lines: 87 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julo, In general, I would prefer to have reasonably specific error codes rather than "catch alls". What do other people think? In this particular case it is arguable that the initiator is in error rather than the target because the maximum number of connections per session has been previously negotiated and, therefore, the initiator should not try and open a new connection. I therefore suggest: 0207 'No Free Connections' (or similar) Other login error situations not particularly well matched to the existing codes are: 1 - Connection duplicates a CID value already used in the session - I suggest: (0208 'Initiator CID Error') 2 - A mandatory parameter has not been specified but the F bit is set in a Login PDU. A helpful thing for the target to do in this situation would be to return the key(s) of the missing mandatory parameters in the data segment. This could be made an optional capability. I suggest: (0209 'Mandatory parameter missing') 3 - A value is specified for a session parameter that conflicts with a previously negotiated value (negotiated by the leading connection). A Reject response could be used in this situation (preferably with a new reject reason code). One other question is: how should a target respond if it receives a Login command on a connection that has already reach full feature phase? Rejecting the command seems obvious but with what code? Regards, Mark From: julian_satran@il.ibm.com Subject: Re: yet another login question Date: Wed, 28 Feb 2001 14:53:37 +0200 > > > Mark - you don't have to apologize. > > The 0300 (2.11.4) response is supposed to cover this type of error. > > If you and others feel that we have to be more specific - speak out loudly. > > Regards, > Julo > > > Mark Burton on 27/02/2001 22:43:39 > > Please respond to Mark Burton > > To: ips@ece.cmu.edu > cc: > Subject: yet another login question > > > > > > Hello again, > > sorry to be a pest but I have another query re the login command: > > If an initiator opens a new connection and subsequently submits a > login pdu that identifies an existing session that is already > supporting the maximum number of connections, what error code should > be returned to the initiator? Perhaps "target conflict", or maybe a > new code yet to be defined like "No free connections". > > Apologies if this is covered in the spec but I have missed it. > > Thanks, > > Mark > > > > > < From owner-ips@ece.cmu.edu Wed Feb 28 13:17:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17404 for ; Wed, 28 Feb 2001 13:17:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1SG8b314942 for ips-outgoing; Wed, 28 Feb 2001 11:08:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1SBwZ101066 for ; Wed, 28 Feb 2001 06:58:36 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02902; Wed, 28 Feb 2001 06:58:35 -0500 (EST) Message-Id: <200102281158.GAA02902@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-monia-ips-ifcpenc-00.txt Date: Wed, 28 Feb 2001 06:58:35 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : iFCP Encapsulation Goals and Requirements Author(s) : C. Monia Filename : draft-monia-ips-ifcpenc-00.txt Pages : Date : 27-Feb-01 This document specifies iFCP requirements and design goals applicable to a common FCIP/iFCP format for the encapsulation of Fibre Channel frames. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-monia-ips-ifcpenc-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-monia-ips-ifcpenc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-monia-ips-ifcpenc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010227123956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-monia-ips-ifcpenc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-monia-ips-ifcpenc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010227123956.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Feb 28 15:18:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22390 for ; Wed, 28 Feb 2001 15:18:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1SHrjT23688 for ips-outgoing; Wed, 28 Feb 2001 12:53:45 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from enigma.qlogic.com (216-231-2-10.qlc.com [216.231.2.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1SHr5123646 for ; Wed, 28 Feb 2001 12:53:06 -0500 (EST) Received: from thompson ([10.14.52.207]) by enigma.qlogic.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f1SHqvH03898 for ; Wed, 28 Feb 2001 09:52:57 -0800 (PST) From: mike.thompson@qlogic.com Reply-To: To: "'ips'" Subject: What happened to the Length field? Date: Wed, 28 Feb 2001 09:56:02 -0800 Message-ID: <25DF077EB401D311819E009027513B500FF494@LMGSERVER> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit In the latest version of the iSCSI spec, the total PDU length field has been dropped from the PDU header. This field significantly helps the parsing of the incoming iSCSI PDU stream without having to parse through several levels of headers to get to the next PDU. This is especially useful in cases where out of order data placement is being done. Mike Thompson QLogic Corporation, Roseville 11768 Atwood Rd. Suite 23 Auburn, CA 95603 Ph# 530.886.0601 x17 Fx# 530.886.0746 From owner-ips@ece.cmu.edu Wed Feb 28 17:19:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28593 for ; Wed, 28 Feb 2001 17:19:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1SJxg804604 for ips-outgoing; Wed, 28 Feb 2001 14:59:42 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sungod.ctsinc.net ([216.132.202.12]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1SJwu104559; Wed, 28 Feb 2001 14:58:56 -0500 (EST) Received: from wazoo ([216.132.202.101]) by sungod.ctsinc.net (Lotus Domino Release 5.0.2c) with ESMTP id 2001022815021130:773422 ; Wed, 28 Feb 2001 15:02:11 -0500 From: "Thomas Crowe" To: , Cc: Subject: RE: max connections exceeded (was yet another login question) Date: Wed, 28 Feb 2001 14:59:14 -0500 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010228161239J.markb@ordern.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MIMETrack: Itemize by SMTP Server on sungod/CTS(Release 5.0.2c |February 2, 2000) at 02/28/2001 03:02:11 PM, Serialize by Router on sungod/CTS(Release 5.0.2c |February 2, 2000) at 02/28/2001 03:02:13 PM Content-Type: multipart/mixed; boundary="----=_NextPart_000_0029_01C0A197.03AD5A40" Sender: owner-ips@ece.cmu.edu Precedence: bulk ------=_NextPart_000_0029_01C0A197.03AD5A40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Team; Working from the implementation side of the house. The more error codes the better, and the more verbosity the better. With any new technology, error conditions seem to be the last thing implemented, however in a troubleshooting scenario the error codes are the most important thing that we can have. The team has put together a very robust set of error conditions and error codes, but there should always be room for more. ____________________________________________ Thomas Crowe Technical Director, Research and Development CTS - Atlanta Office 770-664-3900 ext. 45 ____________________________________________ -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] Sent: Wednesday, February 28, 2001 11:13 AM To: julian_satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: max connections exceeded (was yet another login question) Julo, In general, I would prefer to have reasonably specific error codes rather than "catch alls". What do other people think? In this particular case it is arguable that the initiator is in error rather than the target because the maximum number of connections per session has been previously negotiated and, therefore, the initiator should not try and open a new connection. I therefore suggest: 0207 'No Free Connections' (or similar) Other login error situations not particularly well matched to the existing codes are: 1 - Connection duplicates a CID value already used in the session - I suggest: (0208 'Initiator CID Error') 2 - A mandatory parameter has not been specified but the F bit is set in a Login PDU. A helpful thing for the target to do in this situation would be to return the key(s) of the missing mandatory parameters in the data segment. This could be made an optional capability. I suggest: (0209 'Mandatory parameter missing') 3 - A value is specified for a session parameter that conflicts with a previously negotiated value (negotiated by the leading connection). A Reject response could be used in this situation (preferably with a new reject reason code). One other question is: how should a target respond if it receives a Login command on a connection that has already reach full feature phase? Rejecting the command seems obvious but with what code? Regards, Mark From: julian_satran@il.ibm.com Subject: Re: yet another login question Date: Wed, 28 Feb 2001 14:53:37 +0200 > > > Mark - you don't have to apologize. > > The 0300 (2.11.4) response is supposed to cover this type of error. > > If you and others feel that we have to be more specific - speak out loudly. > > Regards, > Julo > > > Mark Burton on 27/02/2001 22:43:39 > > Please respond to Mark Burton > > To: ips@ece.cmu.edu > cc: > Subject: yet another login question > > > > > > Hello again, > > sorry to be a pest but I have another query re the login command: > > If an initiator opens a new connection and subsequently submits a > login pdu that identifies an existing session that is already > supporting the maximum number of connections, what error code should > be returned to the initiator? Perhaps "target conflict", or maybe a > new code yet to be defined like "No free connections". > > Apologies if this is covered in the spec but I have missed it. > > Thanks, > > Mark > > > > > < ------=_NextPart_000_0029_01C0A197.03AD5A40 Content-Type: text/x-vcard; name="Thomas Crowe.vcf" Content-Disposition: attachment; filename="Thomas Crowe.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Crowe;Thomas FN:Thomas Crowe ORG:CTS TITLE:Technical Director TEL;WORK;VOICE:(770) 664-3900 TEL;WORK;FAX:(770) 664-3914 ADR;WORK:;;11600 Alpharetta Highway;Roswell;GA;30076;United States of Ameri= ca LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:11600 Alpharetta Highway=3D0D=3D0ARo= swell, GA 30076=3D0D=3D0AUnited States of Americ=3D a EMAIL;PREF;INTERNET:tcrowe@ctsinc.net REV:20010228T161349Z END:VCARD ------=_NextPart_000_0029_01C0A197.03AD5A40-- From owner-ips@ece.cmu.edu Wed Feb 28 17:21:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28675 for ; Wed, 28 Feb 2001 17:21:25 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1SKKhD06491 for ips-outgoing; Wed, 28 Feb 2001 15:20:43 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1SKK1106382 for ; Wed, 28 Feb 2001 15:20:01 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id VAA130544 for ; Wed, 28 Feb 2001 21:19:53 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay02.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id VAA95418 for ; Wed, 28 Feb 2001 21:18:37 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A01.006F9144 ; Wed, 28 Feb 2001 21:18:36 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Wed, 28 Feb 2001 22:20:06 +0200 Subject: Re: What happened to the Length field? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk It is in the NW now. Follow the new format (it was discussed on this list a while ago). Julo mike.thompson@qlogic.com on 28/02/2001 19:56:02 Please respond to mike.thompson@qlogic.com To: "'ips'" cc: Subject: What happened to the Length field? In the latest version of the iSCSI spec, the total PDU length field has been dropped from the PDU header. This field significantly helps the parsing of the incoming iSCSI PDU stream without having to parse through several levels of headers to get to the next PDU. This is especially useful in cases where out of order data placement is being done. Mike Thompson QLogic Corporation, Roseville 11768 Atwood Rd. Suite 23 Auburn, CA 95603 Ph# 530.886.0601 x17 Fx# 530.886.0746 From owner-ips@ece.cmu.edu Wed Feb 28 17:22:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28772 for ; Wed, 28 Feb 2001 17:22:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1SKFt006043 for ips-outgoing; Wed, 28 Feb 2001 15:15:55 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1SKFK105958 for ; Wed, 28 Feb 2001 15:15:20 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id VAA16710 for ; Wed, 28 Feb 2001 21:15:12 +0100 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id VAA60584 for ; Wed, 28 Feb 2001 21:14:27 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A01.006F231B ; Wed, 28 Feb 2001 21:13:54 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Wed, 28 Feb 2001 22:15:25 +0200 Subject: Re: max connections exceeded (was yet another login question) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, Keep in mind though that you have to strike a balance between being friendly to a new implementation (initiator and target) to wasting to many resources for what will be used only during debugging. Protocol errors could be detected if you ran initiator/target again a friendly partner (with detailed error logs). You don't want to burden running things with all the clutter. Regards, Julo Mark Burton on 28/02/2001 18:12:39 Please respond to Mark Burton To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: max connections exceeded (was yet another login question) Julo, In general, I would prefer to have reasonably specific error codes rather than "catch alls". What do other people think? In this particular case it is arguable that the initiator is in error rather than the target because the maximum number of connections per session has been previously negotiated and, therefore, the initiator should not try and open a new connection. I therefore suggest: 0207 'No Free Connections' (or similar) Other login error situations not particularly well matched to the existing codes are: 1 - Connection duplicates a CID value already used in the session - I suggest: (0208 'Initiator CID Error') 2 - A mandatory parameter has not been specified but the F bit is set in a Login PDU. A helpful thing for the target to do in this situation would be to return the key(s) of the missing mandatory parameters in the data segment. This could be made an optional capability. I suggest: (0209 'Mandatory parameter missing') 3 - A value is specified for a session parameter that conflicts with a previously negotiated value (negotiated by the leading connection). A Reject response could be used in this situation (preferably with a new reject reason code). One other question is: how should a target respond if it receives a Login command on a connection that has already reach full feature phase? Rejecting the command seems obvious but with what code? Regards, Mark From: julian_satran@il.ibm.com Subject: Re: yet another login question Date: Wed, 28 Feb 2001 14:53:37 +0200 > > > Mark - you don't have to apologize. > > The 0300 (2.11.4) response is supposed to cover this type of error. > > If you and others feel that we have to be more specific - speak out loudly. > > Regards, > Julo > > > Mark Burton on 27/02/2001 22:43:39 > > Please respond to Mark Burton > > To: ips@ece.cmu.edu > cc: > Subject: yet another login question > > > > > > Hello again, > > sorry to be a pest but I have another query re the login command: > > If an initiator opens a new connection and subsequently submits a > login pdu that identifies an existing session that is already > supporting the maximum number of connections, what error code should > be returned to the initiator? Perhaps "target conflict", or maybe a > new code yet to be defined like "No free connections". > > Apologies if this is covered in the spec but I have missed it. > > Thanks, > > Mark > > > > > < From owner-ips@ece.cmu.edu Wed Feb 28 18:10:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00886 for ; Wed, 28 Feb 2001 18:10:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1SKkid08715 for ips-outgoing; Wed, 28 Feb 2001 15:46:44 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1SJvB104386 for ; Wed, 28 Feb 2001 14:57:11 -0500 (EST) Received: from src-news.pa.dec.com (src-news.pa.dec.com [16.4.16.111]) by mail1.digital.com (8.9.2/8.9.3/WV2.0h) with ESMTP id LAA23031 for ; Wed, 28 Feb 2001 11:57:02 -0800 (PST) Received: by src-news.pa.dec.com; id LAA02580; Wed, 28 Feb 2001 11:55:46 -0800 (PST) Path: pa.dec.com!owner-ietf-redist From: Internet-Drafts@ietf.org Newsgroups: dec.mail.lists.ietf Subject: I-D ACTION:draft-monia-ips-ifcpenc-00.txt Date: 28 Feb 2001 11:55:45 -0800 Organization: Systems Research Center, Compaq Computer Corporation Lines: 79 Distribution: dec Message-ID: <200102281158.GAA02902@ietf.org> To: IETF-Announce:;;;;;;@pa.dec.com;;;;;;@pa.dec.com;;;;;;;;;;;;;;;;;;;;;;;;@pa.dec.com;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Cc: ips@ece.cmu.edu In-Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" X-Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 8160010C68 for ; Wed, 28 Feb 2001 14:55:37 -0500 (EST) Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : iFCP Encapsulation Goals and Requirements Author(s) : C. Monia Filename : draft-monia-ips-ifcpenc-00.txt Pages : Date : 27-Feb-01 This document specifies iFCP requirements and design goals applicable to a common FCIP/iFCP format for the encapsulation of Fibre Channel frames. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-monia-ips-ifcpenc-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-monia-ips-ifcpenc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-monia-ips-ifcpenc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010227123956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-monia-ips-ifcpenc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-monia-ips-ifcpenc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010227123956.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Feb 28 19:29:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03119 for ; Wed, 28 Feb 2001 19:29:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1SM7hk15541 for ips-outgoing; Wed, 28 Feb 2001 17:07:43 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1SM7N115492 for ; Wed, 28 Feb 2001 17:07:23 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id XAA46610 for ; Wed, 28 Feb 2001 23:07:16 +0100 From: biran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta02_cs0 [9.165.222.253]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id XAA120438 for ; Wed, 28 Feb 2001 23:06:30 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A01.00796595 ; Wed, 28 Feb 2001 23:05:58 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Thu, 1 Mar 2001 00:03:29 +0200 Subject: Re: iSCSI: Use of SRP (draft -04) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Steve, You are correct, we'll change the SRP message sequence similar to telnet (U --- N,g,s -- A -- B...). For simultaneous authentication processes (InitAuth, TargetAuth) it seems a problem of over flexibility. The simpler and reasonable way would be to negotiate one authentication method AuthMethod and leave the one way / mutual authentication decision to the specific method selected. In KERB5 the client decides it by setting the krb_ap_req mutual flag, in SRP it's actually mutual. Regards, Ofer Ofer Biran Systems and Software IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Steve Senum on 02/28/2001 01:41:01 AM Please respond to Steve Senum To: ietf-ips cc: Subject: iSCSI: Use of SRP (draft -04) Julian: With respect to use of the SRP protocol for authentication, I think the current draft is incomplete. The SRP spec requires that values for the Prime Modulus value 'N' and the Generator value 'g' be sent by the authenticating entity as well as 's' and 'B' (or known through some other method). Look at RFC 2944 to see how telnet handles this. Also, if both Initiator and Target choose to authenticate with SRP, or if InitAuth=KERB5 and TargetAuth=srp, the same key names will be needed by both sides at the same time, resulting in the same key name appearing twice in the same text message. This will make it difficult for the receiver to know which key names goes with which authentication process, since there can be two going on at one time. Regards, Steve Senum From owner-ips@ece.cmu.edu Wed Feb 28 19:29:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03131 for ; Wed, 28 Feb 2001 19:29:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1SNGpu21481 for ips-outgoing; Wed, 28 Feb 2001 18:16:51 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1SNFh121398 for ; Wed, 28 Feb 2001 18:15:43 -0500 (EST) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA19656; Wed, 28 Feb 2001 18:15:37 -0500 (EST) Message-ID: <3A9D8657.2DD358A7@cisco.com> Date: Wed, 28 Feb 2001 17:14:31 -0600 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: biran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI: Use of SRP (draft -04) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ofer: If SRP is mutual, then I think the draft should state that with text similiar to the Kerberos method, and also state how to handle mixed SRB and Kerberos authentication (or disallow it). Also, I am not sure I agree that SRP is entirely mutual. See draft-ietf-pppext-eap-srp-00.txt for a proposal for using SRP with PPP. Regards, Steve Senum biran@il.ibm.com wrote: > > Steve, > > You are correct, we'll change the SRP message sequence similar to telnet (U > --- N,g,s -- A -- B...). > > For simultaneous authentication processes (InitAuth, TargetAuth) it seems a > problem of over flexibility. The simpler > and reasonable way would be to negotiate one authentication method > AuthMethod and leave the one way / mutual > authentication decision to the specific method selected. In KERB5 the > client decides it by setting the krb_ap_req mutual > flag, in SRP it's actually mutual. > > Regards, > Ofer > > Ofer Biran > Systems and Software > IBM Research Lab in Haifa > biran@il.ibm.com 972-4-8296253 > > Steve Senum on 02/28/2001 01:41:01 AM > > Please respond to Steve Senum > > To: ietf-ips > cc: > Subject: iSCSI: Use of SRP (draft -04) > > Julian: > > With respect to use of the SRP protocol for authentication, > I think the current draft is incomplete. The SRP spec > requires that values for the Prime Modulus value 'N' and the > Generator value 'g' be sent by the authenticating entity > as well as 's' and 'B' (or known through some other method). > Look at RFC 2944 to see how telnet handles this. > > Also, if both Initiator and Target choose to authenticate with > SRP, or if InitAuth=KERB5 and TargetAuth=srp, the same key names > will be needed by both sides at the same time, resulting in the > same key name appearing twice in the same text message. This > will make it difficult for the receiver to know which key names > goes with which authentication process, since there can be two > going on at one time. > > Regards, > Steve Senum From owner-ips@ece.cmu.edu Wed Feb 28 19:30:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03152 for ; Wed, 28 Feb 2001 19:30:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f1SMvi019889 for ips-outgoing; Wed, 28 Feb 2001 17:57:44 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from main.connectcom.net (ns1.advansys.com [204.247.22.3] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f1SMrC119494 for ; Wed, 28 Feb 2001 17:53:13 -0500 (EST) Received: from ypportable (anubis.advansys.com [204.247.22.2]) by main.connectcom.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 11CPQ8VA; Wed, 28 Feb 2001 14:53:10 -0800 From: "Y P Cheng" To: "'Ips@Ece. Cmu. Edu'" Subject: Re: iSCSI.04 Comments Date: Wed, 28 Feb 2001 14:49:32 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01C0A195.A8EA4BA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0055_01C0A195.A8EA4BA0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ece.cmu.edu id f1SMvi119889 Content-Transfer-Encoding: quoted-printable I apologize if someone has already touched this topic. I found the use of F-bit in Section 2.3 for =93immediate data=94 a littl= e confusing. Why don=92t we reserve bit 7 and use bit 4 instead and call i= t I-bit. In Section 2.4, the S-bit indicating Sense-data has similar meani= ng, i.e. data field after the basic header. Y.P., ConnectCom Solutions. ------=_NextPart_000_0055_01C0A195.A8EA4BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I apologize if someone has = already touched this topic.

 

I found the use of F-bit = in Section 2.3 for “immediate data”  a little confusing.  Why = don’t we reserve bit 7 and use bit 4 instead and call it I-bit.  In Section 2.4, the S-bit indicating Sense-data has = similar meaning, i.e. data field after the basic header. =

 

Y.P., ConnectCom = Solutions.

 <= /p>

------=_NextPart_000_0055_01C0A195.A8EA4BA0--