From ips-bounces@ietf.org Wed Apr 05 12:39:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRB2b-0001qI-3p; Wed, 05 Apr 2006 12:39:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRB2a-0001nl-Fv for ips@ietf.org; Wed, 05 Apr 2006 12:39:32 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRB2Y-0007Ej-3E for ips@ietf.org; Wed, 05 Apr 2006 12:39:32 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 05 Apr 2006 09:39:22 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 5EDB02AF; Wed, 5 Apr 2006 09:39:22 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 376CD2AE for ; Wed, 5 Apr 2006 09:39:22 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id DFV81458; Wed, 5 Apr 2006 09:39:22 -0700 (PDT) Received: from NT-IRVA-0751.brcm.ad.broadcom.com (nt-irva-0751 [10.8.194.65]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 00BCF69CA5 for ; Wed, 5 Apr 2006 09:39:21 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Apr 2006 09:39:21 -0700 Message-ID: <00DDB8FFD8F89A488797060F19D0BD82878019@NT-IRVA-0751.brcm.ad.broadcom.com> Thread-Topic: RAIT 2006 Thread-Index: AcZYz31UQO8yDvxOSIe0ZL1ZSRtyOA== From: "Hemal Shah" To: ips@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006040504; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230352E34343333463142442E303032442D412D; ENG=IBF; TS=20060405163922; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006040504_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 682D2D303NG5589711-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Subject: [Ips] RAIT 2006 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org We would like to invite interested parties on this list to submit papers = to the third workshop on RDMA: Applications, Implementations, and = Technologies (RAIT 2006). See below for the detailed call for papers. Hemal and Jim (RAIT 2006 Workshop co-chairs) -------------------------------------------------------------------------= --- Third=A0Workshop on Remote Direct Memory Access (RDMA): Applications, = Implementations, and Technologies (RAIT 2006) To be held on Sept 28th, 2006, in=A0Barcelona, Spain in conjunction with the Cluster 2006 conference. Barcelona, Spain. =A0 ________________________________________ * Call for papers=20 * Paper submission=20 * Important dates=20 * Organizers and program committee=20 ________________________________________ =A0 Call for papers =A0 Remote Direct Memory Access (RDMA) enables transfer of data across a = network directly to and from application buffers without requiring any = intermediate copies or buffers. RDMA, along with direct access to the = networking hardware, also provides a low overhead mechanism for = achieving low latency, high-bandwidth communication. RDMA has become a = desirable feature in high-speed clusters and data-center networks.=20 =A0 Scope The RAIT 2006 workshop is the third time that the RAIT workshop has been = held. RAIT 2006 is intended to serve as a forum to present the latest = research work by the researchers and developers from both academia and = industry. The workshop focuses on the applications of RDMA, the = implementation aspects of RDMA, and the technologies for RDMA. Topics of = special interest include advanced new features such as TCP offload = engines embedded within RDMA, virtualization technologies for RDMA, and = new techniques to extend RDMA functionality, such as atomics, multicast, = and broadcast operations. =A0=20 Topics of interest include, but are not limited to: *=A0=A0=A0=A0=A0=A0=A0 RDMA hardware (RDMA-enabled Ethernet adapters, = InfiniBand adapters, or other adapters) *=A0=A0=A0=A0=A0=A0=A0 RDMA-aware networks and interfaces *=A0=A0=A0=A0=A0=A0=A0 Middleware and network services for RDMA-based = networking *=A0=A0=A0=A0=A0=A0=A0Virtualization and RDMA *=A0=A0=A0=A0=A0=A0=A0Applications of RDMA (iSCSI/iSER, NFS, DAFS, SDP, = databases, clustering, storage networking, etc.) *=A0=A0=A0=A0=A0=A0=A0 RDMA Protocols *=A0=A0=A0=A0=A0=A0=A0 Protocol offload engines (TCP offload engines, = RDMA offload engines, etc.)=20 *=A0=A0=A0=A0=A0=A0=A0Operating system infrastructure for RDMA *=A0=A0=A0=A0=A0=A0=A0 RDMA performance evaluation (application = performance, performance metrics, network performance, etc.) *=A0=A0=A0=A0=A0=A0=A0 RDMA and security *=A0=A0=A0=A0=A0=A0=A0 Future directions for RDMA=A0=A0 =A0=A0 =A0 ________________________________________ =A0 Paper Submission =A0 We invite submissions of technical papers, position papers, and case = studies relevant to the workshop. Submission implies the willingness of = at least one of the authors to present the paper and register. = Submission should include on the front page the authors' name, = affiliations, addresses, email addresses, and phone numbers. =A0 Please submit a full paper not exceeding 8 single-spaced pages in PDF or = Postscript form, page-numbered, in 10-point font or larger, and suitable = for printing on 8.5"x11" paper with at least 1 inch margin all around. = Please submit the full paper for consideration to this workshop to Hemal = Shah (hemal@broadcom.com) and James Pinkerton (jpink@microsoft.com) by = email. =A0 =A0 ________________________________________ =A0 Important dates Deadline for = submission=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0May 31, 2006=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Notification of = acceptance=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0June 19, 2006 Camera ready = papers=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0July 10, 2006 Workshop = date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 September 28, 2006 =A0 ________________________________________ =A0 Organizers Program Co-chair: Hemal V. Shah,=A0Broadcom Corporation Program Co-chair: James Pinkerton, Microsoft Corporation =A0 Program Committee Jeff Chase, Duke University Uri Elzur, Broadcom Corporation Dirk Grunwald, University of Colorado, Boulder Mike Ko, IBM Research Michael Krause, Hewlett-Packard Company Kai Li, Princeton University Dhabaleswar Panda, Ohio State University Fabrizio Petrini, Los Alamos National Laboratory _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Apr 05 15:50:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRE13-0007wY-Cl; Wed, 05 Apr 2006 15:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRE0w-0007sx-IW; Wed, 05 Apr 2006 15:50:02 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRE0v-0007Mi-Te; Wed, 05 Apr 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k35Jo1BX011945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Apr 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FRE0v-0003t8-Nt; Wed, 05 Apr 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 05 Apr 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-isns-mib-09.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org --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 : Definitions of Managed Objects for iSNS (Internet Storage Name Service) Author(s) : K. Gibbons, et al. Filename : draft-ietf-ips-isns-mib-09.txt Pages : 69 Date : 2006-4-5 The iSNS protocol provides storage name service functionality on an IP network that is being used for iSCSI or iFCP storage. This draft provides a mechanism to monitor multiple iSNS Servers, including information about registered objects in an iSNS Server. This memo is a product of the IP Storage (IPS) working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ips@ietf.org and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-mib-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-isns-mib-09.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-isns-mib-09.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: <2006-4-5113125.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-isns-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-isns-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-5113125.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Wed Apr 05 16:22:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREWW-0004Fl-Gl; Wed, 05 Apr 2006 16:22:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREWV-00045Y-1f for ips@ietf.org; Wed, 05 Apr 2006 16:22:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FREWV-0002yd-0B for ips@ietf.org; Wed, 05 Apr 2006 16:22:39 -0400 Received: from mexforward.lss.emc.com ([168.159.213.200]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FRESp-0006Di-Jf for ips@ietf.org; Wed, 05 Apr 2006 16:18:51 -0400 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k35KIpWQ021090; Wed, 5 Apr 2006 16:18:51 -0400 (EDT) Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k35KImrg022897; Wed, 5 Apr 2006 16:18:49 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Apr 2006 16:18:47 -0400 Message-ID: From: Black_David@emc.com To: postmaster@maxtor.com Date: Wed, 5 Apr 2006 16:19:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.04.05.125107 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __FRAUD_419_MISC 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __STOCK_SUBJ_7 0' X-Spam-Score: -2.0 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ips@ietf.org Subject: [Ips] (no subject) X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Gentlemen, Your email software is configured to reject an attachment type, probably URL, that is part of IETF Internet-Draft announcements. This mistaken policy prevents your employees from fully participating in the process of standardizing protocols used in the Internet (e.g., iSCSI). I suggest that you change this policy. Thanks, --David (IETF IP Storage Working Group Chair) p.s. This has been publicly cc:'d to the IPS WG mailing list in the hope that someone at Maxtor will cause it to be corrected. In the words of the late Justice Brandeis, "sunlight is the best disinfectant" ... ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- -----Original Message----- From: PureMessage Admin [mailto:postmaster@maxtor.com] Sent: Wednesday, April 05, 2006 4:12 PM Subject: Maxtor Attachment Policy Violation Due to viruses and malicious code found in email attachments your email was blocked. Maxtor does not accept the transfer of files or attachments that do not meet Maxtor's acceptable attachment policy. For example: ZIP, EXE, SCR, COM, BAT, VBS, RAR, CMD, PIF, etc... Maxtor does accept some ZIP attachments that meet certain criteria. For more information please call or email your Maxtor contact. PureMessage Admin _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Apr 05 19:27:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHP1-0005y4-Ly; Wed, 05 Apr 2006 19:27:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHP1-0005xi-0R for ips@ietf.org; Wed, 05 Apr 2006 19:27:07 -0400 Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRHP0-0002eG-MS for ips@ietf.org; Wed, 05 Apr 2006 19:27:06 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k35NR6Xb005366 for ; Wed, 5 Apr 2006 19:27:06 -0400 (EDT) Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k35NR4l1021034 for ; Wed, 5 Apr 2006 19:27:04 -0400 (EDT) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Apr 2006 19:27:03 -0400 Message-ID: From: Black_David@emc.com To: ips@ietf.org Date: Wed, 5 Apr 2006 19:26:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.04.05.161104 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Black_David@emc.com Subject: [Ips] Publication Requested: iSNS MIB X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Publication has just been requested on the iSNS MIB draft. The PROTO process (cf. draft-ietf-proto-wgchair-doc-shepherding-06.txt) is being used. Here is the PROTO writeup: PROTO writeup: Definitions of Managed Objects for iSNS (Internet Storage Name Service) draft-ietf-ips-isns-mib-09.txt Requested Publication Status: Proposed Standard PROTO shepherd: David L. Black (IPS WG Chair) ------------------------------------------------------------------------ 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Yes. The chair has reviewed the text portions of the draft, and is relying upon the WG's MIB Expert (Keith McCloghrie)'s review of the MIB content. 1.b) Has the document had adequate review from both key WG members and key non-WG members? Yes. Do you have any concerns about the depth or breadth of the reviews that have been performed? No. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? Needs the usual IETF OPS Area MIB Doctor review. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No. The IESG should be aware that this is a monitoring-only MIB - it cannot be used for configuration, as it contains no writeable objects. 1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is solid support for this document within the WG, including support for it being only for monitoring iSNS servers; it cannot do configuration, and is not applicable to iSNS clients. 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. No. 1.g) Have the chairs verified that the document adheres to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html). The online nits checker says everything is ok. 1.h) Is the document split into normative and informative references? Yes. Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) There are no normative references to Internet Drafts. 1.i) For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary * Working Group Summary * Protocol Quality 1.j) Please provide such a write-up. Recent examples can be found in the "protocol action" announcements for approved documents. -- Technical Summary The iSNS protocol provides storage name service functionality on an IP network that is being used for iSCSI or iFCP storage. This draft provides a mechanism to monitor multiple iSNS Servers, including information about registered objects in an iSNS Server. -- Working Group Summary This MIB was originally undertaken as a MIB for monitoring and configuration of both iSNS servers and clients, but ran into significant complexity and structural issues. The scope of the MIB was reduced to server monitoring in order, as that comprised most of the interest in (and perceived value of) the MIB. -- Protocol Quality The protocol has been reviewed for the ips WG by Keith McCloghrie. An approval announcement should credit a MIB Doctor as having reviewed this for the IESG. Thanks, --David (ips WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Apr 05 19:52:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHnf-0000Q4-TX; Wed, 05 Apr 2006 19:52:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHne-0000Pz-Ce for ips@ietf.org; Wed, 05 Apr 2006 19:52:34 -0400 Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRHne-0003N7-1P for ips@ietf.org; Wed, 05 Apr 2006 19:52:34 -0400 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k35NqXh6018137 for ; Wed, 5 Apr 2006 19:52:33 -0400 (EDT) Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k35NqUxm024408 for ; Wed, 5 Apr 2006 19:52:31 -0400 (EDT) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Apr 2006 19:52:30 -0400 Message-ID: From: Black_David@emc.com To: Black_David@emc.com, ips@ietf.org Date: Wed, 5 Apr 2006 19:52:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.04.05.161104 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_NOT_1 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __STOCK_SUBJ_7 0' X-Spam-Score: 1.7 (+) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: lars.eggert@netlab.nec.de Subject: [Ips] (no subject) X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Minor correction - in the Working Group Summary, the words "in order" should be removed from the following sentence: > The scope of the > MIB was reduced to server monitoring in order, as that comprised > most of the interest in (and perceived value of) the MIB. My mistake, sorry, --David > -----Original Message----- > From: Black, David > Sent: Wednesday, April 05, 2006 7:27 PM > To: ips@ietf.org > Cc: Black, David > Subject: Publication Requested: iSNS MIB > > Publication has just been requested on the iSNS MIB draft. The > PROTO process (cf. draft-ietf-proto-wgchair-doc-shepherding-06.txt) > is being used. Here is the PROTO writeup: > > PROTO writeup: > Definitions of Managed Objects for iSNS > (Internet Storage Name Service) > draft-ietf-ips-isns-mib-09.txt > > Requested Publication Status: Proposed Standard > PROTO shepherd: David L. Black (IPS WG Chair) > -------------------------------------------------------------- > ---------- > > 1.a) Have the chairs personally reviewed this version of > the Internet > Draft (ID), and in particular, do they believe this > ID is ready > to forward to the IESG for publication? > > Yes. The chair has reviewed the text portions of the draft, and is > relying upon the WG's MIB Expert (Keith McCloghrie)'s review of the > MIB content. > > 1.b) Has the document had adequate review from both key WG members > and key non-WG members? > > Yes. > Do you have any concerns about the > depth or breadth of the reviews that have been performed? > > No. > > 1.c) Do you have concerns that the document needs more > review from a > particular (broader) perspective (e.g., security, operational > complexity, someone familiar with AAA, etc.)? > > Needs the usual IETF OPS Area MIB Doctor review. > > 1.d) Do you have any specific concerns/issues with this > document that > you believe the ADs and/or IESG should be aware of? For > example, perhaps you are uncomfortable with certain > parts of the > document, or have concerns whether there really is a need for > it. In any event, if your issues have been discussed > in the WG > and the WG has indicated it that it still wishes to > advance the > document, detail those concerns in the write-up. > > No. The IESG should be aware that this is a monitoring-only MIB - it > cannot be used for configuration, as it contains no writeable objects. > > 1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? > > There is solid support for this document within the WG, including > support for it being only for monitoring iSNS servers; it cannot do > configuration, and is not applicable to iSNS clients. > > 1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email to the Responsible Area Director. > > No. > > 1.g) Have the chairs verified that the document adheres to > all of the > ID nits? (see http://www.ietf.org/ID-Checklist.html). > > The online nits checker says everything is ok. > > 1.h) Is the document split into normative and informative > references? > > Yes. > > Are there normative references to IDs, where the IDs are not > also ready for advancement or are otherwise in an > unclear state? > (note here that the RFC editor will not publish an RFC with > normative references to IDs, it will delay > publication until all > such IDs are also ready for publication as RFCs.) > > There are no normative references to Internet Drafts. > > 1.i) For Standards Track and BCP documents, the IESG approval > announcement includes a write-up section with the following > sections: > > * Technical Summary > > * Working Group Summary > > * Protocol Quality > > 1.j) Please provide such a write-up. Recent examples can > be found in > the "protocol action" announcements for approved documents. > > -- Technical Summary > > The iSNS protocol provides storage name service functionality on > an IP network that is being used for iSCSI or iFCP storage. This > draft provides a mechanism to monitor multiple iSNS Servers, > including information about registered objects in an iSNS > Server. > > -- Working Group Summary > > This MIB was originally undertaken as a MIB for monitoring and > configuration of both iSNS servers and clients, but ran into > significant complexity and structural issues. The scope of the > MIB was reduced to server monitoring in order, as that comprised > most of the interest in (and perceived value of) the MIB. > > -- Protocol Quality > > The protocol has been reviewed for the ips WG by Keith McCloghrie. > An approval announcement should credit a MIB Doctor as having > reviewed this for the IESG. > > Thanks, > --David (ips WG chair) > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Apr 06 18:08:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRceg-0003vK-3C; Thu, 06 Apr 2006 18:08:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRcee-0003vF-Lg for ips@ietf.org; Thu, 06 Apr 2006 18:08:40 -0400 Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRcee-0000vY-8L for ips@ietf.org; Thu, 06 Apr 2006 18:08:40 -0400 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k36M8dBv000050; Thu, 6 Apr 2006 18:08:39 -0400 (EDT) Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k36M8aEb002499; Thu, 6 Apr 2006 18:08:36 -0400 (EDT) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Apr 2006 18:08:35 -0400 Message-ID: From: Black_David@emc.com To: davidw@netapp.com Subject: RE: [Ips] X#NodeArchitecture draft - next steps Date: Thu, 6 Apr 2006 18:08:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.04.06.143605 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_MEDIA_2_BODY 0, __CP_NOT_1 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: ips@ietf.org, Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Dave, > New proposed text: > > 3. Security Considerations > > In certain environments where security is a primary concern, > the use of this extension key may not be appropriate as it > reveals specific details about an iSCSI node. For these > environments, nodes implementing this public extension key > MUST provide a method to disable sending the key. In > addition to providing a disable mechanism, security sensitive > environments SHOULD consider use of IPsec, as specified in > RFC 3720 and 3723, as a means to shield the contents of this > key from observers of network traffic. Good start, needs editing to something like: This extension key transmits specific implementation details about the node that sends it; such details may be considered sensitive in some environments. For example, if a certain software or firmware version is known to contain security weaknesses, announcing the presence of that version via this key may not be desirable. The countermeasures for this security concern are: - not sending the extension key, or - using IPsec to provide confidentiality for the iSCSI connection on which the key is sent (see RFC 3720 and RFC 3723). To support the first countermeasure, all implementations of this extension key MUST provide an administrative mechanism to disable sending the key. Reasons for the edits: - Focus on specific threat, not general "where security is a primary concern". - Make the "MUST" for disabling transmission of the key globally applicable, vs. possibly scoped to specific environments. This is a "MUST implement" requirement, not "MUST use". - Avoid the "SHOULD ... use ... IPsec" phrasing, at least for now. > New proposed text: > > The following described Public Extension Key is sent during > the login phase of an iSCSI normal session. It is important > to note that the proper use of this key is to provide enhanced > logging and support capabilities, and for better understanding > of customer environments. Functional behavior of the iSCSI > node MUST NOT depend on the presence, absence, or content of > the key. The key MUST NOT be used by iSCSI nodes for things > such as interoperability, performance, exclusion or deception > of other nodes, or other uses not defined here. To enforce > proper use, iSCSI nodes MUST NOT allow user modification of > the key value(s), and SHOULD set the value automatically based > on standard internal interfaces. This one is close - 3 suggestions: - "proper" -> "intended" - remove "and for better understanding of customer environments" or replace it with something more specific like "and to enable collection of iSCSI implementation usage information" - The "such as ... or other uses not defined here" is not sufficiently precise. The last one is crucial - it needs to be easy for an implementer to determine whether s/he's stepped over this line. I'm comfortable with not mentioning the JavaScript and browser versions mess, as I think we all know that it's the motivating example for this text. Thanks, --David (as individual participant, *not* as WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Dave Wysochanski [mailto:davidw@netapp.com] > Sent: Friday, March 31, 2006 9:35 PM > To: Black, David > Cc: ips@ietf.org > Subject: Re: [Ips] X#NodeArchitecture draft - next steps > > Black_David@emc.com wrote: > > > This draft is better known as: > > draft-wysochanski-xkey-iscsi-support-00.txt > > > > This draft will be an official WG draft, but three things > > need to happen first: > > > > (1) New security text. The existing "SHOULD" in the security > > considerations text needs to be a "MUST". In addition, > > there needs to be a sentence pointing out that it may > > be important to shield the contents of this key from > > observers of network traffic, and that IPsec as specified > > for iSCSI in RFC 3720 and 3723 (cite both of them) is an > > appropriate tool for this purpose. > > > New proposed text: > > 3. Security Considerations > > In certain environments where security is a primary concern, > the use of this extension key may not be appropriate as it > reveals specific details about an iSCSI node. For these > environments, nodes implementing this public extension key > MUST provide a method to disable sending the key. In > addition to providing a disable mechanism, security sensitive > environments SHOULD consider use of IPsec, as specified in > RFC 3720 and 3723, as a means to shield the contents of this > key from observers of network traffic. > > > > Original text: > > 3. Security Considerations > > In certain environments where security is a primary concern, > the use of this extension key may not be appropriate as it > reveals specific details about an iSCSI node. For these > environments, nodes implementing this public extension key > SHOULD provide a method to disable sending the key. > > > > > (2) New "prevention of abuse" text. The current "The key MUST NOT > > be used by iSCSI nodes for things such as ..." is well- > > intentioned but does not get the job done. My recollection > > of discussion in Dallas is that saying that "functional behavior > > of the iSCSI node MUST NOT depend on this key (presence/absence > > or value)" may be closer to the mark. The only permitted > > (and intended) use of this key is to report it/log it in order > > to avoid the browser detection JavaScript disasters caused by > > the corresponding HTTP header fields. > > > > I wasn't sure about deleting the original "MUST NOT" sentence so I left it in. Anyone > have a preference? Also wasn't sure whether it's worth putting in a sentence or two at > least acknowledging what has happened in the past with User-Agent -- intent would be > the working group acknowledges this historical misuse and wishes to avoid it. > > New proposed text: > > The following described Public Extension Key is sent during > the login phase of an iSCSI normal session. It is important > to note that the proper use of this key is to provide enhanced > logging and support capabilities, and for better understanding > of customer environments. Functional behavior of the iSCSI > node MUST NOT depend on the presence, absence, or content of > the key. The key MUST NOT be used by iSCSI nodes for things > such as interoperability, performance, exclusion or deception > of other nodes, or other uses not defined here. To enforce > proper use, iSCSI nodes MUST NOT allow user modification of > the key value(s), and SHOULD set the value automatically based > on standard internal interfaces. > > > > Original text: > > The following described Public Extension Key is sent during > the login phase of an iSCSI normal session. It is important > to note that the proper use of this key is to provide enhanced > logging and support capabilities, and for better understanding > of customer environments. The key MUST NOT be used by iSCSI > nodes for things such as interoperability, performance, > exclusion or deception of other nodes, or other uses not > defined here. To enforce proper use, iSCSI nodes MUST NOT > allow user modification of the key value(s), and SHOULD set > the value automatically based on standard internal interfaces. > > > > > > > > (3) The draft needs a new title and file name ("supportability" just > > reeks of marketing ;-) ). Let's try: > > > > The iSCSI X#NodeArchitecture Key > > draft-ietf-ips-iscsi-nodearch-key-00.txt > > > Sounds fine to me. > > > > Text for (1) and (2), or at least initial versions of it should be > > worked out on the list before the -00 version of the draft-ietf-ips-... > > draft is submitted. I've just sent the request to the secretariat for > > an end-of-2006 completion milestone for this, but in practice, it > > could be done shortly after Montreal, if not before. > > > Great, thanks. > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Apr 07 08:38:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqEh-0004RG-M6; Fri, 07 Apr 2006 08:38:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqEg-0004Op-7m for ips@ietf.org; Fri, 07 Apr 2006 08:38:46 -0400 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRqEf-0002sQ-3D for ips@ietf.org; Fri, 07 Apr 2006 08:38:46 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.6/8.13.6) with ESMTP id k37CciCD039654 for ; Fri, 7 Apr 2006 12:38:44 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k37CdXIk226162 for ; Fri, 7 Apr 2006 14:39:33 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k37CchOA024393 for ; Fri, 7 Apr 2006 14:38:43 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k37CchPf024390; Fri, 7 Apr 2006 14:38:43 +0200 In-Reply-To: To: Black_David@emc.com Subject: RE: [Ips] X#NodeArchitecture draft - next steps MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Fri, 7 Apr 2006 08:39:30 -0400 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0HF90 | November 16, 2005) at 07/04/2006 15:39:32, Serialize complete at 07/04/2006 15:39:32 X-Spam-Score: 0.1 (/) X-Scan-Signature: 645960076aa293effd9740db2f975dc3 Cc: ips@ietf.org, Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0174542598==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0174542598== Content-Type: multipart/alternative; boundary="=_alternative 0044D3CC85257149_=" This is a multipart message in MIME format. --=_alternative 0044D3CC85257149_= Content-Type: text/plain; charset="US-ASCII" I am not sure that not sending the key is that good a measure (not sending it when it was previously seen is a way of leaking information). I guess what you want to mandate is that the value can be specifically faked (set) and/or responding "not understood". Julo Black_David@emc.com 06/04/06 18:08 To davidw@netapp.com cc ips@ietf.org, Black_David@emc.com Subject RE: [Ips] X#NodeArchitecture draft - next steps Dave, > New proposed text: > > 3. Security Considerations > > In certain environments where security is a primary concern, > the use of this extension key may not be appropriate as it > reveals specific details about an iSCSI node. For these > environments, nodes implementing this public extension key > MUST provide a method to disable sending the key. In > addition to providing a disable mechanism, security sensitive > environments SHOULD consider use of IPsec, as specified in > RFC 3720 and 3723, as a means to shield the contents of this > key from observers of network traffic. Good start, needs editing to something like: This extension key transmits specific implementation details about the node that sends it; such details may be considered sensitive in some environments. For example, if a certain software or firmware version is known to contain security weaknesses, announcing the presence of that version via this key may not be desirable. The countermeasures for this security concern are: - not sending the extension key, or - using IPsec to provide confidentiality for the iSCSI connection on which the key is sent (see RFC 3720 and RFC 3723). To support the first countermeasure, all implementations of this extension key MUST provide an administrative mechanism to disable sending the key. Reasons for the edits: - Focus on specific threat, not general "where security is a primary concern". - Make the "MUST" for disabling transmission of the key globally applicable, vs. possibly scoped to specific environments. This is a "MUST implement" requirement, not "MUST use". - Avoid the "SHOULD ... use ... IPsec" phrasing, at least for now. > New proposed text: > > The following described Public Extension Key is sent during > the login phase of an iSCSI normal session. It is important > to note that the proper use of this key is to provide enhanced > logging and support capabilities, and for better understanding > of customer environments. Functional behavior of the iSCSI > node MUST NOT depend on the presence, absence, or content of > the key. The key MUST NOT be used by iSCSI nodes for things > such as interoperability, performance, exclusion or deception > of other nodes, or other uses not defined here. To enforce > proper use, iSCSI nodes MUST NOT allow user modification of > the key value(s), and SHOULD set the value automatically based > on standard internal interfaces. This one is close - 3 suggestions: - "proper" -> "intended" - remove "and for better understanding of customer environments" or replace it with something more specific like "and to enable collection of iSCSI implementation usage information" - The "such as ... or other uses not defined here" is not sufficiently precise. The last one is crucial - it needs to be easy for an implementer to determine whether s/he's stepped over this line. I'm comfortable with not mentioning the JavaScript and browser versions mess, as I think we all know that it's the motivating example for this text. Thanks, --David (as individual participant, *not* as WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Dave Wysochanski [mailto:davidw@netapp.com] > Sent: Friday, March 31, 2006 9:35 PM > To: Black, David > Cc: ips@ietf.org > Subject: Re: [Ips] X#NodeArchitecture draft - next steps > > Black_David@emc.com wrote: > > > This draft is better known as: > > draft-wysochanski-xkey-iscsi-support-00.txt > > > > This draft will be an official WG draft, but three things > > need to happen first: > > > > (1) New security text. The existing "SHOULD" in the security > > considerations text needs to be a "MUST". In addition, > > there needs to be a sentence pointing out that it may > > be important to shield the contents of this key from > > observers of network traffic, and that IPsec as specified > > for iSCSI in RFC 3720 and 3723 (cite both of them) is an > > appropriate tool for this purpose. > > > New proposed text: > > 3. Security Considerations > > In certain environments where security is a primary concern, > the use of this extension key may not be appropriate as it > reveals specific details about an iSCSI node. For these > environments, nodes implementing this public extension key > MUST provide a method to disable sending the key. In > addition to providing a disable mechanism, security sensitive > environments SHOULD consider use of IPsec, as specified in > RFC 3720 and 3723, as a means to shield the contents of this > key from observers of network traffic. > > > > Original text: > > 3. Security Considerations > > In certain environments where security is a primary concern, > the use of this extension key may not be appropriate as it > reveals specific details about an iSCSI node. For these > environments, nodes implementing this public extension key > SHOULD provide a method to disable sending the key. > > > > > (2) New "prevention of abuse" text. The current "The key MUST NOT > > be used by iSCSI nodes for things such as ..." is well- > > intentioned but does not get the job done. My recollection > > of discussion in Dallas is that saying that "functional behavior > > of the iSCSI node MUST NOT depend on this key (presence/absence > > or value)" may be closer to the mark. The only permitted > > (and intended) use of this key is to report it/log it in order > > to avoid the browser detection JavaScript disasters caused by > > the corresponding HTTP header fields. > > > > I wasn't sure about deleting the original "MUST NOT" sentence so I left it in. Anyone > have a preference? Also wasn't sure whether it's worth putting in a sentence or two at > least acknowledging what has happened in the past with User-Agent -- intent would be > the working group acknowledges this historical misuse and wishes to avoid it. > > New proposed text: > > The following described Public Extension Key is sent during > the login phase of an iSCSI normal session. It is important > to note that the proper use of this key is to provide enhanced > logging and support capabilities, and for better understanding > of customer environments. Functional behavior of the iSCSI > node MUST NOT depend on the presence, absence, or content of > the key. The key MUST NOT be used by iSCSI nodes for things > such as interoperability, performance, exclusion or deception > of other nodes, or other uses not defined here. To enforce > proper use, iSCSI nodes MUST NOT allow user modification of > the key value(s), and SHOULD set the value automatically based > on standard internal interfaces. > > > > Original text: > > The following described Public Extension Key is sent during > the login phase of an iSCSI normal session. It is important > to note that the proper use of this key is to provide enhanced > logging and support capabilities, and for better understanding > of customer environments. The key MUST NOT be used by iSCSI > nodes for things such as interoperability, performance, > exclusion or deception of other nodes, or other uses not > defined here. To enforce proper use, iSCSI nodes MUST NOT > allow user modification of the key value(s), and SHOULD set > the value automatically based on standard internal interfaces. > > > > > > > > (3) The draft needs a new title and file name ("supportability" just > > reeks of marketing ;-) ). Let's try: > > > > The iSCSI X#NodeArchitecture Key > > draft-ietf-ips-iscsi-nodearch-key-00.txt > > > Sounds fine to me. > > > > Text for (1) and (2), or at least initial versions of it should be > > worked out on the list before the -00 version of the draft-ietf-ips-... > > draft is submitted. I've just sent the request to the secretariat for > > an end-of-2006 completion milestone for this, but in practice, it > > could be done shortly after Montreal, if not before. > > > Great, thanks. > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0044D3CC85257149_= Content-Type: text/html; charset="US-ASCII"
I am not sure that not sending the key is that good a measure (not sending it when it was previously seen is a way of leaking information).
I guess what you want to mandate is that the value can be specifically faked (set) and/or responding "not understood".

Julo


Black_David@emc.com

06/04/06 18:08

To
davidw@netapp.com
cc
ips@ietf.org, Black_David@emc.com
Subject
RE: [Ips] X#NodeArchitecture draft - next steps





Dave,

> New proposed text:
>
> 3.  Security Considerations
>
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node.  For these
>    environments, nodes implementing this public extension key
>    MUST provide a method to disable sending the key.  In
>    addition to providing a disable mechanism, security sensitive
>    environments SHOULD consider use of IPsec, as specified in
>    RFC 3720 and 3723, as a means to shield the contents of this
>    key from observers of network traffic.

Good start, needs editing to something like:

   This extension key transmits specific implementation details
   about the node that sends it; such details may be considered
   sensitive in some environments.  For example, if a certain
   software or firmware version is known to contain security
   weaknesses, announcing the presence of that version via this
   key may not be desirable.  The countermeasures for this
   security concern are:
                - not sending the extension key, or
                - using IPsec to provide confidentiality for the iSCSI
                                 connection on  which the key is sent (see RFC 3720
                                 and RFC 3723).
   To support the first countermeasure, all implementations of
   this extension key MUST provide an administrative mechanism
   to disable sending the key.

Reasons for the edits:
- Focus on specific threat, not general "where security is a primary
                concern".
- Make the "MUST" for disabling transmission of the key globally
                applicable, vs. possibly scoped to specific environments.
                This is a "MUST implement" requirement, not "MUST use".
- Avoid the "SHOULD ... use ... IPsec" phrasing, at least for now.

> New proposed text:
>
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  Functional behavior of the iSCSI
>    node MUST NOT depend on the presence, absence, or content of
>    the key.  The key MUST NOT be used by iSCSI nodes for things
>    such as interoperability, performance, exclusion or deception
>    of other nodes, or other uses not defined here.  To enforce
>    proper use, iSCSI nodes MUST NOT allow user modification of
>    the key value(s), and SHOULD set the value automatically based
>    on standard internal interfaces.

This one is close - 3 suggestions:
- "proper" -> "intended"
- remove "and for better understanding of customer environments" or
                replace it with something more specific like "and to enable
                collection of iSCSI implementation usage information"
- The "such as ... or other uses not defined here" is not sufficiently
                precise.
The last one is crucial - it needs to be easy for an implementer to
determine whether s/he's stepped over this line.

I'm comfortable with not mentioning the JavaScript and browser versions
mess, as I think we all know that it's the motivating example for this
text.

Thanks,
--David (as individual participant, *not* as WG chair)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Dave Wysochanski [mailto:davidw@netapp.com]
> Sent: Friday, March 31, 2006 9:35 PM
> To: Black, David
> Cc: ips@ietf.org
> Subject: Re: [Ips] X#NodeArchitecture draft - next steps
>
> Black_David@emc.com wrote:
>
> > This draft is better known as:
> > draft-wysochanski-xkey-iscsi-support-00.txt
> >
> > This draft will be an official WG draft, but three things
> > need to happen first:
> >
> > (1) New security text.  The existing "SHOULD" in the security
> >         considerations text needs to be a "MUST".  In addition,
> >         there needs to be a sentence pointing out that it may
> >         be important to shield the contents of this key from
> >         observers of network traffic, and that IPsec as specified
> >         for iSCSI in RFC 3720 and 3723 (cite both of them) is an
> >         appropriate tool for this purpose.
> >
> New proposed text:
>
> 3.  Security Considerations
>
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node.  For these
>    environments, nodes implementing this public extension key
>    MUST provide a method to disable sending the key.  In
>    addition to providing a disable mechanism, security sensitive
>    environments SHOULD consider use of IPsec, as specified in
>    RFC 3720 and 3723, as a means to shield the contents of this
>    key from observers of network traffic.
>
>
>
> Original text:      
>
> 3.  Security Considerations
>
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node. For these
>    environments, nodes implementing this public extension key
>    SHOULD provide a method to disable sending the key.
>
>      
>
> > (2) New "prevention of abuse" text.  The current "The key MUST NOT
> >         be used by iSCSI nodes for things such as ..." is well-
> >         intentioned but does not get the job done.  My recollection
> >         of discussion in Dallas is that saying that "functional behavior
> >         of the iSCSI node MUST NOT depend on this key (presence/absence
> >         or value)"  may be closer to the mark.  The only permitted
> >         (and intended) use of this key is to report it/log it in order
> >         to avoid the browser detection JavaScript disasters caused by
> >         the corresponding HTTP header fields.
> >
>
> I wasn't sure about deleting the original "MUST NOT" sentence so I left it
in.  Anyone
> have a preference?  Also wasn't sure whether it's worth putting in a
sentence or two at
> least acknowledging what has happened in the past with User-Agent --
intent would be
> the working group acknowledges this historical misuse and wishes to avoid
it.
>
> New proposed text:
>
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  Functional behavior of the iSCSI
>    node MUST NOT depend on the presence, absence, or content of
>    the key.  The key MUST NOT be used by iSCSI nodes for things
>    such as interoperability, performance, exclusion or deception
>    of other nodes, or other uses not defined here.  To enforce
>    proper use, iSCSI nodes MUST NOT allow user modification of
>    the key value(s), and SHOULD set the value automatically based
>    on standard internal interfaces.
>
>
>
> Original text:
>
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  The key MUST NOT be used by iSCSI
>    nodes for things such as interoperability, performance,
>    exclusion or deception of other nodes, or other uses not
>    defined here.  To enforce proper use, iSCSI nodes MUST NOT
>    allow user modification of the key value(s), and SHOULD set
>    the value automatically based on standard internal interfaces.
>
>
>
>
>
>
> > (3) The draft needs a new title and file name ("supportability" just
> >         reeks of marketing ;-) ).  Let's try:
> >
> >            The iSCSI X#NodeArchitecture Key
> >         draft-ietf-ips-iscsi-nodearch-key-00.txt
> >
> Sounds fine to me.
>
>
> > Text for (1) and (2), or at least initial versions of it should be
> > worked out on the list before the -00 version of the draft-ietf-ips-...
> > draft is submitted.  I've just sent the request to the secretariat for
> > an end-of-2006 completion milestone for this, but in practice, it
> > could be done shortly after Montreal, if not before.
> >
> Great, thanks.
>
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > black_david@emc.com        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> > _______________________________________________
> > Ips mailing list
> > Ips@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ips
> >
>

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 0044D3CC85257149_=-- --===============0174542598== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0174542598==-- From ips-bounces@ietf.org Fri Apr 07 23:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS43m-0002SR-7Q; Fri, 07 Apr 2006 23:24:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS43l-0002SM-O5 for ips@ietf.org; Fri, 07 Apr 2006 23:24:25 -0400 Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS43j-0001eG-TS for ips@ietf.org; Fri, 07 Apr 2006 23:24:25 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k383OM3a020601; Fri, 7 Apr 2006 23:24:23 -0400 (EDT) Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k383OG5I026522; Fri, 7 Apr 2006 23:24:17 -0400 (EDT) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Apr 2006 23:24:16 -0400 Message-ID: From: Black_David@emc.com To: Julian_Satran@il.ibm.com Subject: RE: [Ips] X#NodeArchitecture draft - next steps Date: Fri, 7 Apr 2006 23:24:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.04.07.195105 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_MEDIA_2_BODY 0, __CP_NOT_1 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 0.5 (/) X-Scan-Signature: 9b157e6e8a3799aef911c0bc37fc93a6 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1617919707==" Errors-To: ips-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1617919707== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65ABB.7C9D26A3" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C65ABB.7C9D26A3 Content-Type: text/plain IMHO, a site-wide policy of not using the key is within reason. Obfuscating the value defeats the primary purpose of the key - the interest is in what is *actually* running, not the name of some other implementation that this one ought to be behaviorally indistinguishable from. Not sending the key is a better means of dealing with this concern. Thanks, --David _____ From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, April 07, 2006 8:40 AM To: Black, David Cc: Black, David; davidw@netapp.com; ips@ietf.org Subject: RE: [Ips] X#NodeArchitecture draft - next steps I am not sure that not sending the key is that good a measure (not sending it when it was previously seen is a way of leaking information). I guess what you want to mandate is that the value can be specifically faked (set) and/or responding "not understood". Julo Black_David@emc.com 06/04/06 18:08 To davidw@netapp.com cc ips@ietf.org, Black_David@emc.com Subject RE: [Ips] X#NodeArchitecture draft - next steps Dave, > New proposed text: > > 3. Security Considerations > > In certain environments where security is a primary concern, > the use of this extension key may not be appropriate as it > reveals specific details about an iSCSI node. For these > environments, nodes implementing this public extension key > MUST provide a method to disable sending the key. In > addition to providing a disable mechanism, security sensitive > environments SHOULD consider use of IPsec, as specified in > RFC 3720 and 3723, as a means to shield the contents of this > key from observers of network traffic. Good start, needs editing to something like: This extension key transmits specific implementation details about the node that sends it; such details may be considered sensitive in some environments. For example, if a certain software or firmware version is known to contain security weaknesses, announcing the presence of that version via this key may not be desirable. The countermeasures for this security concern are: - not sending the extension key, or - using IPsec to provide confidentiality for the iSCSI connection on which the key is sent (see RFC 3720 and RFC 3723). To support the first countermeasure, all implementations of this extension key MUST provide an administrative mechanism to disable sending the key. Reasons for the edits: - Focus on specific threat, not general "where security is a primary concern". - Make the "MUST" for disabling transmission of the key globally applicable, vs. possibly scoped to specific environments. This is a "MUST implement" requirement, not "MUST use". - Avoid the "SHOULD ... use ... IPsec" phrasing, at least for now. > New proposed text: > > The following described Public Extension Key is sent during > the login phase of an iSCSI normal session. It is important > to note that the proper use of this key is to provide enhanced > logging and support capabilities, and for better understanding > of customer environments. Functional behavior of the iSCSI > node MUST NOT depend on the presence, absence, or content of > the key. The key MUST NOT be used by iSCSI nodes for things > such as interoperability, performance, exclusion or deception > of other nodes, or other uses not defined here. To enforce > proper use, iSCSI nodes MUST NOT allow user modification of > the key value(s), and SHOULD set the value automatically based > on standard internal interfaces. This one is close - 3 suggestions: - "proper" -> "intended" - remove "and for better understanding of customer environments" or replace it with something more specific like "and to enable collection of iSCSI implementation usage information" - The "such as ... or other uses not defined here" is not sufficiently precise. The last one is crucial - it needs to be easy for an implementer to determine whether s/he's stepped over this line. I'm comfortable with not mentioning the JavaScript and browser versions mess, as I think we all know that it's the motivating example for this text. Thanks, --David (as individual participant, *not* as WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Dave Wysochanski [mailto:davidw@netapp.com] > Sent: Friday, March 31, 2006 9:35 PM > To: Black, David > Cc: ips@ietf.org > Subject: Re: [Ips] X#NodeArchitecture draft - next steps > > Black_David@emc.com wrote: > > > This draft is better known as: > > draft-wysochanski-xkey-iscsi-support-00.txt > > > > This draft will be an official WG draft, but three things > > need to happen first: > > > > (1) New security text. The existing "SHOULD" in the security > > considerations text needs to be a "MUST". In addition, > > there needs to be a sentence pointing out that it may > > be important to shield the contents of this key from > > observers of network traffic, and that IPsec as specified > > for iSCSI in RFC 3720 and 3723 (cite both of them) is an > > appropriate tool for this purpose. > > > New proposed text: > > 3. Security Considerations > > In certain environments where security is a primary concern, > the use of this extension key may not be appropriate as it > reveals specific details about an iSCSI node. For these > environments, nodes implementing this public extension key > MUST provide a method to disable sending the key. In > addition to providing a disable mechanism, security sensitive > environments SHOULD consider use of IPsec, as specified in > RFC 3720 and 3723, as a means to shield the contents of this > key from observers of network traffic. > > > > Original text: > > 3. Security Considerations > > In certain environments where security is a primary concern, > the use of this extension key may not be appropriate as it > reveals specific details about an iSCSI node. For these > environments, nodes implementing this public extension key > SHOULD provide a method to disable sending the key. > > > > > (2) New "prevention of abuse" text. The current "The key MUST NOT > > be used by iSCSI nodes for things such as ..." is well- > > intentioned but does not get the job done. My recollection > > of discussion in Dallas is that saying that "functional behavior > > of the iSCSI node MUST NOT depend on this key (presence/absence > > or value)" may be closer to the mark. The only permitted > > (and intended) use of this key is to report it/log it in order > > to avoid the browser detection JavaScript disasters caused by > > the corresponding HTTP header fields. > > > > I wasn't sure about deleting the original "MUST NOT" sentence so I left it in. Anyone > have a preference? Also wasn't sure whether it's worth putting in a sentence or two at > least acknowledging what has happened in the past with User-Agent -- intent would be > the working group acknowledges this historical misuse and wishes to avoid it. > > New proposed text: > > The following described Public Extension Key is sent during > the login phase of an iSCSI normal session. It is important > to note that the proper use of this key is to provide enhanced > logging and support capabilities, and for better understanding > of customer environments. Functional behavior of the iSCSI > node MUST NOT depend on the presence, absence, or content of > the key. The key MUST NOT be used by iSCSI nodes for things > such as interoperability, performance, exclusion or deception > of other nodes, or other uses not defined here. To enforce > proper use, iSCSI nodes MUST NOT allow user modification of > the key value(s), and SHOULD set the value automatically based > on standard internal interfaces. > > > > Original text: > > The following described Public Extension Key is sent during > the login phase of an iSCSI normal session. It is important > to note that the proper use of this key is to provide enhanced > logging and support capabilities, and for better understanding > of customer environments. The key MUST NOT be used by iSCSI > nodes for things such as interoperability, performance, > exclusion or deception of other nodes, or other uses not > defined here. To enforce proper use, iSCSI nodes MUST NOT > allow user modification of the key value(s), and SHOULD set > the value automatically based on standard internal interfaces. > > > > > > > > (3) The draft needs a new title and file name ("supportability" just > > reeks of marketing ;-) ). Let's try: > > > > The iSCSI X#NodeArchitecture Key > > draft-ietf-ips-iscsi-nodearch-key-00.txt > > > Sounds fine to me. > > > > Text for (1) and (2), or at least initial versions of it should be > > worked out on the list before the -00 version of the draft-ietf-ips-... > > draft is submitted. I've just sent the request to the secretariat for > > an end-of-2006 completion milestone for this, but in practice, it > > could be done shortly after Montreal, if not before. > > > Great, thanks. > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------_=_NextPart_001_01C65ABB.7C9D26A3 Content-Type: text/html
IMHO, a site-wide policy of not using the key is within reason.
Obfuscating the value defeats the primary purpose of the key -
the interest is in what is *actually* running, not the name
of some other implementation that this one ought to be
behaviorally indistinguishable from.  Not sending the key is
a better means of dealing with this concern.
 
Thanks,
--David

From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, April 07, 2006 8:40 AM
To: Black, David
Cc: Black, David; davidw@netapp.com; ips@ietf.org
Subject: RE: [Ips] X#NodeArchitecture draft - next steps


I am not sure that not sending the key is that good a measure (not sending it when it was previously seen is a way of leaking information).
I guess what you want to mandate is that the value can be specifically faked (set) and/or responding "not understood".

Julo


Black_David@emc.com

06/04/06 18:08

To
davidw@netapp.com
cc
ips@ietf.org, Black_David@emc.com
Subject
RE: [Ips] X#NodeArchitecture draft - next steps





Dave,

> New proposed text:
>
> 3.  Security Considerations
>
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node.  For these
>    environments, nodes implementing this public extension key
>    MUST provide a method to disable sending the key.  In
>    addition to providing a disable mechanism, security sensitive
>    environments SHOULD consider use of IPsec, as specified in
>    RFC 3720 and 3723, as a means to shield the contents of this
>    key from observers of network traffic.

Good start, needs editing to something like:

   This extension key transmits specific implementation details
   about the node that sends it; such details may be considered
   sensitive in some environments.  For example, if a certain
   software or firmware version is known to contain security
   weaknesses, announcing the presence of that version via this
   key may not be desirable.  The countermeasures for this
   security concern are:
                - not sending the extension key, or
                - using IPsec to provide confidentiality for the iSCSI
                                 connection on  which the key is sent (see RFC 3720
                                 and RFC 3723).
   To support the first countermeasure, all implementations of
   this extension key MUST provide an administrative mechanism
   to disable sending the key.

Reasons for the edits:
- Focus on specific threat, not general "where security is a primary
                concern".
- Make the "MUST" for disabling transmission of the key globally
                applicable, vs. possibly scoped to specific environments.
                This is a "MUST implement" requirement, not "MUST use".
- Avoid the "SHOULD ... use ... IPsec" phrasing, at least for now.

> New proposed text:
>
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  Functional behavior of the iSCSI
>    node MUST NOT depend on the presence, absence, or content of
>    the key.  The key MUST NOT be used by iSCSI nodes for things
>    such as interoperability, performance, exclusion or deception
>    of other nodes, or other uses not defined here.  To enforce
>    proper use, iSCSI nodes MUST NOT allow user modification of
>    the key value(s), and SHOULD set the value automatically based
>    on standard internal interfaces.

This one is close - 3 suggestions:
- "proper" -> "intended"
- remove "and for better understanding of customer environments" or
                replace it with something more specific like "and to enable
                collection of iSCSI implementation usage information"
- The "such as ... or other uses not defined here" is not sufficiently
                precise.
The last one is crucial - it needs to be easy for an implementer to
determine whether s/he's stepped over this line.

I'm comfortable with not mentioning the JavaScript and browser versions
mess, as I think we all know that it's the motivating example for this
text.

Thanks,
--David (as individual participant, *not* as WG chair)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Dave Wysochanski [mailto:davidw@netapp.com]
> Sent: Friday, March 31, 2006 9:35 PM
> To: Black, David
> Cc: ips@ietf.org
> Subject: Re: [Ips] X#NodeArchitecture draft - next steps
>
> Black_David@emc.com wrote:
>
> > This draft is better known as:
> > draft-wysochanski-xkey-iscsi-support-00.txt
> >
> > This draft will be an official WG draft, but three things
> > need to happen first:
> >
> > (1) New security text.  The existing "SHOULD" in the security
> >         considerations text needs to be a "MUST".  In addition,
> >         there needs to be a sentence pointing out that it may
> >         be important to shield the contents of this key from
> >         observers of network traffic, and that IPsec as specified
> >         for iSCSI in RFC 3720 and 3723 (cite both of them) is an
> >         appropriate tool for this purpose.
> >
> New proposed text:
>
> 3.  Security Considerations
>
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node.  For these
>    environments, nodes implementing this public extension key
>    MUST provide a method to disable sending the key.  In
>    addition to providing a disable mechanism, security sensitive
>    environments SHOULD consider use of IPsec, as specified in
>    RFC 3720 and 3723, as a means to shield the contents of this
>    key from observers of network traffic.
>
>
>
> Original text:      
>
> 3.  Security Considerations
>
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node. For these
>    environments, nodes implementing this public extension key
>    SHOULD provide a method to disable sending the key.
>
>      
>
> > (2) New "prevention of abuse" text.  The current "The key MUST NOT
> >         be used by iSCSI nodes for things such as ..." is well-
> >         intentioned but does not get the job done.  My recollection
> >         of discussion in Dallas is that saying that "functional behavior
> >         of the iSCSI node MUST NOT depend on this key (presence/absence
> >         or value)"  may be closer to the mark.  The only permitted
> >         (and intended) use of this key is to report it/log it in order
> >         to avoid the browser detection JavaScript disasters caused by
> >         the corresponding HTTP header fields.
> >
>
> I wasn't sure about deleting the original "MUST NOT" sentence so I left it
in.  Anyone
> have a preference?  Also wasn't sure whether it's worth putting in a
sentence or two at
> least acknowledging what has happened in the past with User-Agent --
intent would be
> the working group acknowledges this historical misuse and wishes to avoid
it.
>
> New proposed text:
>
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  Functional behavior of the iSCSI
>    node MUST NOT depend on the presence, absence, or content of
>    the key.  The key MUST NOT be used by iSCSI nodes for things
>    such as interoperability, performance, exclusion or deception
>    of other nodes, or other uses not defined here.  To enforce
>    proper use, iSCSI nodes MUST NOT allow user modification of
>    the key value(s), and SHOULD set the value automatically based
>    on standard internal interfaces.
>
>
>
> Original text:
>
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  The key MUST NOT be used by iSCSI
>    nodes for things such as interoperability, performance,
>    exclusion or deception of other nodes, or other uses not
>    defined here.  To enforce proper use, iSCSI nodes MUST NOT
>    allow user modification of the key value(s), and SHOULD set
>    the value automatically based on standard internal interfaces.
>
>
>
>
>
>
> > (3) The draft needs a new title and file name ("supportability" just
> >         reeks of marketing ;-) ).  Let's try:
> >
> >            The iSCSI X#NodeArchitecture Key
> >         draft-ietf-ips-iscsi-nodearch-key-00.txt
> >
> Sounds fine to me.
>
>
> > Text for (1) and (2), or at least initial versions of it should be
> > worked out on the list before the -00 version of the draft-ietf-ips-...
> > draft is submitted.  I've just sent the request to the secretariat for
> > an end-of-2006 completion milestone for this, but in practice, it
> > could be done shortly after Montreal, if not before.
> >
> Great, thanks.
>
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > black_david@emc.com        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> > _______________________________________________
> > Ips mailing list
> > Ips@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ips
> >
>

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

------_=_NextPart_001_01C65ABB.7C9D26A3-- --===============1617919707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1617919707==-- From ips-bounces@ietf.org Sat Apr 08 07:43:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSBqT-0003bN-H1; Sat, 08 Apr 2006 07:43:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSBqQ-0003Vo-Nh for ips@ietf.org; Sat, 08 Apr 2006 07:43:10 -0400 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSBqP-0000oe-FM for ips@ietf.org; Sat, 08 Apr 2006 07:43:10 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.6/8.13.6) with ESMTP id k38Bh8IL110000 for ; Sat, 8 Apr 2006 11:43:08 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k38Bhxna133556 for ; Sat, 8 Apr 2006 13:43:59 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k38Bh8NV004255 for ; Sat, 8 Apr 2006 13:43:08 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k38Bh8th004252; Sat, 8 Apr 2006 13:43:08 +0200 In-Reply-To: To: Black_David@emc.com Subject: RE: [Ips] X#NodeArchitecture draft - next steps MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Sat, 8 Apr 2006 07:43:56 -0400 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0HF90 | November 16, 2005) at 08/04/2006 14:43:57, Serialize complete at 08/04/2006 14:43:57 X-Spam-Score: 0.1 (/) X-Scan-Signature: e02509f7a15c0aaea12155beed3396f0 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1489213573==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1489213573== Content-Type: multipart/alternative; boundary="=_alternative 00405D888525714A_=" This is a multipart message in MIME format. --=_alternative 00405D888525714A_= Content-Type: text/plain; charset="US-ASCII" David, Sites might be small. If a given target code has a known weakness just not answering or even answering "not understood" invites an attack by a scanner. IMHO the best solution would be for the draft to say nothing. Julo Black_David@emc.com 07/04/06 23:24 To Julian Satran/Haifa/IBM@IBMIL cc davidw@netapp.com, ips@ietf.org Subject RE: [Ips] X#NodeArchitecture draft - next steps IMHO, a site-wide policy of not using the key is within reason. Obfuscating the value defeats the primary purpose of the key - the interest is in what is *actually* running, not the name of some other implementation that this one ought to be behaviorally indistinguishable from. Not sending the key is a better means of dealing with this concern. Thanks, --David From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, April 07, 2006 8:40 AM To: Black, David Cc: Black, David; davidw@netapp.com; ips@ietf.org Subject: RE: [Ips] X#NodeArchitecture draft - next steps I am not sure that not sending the key is that good a measure (not sending it when it was previously seen is a way of leaking information). I guess what you want to mandate is that the value can be specifically faked (set) and/or responding "not understood". Julo Black_David@emc.com 06/04/06 18:08 To davidw@netapp.com cc ips@ietf.org, Black_David@emc.com Subject RE: [Ips] X#NodeArchitecture draft - next steps Dave, > New proposed text: > > 3. Security Considerations > > In certain environments where security is a primary concern, > the use of this extension key may not be appropriate as it > reveals specific details about an iSCSI node. For these > environments, nodes implementing this public extension key > MUST provide a method to disable sending the key. In > addition to providing a disable mechanism, security sensitive > environments SHOULD consider use of IPsec, as specified in > RFC 3720 and 3723, as a means to shield the contents of this > key from observers of network traffic. Good start, needs editing to something like: This extension key transmits specific implementation details about the node that sends it; such details may be considered sensitive in some environments. For example, if a certain software or firmware version is known to contain security weaknesses, announcing the presence of that version via this key may not be desirable. The countermeasures for this security concern are: - not sending the extension key, or - using IPsec to provide confidentiality for the iSCSI connection on which the key is sent (see RFC 3720 and RFC 3723). To support the first countermeasure, all implementations of this extension key MUST provide an administrative mechanism to disable sending the key. Reasons for the edits: - Focus on specific threat, not general "where security is a primary concern". - Make the "MUST" for disabling transmission of the key globally applicable, vs. possibly scoped to specific environments. This is a "MUST implement" requirement, not "MUST use". - Avoid the "SHOULD ... use ... IPsec" phrasing, at least for now. > New proposed text: > > The following described Public Extension Key is sent during > the login phase of an iSCSI normal session. It is important > to note that the proper use of this key is to provide enhanced > logging and support capabilities, and for better understanding > of customer environments. Functional behavior of the iSCSI > node MUST NOT depend on the presence, absence, or content of > the key. The key MUST NOT be used by iSCSI nodes for things > such as interoperability, performance, exclusion or deception > of other nodes, or other uses not defined here. To enforce > proper use, iSCSI nodes MUST NOT allow user modification of > the key value(s), and SHOULD set the value automatically based > on standard internal interfaces. This one is close - 3 suggestions: - "proper" -> "intended" - remove "and for better understanding of customer environments" or replace it with something more specific like "and to enable collection of iSCSI implementation usage information" - The "such as ... or other uses not defined here" is not sufficiently precise. The last one is crucial - it needs to be easy for an implementer to determine whether s/he's stepped over this line. I'm comfortable with not mentioning the JavaScript and browser versions mess, as I think we all know that it's the motivating example for this text. Thanks, --David (as individual participant, *not* as WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Dave Wysochanski [mailto:davidw@netapp.com] > Sent: Friday, March 31, 2006 9:35 PM > To: Black, David > Cc: ips@ietf.org > Subject: Re: [Ips] X#NodeArchitecture draft - next steps > > Black_David@emc.com wrote: > > > This draft is better known as: > > draft-wysochanski-xkey-iscsi-support-00.txt > > > > This draft will be an official WG draft, but three things > > need to happen first: > > > > (1) New security text. The existing "SHOULD" in the security > > considerations text needs to be a "MUST". In addition, > > there needs to be a sentence pointing out that it may > > be important to shield the contents of this key from > > observers of network traffic, and that IPsec as specified > > for iSCSI in RFC 3720 and 3723 (cite both of them) is an > > appropriate tool for this purpose. > > > New proposed text: > > 3. Security Considerations > > In certain environments where security is a primary concern, > the use of this extension key may not be appropriate as it > reveals specific details about an iSCSI node. For these > environments, nodes implementing this public extension key > MUST provide a method to disable sending the key. In > addition to providing a disable mechanism, security sensitive > environments SHOULD consider use of IPsec, as specified in > RFC 3720 and 3723, as a means to shield the contents of this > key from observers of network traffic. > > > > Original text: > > 3. Security Considerations > > In certain environments where security is a primary concern, > the use of this extension key may not be appropriate as it > reveals specific details about an iSCSI node. For these > environments, nodes implementing this public extension key > SHOULD provide a method to disable sending the key. > > > > > (2) New "prevention of abuse" text. The current "The key MUST NOT > > be used by iSCSI nodes for things such as ..." is well- > > intentioned but does not get the job done. My recollection > > of discussion in Dallas is that saying that "functional behavior > > of the iSCSI node MUST NOT depend on this key (presence/absence > > or value)" may be closer to the mark. The only permitted > > (and intended) use of this key is to report it/log it in order > > to avoid the browser detection JavaScript disasters caused by > > the corresponding HTTP header fields. > > > > I wasn't sure about deleting the original "MUST NOT" sentence so I left it in. Anyone > have a preference? Also wasn't sure whether it's worth putting in a sentence or two at > least acknowledging what has happened in the past with User-Agent -- intent would be > the working group acknowledges this historical misuse and wishes to avoid it. > > New proposed text: > > The following described Public Extension Key is sent during > the login phase of an iSCSI normal session. It is important > to note that the proper use of this key is to provide enhanced > logging and support capabilities, and for better understanding > of customer environments. Functional behavior of the iSCSI > node MUST NOT depend on the presence, absence, or content of > the key. The key MUST NOT be used by iSCSI nodes for things > such as interoperability, performance, exclusion or deception > of other nodes, or other uses not defined here. To enforce > proper use, iSCSI nodes MUST NOT allow user modification of > the key value(s), and SHOULD set the value automatically based > on standard internal interfaces. > > > > Original text: > > The following described Public Extension Key is sent during > the login phase of an iSCSI normal session. It is important > to note that the proper use of this key is to provide enhanced > logging and support capabilities, and for better understanding > of customer environments. The key MUST NOT be used by iSCSI > nodes for things such as interoperability, performance, > exclusion or deception of other nodes, or other uses not > defined here. To enforce proper use, iSCSI nodes MUST NOT > allow user modification of the key value(s), and SHOULD set > the value automatically based on standard internal interfaces. > > > > > > > > (3) The draft needs a new title and file name ("supportability" just > > reeks of marketing ;-) ). Let's try: > > > > The iSCSI X#NodeArchitecture Key > > draft-ietf-ips-iscsi-nodearch-key-00.txt > > > Sounds fine to me. > > > > Text for (1) and (2), or at least initial versions of it should be > > worked out on the list before the -00 version of the draft-ietf-ips-... > > draft is submitted. I've just sent the request to the secretariat for > > an end-of-2006 completion milestone for this, but in practice, it > > could be done shortly after Montreal, if not before. > > > Great, thanks. > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 00405D888525714A_= Content-Type: text/html; charset="US-ASCII"
David,

Sites might be small. If a given target code has a known weakness just not answering or even answering "not understood" invites an attack by a scanner.
IMHO the best solution would be for the draft to say nothing.

Julo


Black_David@emc.com

07/04/06 23:24

To
Julian Satran/Haifa/IBM@IBMIL
cc
davidw@netapp.com, ips@ietf.org
Subject
RE: [Ips] X#NodeArchitecture draft - next steps





IMHO, a site-wide policy of not using the key is within reason.
Obfuscating the value defeats the primary purpose of the key -
the interest is in what is *actually* running, not the name
of some other implementation that this one ought to be
behaviorally indistinguishable from.  Not sending the key is
a better means of dealing with this concern.
 
Thanks,
--David

From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, April 07, 2006 8:40 AM
To: Black, David
Cc: Black, David; davidw@netapp.com; ips@ietf.org
Subject: RE: [Ips] X#NodeArchitecture draft - next steps

I am not sure that not sending the key is that good a measure (not sending it when it was previously seen is a way of leaking information).
I guess what you want to mandate is that the value can be specifically faked (set) and/or responding "not understood".

Julo

Black_David@emc.com

06/04/06 18:08


To
davidw@netapp.com
cc
ips@ietf.org, Black_David@emc.com
Subject
RE: [Ips] X#NodeArchitecture draft - next steps







Dave,

> New proposed text:
>
> 3.  Security Considerations
>
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node.  For these
>    environments, nodes implementing this public extension key
>    MUST provide a method to disable sending the key.  In
>    addition to providing a disable mechanism, security sensitive
>    environments SHOULD consider use of IPsec, as specified in
>    RFC 3720 and 3723, as a means to shield the contents of this
>    key from observers of network traffic.

Good start, needs editing to something like:

  This extension key transmits specific implementation details
  about the node that sends it; such details may be considered
  sensitive in some environments.  For example, if a certain
  software or firmware version is known to contain security
  weaknesses, announcing the presence of that version via this
  key may not be desirable.  The countermeasures for this
  security concern are:
               - not sending the extension key, or
               - using IPsec to provide confidentiality for the iSCSI
                                connection on  which the key is sent (see RFC 3720
                                and RFC 3723).
  To support the first countermeasure, all implementations of
  this extension key MUST provide an administrative mechanism
  to disable sending the key.

Reasons for the edits:
- Focus on specific threat, not general "where security is a primary
               concern".
- Make the "MUST" for disabling transmission of the key globally
               applicable, vs. possibly scoped to specific environments.
               This is a "MUST implement" requirement, not "MUST use".
- Avoid the "SHOULD ... use ... IPsec" phrasing, at least for now.

> New proposed text:
>
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  Functional behavior of the iSCSI
>    node MUST NOT depend on the presence, absence, or content of
>    the key.  The key MUST NOT be used by iSCSI nodes for things
>    such as interoperability, performance, exclusion or deception
>    of other nodes, or other uses not defined here.  To enforce
>    proper use, iSCSI nodes MUST NOT allow user modification of
>    the key value(s), and SHOULD set the value automatically based
>    on standard internal interfaces.

This one is close - 3 suggestions:
- "proper" -> "intended"
- remove "and for better understanding of customer environments" or
               replace it with something more specific like "and to enable
               collection of iSCSI implementation usage information"
- The "such as ... or other uses not defined here" is not sufficiently
               precise.
The last one is crucial - it needs to be easy for an implementer to
determine whether s/he's stepped over this line.

I'm comfortable with not mentioning the JavaScript and browser versions
mess, as I think we all know that it's the motivating example for this
text.

Thanks,
--David (as individual participant, *not* as WG chair)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Dave Wysochanski [mailto:davidw@netapp.com]
> Sent: Friday, March 31, 2006 9:35 PM
> To: Black, David
> Cc: ips@ietf.org
> Subject: Re: [Ips] X#NodeArchitecture draft - next steps
>
> Black_David@emc.com wrote:
>
> > This draft is better known as:
> > draft-wysochanski-xkey-iscsi-support-00.txt
> >
> > This draft will be an official WG draft, but three things
> > need to happen first:
> >
> > (1) New security text.  The existing "SHOULD" in the security
> >         considerations text needs to be a "MUST".  In addition,
> >         there needs to be a sentence pointing out that it may
> >         be important to shield the contents of this key from
> >         observers of network traffic, and that IPsec as specified
> >         for iSCSI in RFC 3720 and 3723 (cite both of them) is an
> >         appropriate tool for this purpose.
> >
> New proposed text:
>
> 3.  Security Considerations
>
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node.  For these
>    environments, nodes implementing this public extension key
>    MUST provide a method to disable sending the key.  In
>    addition to providing a disable mechanism, security sensitive
>    environments SHOULD consider use of IPsec, as specified in
>    RFC 3720 and 3723, as a means to shield the contents of this
>    key from observers of network traffic.
>
>
>
> Original text:      
>
> 3.  Security Considerations
>
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node. For these
>    environments, nodes implementing this public extension key
>    SHOULD provide a method to disable sending the key.
>
>      
>
> > (2) New "prevention of abuse" text.  The current "The key MUST NOT
> >         be used by iSCSI nodes for things such as ..." is well-
> >         intentioned but does not get the job done.  My recollection
> >         of discussion in Dallas is that saying that "functional behavior
> >         of the iSCSI node MUST NOT depend on this key (presence/absence
> >         or value)"  may be closer to the mark.  The only permitted
> >         (and intended) use of this key is to report it/log it in order
> >         to avoid the browser detection JavaScript disasters caused by
> >         the corresponding HTTP header fields.
> >
>
> I wasn't sure about deleting the original "MUST NOT" sentence so I left it
in.  Anyone
> have a preference?  Also wasn't sure whether it's worth putting in a
sentence or two at
> least acknowledging what has happened in the past with User-Agent --
intent would be
> the working group acknowledges this historical misuse and wishes to avoid
it.
>
> New proposed text:
>
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  Functional behavior of the iSCSI
>    node MUST NOT depend on the presence, absence, or content of
>    the key.  The key MUST NOT be used by iSCSI nodes for things
>    such as interoperability, performance, exclusion or deception
>    of other nodes, or other uses not defined here.  To enforce
>    proper use, iSCSI nodes MUST NOT allow user modification of
>    the key value(s), and SHOULD set the value automatically based
>    on standard internal interfaces.
>
>
>
> Original text:
>
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  The key MUST NOT be used by iSCSI
>    nodes for things such as interoperability, performance,
>    exclusion or deception of other nodes, or other uses not
>    defined here.  To enforce proper use, iSCSI nodes MUST NOT
>    allow user modification of the key value(s), and SHOULD set
>    the value automatically based on standard internal interfaces.
>
>
>
>
>
>
> > (3) The draft needs a new title and file name ("supportability" just
> >         reeks of marketing ;-) ).  Let's try:
> >
> >            The iSCSI X#NodeArchitecture Key
> >         draft-ietf-ips-iscsi-nodearch-key-00.txt
> >
> Sounds fine to me.
>
>
> > Text for (1) and (2), or at least initial versions of it should be
> > worked out on the list before the -00 version of the draft-ietf-ips-...
> > draft is submitted.  I've just sent the request to the secretariat for
> > an end-of-2006 completion milestone for this, but in practice, it
> > could be done shortly after Montreal, if not before.
> >
> Great, thanks.
>
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > black_david@emc.com        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> > _______________________________________________
> > Ips mailing list
> > Ips@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ips
> >
>

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 00405D888525714A_=-- --===============1489213573== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1489213573==-- From ips-bounces@ietf.org Mon Apr 10 08:15:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSvJ4-0007qF-3F; Mon, 10 Apr 2006 08:15:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSvJ2-0007pI-NL for ips@ietf.org; Mon, 10 Apr 2006 08:15:44 -0400 Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSv4G-00067R-BB for ips@ietf.org; Mon, 10 Apr 2006 08:00:29 -0400 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3AC0Rvt004776; Mon, 10 Apr 2006 08:00:27 -0400 (EDT) Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k3AC0JY7010180; Mon, 10 Apr 2006 08:00:20 -0400 (EDT) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Apr 2006 08:00:18 -0400 Message-ID: From: Black_David@emc.com To: Julian_Satran@il.ibm.com Subject: RE: [Ips] X#NodeArchitecture draft - next steps Date: Mon, 10 Apr 2006 08:00:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.04.10.043222 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_MEDIA_2_BODY 0, __CP_NOT_1 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 0.5 (/) X-Scan-Signature: 06321bb70e4329e24fb56a67c5eca3a0 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1153174691==" Errors-To: ips-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1153174691== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65C96.52C1D4CC" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C65C96.52C1D4CC Content-Type: text/plain But sites might not be small, plus some sites might have this concern even when there is no known vulnerability to hide. This security concern is similar to one addressed in the standard SNMP security "boilerplate" - the concern needs to be addressed in something like this fashion, and disabling off sending the key "just in case" is fine. I also disagree with your "invites an attack rationale" - not sending the key might be indicative of a more thorough/aggressive site security policy/posture, in which case an attacker might look elsewhere (e.g., for a site that may be less diligent about keeping patch levels up to date). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _____ From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, April 08, 2006 7:44 AM To: Black, David Cc: davidw@netapp.com; ips@ietf.org Subject: RE: [Ips] X#NodeArchitecture draft - next steps David, Sites might be small. If a given target code has a known weakness just not answering or even answering "not understood" invites an attack by a scanner. IMHO the best solution would be for the draft to say nothing. Julo Black_David@emc.com 07/04/06 23:24 To Julian Satran/Haifa/IBM@IBMIL cc davidw@netapp.com, ips@ietf.org Subject RE: [Ips] X#NodeArchitecture draft - next steps IMHO, a site-wide policy of not using the key is within reason. Obfuscating the value defeats the primary purpose of the key - the interest is in what is *actually* running, not the name of some other implementation that this one ought to be behaviorally indistinguishable from. Not sending the key is a better means of dealing with this concern. Thanks, --David _____ From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, April 07, 2006 8:40 AM To: Black, David Cc: Black, David; davidw@netapp.com; ips@ietf.org Subject: RE: [Ips] X#NodeArchitecture draft - next steps I am not sure that not sending the key is that good a measure (not sending it when it was previously seen is a way of leaking information). I guess what you want to mandate is that the value can be specifically faked (set) and/or responding "not understood". Julo Black_David@emc.com 06/04/06 18:08 To davidw@netapp.com cc ips@ietf.org, Black_David@emc.com Subject RE: [Ips] X#NodeArchitecture draft - next steps Dave, > New proposed text: > > 3. Security Considerations > > In certain environments where security is a primary concern, > the use of this extension key may not be appropriate as it > reveals specific details about an iSCSI node. For these > environments, nodes implementing this public extension key > MUST provide a method to disable sending the key. In > addition to providing a disable mechanism, security sensitive > environments SHOULD consider use of IPsec, as specified in > RFC 3720 and 3723, as a means to shield the contents of this > key from observers of network traffic. Good start, needs editing to something like: This extension key transmits specific implementation details about the node that sends it; such details may be considered sensitive in some environments. For example, if a certain software or firmware version is known to contain security weaknesses, announcing the presence of that version via this key may not be desirable. The countermeasures for this security concern are: - not sending the extension key, or - using IPsec to provide confidentiality for the iSCSI connection on which the key is sent (see RFC 3720 and RFC 3723). To support the first countermeasure, all implementations of this extension key MUST provide an administrative mechanism to disable sending the key. Reasons for the edits: - Focus on specific threat, not general "where security is a primary concern". - Make the "MUST" for disabling transmission of the key globally applicable, vs. possibly scoped to specific environments. This is a "MUST implement" requirement, not "MUST use". - Avoid the "SHOULD ... use ... IPsec" phrasing, at least for now. > New proposed text: > > The following described Public Extension Key is sent during > the login phase of an iSCSI normal session. It is important > to note that the proper use of this key is to provide enhanced > logging and support capabilities, and for better understanding > of customer environments. Functional behavior of the iSCSI > node MUST NOT depend on the presence, absence, or content of > the key. The key MUST NOT be used by iSCSI nodes for things > such as interoperability, performance, exclusion or deception > of other nodes, or other uses not defined here. To enforce > proper use, iSCSI nodes MUST NOT allow user modification of > the key value(s), and SHOULD set the value automatically based > on standard internal interfaces. This one is close - 3 suggestions: - "proper" -> "intended" - remove "and for better understanding of customer environments" or replace it with something more specific like "and to enable collection of iSCSI implementation usage information" - The "such as ... or other uses not defined here" is not sufficiently precise. The last one is crucial - it needs to be easy for an implementer to determine whether s/he's stepped over this line. I'm comfortable with not mentioning the JavaScript and browser versions mess, as I think we all know that it's the motivating example for this text. Thanks, --David (as individual participant, *not* as WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Dave Wysochanski [mailto:davidw@netapp.com] > Sent: Friday, March 31, 2006 9:35 PM > To: Black, David > Cc: ips@ietf.org > Subject: Re: [Ips] X#NodeArchitecture draft - next steps > > Black_David@emc.com wrote: > > > This draft is better known as: > > draft-wysochanski-xkey-iscsi-support-00.txt > > > > This draft will be an official WG draft, but three things > > need to happen first: > > > > (1) New security text. The existing "SHOULD" in the security > > considerations text needs to be a "MUST". In addition, > > there needs to be a sentence pointing out that it may > > be important to shield the contents of this key from > > observers of network traffic, and that IPsec as specified > > for iSCSI in RFC 3720 and 3723 (cite both of them) is an > > appropriate tool for this purpose. > > > New proposed text: > > 3. Security Considerations > > In certain environments where security is a primary concern, > the use of this extension key may not be appropriate as it > reveals specific details about an iSCSI node. For these > environments, nodes implementing this public extension key > MUST provide a method to disable sending the key. In > addition to providing a disable mechanism, security sensitive > environments SHOULD consider use of IPsec, as specified in > RFC 3720 and 3723, as a means to shield the contents of this > key from observers of network traffic. > > > > Original text: > > 3. Security Considerations > > In certain environments where security is a primary concern, > the use of this extension key may not be appropriate as it > reveals specific details about an iSCSI node. For these > environments, nodes implementing this public extension key > SHOULD provide a method to disable sending the key. > > > > > (2) New "prevention of abuse" text. The current "The key MUST NOT > > be used by iSCSI nodes for things such as ..." is well- > > intentioned but does not get the job done. My recollection > > of discussion in Dallas is that saying that "functional behavior > > of the iSCSI node MUST NOT depend on this key (presence/absence > > or value)" may be closer to the mark. The only permitted > > (and intended) use of this key is to report it/log it in order > > to avoid the browser detection JavaScript disasters caused by > > the corresponding HTTP header fields. > > > > I wasn't sure about deleting the original "MUST NOT" sentence so I left it in. Anyone > have a preference? Also wasn't sure whether it's worth putting in a sentence or two at > least acknowledging what has happened in the past with User-Agent -- intent would be > the working group acknowledges this historical misuse and wishes to avoid it. > > New proposed text: > > The following described Public Extension Key is sent during > the login phase of an iSCSI normal session. It is important > to note that the proper use of this key is to provide enhanced > logging and support capabilities, and for better understanding > of customer environments. Functional behavior of the iSCSI > node MUST NOT depend on the presence, absence, or content of > the key. The key MUST NOT be used by iSCSI nodes for things > such as interoperability, performance, exclusion or deception > of other nodes, or other uses not defined here. To enforce > proper use, iSCSI nodes MUST NOT allow user modification of > the key value(s), and SHOULD set the value automatically based > on standard internal interfaces. > > > > Original text: > > The following described Public Extension Key is sent during > the login phase of an iSCSI normal session. It is important > to note that the proper use of this key is to provide enhanced > logging and support capabilities, and for better understanding > of customer environments. The key MUST NOT be used by iSCSI > nodes for things such as interoperability, performance, > exclusion or deception of other nodes, or other uses not > defined here. To enforce proper use, iSCSI nodes MUST NOT > allow user modification of the key value(s), and SHOULD set > the value automatically based on standard internal interfaces. > > > > > > > > (3) The draft needs a new title and file name ("supportability" just > > reeks of marketing ;-) ). Let's try: > > > > The iSCSI X#NodeArchitecture Key > > draft-ietf-ips-iscsi-nodearch-key-00.txt > > > Sounds fine to me. > > > > Text for (1) and (2), or at least initial versions of it should be > > worked out on the list before the -00 version of the draft-ietf-ips-... > > draft is submitted. I've just sent the request to the secretariat for > > an end-of-2006 completion milestone for this, but in practice, it > > could be done shortly after Montreal, if not before. > > > Great, thanks. > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------_=_NextPart_001_01C65C96.52C1D4CC Content-Type: text/html
But sites might not be small, plus some sites might have this
concern even when there is no known vulnerability to hide.  This
security concern is similar to one addressed in the standard SNMP
security "boilerplate" - the concern needs to be addressed in something
like this fashion, and disabling off sending the key "just in
case" is fine.  I also disagree with your "invites an attack
rationale" - not sending the key might be indicative of a more
thorough/aggressive site security policy/posture, in which case
an attacker might look elsewhere (e.g., for a site that may be
less diligent about keeping patch levels up to date).
 
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------
 
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, April 08, 2006 7:44 AM
To: Black, David
Cc: davidw@netapp.com; ips@ietf.org
Subject: RE: [Ips] X#NodeArchitecture draft - next steps


David,

Sites might be small. If a given target code has a known weakness just not answering or even answering "not understood" invites an attack by a scanner.
IMHO the best solution would be for the draft to say nothing.

Julo


Black_David@emc.com

07/04/06 23:24

To
Julian Satran/Haifa/IBM@IBMIL
cc
davidw@netapp.com, ips@ietf.org
Subject
RE: [Ips] X#NodeArchitecture draft - next steps





IMHO, a site-wide policy of not using the key is within reason.
Obfuscating the value defeats the primary purpose of the key -
the interest is in what is *actually* running, not the name
of some other implementation that this one ought to be
behaviorally indistinguishable from.  Not sending the key is
a better means of dealing with this concern.
 
Thanks,
--David

From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, April 07, 2006 8:40 AM
To: Black, David
Cc: Black, David; davidw@netapp.com; ips@ietf.org
Subject: RE: [Ips] X#NodeArchitecture draft - next steps


I am not sure that not sending the key is that good a measure (not sending it when it was previously seen is a way of leaking information).
I guess what you want to mandate is that the value can be specifically faked (set) and/or responding "not understood".

Julo

Black_David@emc.com

06/04/06 18:08


To
davidw@netapp.com
cc
ips@ietf.org, Black_David@emc.com
Subject
RE: [Ips] X#NodeArchitecture draft - next steps







Dave,

> New proposed text:
>
> 3.  Security Considerations
>
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node.  For these
>    environments, nodes implementing this public extension key
>    MUST provide a method to disable sending the key.  In
>    addition to providing a disable mechanism, security sensitive
>    environments SHOULD consider use of IPsec, as specified in
>    RFC 3720 and 3723, as a means to shield the contents of this
>    key from observers of network traffic.

Good start, needs editing to something like:

  This extension key transmits specific implementation details
  about the node that sends it; such details may be considered
  sensitive in some environments.  For example, if a certain
  software or firmware version is known to contain security
  weaknesses, announcing the presence of that version via this
  key may not be desirable.  The countermeasures for this
  security concern are:
               - not sending the extension key, or
               - using IPsec to provide confidentiality for the iSCSI
                                connection on  which the key is sent (see RFC 3720
                                and RFC 3723).
  To support the first countermeasure, all implementations of
  this extension key MUST provide an administrative mechanism
  to disable sending the key.

Reasons for the edits:
- Focus on specific threat, not general "where security is a primary
               concern".
- Make the "MUST" for disabling transmission of the key globally
               applicable, vs. possibly scoped to specific environments.
               This is a "MUST implement" requirement, not "MUST use".
- Avoid the "SHOULD ... use ... IPsec" phrasing, at least for now.

> New proposed text:
>
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  Functional behavior of the iSCSI
>    node MUST NOT depend on the presence, absence, or content of
>    the key.  The key MUST NOT be used by iSCSI nodes for things
>    such as interoperability, performance, exclusion or deception
>    of other nodes, or other uses not defined here.  To enforce
>    proper use, iSCSI nodes MUST NOT allow user modification of
>    the key value(s), and SHOULD set the value automatically based
>    on standard internal interfaces.

This one is close - 3 suggestions:
- "proper" -> "intended"
- remove "and for better understanding of customer environments" or
               replace it with something more specific like "and to enable
               collection of iSCSI implementation usage information"
- The "such as ... or other uses not defined here" is not sufficiently
               precise.
The last one is crucial - it needs to be easy for an implementer to
determine whether s/he's stepped over this line.

I'm comfortable with not mentioning the JavaScript and browser versions
mess, as I think we all know that it's the motivating example for this
text.

Thanks,
--David (as individual participant, *not* as WG chair)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Dave Wysochanski [mailto:davidw@netapp.com]
> Sent: Friday, March 31, 2006 9:35 PM
> To: Black, David
> Cc: ips@ietf.org
> Subject: Re: [Ips] X#NodeArchitecture draft - next steps
>
> Black_David@emc.com wrote:
>
> > This draft is better known as:
> > draft-wysochanski-xkey-iscsi-support-00.txt
> >
> > This draft will be an official WG draft, but three things
> > need to happen first:
> >
> > (1) New security text.  The existing "SHOULD" in the security
> >         considerations text needs to be a "MUST".  In addition,
> >         there needs to be a sentence pointing out that it may
> >         be important to shield the contents of this key from
> >         observers of network traffic, and that IPsec as specified
> >         for iSCSI in RFC 3720 and 3723 (cite both of them) is an
> >         appropriate tool for this purpose.
> >
> New proposed text:
>
> 3.  Security Considerations
>
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node.  For these
>    environments, nodes implementing this public extension key
>    MUST provide a method to disable sending the key.  In
>    addition to providing a disable mechanism, security sensitive
>    environments SHOULD consider use of IPsec, as specified in
>    RFC 3720 and 3723, as a means to shield the contents of this
>    key from observers of network traffic.
>
>
>
> Original text:      
>
> 3.  Security Considerations
>
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node. For these
>    environments, nodes implementing this public extension key
>    SHOULD provide a method to disable sending the key.
>
>      
>
> > (2) New "prevention of abuse" text.  The current "The key MUST NOT
> >         be used by iSCSI nodes for things such as ..." is well-
> >         intentioned but does not get the job done.  My recollection
> >         of discussion in Dallas is that saying that "functional behavior
> >         of the iSCSI node MUST NOT depend on this key (presence/absence
> >         or value)"  may be closer to the mark.  The only permitted
> >         (and intended) use of this key is to report it/log it in order
> >         to avoid the browser detection JavaScript disasters caused by
> >         the corresponding HTTP header fields.
> >
>
> I wasn't sure about deleting the original "MUST NOT" sentence so I left it
in.  Anyone
> have a preference?  Also wasn't sure whether it's worth putting in a
sentence or two at
> least acknowledging what has happened in the past with User-Agent --
intent would be
> the working group acknowledges this historical misuse and wishes to avoid
it.
>
> New proposed text:
>
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  Functional behavior of the iSCSI
>    node MUST NOT depend on the presence, absence, or content of
>    the key.  The key MUST NOT be used by iSCSI nodes for things
>    such as interoperability, performance, exclusion or deception
>    of other nodes, or other uses not defined here.  To enforce
>    proper use, iSCSI nodes MUST NOT allow user modification of
>    the key value(s), and SHOULD set the value automatically based
>    on standard internal interfaces.
>
>
>
> Original text:
>
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  The key MUST NOT be used by iSCSI
>    nodes for things such as interoperability, performance,
>    exclusion or deception of other nodes, or other uses not
>    defined here.  To enforce proper use, iSCSI nodes MUST NOT
>    allow user modification of the key value(s), and SHOULD set
>    the value automatically based on standard internal interfaces.
>
>
>
>
>
>
> > (3) The draft needs a new title and file name ("supportability" just
> >         reeks of marketing ;-) ).  Let's try:
> >
> >            The iSCSI X#NodeArchitecture Key
> >         draft-ietf-ips-iscsi-nodearch-key-00.txt
> >
> Sounds fine to me.
>
>
> > Text for (1) and (2), or at least initial versions of it should be
> > worked out on the list before the -00 version of the draft-ietf-ips-...
> > draft is submitted.  I've just sent the request to the secretariat for
> > an end-of-2006 completion milestone for this, but in practice, it
> > could be done shortly after Montreal, if not before.
> >
> Great, thanks.
>
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > black_david@emc.com        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> > _______________________________________________
> > Ips mailing list
> > Ips@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ips
> >
>

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

------_=_NextPart_001_01C65C96.52C1D4CC-- --===============1153174691== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1153174691==-- From ips-bounces@ietf.org Tue Apr 11 19:29:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTSIo-0002cq-Dz; Tue, 11 Apr 2006 19:29:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTSIl-0002Zt-6J; Tue, 11 Apr 2006 19:29:39 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTSIk-0001zm-RL; Tue, 11 Apr 2006 19:29:39 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k3BNTcY7023623; Tue, 11 Apr 2006 16:29:38 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k3BNTbnA023622; Tue, 11 Apr 2006 16:29:37 -0700 Date: Tue, 11 Apr 2006 16:29:37 -0700 Message-Id: <200604112329.k3BNTbnA023622@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ips@ietf.org, rfc-editor@rfc-editor.org Subject: [Ips] RFC 4455 on Definition of Managed Objects for Small Computer System Interface (SCSI) Entities X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4455 Title: Definition of Managed Objects for Small Computer System Interface (SCSI) Entities Author: M. Hallak-Stamler, M. Bakke, Y. Lederman, M. Krueger, K. McCloghrie Status: Standards Track Date: April 2006 Mailbox: michele@sanrad.com, mbakke@cisco.com, yaronled@bezeqint.net, marjorie_krueger@hp.com, kzm@cisco.com Pages: 88 Characters: 178947 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ips-scsi-mib-09.txt URL: http://www.rfc-editor.org/rfc/rfc4455.txt This memo defines a portion of the Management Information Base (MIB), for use with network management protocols in the Internet community. In particular, it describes managed objects for Small Computer System Interface (SCSI) entities, independently of the interconnect subsystem layer. [STANDARDS TRACK] This document is a product of the IP Storage Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Apr 14 07:57:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUMvH-0002z3-MW; Fri, 14 Apr 2006 07:57:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUMvG-0002u3-80 for ips@ietf.org; Fri, 14 Apr 2006 07:57:10 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUMvE-00074T-1g for ips@ietf.org; Fri, 14 Apr 2006 07:57:10 -0400 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 14 Apr 2006 04:57:08 -0700 X-IronPort-AV: i="4.04,120,1144047600"; d="scan'208,217"; a="374483002:sNHT37221636" Received: from [10.30.24.89] ([10.30.24.89]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k3EBv58B021076; Fri, 14 Apr 2006 04:57:05 -0700 (PDT) Message-ID: <443F8E11.2090502@netapp.com> Date: Fri, 14 Apr 2006 07:57:05 -0400 From: Dave Wysochanski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [Ips] X#NodeArchitecture draft - next steps References: In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 826b8da4948b827b02e4b599895c9e48 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0338111322==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0338111322== Content-Type: multipart/alternative; boundary="------------020200090200020201050605" This is a multi-part message in MIME format. --------------020200090200020201050605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Black_David@emc.com wrote: > Dave, > > > New proposed text: > > > > 3. Security Considerations > > > > In certain environments where security is a primary concern, > > the use of this extension key may not be appropriate as it > > reveals specific details about an iSCSI node. For these > > environments, nodes implementing this public extension key > > MUST provide a method to disable sending the key. In > > addition to providing a disable mechanism, security sensitive > > environments SHOULD consider use of IPsec, as specified in > > RFC 3720 and 3723, as a means to shield the contents of this > > key from observers of network traffic. > > Good start, needs editing to something like: > > This extension key transmits specific implementation details > about the node that sends it; such details may be considered > sensitive in some environments. For example, if a certain > software or firmware version is known to contain security > weaknesses, announcing the presence of that version via this > key may not be desirable. The countermeasures for this > security concern are: > How about another option: - sending less detailed information in the key values Security concerns could also be lessened by sending less detailed information, such as omitting the version numbers of things (for example, send "Microsoft Windows, software initiator" instead of "Microsoft Windows 2003, software initiator version 1.2.3.4"). I will have to rework the format of the key a bit but this seems worth doing. Hopefully there is a reasonable level of information that most people will find acceptable transmitting by default while not greatly compromising security. > - not sending the extension key, or > > - using IPsec to provide confidentiality for the iSCSI > connection on which the key is sent (see RFC 3720 > and RFC 3723). > To support the first countermeasure, all implementations of > this extension key MUST provide an administrative mechanism > to disable sending the key. > This sentence then becomes something like. To support the first and second countermeasures, all implementations of this extension key SHOULD provide a way to configure different levels of detail in the extension key values and MUST provide an administrative mechanism to disable sending the key. > Reasons for the edits: > - Focus on specific threat, not general "where security is a primary > concern". > - Make the "MUST" for disabling transmission of the key globally > applicable, vs. possibly scoped to specific environments. > This is a "MUST implement" requirement, not "MUST use". > - Avoid the "SHOULD ... use ... IPsec" phrasing, at least for now. > > > New proposed text: > > > > The following described Public Extension Key is sent during > > the login phase of an iSCSI normal session. It is important > > to note that the proper use of this key is to provide enhanced > > logging and support capabilities, and for better understanding > > of customer environments. Functional behavior of the iSCSI > > node MUST NOT depend on the presence, absence, or content of > > the key. The key MUST NOT be used by iSCSI nodes for things > > such as interoperability, performance, exclusion or deception > > of other nodes, or other uses not defined here. To enforce > > proper use, iSCSI nodes MUST NOT allow user modification of > > the key value(s), and SHOULD set the value automatically based > > on standard internal interfaces. > > This one is close - 3 suggestions: > - "proper" -> "intended" > - remove "and for better understanding of customer environments" or > replace it with something more specific like "and to enable > collection of iSCSI implementation usage information" > - The "such as ... or other uses not defined here" is not sufficiently > precise. > The last one is crucial - it needs to be easy for an implementer to > determine whether s/he's stepped over this line. > > I'm comfortable with not mentioning the JavaScript and browser versions > mess, as I think we all know that it's the motivating example for this > text. > > Thanks, > --David (as individual participant, *not* as WG chair) > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > -----Original Message----- > > From: Dave Wysochanski [mailto:davidw@netapp.com] > > Sent: Friday, March 31, 2006 9:35 PM > > To: Black, David > > Cc: ips@ietf.org > > Subject: Re: [Ips] X#NodeArchitecture draft - next steps > > > > Black_David@emc.com wrote: > > > > > This draft is better known as: > > > draft-wysochanski-xkey-iscsi-support-00.txt > > > > > > This draft will be an official WG draft, but three things > > > need to happen first: > > > > > > (1) New security text. The existing "SHOULD" in the security > > > considerations text needs to be a "MUST". In addition, > > > there needs to be a sentence pointing out that it may > > > be important to shield the contents of this key from > > > observers of network traffic, and that IPsec as specified > > > for iSCSI in RFC 3720 and 3723 (cite both of them) is an > > > appropriate tool for this purpose. > > > > > New proposed text: > > > > 3. Security Considerations > > > > In certain environments where security is a primary concern, > > the use of this extension key may not be appropriate as it > > reveals specific details about an iSCSI node. For these > > environments, nodes implementing this public extension key > > MUST provide a method to disable sending the key. In > > addition to providing a disable mechanism, security sensitive > > environments SHOULD consider use of IPsec, as specified in > > RFC 3720 and 3723, as a means to shield the contents of this > > key from observers of network traffic. > > > > > > > > Original text: > > > > 3. Security Considerations > > > > In certain environments where security is a primary concern, > > the use of this extension key may not be appropriate as it > > reveals specific details about an iSCSI node. For these > > environments, nodes implementing this public extension key > > SHOULD provide a method to disable sending the key. > > > > > > > > > (2) New "prevention of abuse" text. The current "The key MUST NOT > > > be used by iSCSI nodes for things such as ..." is well- > > > intentioned but does not get the job done. My recollection > > > of discussion in Dallas is that saying that "functional > behavior > > > of the iSCSI node MUST NOT depend on this key > (presence/absence > > > or value)" may be closer to the mark. The only permitted > > > (and intended) use of this key is to report it/log it in > order > > > to avoid the browser detection JavaScript disasters caused by > > > the corresponding HTTP header fields. > > > > > > > I wasn't sure about deleting the original "MUST NOT" sentence so I > left it > in. Anyone > > have a preference? Also wasn't sure whether it's worth putting in a > sentence or two at > > least acknowledging what has happened in the past with User-Agent -- > intent would be > > the working group acknowledges this historical misuse and wishes to > avoid > it. > > > > New proposed text: > > > > The following described Public Extension Key is sent during > > the login phase of an iSCSI normal session. It is important > > to note that the proper use of this key is to provide enhanced > > logging and support capabilities, and for better understanding > > of customer environments. Functional behavior of the iSCSI > > node MUST NOT depend on the presence, absence, or content of > > the key. The key MUST NOT be used by iSCSI nodes for things > > such as interoperability, performance, exclusion or deception > > of other nodes, or other uses not defined here. To enforce > > proper use, iSCSI nodes MUST NOT allow user modification of > > the key value(s), and SHOULD set the value automatically based > > on standard internal interfaces. > > > > > > > > Original text: > > > > The following described Public Extension Key is sent during > > the login phase of an iSCSI normal session. It is important > > to note that the proper use of this key is to provide enhanced > > logging and support capabilities, and for better understanding > > of customer environments. The key MUST NOT be used by iSCSI > > nodes for things such as interoperability, performance, > > exclusion or deception of other nodes, or other uses not > > defined here. To enforce proper use, iSCSI nodes MUST NOT > > allow user modification of the key value(s), and SHOULD set > > the value automatically based on standard internal interfaces. > > > > > > > > > > > > > > > (3) The draft needs a new title and file name ("supportability" just > > > reeks of marketing ;-) ). Let's try: > > > > > > The iSCSI X#NodeArchitecture Key > > > draft-ietf-ips-iscsi-nodearch-key-00.txt > > > > > Sounds fine to me. > > > > > > > Text for (1) and (2), or at least initial versions of it should be > > > worked out on the list before the -00 version of the > draft-ietf-ips-... > > > draft is submitted. I've just sent the request to the secretariat > for > > > an end-of-2006 completion milestone for this, but in practice, it > > > could be done shortly after Montreal, if not before. > > > > > Great, thanks. > > > > > Thanks, > > > --David > > > ---------------------------------------------------- > > > David L. Black, Senior Technologist > > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > ---------------------------------------------------- > > > > > > _______________________________________________ > > > Ips mailing list > > > Ips@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ips > > > > > > --------------020200090200020201050605 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Black_David@emc.com wrote:
RE: [Ips] X#NodeArchitecture draft - next steps

Dave,

> New proposed text:
>
> 3.  Security Considerations
>
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node.  For these
>    environments, nodes implementing this public extension key
>    MUST provide a method to disable sending the key.  In
>    addition to providing a disable mechanism, security sensitive
>    environments SHOULD consider use of IPsec, as specified in
>    RFC 3720 and 3723, as a means to shield the contents of this
>    key from observers of network traffic.

Good start, needs editing to something like:

    This extension key transmits specific implementation details
    about the node that sends it; such details may be considered
    sensitive in some environments.  For example, if a certain
    software or firmware version is known to contain security
    weaknesses, announcing the presence of that version via this
    key may not be desirable.  The countermeasures for this
    security concern are:

How about another option:
             - sending less detailed information in the key values

Security concerns could also be lessened by sending less
detailed information, such as omitting the version numbers of
things (for example, send "Microsoft Windows, software initiator"
instead of  "Microsoft Windows 2003, software initiator version 1.2.3.4").
I will have to rework the format of the key a bit but this seems
worth doing.  Hopefully there is a reasonable level of information
that most people will find acceptable transmitting by default while
not greatly compromising security.


        - not sending the extension key, or





        - using IPsec to provide confidentiality for the iSCSI
                connection on  which the key is sent (see RFC 3720
                and RFC 3723).
    To support the first countermeasure, all implementations of
    this extension key MUST provide an administrative mechanism
    to disable sending the key.

This sentence then becomes something like.

To support the first and second countermeasures, all implementations
of this extension key SHOULD provide a way to configure different
levels of detail in the extension key values and MUST provide an
administrative mechanism to disable sending the key.

Reasons for the edits:
- Focus on specific threat, not general "where security is a primary
        concern".
- Make the "MUST" for disabling transmission of the key globally
        applicable, vs. possibly scoped to specific environments.
        This is a "MUST implement" requirement, not "MUST use".
- Avoid the "SHOULD ... use ... IPsec" phrasing, at least for now.

> New proposed text:
>
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  Functional behavior of the iSCSI
>    node MUST NOT depend on the presence, absence, or content of
>    the key.  The key MUST NOT be used by iSCSI nodes for things
>    such as interoperability, performance, exclusion or deception
>    of other nodes, or other uses not defined here.  To enforce
>    proper use, iSCSI nodes MUST NOT allow user modification of
>    the key value(s), and SHOULD set the value automatically based
>    on standard internal interfaces.

This one is close - 3 suggestions:
- "proper" -> "intended"
- remove "and for better understanding of customer environments" or
        replace it with something more specific like "and to enable
        collection of iSCSI implementation usage information"
- The "such as ... or other uses not defined here" is not sufficiently
        precise.
The last one is crucial - it needs to be easy for an implementer to
determine whether s/he's stepped over this line.

I'm comfortable with not mentioning the JavaScript and browser versions
mess, as I think we all know that it's the motivating example for this
text.

Thanks,
--David (as individual participant, *not* as WG chair)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Dave Wysochanski [mailto:davidw@netapp.com]
> Sent: Friday, March 31, 2006 9:35 PM
> To: Black, David
> Cc: ips@ietf.org
> Subject: Re: [Ips] X#NodeArchitecture draft - next steps
>
> Black_David@emc.com wrote:
>
> > This draft is better known as:
> > draft-wysochanski-xkey-iscsi-support-00.txt
> >
> > This draft will be an official WG draft, but three things
> > need to happen first:
> >
> > (1) New security text.  The existing "SHOULD" in the security
> >         considerations text needs to be a "MUST".  In addition,
> >         there needs to be a sentence pointing out that it may
> >         be important to shield the contents of this key from
> >         observers of network traffic, and that IPsec as specified
> >         for iSCSI in RFC 3720 and 3723 (cite both of them) is an
> >         appropriate tool for this purpose.
> >
> New proposed text:
>
> 3.  Security Considerations
>
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node.  For these
>    environments, nodes implementing this public extension key
>    MUST provide a method to disable sending the key.  In
>    addition to providing a disable mechanism, security sensitive
>    environments SHOULD consider use of IPsec, as specified in
>    RFC 3720 and 3723, as a means to shield the contents of this
>    key from observers of network traffic.
>
>
>
> Original text:     
>
> 3.  Security Considerations
>
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node. For these
>    environments, nodes implementing this public extension key
>    SHOULD provide a method to disable sending the key.
>
>      
>
> > (2) New "prevention of abuse" text.  The current "The key MUST NOT
> >         be used by iSCSI nodes for things such as ..." is well-
> >         intentioned but does not get the job done.  My recollection
> >         of discussion in Dallas is that saying that "functional behavior
> >         of the iSCSI node MUST NOT depend on this key (presence/absence
> >         or value)"  may be closer to the mark.  The only permitted
> >         (and intended) use of this key is to report it/log it in order
> >         to avoid the browser detection JavaScript disasters caused by
> >         the corresponding HTTP header fields.
> >
>
> I wasn't sure about deleting the original "MUST NOT" sentence so I left it
in.  Anyone
> have a preference?  Also wasn't sure whether it's worth putting in a
sentence or two at
> least acknowledging what has happened in the past with User-Agent --
intent would be
> the working group acknowledges this historical misuse and wishes to avoid
it.
>
> New proposed text:
>
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  Functional behavior of the iSCSI
>    node MUST NOT depend on the presence, absence, or content of
>    the key.  The key MUST NOT be used by iSCSI nodes for things
>    such as interoperability, performance, exclusion or deception
>    of other nodes, or other uses not defined here.  To enforce
>    proper use, iSCSI nodes MUST NOT allow user modification of
>    the key value(s), and SHOULD set the value automatically based
>    on standard internal interfaces.
>
>
>
> Original text:
>
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  The key MUST NOT be used by iSCSI
>    nodes for things such as interoperability, performance,
>    exclusion or deception of other nodes, or other uses not
>    defined here.  To enforce proper use, iSCSI nodes MUST NOT
>    allow user modification of the key value(s), and SHOULD set
>    the value automatically based on standard internal interfaces.
>
>
>
>
>
>
> > (3) The draft needs a new title and file name ("supportability" just
> >         reeks of marketing ;-) ).  Let's try:
> >
> >            The iSCSI X#NodeArchitecture Key
> >         draft-ietf-ips-iscsi-nodearch-key-00.txt
> >
> Sounds fine to me.
>
>
> > Text for (1) and (2), or at least initial versions of it should be
> > worked out on the list before the -00 version of the draft-ietf-ips-...
> > draft is submitted.  I've just sent the request to the secretariat for
> > an end-of-2006 completion milestone for this, but in practice, it
> > could be done shortly after Montreal, if not before.
> >
> Great, thanks.
>
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > black_david@emc.com        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> > _______________________________________________
> > Ips mailing list
> > Ips@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ips
> >
>


--------------020200090200020201050605-- --===============0338111322== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0338111322==-- From ips-bounces@ietf.org Mon Apr 17 14:55:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVYsL-0005qD-7K; Mon, 17 Apr 2006 14:55:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVYsK-0005q7-0Z for ips@ietf.org; Mon, 17 Apr 2006 14:55:04 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVYsI-0006ev-PI for ips@ietf.org; Mon, 17 Apr 2006 14:55:03 -0400 Received: from ivvtdkv0981 (c-66-177-56-218.hsd1.fl.comcast.net[66.177.56.218]) by comcast.net (sccrmhc14) with SMTP id <200604171855010140089fb6e>; Mon, 17 Apr 2006 18:55:02 +0000 Message-ID: <000801c66250$6ecf8f80$06031eac@ivivity.com> From: "Eddy Quicksall" To: Date: Mon, 17 Apr 2006 14:55:01 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Ips] MPA alignment X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0041113922==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0041113922== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C6622E.E71BE320" This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C6622E.E71BE320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It is preferable to have TCP sender to align MPA header where a TCP = segment begins and to keep the MPA FPDU within a TCP segment, so that = the receiver hardware doesn't need to temporarily buffer the FPDU for = the CRC checking. =20 Does anyone know of any software or hardware that is not an FPDU = alignment sender? Does anyone have a feel for the likelihood of software or hardware to = not align FPDU's on a TCP segment? Eddy ------=_NextPart_000_0005_01C6622E.E71BE320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It is = preferable to have=20 TCP sender to align MPA header where a TCP segment begins and to = keep the=20 MPA FPDU within a TCP segment, so that the receiver hardware doesn=92t=20 need to temporarily buffer the FPDU for the CRC checking. =20
 
Does anyone = know of any=20 software or hardware that is not an FPDU alignment sender?
Does anyone = have a feel=20 for the likelihood of software or hardware to not align FPDU's on a TCP=20 segment?
 
Eddy
------=_NextPart_000_0005_01C6622E.E71BE320-- --===============0041113922== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0041113922==-- From ips-bounces@ietf.org Mon Apr 17 17:49:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVbac-00037j-Jm; Mon, 17 Apr 2006 17:48:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVbab-00037b-04 for ips@ietf.org; Mon, 17 Apr 2006 17:48:57 -0400 Received: from ausc60pc101.us.dell.com ([143.166.85.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVbaZ-0007T9-L8 for ips@ietf.org; Mon, 17 Apr 2006 17:48:56 -0400 DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; b=e44hxeu+oBbbYHw3F11Q47sd7dp9xxyA1KAhDj6av9bG2ONE2osQevEtx6358F0Mc06kd6kana21tG5zZMXNEvarfhIiCWvBt2uq0nRgRT/JY63yEmbObbMoBnv1GJ0V; Received: from ausx3bpc102.aus.amer.dell.com ([10.30.101.52]) by ausc60pc101.us.dell.com with ESMTP; 17 Apr 2006 16:48:55 -0500 X-IronPort-AV: i="4.04,127,1144040400"; d="scan'208,217"; a="1300056:sNHT54913599" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Apr 2006 16:48:49 -0500 Message-ID: <389040536173ED4AADA5EFEA9633358601677A0C@ausx3mpc106.aus.amer.dell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Target Behavior Clarifications Thread-Index: AcZiaKyilbQPptAyRXCgqwphG3vJGw== From: To: X-OriginalArrivalTime: 17 Apr 2006 21:48:52.0474 (UTC) FILETIME=[B7B34DA0:01C66268] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Subject: [Ips] Target Behavior Clarifications X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1154509896==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1154509896== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66268.B6242447" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66268.B6242447 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A couple of quick questions? 1) What should the behavior of a target be if it receives a PDU on a connection, larger than what it declared with MaxRecvDataSegmentLength: - If the PDU is part of a SCSI command?=20 - If the PDU is part of a login? 2) What should the target behaviour be if the initiator sends it more data than MaxBurstLength? 3) What should the target behavior be if the initiator sends more data than FirstBurstLength? Any clarification would be greatly appreciated.=20 Thanks, Jacob ------_=_NextPart_001_01C66268.B6242447 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Target Behavior Clarifications

A couple of quick = questions?

1) What should = the behavior of a target be if it receives a PDU on a connection, larger than what it declared with MaxRecvDataSegmentLength:

- If the PDU is part of a = SCSI command?

- = If the PDU is part of a = login?

2) What should the target behaviour be = if the initiator sends it more data = than = MaxBurstLength?

3) = What should the target behavior be if the initiator sends = more data than FirstBurstLength?

Any = clarification would be greatly appreciated.

Thanks,

Jacob


------_=_NextPart_001_01C66268.B6242447-- --===============1154509896== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1154509896==-- From ips-bounces@ietf.org Mon Apr 17 18:09:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVbuK-0000uc-Pp; Mon, 17 Apr 2006 18:09:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVbuJ-0000uL-G3 for ips@ietf.org; Mon, 17 Apr 2006 18:09:19 -0400 Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVbuI-0000Og-IF for ips@ietf.org; Mon, 17 Apr 2006 18:09:19 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k3HM9Ih5004060; Mon, 17 Apr 2006 18:09:18 -0400 (EDT) Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3HM9Dot027374; Mon, 17 Apr 2006 18:09:13 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Apr 2006 18:09:13 -0400 Message-ID: From: Black_David@emc.com To: davidw@netapp.com Subject: RE: [Ips] X#NodeArchitecture draft - next steps Date: Mon, 17 Apr 2006 18:09:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.04.17.143105 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_MEDIA_2_BODY 0, __CP_NOT_1 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: dd055ca905b7a8538e016a7989511901 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1333493010==" Errors-To: ips-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1333493010== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6626B.1577E8E8" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C6626B.1577E8E8 Content-Type: text/plain > How about another option: > - sending less detailed information in the key values Sounds reasonable. I think you can take the results of the list discussion to date and submit a -00 WG draft for further discussion and editing. Thanks, --David (as WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _____ From: Dave Wysochanski [mailto:davidw@netapp.com] Sent: Friday, April 14, 2006 7:57 AM To: Black, David Cc: ips@ietf.org Subject: Re: [Ips] X#NodeArchitecture draft - next steps Black_David@emc.com wrote: Dave, > New proposed text: > > 3. Security Considerations > > In certain environments where security is a primary concern, > the use of this extension key may not be appropriate as it > reveals specific details about an iSCSI node. For these > environments, nodes implementing this public extension key > MUST provide a method to disable sending the key. In > addition to providing a disable mechanism, security sensitive > environments SHOULD consider use of IPsec, as specified in > RFC 3720 and 3723, as a means to shield the contents of this > key from observers of network traffic. Good start, needs editing to something like: This extension key transmits specific implementation details about the node that sends it; such details may be considered sensitive in some environments. For example, if a certain software or firmware version is known to contain security weaknesses, announcing the presence of that version via this key may not be desirable. The countermeasures for this security concern are: How about another option: - sending less detailed information in the key values Security concerns could also be lessened by sending less detailed information, such as omitting the version numbers of things (for example, send "Microsoft Windows, software initiator" instead of "Microsoft Windows 2003, software initiator version 1.2.3.4"). I will have to rework the format of the key a bit but this seems worth doing. Hopefully there is a reasonable level of information that most people will find acceptable transmitting by default while not greatly compromising security. - not sending the extension key, or - using IPsec to provide confidentiality for the iSCSI connection on which the key is sent (see RFC 3720 and RFC 3723). To support the first countermeasure, all implementations of this extension key MUST provide an administrative mechanism to disable sending the key. This sentence then becomes something like. To support the first and second countermeasures, all implementations of this extension key SHOULD provide a way to configure different levels of detail in the extension key values and MUST provide an administrative mechanism to disable sending the key. Reasons for the edits: - Focus on specific threat, not general "where security is a primary concern". - Make the "MUST" for disabling transmission of the key globally applicable, vs. possibly scoped to specific environments. This is a "MUST implement" requirement, not "MUST use". - Avoid the "SHOULD ... use ... IPsec" phrasing, at least for now. > New proposed text: > > The following described Public Extension Key is sent during > the login phase of an iSCSI normal session. It is important > to note that the proper use of this key is to provide enhanced > logging and support capabilities, and for better understanding > of customer environments. Functional behavior of the iSCSI > node MUST NOT depend on the presence, absence, or content of > the key. The key MUST NOT be used by iSCSI nodes for things > such as interoperability, performance, exclusion or deception > of other nodes, or other uses not defined here. To enforce > proper use, iSCSI nodes MUST NOT allow user modification of > the key value(s), and SHOULD set the value automatically based > on standard internal interfaces. This one is close - 3 suggestions: - "proper" -> "intended" - remove "and for better understanding of customer environments" or replace it with something more specific like "and to enable collection of iSCSI implementation usage information" - The "such as ... or other uses not defined here" is not sufficiently precise. The last one is crucial - it needs to be easy for an implementer to determine whether s/he's stepped over this line. I'm comfortable with not mentioning the JavaScript and browser versions mess, as I think we all know that it's the motivating example for this text. Thanks, --David (as individual participant, *not* as WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Dave Wysochanski [mailto:davidw@netapp.com ] > Sent: Friday, March 31, 2006 9:35 PM > To: Black, David > Cc: ips@ietf.org > Subject: Re: [Ips] X#NodeArchitecture draft - next steps > > Black_David@emc.com wrote: > > > This draft is better known as: > > draft-wysochanski-xkey-iscsi-support-00.txt > > > > This draft will be an official WG draft, but three things > > need to happen first: > > > > (1) New security text. The existing "SHOULD" in the security > > considerations text needs to be a "MUST". In addition, > > there needs to be a sentence pointing out that it may > > be important to shield the contents of this key from > > observers of network traffic, and that IPsec as specified > > for iSCSI in RFC 3720 and 3723 (cite both of them) is an > > appropriate tool for this purpose. > > > New proposed text: > > 3. Security Considerations > > In certain environments where security is a primary concern, > the use of this extension key may not be appropriate as it > reveals specific details about an iSCSI node. For these > environments, nodes implementing this public extension key > MUST provide a method to disable sending the key. In > addition to providing a disable mechanism, security sensitive > environments SHOULD consider use of IPsec, as specified in > RFC 3720 and 3723, as a means to shield the contents of this > key from observers of network traffic. > > > > Original text: > > 3. Security Considerations > > In certain environments where security is a primary concern, > the use of this extension key may not be appropriate as it > reveals specific details about an iSCSI node. For these > environments, nodes implementing this public extension key > SHOULD provide a method to disable sending the key. > > > > > (2) New "prevention of abuse" text. The current "The key MUST NOT > > be used by iSCSI nodes for things such as ..." is well- > > intentioned but does not get the job done. My recollection > > of discussion in Dallas is that saying that "functional behavior > > of the iSCSI node MUST NOT depend on this key (presence/absence > > or value)" may be closer to the mark. The only permitted > > (and intended) use of this key is to report it/log it in order > > to avoid the browser detection JavaScript disasters caused by > > the corresponding HTTP header fields. > > > > I wasn't sure about deleting the original "MUST NOT" sentence so I left it in. Anyone > have a preference? Also wasn't sure whether it's worth putting in a sentence or two at > least acknowledging what has happened in the past with User-Agent -- intent would be > the working group acknowledges this historical misuse and wishes to avoid it. > > New proposed text: > > The following described Public Extension Key is sent during > the login phase of an iSCSI normal session. It is important > to note that the proper use of this key is to provide enhanced > logging and support capabilities, and for better understanding > of customer environments. Functional behavior of the iSCSI > node MUST NOT depend on the presence, absence, or content of > the key. The key MUST NOT be used by iSCSI nodes for things > such as interoperability, performance, exclusion or deception > of other nodes, or other uses not defined here. To enforce > proper use, iSCSI nodes MUST NOT allow user modification of > the key value(s), and SHOULD set the value automatically based > on standard internal interfaces. > > > > Original text: > > The following described Public Extension Key is sent during > the login phase of an iSCSI normal session. It is important > to note that the proper use of this key is to provide enhanced > logging and support capabilities, and for better understanding > of customer environments. The key MUST NOT be used by iSCSI > nodes for things such as interoperability, performance, > exclusion or deception of other nodes, or other uses not > defined here. To enforce proper use, iSCSI nodes MUST NOT > allow user modification of the key value(s), and SHOULD set > the value automatically based on standard internal interfaces. > > > > > > > > (3) The draft needs a new title and file name ("supportability" just > > reeks of marketing ;-) ). Let's try: > > > > The iSCSI X#NodeArchitecture Key > > draft-ietf-ips-iscsi-nodearch-key-00.txt > > > Sounds fine to me. > > > > Text for (1) and (2), or at least initial versions of it should be > > worked out on the list before the -00 version of the draft-ietf-ips-... > > draft is submitted. I've just sent the request to the secretariat for > > an end-of-2006 completion milestone for this, but in practice, it > > could be done shortly after Montreal, if not before. > > > Great, thanks. > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > > ------_=_NextPart_001_01C6626B.1577E8E8 Content-Type: text/html
> How about another option:
>              - sending less detailed information in the key values
 
Sounds reasonable.  I think you can take the results of the list
discussion to date and submit a -00 WG draft for further discussion
and editing.
 
Thanks,
--David (as WG chair)

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------


From: Dave Wysochanski [mailto:davidw@netapp.com]
Sent: Friday, April 14, 2006 7:57 AM
To: Black, David
Cc: ips@ietf.org
Subject: Re: [Ips] X#NodeArchitecture draft - next steps

Black_David@emc.com wrote:

Dave,

> New proposed text:
>
> 3.  Security Considerations
>
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node.  For these
>    environments, nodes implementing this public extension key
>    MUST provide a method to disable sending the key.  In
>    addition to providing a disable mechanism, security sensitive
>    environments SHOULD consider use of IPsec, as specified in
>    RFC 3720 and 3723, as a means to shield the contents of this
>    key from observers of network traffic.

Good start, needs editing to something like:

    This extension key transmits specific implementation details
    about the node that sends it; such details may be considered
    sensitive in some environments.  For example, if a certain
    software or firmware version is known to contain security
    weaknesses, announcing the presence of that version via this
    key may not be desirable.  The countermeasures for this
    security concern are:

How about another option:
             - sending less detailed information in the key values

Security concerns could also be lessened by sending less
detailed information, such as omitting the version numbers of
things (for example, send "Microsoft Windows, software initiator"
instead of  "Microsoft Windows 2003, software initiator version 1.2.3.4").
I will have to rework the format of the key a bit but this seems
worth doing.  Hopefully there is a reasonable level of information
that most people will find acceptable transmitting by default while
not greatly compromising security.


        - not sending the extension key, or





        - using IPsec to provide confidentiality for the iSCSI
                connection on  which the key is sent (see RFC 3720
                and RFC 3723).
    To support the first countermeasure, all implementations of
    this extension key MUST provide an administrative mechanism
    to disable sending the key.

This sentence then becomes something like.

To support the first and second countermeasures, all implementations
of this extension key SHOULD provide a way to configure different
levels of detail in the extension key values and MUST provide an
administrative mechanism to disable sending the key.

Reasons for the edits:
- Focus on specific threat, not general "where security is a primary
        concern".
- Make the "MUST" for disabling transmission of the key globally
        applicable, vs. possibly scoped to specific environments.
        This is a "MUST implement" requirement, not "MUST use".
- Avoid the "SHOULD ... use ... IPsec" phrasing, at least for now.

> New proposed text:
>
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  Functional behavior of the iSCSI
>    node MUST NOT depend on the presence, absence, or content of
>    the key.  The key MUST NOT be used by iSCSI nodes for things
>    such as interoperability, performance, exclusion or deception
>    of other nodes, or other uses not defined here.  To enforce
>    proper use, iSCSI nodes MUST NOT allow user modification of
>    the key value(s), and SHOULD set the value automatically based
>    on standard internal interfaces.

This one is close - 3 suggestions:
- "proper" -> "intended"
- remove "and for better understanding of customer environments" or
        replace it with something more specific like "and to enable
        collection of iSCSI implementation usage information"
- The "such as ... or other uses not defined here" is not sufficiently
        precise.
The last one is crucial - it needs to be easy for an implementer to
determine whether s/he's stepped over this line.

I'm comfortable with not mentioning the JavaScript and browser versions
mess, as I think we all know that it's the motivating example for this
text.

Thanks,
--David (as individual participant, *not* as WG chair)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Dave Wysochanski [mailto:davidw@netapp.com]
> Sent: Friday, March 31, 2006 9:35 PM
> To: Black, David
> Cc: ips@ietf.org
> Subject: Re: [Ips] X#NodeArchitecture draft - next steps
>
> Black_David@emc.com wrote:
>
> > This draft is better known as:
> > draft-wysochanski-xkey-iscsi-support-00.txt
> >
> > This draft will be an official WG draft, but three things
> > need to happen first:
> >
> > (1) New security text.  The existing "SHOULD" in the security
> >         considerations text needs to be a "MUST".  In addition,
> >         there needs to be a sentence pointing out that it may
> >         be important to shield the contents of this key from
> >         observers of network traffic, and that IPsec as specified
> >         for iSCSI in RFC 3720 and 3723 (cite both of them) is an
> >         appropriate tool for this purpose.
> >
> New proposed text:
>
> 3.  Security Considerations
>
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node.  For these
>    environments, nodes implementing this public extension key
>    MUST provide a method to disable sending the key.  In
>    addition to providing a disable mechanism, security sensitive
>    environments SHOULD consider use of IPsec, as specified in
>    RFC 3720 and 3723, as a means to shield the contents of this
>    key from observers of network traffic.
>
>
>
> Original text:     
>
> 3.  Security Considerations
>
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node. For these
>    environments, nodes implementing this public extension key
>    SHOULD provide a method to disable sending the key.
>
>      
>
> > (2) New "prevention of abuse" text.  The current "The key MUST NOT
> >         be used by iSCSI nodes for things such as ..." is well-
> >         intentioned but does not get the job done.  My recollection
> >         of discussion in Dallas is that saying that "functional behavior
> >         of the iSCSI node MUST NOT depend on this key (presence/absence
> >         or value)"  may be closer to the mark.  The only permitted
> >         (and intended) use of this key is to report it/log it in order
> >         to avoid the browser detection JavaScript disasters caused by
> >         the corresponding HTTP header fields.
> >
>
> I wasn't sure about deleting the original "MUST NOT" sentence so I left it
in.  Anyone
> have a preference?  Also wasn't sure whether it's worth putting in a
sentence or two at
> least acknowledging what has happened in the past with User-Agent --
intent would be
> the working group acknowledges this historical misuse and wishes to avoid
it.
>
> New proposed text:
>
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  Functional behavior of the iSCSI
>    node MUST NOT depend on the presence, absence, or content of
>    the key.  The key MUST NOT be used by iSCSI nodes for things
>    such as interoperability, performance, exclusion or deception
>    of other nodes, or other uses not defined here.  To enforce
>    proper use, iSCSI nodes MUST NOT allow user modification of
>    the key value(s), and SHOULD set the value automatically based
>    on standard internal interfaces.
>
>
>
> Original text:
>
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  The key MUST NOT be used by iSCSI
>    nodes for things such as interoperability, performance,
>    exclusion or deception of other nodes, or other uses not
>    defined here.  To enforce proper use, iSCSI nodes MUST NOT
>    allow user modification of the key value(s), and SHOULD set
>    the value automatically based on standard internal interfaces.
>
>
>
>
>
>
> > (3) The draft needs a new title and file name ("supportability" just
> >         reeks of marketing ;-) ).  Let's try:
> >
> >            The iSCSI X#NodeArchitecture Key
> >         draft-ietf-ips-iscsi-nodearch-key-00.txt
> >
> Sounds fine to me.
>
>
> > Text for (1) and (2), or at least initial versions of it should be
> > worked out on the list before the -00 version of the draft-ietf-ips-...
> > draft is submitted.  I've just sent the request to the secretariat for
> > an end-of-2006 completion milestone for this, but in practice, it
> > could be done shortly after Montreal, if not before.
> >
> Great, thanks.
>
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > black_david@emc.com        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> > _______________________________________________
> > Ips mailing list
> > Ips@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ips
> >
>


------_=_NextPart_001_01C6626B.1577E8E8-- --===============1333493010== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1333493010==-- From ips-bounces@ietf.org Mon Apr 17 19:00:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVchM-0004Ea-70; Mon, 17 Apr 2006 19:00:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVchL-0004EQ-IV for ips@ietf.org; Mon, 17 Apr 2006 18:59:59 -0400 Received: from mother.pmc-sierra.com ([216.241.224.12] helo=mother.pmc-sierra.bc.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVchL-0002oP-24 for ips@ietf.org; Mon, 17 Apr 2006 18:59:59 -0400 Received: (qmail 21791 invoked by uid 101); 17 Apr 2006 22:53:17 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by mother.pmc-sierra.com with SMTP; 17 Apr 2006 22:53:17 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogyruan.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k3HMrHRW029807; Mon, 17 Apr 2006 15:53:17 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id <132HSX7P>; Mon, 17 Apr 2006 15:53:16 -0700 Message-ID: <5C1FD43E5F1B824E83985A74F396286E01BCE5FB@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca> From: Sanjay Goyal To: Jacob_Cherian@Dell.com, ips@ietf.org Subject: RE: [Ips] Target Behavior Clarifications Date: Mon, 17 Apr 2006 15:52:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0321741012==" Errors-To: ips-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0321741012== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66271.9DE51277" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C66271.9DE51277 Content-Type: text/plain Hi, What it indicates is that the other side is misbehaving. It should be treated as protocol error and the session should be terminated. -Sanjay _____ From: Jacob_Cherian@Dell.com [mailto:Jacob_Cherian@Dell.com] Sent: Monday, April 17, 2006 2:49 PM To: ips@ietf.org Subject: [Ips] Target Behavior Clarifications A couple of quick questions? 1) What should the behavior of a target be if it receives a PDU on a connection, larger than what it declared with MaxRecvDataSegmentLength: - If the PDU is part of a SCSI command? - If the PDU is part of a login? 2) What should the target behaviour be if the initiator sends it more data than MaxBurstLength? 3) What should the target behavior be if the initiator sends more data than FirstBurstLength? Any clarification would be greatly appreciated. Thanks, Jacob ------_=_NextPart_001_01C66271.9DE51277 Content-Type: text/html Target Behavior Clarifications
Hi,
 
What it indicates is that the other side is misbehaving. It should be treated as protocol error and the session should be terminated.
 
-Sanjay

From: Jacob_Cherian@Dell.com [mailto:Jacob_Cherian@Dell.com]
Sent: Monday, April 17, 2006 2:49 PM
To: ips@ietf.org
Subject: [Ips] Target Behavior Clarifications

A couple of quick questions?

1) What should the behavior of a target be if it receives a PDU on a connection, larger than what it declared with MaxRecvDataSegmentLength:

- If the PDU is part of a SCSI command?

- If the PDU is part of a login?

2) What should the target behaviour be if the initiator sends it more data than MaxBurstLength?

3) What should the target behavior be if the initiator sends more data than FirstBurstLength?

Any clarification would be greatly appreciated.

Thanks,

Jacob


------_=_NextPart_001_01C66271.9DE51277-- --===============0321741012== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0321741012==-- From ips-bounces@ietf.org Mon Apr 17 19:07:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVcoC-0005Kw-NK; Mon, 17 Apr 2006 19:07:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVcoC-0005Kr-53 for ips@ietf.org; Mon, 17 Apr 2006 19:07:04 -0400 Received: from ausc60pc101.us.dell.com ([143.166.85.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVcoA-0003I5-Hh for ips@ietf.org; Mon, 17 Apr 2006 19:07:04 -0400 DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; b=D9u/y3VHPJJmIUI4T72/qis97UIXu4PdhzdEk0hWSkB93oiCXqk1e9TL5L3Aj+HLYkAmYchNHwPiLZdbMGOUR/a/dYTLOTyKyMrQJFWZ3JhKdpxnIIZP7PWOwFSQfV64; Received: from ausx3bpc102.aus.amer.dell.com ([10.30.101.52]) by ausc60pc101.us.dell.com with ESMTP; 17 Apr 2006 18:07:02 -0500 X-IronPort-AV: i="4.04,127,1144040400"; d="scan'208,217"; a="1326662:sNHT77024628" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Target Behavior Clarifications Date: Mon, 17 Apr 2006 18:07:01 -0500 Message-ID: <389040536173ED4AADA5EFEA9633358601677A0E@ausx3mpc106.aus.amer.dell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Target Behavior Clarifications Thread-Index: AcZicbj0fjQ/Ok5DQLam+pNEMGfQCwAAVC7A From: To: , X-OriginalArrivalTime: 17 Apr 2006 23:07:01.0813 (UTC) FILETIME=[A2C3A650:01C66273] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9b281509fec590bb711c36d4c3ba4f74 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1626107677==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1626107677== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66273.A2665434" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66273.A2665434 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sanjay, Thanks. =20 There seems to be an inconsistency in the spec in terms of how the target is expected to behave when it detects initiator behavior that is not in line with the negotiated operational parameters. As per the spec if the target receives any non-immediate unsolicited data when InitialR2T=3DYes, it shall fail the command with a CHECK CONDITION (0B/0C/0C - COMMAND ABORTED, WRITE ERROR - UNEXPECTED UNSOLICITED DATA) - Why is this a special case? =20 Thanks, Jacob =20 ________________________________ From: Sanjay Goyal [mailto:Sanjay_Goyal@pmc-sierra.com]=20 Sent: Monday, April 17, 2006 5:53 PM To: Cherian, Jacob; ips@ietf.org Subject: RE: [Ips] Target Behavior Clarifications =20 Hi, =20 What it indicates is that the other side is misbehaving. It should be treated as protocol error and the session should be terminated. =20 -Sanjay =20 ________________________________ From: Jacob_Cherian@Dell.com [mailto:Jacob_Cherian@Dell.com]=20 Sent: Monday, April 17, 2006 2:49 PM To: ips@ietf.org Subject: [Ips] Target Behavior Clarifications A couple of quick questions? 1) What should the behavior of a target be if it receives a PDU on a connection, larger than what it declared with MaxRecvDataSegmentLength: - If the PDU is part of a SCSI command?=20 - If the PDU is part of a login? 2) What should the target behaviour be if the initiator sends it more data than MaxBurstLength? 3) What should the target behavior be if the initiator sends more data than FirstBurstLength? Any clarification would be greatly appreciated.=20 Thanks, Jacob =20 ------_=_NextPart_001_01C66273.A2665434 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Target Behavior Clarifications

Sanjay,

=

  = Thanks.

 

 There seems to be an inconsistency in the spec in terms of = how the target is expected to behave when it detects initiator behavior that is = not in line with the negotiated operational parameters. As per the spec = if the target receives any non-immediate unsolicited data when InitialR2T=3DYes, it shall fail the = command with a CHECK CONDITION (0B/0C/0C – COMMAND ABORTED, WRITE ERROR - UNEXPECTED UNSOLICITED DATA) – Why is this a special = case?

 

Thanks,

=

Jacob

 

From: = Sanjay Goyal [mailto:Sanjay_Goyal@pmc-sierra.com]
Sent: Monday, April 17, = 2006 5:53 PM
To: Cherian, Jacob; ips@ietf.org
Subject: RE: [Ips] Target = Behavior Clarifications

 

Hi,

 

What it indicates is that the other = side is misbehaving. It should be treated as protocol error and the session = should be terminated.

 

-Sanjay

=

 

From: Jacob_Cherian@Dell.com [mailto:Jacob_Cherian@Dell.com]
Sent: Monday, April 17, = 2006 2:49 PM
To: ips@ietf.org
Subject: [Ips] Target = Behavior Clarifications

A couple of quick = questions?

1) What should the behavior of a target be if it receives a = PDU on a connection, larger than what it declared with MaxRecvDataSegmentLength:

- If the PDU is part of a SCSI command?

- If the PDU is part of a login?

2) What should the target behaviour be if the initiator sends it more data than MaxBurstLength?

3) What should the target behavior be if the = initiator sends more data than FirstBurstLength?

Any clarification would be greatly appreciated. =

Thanks,

Jacob

 

------_=_NextPart_001_01C66273.A2665434-- --===============1626107677== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1626107677==-- From ips-bounces@ietf.org Tue Apr 18 02:11:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVjQo-00042n-KN; Tue, 18 Apr 2006 02:11:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVjQn-00042i-Bt for ips@ietf.org; Tue, 18 Apr 2006 02:11:21 -0400 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVjQi-0007SL-QZ for ips@ietf.org; Tue, 18 Apr 2006 02:11:21 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.6/8.13.6) with ESMTP id k3I6BFFU036850 for ; Tue, 18 Apr 2006 06:11:15 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k3I6CEmw013974 for ; Tue, 18 Apr 2006 08:12:14 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k3I6BFPC031190 for ; Tue, 18 Apr 2006 08:11:15 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k3I6BF5i031186; Tue, 18 Apr 2006 08:11:15 +0200 In-Reply-To: <389040536173ED4AADA5EFEA9633358601677A0C@ausx3mpc106.aus.amer.dell.com> To: Subject: Re: [Ips] Target Behavior Clarifications MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Tue, 18 Apr 2006 09:12:10 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0HF90 | November 16, 2005) at 18/04/2006 09:12:13, Serialize complete at 18/04/2006 09:12:13 X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0842869812==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0842869812== Content-Type: multipart/alternative; boundary="=_alternative 001D9251C2257154_=" This is a multipart message in MIME format. --=_alternative 001D9251C2257154_= Content-Type: text/plain; charset="US-ASCII" wrote on 18/04/2006 00:48:49: > A couple of quick questions? > 1) What should the behavior of a target be if it receives a PDU on a > connection, larger than what it declared with MaxRecvDataSegmentLength: > - If the PDU is part of a SCSI command? protocol error but you will have also to terminate the SCSI command > - If the PDU is part of a login? The MaxRecvDataSegmentLength is not "fixed" untill login is finished so the target must be ready to accept the default length. > 2) What should the target behaviour be if the initiator sends it > more data than MaxBurstLength? As above > 3) What should the target behavior be if the initiator sends more data than > FirstBurstLength? that is specially bad as the target may have already issued R2Ts - drop the session but terminate the command. > Any clarification would be greatly appreciated. > Thanks, > Jacob > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips --=_alternative 001D9251C2257154_= Content-Type: text/html; charset="US-ASCII"

<Jacob_Cherian@Dell.com> wrote on 18/04/2006 00:48:49:

> A couple of quick questions?
> 1) What should the behavior of a target be if it receives a PDU on a
> connection, larger than what it declared with MaxRecvDataSegmentLength:
> - If the PDU is part of a SCSI command?
protocol error but you will have also to terminate the SCSI command
> - If the PDU is part of a login?
The MaxRecvDataSegmentLength is not "fixed" untill login is finished so the target must be ready to accept the default length.
> 2) What should the target behaviour be if the initiator sends it
> more data than MaxBurstLength?
As above
> 3) What should the target behavior be if the initiator sends more data than
> FirstBurstLength?
that is specially bad as the target may have already issued R2Ts - drop the session but terminate the command.
> Any clarification would be greatly appreciated.
> Thanks,
> Jacob
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
 --=_alternative 001D9251C2257154_=-- --===============0842869812== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0842869812==-- From ips-bounces@ietf.org Tue Apr 18 02:11:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVjQu-0004EW-1h; Tue, 18 Apr 2006 02:11:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVjQs-0004ER-72 for ips@ietf.org; Tue, 18 Apr 2006 02:11:26 -0400 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVjQl-0007SM-G2 for ips@ietf.org; Tue, 18 Apr 2006 02:11:26 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.6/8.13.6) with ESMTP id k3I6BIeL109022 for ; Tue, 18 Apr 2006 06:11:18 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k3I6CHmw038688 for ; Tue, 18 Apr 2006 08:12:17 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k3I6BIU1031995 for ; Tue, 18 Apr 2006 08:11:18 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k3I6BIa2031992; Tue, 18 Apr 2006 08:11:18 +0200 In-Reply-To: <389040536173ED4AADA5EFEA9633358601677A0E@ausx3mpc106.aus.amer.dell.com> To: Subject: RE: [Ips] Target Behavior Clarifications MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Tue, 18 Apr 2006 09:12:12 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0HF90 | November 16, 2005) at 18/04/2006 09:12:16, Serialize complete at 18/04/2006 09:12:16 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: ips@ietf.org, Sanjay_Goyal@pmc-sierra.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0455256943==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0455256943== Content-Type: multipart/alternative; boundary="=_alternative 001DFB12C2257154_=" This is a multipart message in MIME format. --=_alternative 001DFB12C2257154_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable As far as I remember this was done to keep in line with FCP behavior (FCP=20 has no immediate data but can operate with unsolicited data). Julo wrote on 18/04/2006 02:07:01: > Sanjay, > Thanks. >=20 > There seems to be an inconsistency in the spec in terms of how the=20 > target is expected to behave when it detects initiator behavior that > is not in line with the negotiated operational parameters. As per=20 > the spec if the target receives any non-immediate unsolicited data=20 > when InitialR2T=3DYes, it shall fail the command with a CHECK=20 > CONDITION (0B/0C/0C ? COMMAND ABORTED, WRITE ERROR - UNEXPECTED=20 > UNSOLICITED DATA) ? Why is this a special case? >=20 > Thanks, > Jacob >=20 >=20 > From: Sanjay Goyal [mailto:Sanjay=5FGoyal@pmc-sierra.com]=20 > Sent: Monday, April 17, 2006 5:53 PM > To: Cherian, Jacob; ips@ietf.org > Subject: RE: [Ips] Target Behavior Clarifications >=20 > Hi, >=20 > What it indicates is that the other side is misbehaving. It should=20 > be treated as protocol error and the session should be terminated. >=20 > -Sanjay >=20 >=20 > From: Jacob=5FCherian@Dell.com [mailto:Jacob=5FCherian@Dell.com]=20 > Sent: Monday, April 17, 2006 2:49 PM > To: ips@ietf.org > Subject: [Ips] Target Behavior Clarifications > A couple of quick questions? > 1) What should the behavior of a target be if it receives a PDU on a > connection, larger than what it declared with MaxRecvDataSegmentLength: > - If the PDU is part of a SCSI command?=20 > - If the PDU is part of a login? > 2) What should the target behaviour be if the initiator sends it=20 > more data than MaxBurstLength? > 3) What should the target behavior be if the initiator sends more data=20 than=20 > FirstBurstLength? > Any clarification would be greatly appreciated.=20 > Thanks, > Jacob > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips --=_alternative 001DFB12C2257154_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
As far as I remember this was done to keep in line with FCP behavior (FCP has no immediate data but can operate with unsolicited data).

Julo

<Jacob=5FCherian@Dell.com> wrote on 18/04/2006 02:07:01:

> Sanjay,
>   Thanks.
>  
>  There seems to be an inconsistency in the spec in terms of how the
> target is expected to behave when it detects initiator behavior that > is not in line with the negotiated operational parameters. As per
> the spec if the target receives any non-immediate unsolicited data
> when InitialR2T=3DYes, it shall fail the command with a CHECK
> CONDITION (0B/0C/0C – COMMAND ABORTED, WRITE ERROR - UNEXPECTED =
> UNSOLICITED DATA) – Why is this a special case?
>  
> Thanks,
> Jacob
>  
>
> From: Sanjay Goyal [mailto:Sanjay=5FGoyal@pmc-sierra.com]
> Sent: Monday, April 17, 2006 5:53 PM
> To: Cherian, Jacob; ips@ietf.org
> Subject: RE: [Ips] Target Behavior Clarifications
>  
> Hi,
>  
> What it indicates is that the other side is mis= behaving. It should
> be treated as protocol error and the session should be terminated.
>  
> -Sanjay
>  
>
> From: Jacob=5FCherian@Dell.com [mailto:Jacob=5FCherian@Dell.com]
> Sent: Monday, April 17, 2006 2:49 PM
> To: ips@ietf.org
> Subject: [Ips] Target Behavior Clarifications
> A couple of quick questions?
> 1) What should the behavior of a target be if it receives a PDU on a
> connection, larger than what it declared with MaxRecvDataSegmentLength= :
> - If the PDU is part of a SCSI command? =
> - If the PDU is part of a login?
> 2) What should the target behaviour be if the initiator sends it
> more data than MaxBurstLength?
> 3) What should the target behavior be if the initiator sends more data than
> FirstBurstLength?
> Any clarification would be greatly appreciated.
> Thanks,
> Jacob
>  =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
 --=_alternative 001DFB12C2257154_=-- --===============0455256943== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0455256943==-- From ips-bounces@ietf.org Tue Apr 18 02:17:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVjWD-0006dj-6M; Tue, 18 Apr 2006 02:16:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVjWC-0006dd-6Z for ips@ietf.org; Tue, 18 Apr 2006 02:16:56 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVjW4-0007Zd-0b for ips@ietf.org; Tue, 18 Apr 2006 02:16:55 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k3I6GlDp020317 for ; Tue, 18 Apr 2006 02:16:47 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k3I6GlMj158044 for ; Tue, 18 Apr 2006 02:16:47 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k3I6GlLs007176 for ; Tue, 18 Apr 2006 02:16:47 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k3I6Gl3T007173; Tue, 18 Apr 2006 02:16:47 -0400 In-Reply-To: <000801c66250$6ecf8f80$06031eac@ivivity.com> Importance: Normal MIME-Version: 1.0 Sensitivity: To: "Eddy Quicksall" Subject: Re: [Ips] MPA alignment X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Mon, 17 Apr 2006 23:16:45 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 7.0.1HF91 | March 28, 2006) at 04/18/2006 02:16:46, Serialize complete at 04/18/2006 02:16:46 X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1411197814==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1411197814== Content-Type: multipart/alternative; boundary="=_alternative 00227E1A88257154_=" This is a multipart message in MIME format. --=_alternative 00227E1A88257154_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Eddy, If your question is about MPA behavior in general, then it should be=20 directed to the rddp forum. Assuming your question is related to iSER, then if iWARP is implemented in = software and uses the existing TCP/IP stack, then it cannot guarantee that = FPDU's will be aligned with TCP segments. For the general case where=20 iWARP is implemented in an RNIC with an integrated TCP/IP stack, then it=20 is to the RNIC vendor's advantage to optimize his product's performance=20 and therefore FPDU's should be aligned with TCP segments. However, the=20 receiver can still receive FPDU's which are not aligned with TCP segments=20 if there are resegmenting middleboxes somewhere in the connection path. Mike=20 To: cc: =20 Subject: [Ips] MPA alignment It is preferable to have TCP sender to align MPA header where a TCP=20 segment begins and to keep the MPA FPDU within a TCP segment, so that the=20 receiver hardware doesn?t need to temporarily buffer the FPDU for the CRC=20 checking.=20 =20 Does anyone know of any software or hardware that is not an FPDU alignment = sender? Does anyone have a feel for the likelihood of software or hardware to not=20 align FPDU's on a TCP segment? =20 Eddy=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 00227E1A88257154_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Eddy,

If your question is about MPA behavi= or in general, then it should be directed to the rddp forum.

Assuming your question is related to iSER, then if iWARP is implemented in software and uses the existing TCP/IP stack, then it cannot guarantee that FPDU's will be aligned with TCP segmen= ts.  For the general case where iWARP is implemented in an RNIC with an integrated TCP/IP stack, then it is to the RNIC vendor's advantage to optim= ize his product's performance and therefore FPDU's should be aligned with TCP segments.  However, the receiver can still receive FPDU's which are not aligned with TCP segments if there are resegmenting middleboxes somewhe= re in the connection path.

Mike  

To:     &nb= sp;  <ips@ietf.org>
cc:     &n= bsp;  
Subject:   &nbs= p;    [Ips] MPA alignment<= /font>


It is preferable to have TCP sender to al= ign MPA header where a TCP segment begins and to keep the MPA FPDU within a TCP segment, so that the receiver hardware doesn’t need to temporarily buffer the FPDU for the CRC checking.  
 
Does anyone know of any software or hardw= are that is not an FPDU alignment sender?
Does anyone have a feel for the likelihood of software or hardware to not align FPDU's on a TCP segment?
 
Eddy=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 00227E1A88257154_=-- --===============1411197814== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1411197814==-- From ips-bounces@ietf.org Tue Apr 18 08:47:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVpcQ-0006ua-9r; Tue, 18 Apr 2006 08:47:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVpcP-0006uV-An for ips@ietf.org; Tue, 18 Apr 2006 08:47:45 -0400 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVpcP-0004vF-0W for ips@ietf.org; Tue, 18 Apr 2006 08:47:45 -0400 Received: from ivvtdkv0981 (unknown[72.158.100.2]) by comcast.net (sccrmhc11) with SMTP id <2006041812474401100eij0he>; Tue, 18 Apr 2006 12:47:44 +0000 Message-ID: <001201c662e6$47f84190$7b08010a@ivivity.com> From: "Eddy Quicksall" To: "Mike Ko" References: Subject: Re: [Ips] MPA alignment Date: Tue, 18 Apr 2006 08:47:40 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1529990364==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1529990364== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C662C4.C065D8D0" This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C662C4.C065D8D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks, Here is my feeling on this. If one were to use a standard TCP/IP stack = (that does copying) then it is a bit silly to use iSER. If one were to = use a software implementation and write/modify the stack to get the = desired effects of DDP then he will probably heed to the alignment notes = in the spec. So if one were to support misaligned segments using a = slower method then it would be OK. Eddy ----- Original Message -----=20 From: Mike Ko=20 To: Eddy Quicksall=20 Cc: ips@ietf.org=20 Sent: Tuesday, April 18, 2006 2:16 AM Subject: Re: [Ips] MPA alignment Eddy,=20 If your question is about MPA behavior in general, then it should be = directed to the rddp forum.=20 Assuming your question is related to iSER, then if iWARP is = implemented in software and uses the existing TCP/IP stack, then it = cannot guarantee that FPDU's will be aligned with TCP segments. For the = general case where iWARP is implemented in an RNIC with an integrated = TCP/IP stack, then it is to the RNIC vendor's advantage to optimize his = product's performance and therefore FPDU's should be aligned with TCP = segments. However, the receiver can still receive FPDU's which are not = aligned with TCP segments if there are resegmenting middleboxes = somewhere in the connection path.=20 Mike =20 To: =20 cc: =20 Subject: [Ips] MPA alignment=20 It is preferable to have TCP sender to align MPA header where a TCP = segment begins and to keep the MPA FPDU within a TCP segment, so that = the receiver hardware doesn't need to temporarily buffer the FPDU for = the CRC checking. =20 =20 Does anyone know of any software or hardware that is not an FPDU = alignment sender?=20 Does anyone have a feel for the likelihood of software or hardware to = not align FPDU's on a TCP segment?=20 =20 Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_000F_01C662C4.C065D8D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks,
 

Here is my feeling on = this. If=20 one were to use a standard TCP/IP stack (that does copying) then it = is a=20 bit silly to use iSER. If one were to use a software implementation and=20 write/modify the stack to get the desired effects of DDP then he will = probably=20 heed to the alignment notes in the spec. So if one were to support = misaligned=20 segments using a slower method then it would be OK.

 
Eddy
----- Original Message -----
From:=20 Mike Ko=20
To: Eddy = Quicksall=20
Sent: Tuesday, April 18, 2006 = 2:16=20 AM
Subject: Re: [Ips] MPA = alignment


Eddy, =

If your question is about MPA behavior in = general, then=20 it should be directed to the rddp forum.

Assuming your question is related to iSER, then if iWARP is = implemented=20 in software and uses the existing TCP/IP stack, then it cannot = guarantee that=20 FPDU's will be aligned with TCP segments.  For the general case = where=20 iWARP is implemented in an RNIC with an integrated TCP/IP stack, then = it is to=20 the RNIC vendor's advantage to optimize his product's performance and=20 therefore FPDU's should be aligned with TCP segments.  However, = the=20 receiver can still receive FPDU's which are not aligned with TCP = segments if=20 there are resegmenting middleboxes somewhere in the connection = path.=20

Mike  =20

To:     =  =20  <ips@ietf.org>=20
cc:     =    =20
Subject: =    =20    [Ips] MPA = alignment=20


It is preferable to have TCP = sender to=20 align MPA header where a TCP segment begins and to keep the MPA FPDU = within a=20 TCP segment, so that the receiver hardware doesn=92t need to = temporarily buffer=20 the FPDU for the CRC checking.  
 =20
Does anyone know of any software or = hardware that=20 is not an FPDU alignment sender?
Does=20 anyone have a feel for the likelihood of software or hardware to not = align=20 FPDU's on a TCP segment?
  =
Eddy_______________________________________________
Ips = mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_000F_01C662C4.C065D8D0-- --===============1529990364== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1529990364==-- From ips-bounces@ietf.org Tue Apr 18 13:33:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVu4U-0003Aa-2C; Tue, 18 Apr 2006 13:33:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVu4S-0003AR-60 for ips@ietf.org; Tue, 18 Apr 2006 13:33:00 -0400 Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVu4Q-0003ul-Nv for ips@ietf.org; Tue, 18 Apr 2006 13:33:00 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 765EA87181; Tue, 18 Apr 2006 13:32:57 -0400 (EDT) In-Reply-To: <389040536173ED4AADA5EFEA9633358601677A0C@ausx3mpc106.aus.amer.dell.com> References: <389040536173ED4AADA5EFEA9633358601677A0C@ausx3mpc106.aus.amer.dell.com> Mime-Version: 1.0 (Apple Message framework v749.3) Message-Id: From: William Studenmund Subject: Re: [Ips] Target Behavior Clarifications Date: Tue, 18 Apr 2006 10:32:51 -0700 To: X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1129477558==" Errors-To: ips-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1129477558== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2--429353136" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2--429353136 Content-Type: multipart/alternative; boundary=Apple-Mail-1--429353241 --Apple-Mail-1--429353241 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Apr 17, 2006, at 2:48 PM, wrote: > A couple of quick questions? > > 1) What should the behavior of a target be if it receives a PDU on > a connection, larger than what it declared with > MaxRecvDataSegmentLength: > > - If the PDU is part of a SCSI command? > > - If the PDU is part of a login? Drop the connection. Note, the session may still stick around as part of recovery processing. Also, during login (before FFP), the MaxRecvDataSegmentLength in force is 8k, regardless of announced values. > 2) What should the target behaviour be if the initiator sends it > more data than MaxBurstLength? > > 3) What should the target behavior be if the initiator sends more > data than FirstBurstLength? There are specific sense and ASC/Q values for these errors. These are treated as SCSI errors 1) because you have to give some explanation for why you killed the SCSI task, and 2) because it is not obvious which PDU in the burst was "too much." While you might want to say it was the last one, that isn't necessarily true. Note also that to trigger these errors, all the data placement had to stay within the TTT bounds and you have to be in DataPDUInOrder=No. That's the only way you can really write the same area twice. Most other errors involved in sending too much data in a burst would trigger an iSCSI protocol error by placing data outside the bounds of the TTT. Take care, Bill --Apple-Mail-1--429353241 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII
On Apr 17, 2006, at = 2:48 PM, <Jacob_Cherian@Dell.com> = <Jacob_Cherian@Dell.com> = wrote:

A couple = of quick questions?

1) What should the behavior of a target be if it receives a = PDU on a connection, larger than what it declared with MaxRecvDataSegmentLength:

- If the PDU is part of a SCSI command?

- = If the PDU is part of a = login?


Drop the connection. Note, = the session may still stick around as part of recovery = processing.

Also, during login (before = FFP), the MaxRecvDataSegmentLength in force is 8k, regardless of = announced values.

2) = What should the target = behaviour be if the initiator sends it more data = than = MaxBurstLength?

3) What should the = target = behavior be if the initiator sends more data = than = FirstBurstLength?

There are = specific sense and ASC/Q values for these errors.

These are treated as SCSI = errors 1) because you have to give some explanation for why you killed = the SCSI task, and 2) because it is not obvious which PDU in the burst = was "too much." While you might want to say it was the last one, that = isn't necessarily true.

Note also that to trigger = these errors, all the data placement had to stay within the TTT bounds = and you have to be in DataPDUInOrder=3DNo. That's the only way you can = really write the same area twice. Most other errors involved in sending = too much data in a burst would trigger an iSCSI protocol error by = placing data outside the bounds of the TTT.

Take care,

Bill
= --Apple-Mail-1--429353241-- --Apple-Mail-2--429353136 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFERSLJDJT2Egh26K0RAsx+AJ9xXLPmrbxskkVT4tNmV39MEPUo5wCbBuE5 nnUy7ilglMWkA+qx2Cly+SE= =gCfr -----END PGP SIGNATURE----- --Apple-Mail-2--429353136-- --===============1129477558== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1129477558==-- From ips-bounces@ietf.org Tue Apr 18 14:11:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVuf5-0004wK-2I; Tue, 18 Apr 2006 14:10:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVuf3-0004wF-FZ for ips@ietf.org; Tue, 18 Apr 2006 14:10:49 -0400 Received: from ausc60pc101.us.dell.com ([143.166.85.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVuf2-0006UP-OG for ips@ietf.org; Tue, 18 Apr 2006 14:10:49 -0400 DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; b=Je3Ku6IaioOIeBLYqcAMXbwCO24peLlaTsruOgCo73VO/0lEP3DeCHvvytgYMcT+px4flG6D1SccUIBACA3WYREpG6qE/ZgngwkL6P12Jot2Y8wuPdsaIHT44ZHGGbX9; Received: from ausx3bpc102.aus.amer.dell.com ([10.30.101.52]) by ausc60pc101.us.dell.com with ESMTP; 18 Apr 2006 13:10:48 -0500 X-IronPort-AV: i="4.04,131,1144040400"; d="scan'208,217"; a="1775791:sNHT89100585" Content-class: urn:content-classes:message MIME-Version: 1.0 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Ips] Target Behavior Clarifications Date: Tue, 18 Apr 2006 13:10:46 -0500 Message-ID: <389040536173ED4AADA5EFEA9633358601677A30@ausx3mpc106.aus.amer.dell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Target Behavior Clarifications Thread-Index: AcZjDiOFcXbd7cbXTn+dIttlYI/OSAAAe1bg From: To: , X-OriginalArrivalTime: 18 Apr 2006 18:10:47.0718 (UTC) FILETIME=[6AFDBC60:01C66313] X-Spam-Score: 0.2 (/) X-Scan-Signature: dce614827510b4050294eeec86a3642d Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1588358593==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1588358593== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66313.6A17F30E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66313.6A17F30E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Based on the responses from Bill and Julian this is what I have: =20 1) What should the behavior of a target be if it receives a PDU on a connection, larger than what it declared with MaxRecvDataSegmentLength: - If the PDU is part of a SCSI command?=20 I will drop the connection and terminate the task and generate a UA with ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED BY ISCSI PROTOCOL EVENT". If this is only connection in the session then I generate a UA (06/29/00). - If the PDU is part of a login? I will drop the connection. Agreed that the default value of 8K should be supported since login is not complete. =20 2) What should the target behavior be if the initiator sends it more data than MaxBurstLength? 3) What should the target behavior be if the initiator sends more data than FirstBurstLength? I have two options here:=20 =20 a) As per the spec: The target reports the "Incorrect amount of data" condition if during data output the total data length to output is greater than FirstBurstLength and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurstLength. The target reports the same error when the amount of data sent as a reply to an R2T does not match the amount requested. (0B/0C/0D - Write Error, Incorrect Amount of Data). This should work. =20 The only issue here is that the definition of the sense code does not match the definition in SPC-3 which says 0Ch 0Dh - WRITE ERROR - NOT ENOUGH UNSOLICITED DATA), which is not quite what the iSCSI says. =20 =20 b) Treat this as a really bad error and assume that I have an initiator that does not play well and drop the session and kill the command. =20 =20 I am leaning towards (b). Help!!! Suggestions/Comments/Discussion. =20 Thanks,=20 =20 Jacob Cherian=20 Dell Inc.=20 Ph: (512) 723 3247=20 ________________________________ From: William Studenmund [mailto:wrstuden@wasabisystems.com]=20 Sent: Tuesday, April 18, 2006 12:33 PM To: Cherian, Jacob Cc: ips@ietf.org Subject: Re: [Ips] Target Behavior Clarifications =20 On Apr 17, 2006, at 2:48 PM, wrote: A couple of quick questions? 1) What should the behavior of a target be if it receives a PDU on a connection, larger than what it declared with MaxRecvDataSegmentLength: - If the PDU is part of a SCSI command?=20 - If the PDU is part of a login? =20 Drop the connection. Note, the session may still stick around as part of recovery processing. =20 Also, during login (before FFP), the MaxRecvDataSegmentLength in force is 8k, regardless of announced values. 2) What should the target behaviour be if the initiator sends it more data than MaxBurstLength? 3) What should the target behavior be if the initiator sends more data than FirstBurstLength? There are specific sense and ASC/Q values for these errors. =20 These are treated as SCSI errors 1) because you have to give some explanation for why you killed the SCSI task, and 2) because it is not obvious which PDU in the burst was "too much." While you might want to say it was the last one, that isn't necessarily true. =20 Note also that to trigger these errors, all the data placement had to stay within the TTT bounds and you have to be in DataPDUInOrder=3DNo. That's the only way you can really write the same area twice. Most other errors involved in sending too much data in a burst would trigger an iSCSI protocol error by placing data outside the bounds of the TTT. =20 Take care, =20 Bill ------_=_NextPart_001_01C66313.6A17F30E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Based on the responses from Bill = and Julian this is what I have:

 

1) What should the behavior of a target be if it receives a = PDU on a connection, larger than what it declared with MaxRecvDataSegmentLength:

- If the PDU is part of a = SCSI command?

<JC> I will drop the connection and terminate the task and generate a UA with = ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED BY ISCSI PROTOCOL = EVENT". If this is only connection in the session then I generate a UA = (06/29/00).

- If the PDU is part of a = login?

<JC> I will drop the connection. Agreed that the default value of 8K should = be supported since login is not complete.

 

2) What should the target behavior be if the initiator sends it more data than MaxBurstLength?

3) What should the target behavior be if the = initiator sends more data than FirstBurstLength?

<JC> I have = two options here:

 

a)    As per the spec: The = target reports the "Incorrect amount of data" condition if during = data output the total data length to output is greater than FirstBurstLength = and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurstLength. The target reports = the same error when the amount of data sent as a reply to an R2T does not = match the amount requested. (0B/0C/0D – Write Error, Incorrect Amount of = Data). This should work.

 

The only issue here is that the definition of the sense code does not match = the definition in SPC-3 which says 0Ch 0Dh - WRITE ERROR - NOT ENOUGH UNSOLICITED = DATA), which is not quite what the iSCSI says.

 

 

b)    Treat this as a = really bad error and assume that I have an initiator that does not play well and = drop the session and kill the command.

 

 

I am leaning towards (b). Help!!! = Suggestions/Comments/Discussion.

 

Thanks,
 
= Jacob Cherian
Dell = Inc.
Ph: (512) 723 = 3247

From: = William Studenmund [mailto:wrstuden@wasabisystems.com]
Sent: Tuesday, April 18, = 2006 12:33 PM
To: Cherian, Jacob
Cc: ips@ietf.org
Subject: Re: [Ips] Target = Behavior Clarifications

 

On Apr 17, 2006, at 2:48 PM, <Jacob_Cherian@Dell.com> <Jacob_Cherian@Dell.com> wrote:



A couple of quick questions?

1) What should the behavior of a target be if it receives a = PDU on a connection, larger than what it declared with MaxRecvDataSegmentLength:

- If the PDU is part of a SCSI command?

- If the PDU is part of a login?

 

Drop the connection. Note, the session may still stick around as = part of recovery processing.

 

Also, during login (before FFP), the MaxRecvDataSegmentLength in = force is 8k, regardless of announced values.



2) What should the target behaviour be if the initiator sends it more data than MaxBurstLength?

3) What should the target behavior be if the = initiator sends more data than FirstBurstLength?

There are specific sense and ASC/Q values for these = errors.

 

These are treated as SCSI errors 1) because you have to give = some explanation for why you killed the SCSI task, and 2) because it is not = obvious which PDU in the burst was "too much." While you might want to = say it was the last one, that isn't necessarily = true.

 

Note also that to trigger these errors, all the data placement = had to stay within the TTT bounds and you have to be in DataPDUInOrder=3DNo. = That's the only way you can really write the same area twice. Most other errors = involved in sending too much data in a burst would trigger an iSCSI protocol = error by placing data outside the bounds of the TTT.

 

Take care,

 

Bill

------_=_NextPart_001_01C66313.6A17F30E-- --===============1588358593== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1588358593==-- From ips-bounces@ietf.org Tue Apr 18 14:15:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVujF-0005y5-0V; Tue, 18 Apr 2006 14:15:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVujD-0005y0-3v for ips@ietf.org; Tue, 18 Apr 2006 14:15:07 -0400 Received: from ausc60pc101.us.dell.com ([143.166.85.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVujC-0006n4-Cn for ips@ietf.org; Tue, 18 Apr 2006 14:15:07 -0400 DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; b=B/1aHj5AchbA1rNst1hF/ajEgOpZEsZZMJuG7FodMI/Jrts9XlLkMmq35c11GbjkMeJZhPWL4ayFcK3s+IaVSuOV/enfRKF6U3J2+P6a8j5fMHMl1mXd955X8+4nwd8P; Received: from ausx3bps305.aus.amer.dell.com ([10.3.153.43]) by ausc60pc101.us.dell.com with ESMTP; 18 Apr 2006 13:15:06 -0500 X-IronPort-AV: i="4.04,131,1144040400"; d="scan'208,217"; a="1777701:sNHT95754456" Content-class: urn:content-classes:message MIME-Version: 1.0 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Ips] Target Behavior Clarifications (with corrections) Date: Tue, 18 Apr 2006 13:15:04 -0500 Message-ID: <389040536173ED4AADA5EFEA9633358601677A31@ausx3mpc106.aus.amer.dell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Target Behavior Clarifications (with corrections) Thread-Index: AcZjDiOFcXbd7cbXTn+dIttlYI/OSAAAe1bgAADfleA= From: To: , , X-OriginalArrivalTime: 18 Apr 2006 18:15:05.0283 (UTC) FILETIME=[04830930:01C66314] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9824e5c813daed951dd476ca8f06ed95 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0676845234==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0676845234== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66314.03E967D6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66314.03E967D6 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Based on the responses from Bill and Julian this is what I have: =20 1) What should the behavior of a target be if it receives a PDU on a connection, larger than what it declared with MaxRecvDataSegmentLength: - If the PDU is part of a SCSI command?=20 I will drop the connection and terminate all tasks allegiant on that connection and generate a UA with ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED BY ISCSI PROTOCOL EVENT". If this is only connection in the session then I generate a UA (06/29/00) since when the session is reestablished there wont be any tasks. - If the PDU is part of a login? I will drop the connection. Agreed that the default value of 8K should be supported since login is not complete. =20 2) What should the target behavior be if the initiator sends it more data than MaxBurstLength? 3) What should the target behavior be if the initiator sends more data than FirstBurstLength? I have two options here:=20 =20 a) As per the spec: The target reports the "Incorrect amount of data" condition if during data output the total data length to output is greater than FirstBurstLength and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurstLength. The target reports the same error when the amount of data sent as a reply to an R2T does not match the amount requested. (0B/0C/0D - Write Error, Incorrect Amount of Data). This should work. =20 The only issue here is that the definition of the sense code does not match the definition in SPC-3 which says 0Ch 0Dh - WRITE ERROR - NOT ENOUGH UNSOLICITED DATA), which is not quite what the iSCSI says. =20 =20 b) Treat this as a really bad error and assume that I have an initiator that does not play well and drop the session and kill the command. =20 =20 I am leaning towards (b). Help!!! Suggestions/Comments/Discussion.=20 Thanks,=20 =20 Jacob Cherian=20 ________________________________ From: William Studenmund [mailto:wrstuden@wasabisystems.com]=20 Sent: Tuesday, April 18, 2006 12:33 PM To: Cherian, Jacob Cc: ips@ietf.org Subject: Re: [Ips] Target Behavior Clarifications =20 On Apr 17, 2006, at 2:48 PM, wrote: =20 A couple of quick questions? 1) What should the behavior of a target be if it receives a PDU on a connection, larger than what it declared with MaxRecvDataSegmentLength: - If the PDU is part of a SCSI command?=20 - If the PDU is part of a login? =20 Drop the connection. Note, the session may still stick around as part of recovery processing. =20 Also, during login (before FFP), the MaxRecvDataSegmentLength in force is 8k, regardless of announced values. =20 2) What should the target behaviour be if the initiator sends it more data than MaxBurstLength? 3) What should the target behavior be if the initiator sends more data than FirstBurstLength? There are specific sense and ASC/Q values for these errors. =20 These are treated as SCSI errors 1) because you have to give some explanation for why you killed the SCSI task, and 2) because it is not obvious which PDU in the burst was "too much." While you might want to say it was the last one, that isn't necessarily true. =20 Note also that to trigger these errors, all the data placement had to stay within the TTT bounds and you have to be in DataPDUInOrder=3DNo. That's the only way you can really write the same area twice. Most other errors involved in sending too much data in a burst would trigger an iSCSI protocol error by placing data outside the bounds of the TTT. =20 Take care, =20 Bill ------_=_NextPart_001_01C66314.03E967D6 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Based on the responses from Bill = and Julian this is what I have:

 

1) What should the behavior of a target be if it receives a = PDU on a connection, larger than what it declared with MaxRecvDataSegmentLength:

- If the PDU is part of a = SCSI command?

<JC> I will drop the connection and terminate all tasks allegiant on that connection and = generate a UA with ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED BY ISCSI PROTOCOL EVENT". If this is only connection in the session then I = generate a UA (06/29/00) since when the session is reestablished there wont be = any tasks.

- If the PDU is part of a = login?

<JC> I will drop the connection. Agreed that the default value of 8K should = be supported since login is not complete.

 

2) What should the target behavior be if the initiator sends it more data than MaxBurstLength?

3) What should the target behavior be if the = initiator sends more data than FirstBurstLength?

<JC> I have = two options here:

 

a)    As per the spec: The = target reports the "Incorrect amount of data" condition if during = data output the total data length to output is greater than FirstBurstLength = and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurstLength. The target reports = the same error when the amount of data sent as a reply to an R2T does not = match the amount requested. (0B/0C/0D – Write Error, Incorrect Amount of = Data). This should work.

 

The only issue here is that the definition of the sense code does not match = the definition in SPC-3 which says 0Ch 0Dh - WRITE ERROR - NOT ENOUGH = UNSOLICITED DATA), which is not quite what the iSCSI = says.

 

 

b)    Treat this as a = really bad error and assume that I have an initiator that does not play well and = drop the session and kill the command.

 

 

I am leaning towards (b). Help!!! Suggestions/Comments/Discussion.

Thanks,
 
= Jacob Cherian

From: = William Studenmund [mailto:wrstuden@wasabisystems.com]
Sent: Tuesday, April 18, = 2006 12:33 PM
To: Cherian, Jacob
Cc: ips@ietf.org
Subject: Re: [Ips] Target = Behavior Clarifications

 

On Apr 17, 2006, at 2:48 PM, <Jacob_Cherian@Dell.com> <Jacob_Cherian@Dell.com> wrote:

 

A couple of quick questions?

1) What should the behavior of a target be if it receives a = PDU on a connection, larger than what it declared with MaxRecvDataSegmentLength:

- If the PDU is part of a SCSI command?

- If the PDU is part of a login?

 

Drop the connection. Note, the session may still stick around as = part of recovery processing.

 

Also, during login (before FFP), the MaxRecvDataSegmentLength in = force is 8k, regardless of announced values.

 

2) What should the target behaviour be if the initiator sends it more data than MaxBurstLength?

3) What should the target behavior be if the = initiator sends more data than FirstBurstLength?

There are specific sense and ASC/Q values for these = errors.

 

These are treated as SCSI errors 1) because you have to give = some explanation for why you killed the SCSI task, and 2) because it is not = obvious which PDU in the burst was "too much." While you might want to = say it was the last one, that isn't necessarily = true.

 

Note also that to trigger these errors, all the data placement = had to stay within the TTT bounds and you have to be in DataPDUInOrder=3DNo. = That's the only way you can really write the same area twice. Most other errors = involved in sending too much data in a burst would trigger an iSCSI protocol = error by placing data outside the bounds of the TTT.

 

Take care,

 

Bill

------_=_NextPart_001_01C66314.03E967D6-- --===============0676845234== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0676845234==-- From ips-bounces@ietf.org Tue Apr 18 14:56:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvNH-0007Wq-Cb; Tue, 18 Apr 2006 14:56:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvNF-0007WN-Uo for ips@ietf.org; Tue, 18 Apr 2006 14:56:29 -0400 Received: from mail94.messagelabs.com ([216.82.240.115]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVvNF-0008Rm-Da for ips@ietf.org; Tue, 18 Apr 2006 14:56:29 -0400 X-VirusChecked: Checked X-Env-Sender: jhufferd@Brocade.COM X-Msg-Ref: server-5.tower-94.messagelabs.com!1145386585!55341094!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [66.243.153.112] Received: (qmail 1522 invoked from network); 18 Apr 2006 18:56:25 -0000 Received: from f112.brocade.com (HELO blasphemy.brocade.com) (66.243.153.112) by server-5.tower-94.messagelabs.com with SMTP; 18 Apr 2006 18:56:25 -0000 Received: from hq-ex-6.corp.brocade.com (hq-ex-6 [192.168.38.36]) by blasphemy.brocade.com (Postfix) with ESMTP id F0F4B1425F; Tue, 18 Apr 2006 11:56:24 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] MPA alignment Date: Tue, 18 Apr 2006 11:56:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] MPA alignment thread-index: AcZi5mdxG+AaU3IYTD+P4zcY/aHSUAAMRZ/g From: "John Hufferd" To: "Eddy Quicksall" , "Mike Ko" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9668dd9718e12afaf579fddf1143437a Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2058681031==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============2058681031== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66319.CA75F18A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66319.CA75F18A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Eddy, I agree with your statement about software RDMA being a bit silly, but only when the thought is about implementations on servers. There is at least one type of environment where using RDMA with a software iWARP stack may not be too silly, and that is when the object of the interconnect is to optimize the over all costs and save Server Cycles. In that case is may make sense to operate with a software RDMA stack on the desktop systems or workstations. Those environments often have a plentiful amount of available CPU cycles on the desktop/workstation. So, the approach is to burn CPU cycles at the desktop/workstation and save CPU cycles on the servers, which have RNICs. This type of a configuration actually seems to be a useful configuration. =20 The same argument can be used with iSCSI and iSER, but only in the case where there are RNICs in the target. It is a little bit strange, as you point out, to have the storage controller implement a software version of iSER, except perhaps for some type of compatibility or migration reasons. =20 . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 =20 _____ =20 From: Eddy Quicksall [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net]=20 Sent: Tuesday, April 18, 2006 5:48 AM To: Mike Ko Cc: ips@ietf.org Subject: Re: [Ips] MPA alignment =20 Thanks, =20 Here is my feeling on this. If one were to use a standard TCP/IP stack (that does copying) then it is a bit silly to use iSER. If one were to use a software implementation and write/modify the stack to get the desired effects of DDP then he will probably heed to the alignment notes in the spec. So if one were to support misaligned segments using a slower method then it would be OK. =20 Eddy ----- Original Message -----=20 From: Mike Ko =20 To: Eddy Quicksall =20 Cc: ips@ietf.org=20 Sent: Tuesday, April 18, 2006 2:16 AM Subject: Re: [Ips] MPA alignment =20 =09 Eddy,=20 =09 If your question is about MPA behavior in general, then it should be directed to the rddp forum.=20 =09 Assuming your question is related to iSER, then if iWARP is implemented in software and uses the existing TCP/IP stack, then it cannot guarantee that FPDU's will be aligned with TCP segments. For the general case where iWARP is implemented in an RNIC with an integrated TCP/IP stack, then it is to the RNIC vendor's advantage to optimize his product's performance and therefore FPDU's should be aligned with TCP segments. However, the receiver can still receive FPDU's which are not aligned with TCP segments if there are resegmenting middleboxes somewhere in the connection path.=20 =09 Mike =20 To: =20 cc: =20 Subject: [Ips] MPA alignment=20 =09 =09 It is preferable to have TCP sender to align MPA header where a TCP segment begins and to keep the MPA FPDU within a TCP segment, so that the receiver hardware doesn't need to temporarily buffer the FPDU for the CRC checking. =20 =20 Does anyone know of any software or hardware that is not an FPDU alignment sender?=20 Does anyone have a feel for the likelihood of software or hardware to not align FPDU's on a TCP segment?=20 =20 Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips =09 _____ =20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------_=_NextPart_001_01C66319.CA75F18A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Eddy,

I agree with your statement about = software RDMA being a bit silly, but only when the thought is about = implementations on servers.

There is at least one type of = environment where using RDMA with a software iWARP stack may not be too silly, and that is = when the object of the interconnect is to optimize the over all costs and = save Server Cycles.  In that case is may make sense to operate with a software = RDMA stack on the desktop systems or workstations.  Those environments = often have a plentiful amount of available CPU cycles on the = desktop/workstation.  So, the approach is to burn CPU cycles at the desktop/workstation and = save CPU cycles on the servers, which have RNICs.  This type of a = configuration actually seems to be a useful = configuration.

 

The same argument can be used with = iSCSI and iSER, but only in the case where there are RNICs in the target. =  It is a little bit strange, as you point out, to have the storage controller = implement a software version of iSER, except perhaps for some type of = compatibility or migration reasons.

 

.

.

.

John L Hufferd

Sr. Executive Director of = Technology

Brocade Communications Systems, = Inc

jhufferd@brocade.com

Office Phone: (408) 333-5244; = eFAX: (408) 904-4688

Alt Office Phone: (408) 997-6136; = Cell: (408) 627-9606

 

From: Eddy = Quicksall [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net]
Sent: Tuesday, April 18, = 2006 5:48 AM
To: Mike Ko
Cc: ips@ietf.org
Subject: Re: [Ips] MPA = alignment

 

Thanks,

 

Here is my feeling on this. If one were to use a standard TCP/IP = stack (that does copying) then it is a bit silly to use iSER. If one were = to use a software implementation and write/modify the stack to get the desired = effects of DDP then he will probably heed to the alignment notes in the spec. So = if one were to support misaligned segments using a slower method then it would = be OK.

 

Eddy

----- Original Message ----- =

From: Mike = Ko

Cc: ips@ietf.org =

Sent: = Tuesday, April 18, 2006 2:16 AM

Subject: Re: = [Ips] MPA alignment

 


Eddy,

If your question is about MPA behavior in general, then it should be = directed to the rddp forum.

Assuming your question is related to iSER, then if iWARP is implemented in = software and uses the existing TCP/IP stack, then it cannot guarantee that FPDU's = will be aligned with TCP segments.  For the general case where iWARP is implemented in an RNIC with an integrated TCP/IP stack, then it is to = the RNIC vendor's advantage to optimize his product's performance and therefore = FPDU's should be aligned with TCP segments.  However, the receiver can = still receive FPDU's which are not aligned with TCP segments if there are resegmenting middleboxes somewhere in the connection path. =

Mike  

To:   =      <ips@ietf.org>
cc:         =
Subject:       =  [Ips] MPA alignment


It is preferable to have TCP sender to align MPA header where a TCP segment = begins and to keep the MPA FPDU within a TCP segment, so that the receiver = hardware doesn’t need to temporarily buffer the FPDU for the CRC checking. =  
 
Does anyone know of any software or hardware that is not an FPDU alignment = sender?
Does anyone have a feel for the likelihood of software or hardware to not = align FPDU's on a TCP segment?
 
Eddy______________________________________________= _
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips=

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

------_=_NextPart_001_01C66319.CA75F18A-- --===============2058681031== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============2058681031==-- From ips-bounces@ietf.org Tue Apr 18 15:27:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvrW-0007fQ-8d; Tue, 18 Apr 2006 15:27:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVvrU-0007fL-SX for ips@ietf.org; Tue, 18 Apr 2006 15:27:44 -0400 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVvrU-0001wp-2K for ips@ietf.org; Tue, 18 Apr 2006 15:27:44 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.6/8.13.6) with ESMTP id k3IJRh8g077172 for ; Tue, 18 Apr 2006 19:27:43 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k3IJSgmw083558 for ; Tue, 18 Apr 2006 21:28:42 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k3IJRgd9001990 for ; Tue, 18 Apr 2006 21:27:43 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k3IJRgI7001985; Tue, 18 Apr 2006 21:27:42 +0200 In-Reply-To: <389040536173ED4AADA5EFEA9633358601677A30@ausx3mpc106.aus.amer.dell.com> To: Subject: RE: [Ips] Target Behavior Clarifications MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Tue, 18 Apr 2006 22:28:45 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0HF90 | November 16, 2005) at 18/04/2006 22:28:41, Serialize complete at 18/04/2006 22:28:41 X-Spam-Score: 0.1 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: ips@ietf.org, wrstuden@wasabisystems.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0182388602==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0182388602== Content-Type: multipart/alternative; boundary="=_alternative 006AE65BC2257154_=" This is a multipart message in MIME format. --=_alternative 006AE65BC2257154_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable wrote on 18/04/2006 21:10:46: > Based on the responses from Bill and Julian this is what I have: >=20 > 1) What should the behavior of a target be if it receives a PDU on a > connection, larger than what it declared with MaxRecvDataSegmentLength: > - If the PDU is part of a SCSI command?=20 > I will drop the connection and terminate the task and generate=20 > a UA with ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED BY=20 > ISCSI PROTOCOL EVENT". If this is only connection in the session=20 > then I generate a UA (06/29/00). > - If the PDU is part of a login? > I will drop the connection. Agreed that the default value of 8K > should be supported since login is not complete. >=20 > 2) What should the target behavior be if the initiator sends it moredata = than > MaxBurstLength? > 3) What should the target behavior be if the initiator sends more data=20 than=20 > FirstBurstLength? > I have two options here:=20 >=20 > a) As per the spec: The target reports the "Incorrect amount of=20 > data" condition if during data output the total data length to=20 > output is greater than FirstBurstLength and the initiator sent=20 > unsolicited non-immediate data but the total amount of unsolicited=20 > data is different than FirstBurstLength. The target reports the same > error when the amount of data sent as a reply to an R2T does not=20 > match the amount requested. (0B/0C/0D ? Write Error, Incorrect=20 > Amount of Data). This should work. >=20 > The only issue here is that the definition of the sense code does=20 > not match the definition in SPC-3 which says 0Ch 0Dh - WRITE ERROR - > NOT ENOUGH UNSOLICITED DATA), which is not quite what the iSCSI says. >=20 >=20 > b) Treat this as a really bad error and assume that I have an=20 > initiator that does not play well and drop the session and kill the=20 command. >=20 That's what I would do too=20 >=20 > I am leaning towards (b). Help!!! Suggestions/Comments/Discussion. >=20 > Thanks,=20 >=20 > Jacob Cherian=20 > Dell Inc.=20 > Ph: (512) 723 3247=20 >=20 > From: William Studenmund [mailto:wrstuden@wasabisystems.com]=20 > Sent: Tuesday, April 18, 2006 12:33 PM > To: Cherian, Jacob > Cc: ips@ietf.org > Subject: Re: [Ips] Target Behavior Clarifications >=20 > On Apr 17, 2006, at 2:48 PM, =20 > wrote: >=20 > A couple of quick questions? > 1) What should the behavior of a target be if it receives a PDU on a > connection, larger than what it declared with MaxRecvDataSegmentLength: > - If the PDU is part of a SCSI command?=20 > - If the PDU is part of a login? >=20 > Drop the connection. Note, the session may still stick around as=20 > part of recovery processing. >=20 > Also, during login (before FFP), the MaxRecvDataSegmentLength in=20 > force is 8k, regardless of announced values. >=20 > 2) What should the target behaviour be if the initiator sends it=20 > more data than MaxBurstLength? > 3) What should the target behavior be if the initiator sends more data=20 than=20 > FirstBurstLength? > There are specific sense and ASC/Q values for these errors. >=20 > These are treated as SCSI errors 1) because you have to give some=20 > explanation for why you killed the SCSI task, and 2) because it is=20 > not obvious which PDU in the burst was "too much." While you might=20 > want to say it was the last one, that isn't necessarily true. >=20 > Note also that to trigger these errors, all the data placement had=20 > to stay within the TTT bounds and you have to be in=20 > DataPDUInOrder=3DNo. That's the only way you can really write the same > area twice. Most other errors involved in sending too much data in a > burst would trigger an iSCSI protocol error by placing data outside=20 > the bounds of the TTT. >=20 > Take care, >=20 > Bill=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips --=_alternative 006AE65BC2257154_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

<Jacob=5FCherian@Dell.com> wrote on 18/04/2006 21:10:46:

> Based on the responses from Bill and Julian this is what I have:
>  
> 1) What should the behavior of a target be if it receives a PDU on a
> connection, larger than what it declared with MaxRecvDataSegmentLength= :
> - If the PDU is part of a SCSI command? =
> <JC> I will drop the connection and termi= nate the task and generate
> a UA with ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED BY
> ISCSI PROTOCOL EVENT". If this is only connection in the session
> then I generate a UA (06/29/00).
> - If the PDU is part of a login?
> <JC> I will drop the connection. Agreed that the default value of 8K
> should be supported since login is not complete.
>  
> 2) What should the target behavior be if the initiator sends it moredata than
> MaxBurstLength?
> 3) What should the target behavior be if the initiator sends more data than
> FirstBurstLength?
> <JC> I have two options here:
>  
> a)    As per the spec: The target rep= orts the "Incorrect amount of
> data" condition if during data output the total data length to
> output is greater than FirstBurstLength and the initiator sent
> unsolicited non-immediate data but the total amount of unsolicited
> data is different than FirstBurstLength. The target reports the same > error when the amount of data sent as a reply to an R2T does not
> match the amount requested. (0B/0C/0D – Write Error, Incorrect <= br> > Amount of Data). This should work.
>  
> The only issue here is that the definition of the sense code does
> not match the definition in SPC-3 which says 0Ch 0Dh - WRITE ERROR -
> NOT ENOUGH UNSOLICITED DATA), which is not quite what the iSCSI says.<= /font>
>  
>  
> b)    Treat this as a really bad error and assume that I have an
> initiator that does not play well and drop the session and kill the command.
>  
That's what I would do too
>  
> I am leaning towards (b). Help!!! Suggestions/C= omments/Discussion.
>  
> Thanks,
>  
> Jacob Cherian
> Dell Inc.
> Ph: (512) 723 3247
>
> From: William Studenmund [mailto:wrstuden@wasabisystems.com]
> Sent: Tuesday, April 18, 2006 12:33 PM
> To: Cherian, Jacob
> Cc: ips@ietf.org
> Subject: Re: [Ips] Target Behavior Clarifications
>  
> On Apr 17, 2006, at 2:48 PM, <Jacob=5FCheria= n@Dell.com> <Jacob=5FCherian@Dell.com
> > wrote:
>

> A couple of quick questions?
> 1) What should the behavior of a target be if it receives a PDU on a
> connection, larger than what it declared with MaxRecvDataSegmentLength= :
> - If the PDU is part of a SCSI command? =
> - If the PDU is part of a login?
>  
> Drop the connection. Note, the session may still stick around as
> part of recovery processing.
>  
> Also, during login (before FFP), the MaxRecvDat= aSegmentLength in
> force is 8k, regardless of announced values.
>

> 2) What should the target behaviour be if the initiator sends it
> more data than MaxBurstLength?
> 3) What should the target behavior be if the initiator sends more data than
> FirstBurstLength?
> There are specific sense and ASC/Q values for these errors.
>  
> These are treated as SCSI errors 1) because you have to give some
> explanation for why you killed the SCSI task, and 2) because it is
> not obvious which PDU in the burst was "too much." While you might
> want to say it was the last one, that isn't necessarily true.
>  
> Note also that to trigger these errors, all the data placement had
> to stay within the TTT bounds and you have to be in
> DataPDUInOrder=3DNo. That's the only way you can really write the same=
> area twice. Most other errors involved in sending too much data in a
> burst would trigger an iSCSI protocol error by placing data outside
> the bounds of the TTT.
>  
> Take care,
>  
> Bill=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
 --=_alternative 006AE65BC2257154_=-- --===============0182388602== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0182388602==-- From ips-bounces@ietf.org Tue Apr 18 17:00:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVxJ4-0006GQ-QL; Tue, 18 Apr 2006 17:00:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVxJ1-0006GL-TF for ips@ietf.org; Tue, 18 Apr 2006 17:00:15 -0400 Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVxJ1-000642-37 for ips@ietf.org; Tue, 18 Apr 2006 17:00:15 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 2D1CF87144; Tue, 18 Apr 2006 17:00:10 -0400 (EDT) In-Reply-To: <389040536173ED4AADA5EFEA9633358601677A31@ausx3mpc106.aus.amer.dell.com> References: <389040536173ED4AADA5EFEA9633358601677A31@ausx3mpc106.aus.amer.dell.com> Mime-Version: 1.0 (Apple Message framework v749.3) Message-Id: <0B6B2C4E-DE77-431F-9715-5CE9EF785ED6@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Target Behavior Clarifications (with corrections) Date: Tue, 18 Apr 2006 14:00:05 -0700 To: Jacob_Cherian@Dell.com X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 1.2 (+) X-Scan-Signature: 442d80051e0361a34f3560325c4a7092 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0234748010==" Errors-To: ips-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0234748010== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4--416919007" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-4--416919007 Content-Type: multipart/alternative; boundary=Apple-Mail-3--416919106 --Apple-Mail-3--416919106 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed On Apr 18, 2006, at 11:15 AM, wrote: > Based on the responses from Bill and Julian this is what I have: > > > > 1) What should the behavior of a target be if it receives a PDU on =20 > a connection, larger than what it declared with =20 > MaxRecvDataSegmentLength: > > - If the PDU is part of a SCSI command? > > I will drop the connection and terminate all tasks allegiant =20 > on that connection and generate a UA with ASC/ASCQ value of 47h/7Fh =20= > - "SOME COMMANDS CLEARED BY ISCSI PROTOCOL EVENT". If this is only =20 > connection in the session then I generate a UA (06/29/00) since =20 > when the session is reestablished there wont be any tasks. Actually 06/29/00 is wrong. If the initiator gets another connection =20 in within Time2Wait + Time2Retain, then you really should be doing an =20= 06/29/07. The advantage of that is that you could also do the =20 06/47/7e after the nexus loss. To be honest, I think all of this is governed by the standard =20 connection recovery procedures. :-) > - If the PDU is part of a login? > > I will drop the connection. Agreed that the default value of =20 > 8K should be supported since login is not complete. > > > > 2) What should the target behavior be if the initiator sends it =20 > more data than MaxBurstLength? > > 3) What should the target behavior be if the initiator sends more =20 > data than FirstBurstLength? > > I have two options here: > > > > a) As per the spec: The target reports the "Incorrect amount of =20 > data" condition if during data output the total data length to =20 > output is greater than FirstBurstLength and the initiator sent =20 > unsolicited non-immediate data but the total amount of unsolicited =20 > data is different than FirstBurstLength. The target reports the =20 > same error when the amount of data sent as a reply to an R2T does =20 > not match the amount requested. (0B/0C/0D =96 Write Error, Incorrect =20= > Amount of Data). This should work. > > > > The only issue here is that the definition of the sense code does =20 > not match the definition in SPC-3 which says 0Ch 0Dh - WRITE ERROR =20 > - NOT ENOUGH UNSOLICITED DATA), which is not quite what the iSCSI =20 > says. I'd say go with what the RFC says. > b) Treat this as a really bad error and assume that I have an =20 > initiator that does not play well and drop the session and kill the =20= > command. > > > > > I am leaning towards (b). Help!!! I think (a) is enough. Actually, I think it's not (a) or (b), but (a) =20= or (a) and (b); I think you really need to do the processing in (a). =20 Even if you slam the session down, there are internal processing =20 consequences of (a). :-) Take care, Bill= --Apple-Mail-3--416919106 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252
On Apr 18, 2006, at = 11:15 AM, <Jacob_Cherian@Dell.com> = wrote:

Based on the responses = from Bill and Julian this is what I have:1) What should the behavior of a target be if it receives a = PDU on a connection, larger than what it = declared with

<JC> I will drop the connection and terminate = all tasks allegiant on that = connection and generate = a UA with ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED BY ISCSI = PROTOCOL EVENT". If this is only connection in the session then I = generate a UA (06/29/00) since when the session is reestablished there = wont be any = tasks.

= Actually 06/29/00 is wrong. If the initiator gets another connection in = within Time2Wait + Time2Retain, then you really should be doing an = 06/29/07. The advantage of that is that you could also do the 06/47/7e = after the nexus loss.

To be honest, I think all = of this is governed by the standard connection recovery procedures. = :-)

<JC> I = will drop the connection. Agreed that the default value of 8K should be = supported since login is not complete.

=A0

2) What should the target = behavior be if the initiator sends it = more data than MaxBurstLength?

3) What should the = target behavior be if the initiator sends more data = than FirstBurstLength?

<JC> I = have two options here:

a)=A0=A0=A0 = As per the spec: The target reports the = "Incorrect amount of data" condition if during data output the total = data length to output is greater than FirstBurstLength and the initiator = sent unsolicited non-immediate data but the total amount of unsolicited = data is different than FirstBurstLength. The target reports the same = error when the amount of data sent as a reply to an R2T does not match = the amount requested. (0B/0C/0D =96 Write Error, Incorrect Amount of = Data). This should work.

The only = issue here is that the definition of the sense code does not match the = definition in SPC-3 which says 0Ch 0Dh - WRITE ERROR - NOT ENOUGH = UNSOLICITED DATA), which is not quite what the iSCSI = says.

<= DIV>
I'd say go with = what the RFC says.

b)=A0=A0=A0 = Treat this as a really bad error and = assume that I have an initiator that does not play well and drop the = session and kill the command.

I am leaning towards (b). = Help!!!

I think (a) is enough. Actually, I think it's not (a) or = (b), but (a) or (a) and (b); I think you really need to do the = processing in (a). Even if you slam the session down, there are internal = processing consequences of (a). :-)

Take care,

Bill
= --Apple-Mail-3--416919106-- --Apple-Mail-4--416919007 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFERVNbDJT2Egh26K0RAo4CAJ0T37A7rrXGnlo6fIHmDeQ090RuAwCdHI1l ywbbb86da/Xp86a+2bLr8+E= =HgaJ -----END PGP SIGNATURE----- --Apple-Mail-4--416919007-- --===============0234748010== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0234748010==-- From ips-bounces@ietf.org Tue Apr 18 19:14:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVzPA-0001Wh-FY; Tue, 18 Apr 2006 19:14:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVzP8-0001WY-PK for ips@ietf.org; Tue, 18 Apr 2006 19:14:42 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVzP8-00055z-6p for ips@ietf.org; Tue, 18 Apr 2006 19:14:42 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 18 Apr 2006 16:14:27 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id AF7AA2B0; Tue, 18 Apr 2006 16:14:27 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 8AF752AF; Tue, 18 Apr 2006 16:14:27 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5-GA) with ESMTP id DIK73859; Tue, 18 Apr 2006 16:14:24 -0700 (PDT) Received: from NT-SJCA-0750.brcm.ad.broadcom.com (nt-sjca-0750 [10.16.192.220]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id CBEF720501; Tue, 18 Apr 2006 16:14:24 -0700 (PDT) Received: from NT-SJCA-0752.brcm.ad.broadcom.com ([10.16.192.222]) by NT-SJCA-0750.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 16:14:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Target Behavior Clarifications (with corrections) Date: Tue, 18 Apr 2006 16:14:14 -0700 Message-ID: <710F16C36810444CA2F5821E5EAB7F23036362@NT-SJCA-0752.brcm.ad.broadcom.com> Thread-Topic: [Ips] Target Behavior Clarifications (with corrections) Thread-Index: AcZjKzO0Wp4vFEkfSxGE7j/J83dzWgAEb8Nw From: "Pat Thaler" To: "William Studenmund" , Jacob_Cherian@Dell.com X-OriginalArrivalTime: 18 Apr 2006 23:14:24.0701 (UTC) FILETIME=[D528BED0:01C6633D] X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006041809; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230332E34343435373137372E303032302D412D; ENG=IBF; TS=20060418231432; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006041809_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 685BAD593NG8836736-01-01 X-Spam-Score: 0.0 (/) X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1451534815==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1451534815== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6633D.D4FCE065" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6633D.D4FCE065 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: William Studenmund [mailto:wrstuden@wasabisystems.com]=20 Sent: Tuesday, April 18, 2006 2:00 PM To: Jacob_Cherian@Dell.com Cc: ips@ietf.org Subject: Re: [Ips] Target Behavior Clarifications (with corrections) =20 2) What should the target behavior be if the initiator sends it more data than MaxBurstLength? 3) What should the target behavior be if the initiator sends more data than FirstBurstLength? I have two options here: =09 a) As per the spec: The target reports the "Incorrect amount of data" condition if during data output the total data length to output is greater than FirstBurstLength and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurstLength. The target reports the same error when the amount of data sent as a reply to an R2T does not match the amount requested. (0B/0C/0D - Write Error, Incorrect Amount of Data). This should work. =09 The only issue here is that the definition of the sense code does not match the definition in SPC-3 which says 0Ch 0Dh - WRITE ERROR - NOT ENOUGH UNSOLICITED DATA), which is not quite what the iSCSI says. I'd say go with what the RFC says.=20 When we wrote that, IMO, we were mainly addressing the case where the initiator didn't send enough data because when the command starts we need to know how much unsolicited data there will be so we can construct the first R2T. There really is no reason that the initiator should be sending more than was requested. I have no problem with deciding to do b) instead of a). =09 =09 b) Treat this as a really bad error and assume that I have an initiator that does not play well and drop the session and kill the command. =09 =09 I am leaning towards (b). Help!!! I think (a) is enough. Actually, I think it's not (a) or (b), but (a) or (a) and (b); I think you really need to do the processing in (a). Even if you slam the session down, there are internal processing consequences of (a). :-) Take care, Bill ------_=_NextPart_001_01C6633D.D4FCE065 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
 

From: William Studenmund=20 [mailto:wrstuden@wasabisystems.com]
Sent: Tuesday, April 18, = 2006=20 2:00 PM
To: Jacob_Cherian@Dell.com
Cc:=20 ips@ietf.org
Subject: Re: [Ips] Target Behavior Clarifications = (with=20 corrections)

 <snip> 

2)=20 What should=20 the target behavior be if the = initiator=20 sends it more data than MaxBurstLength?

3) What=20 should the target behavior be=20 if the initiator sends more data than=20 FirstBurstLength?

<JC> I have = two=20 options here:

a)   =20 As per=20 the spec: The target reports the "Incorrect amount of data" condition = if=20 during data output the total data length to output is greater than=20 FirstBurstLength and the initiator sent unsolicited non-immediate data = but the=20 total amount of unsolicited data is different than FirstBurstLength. = The=20 target reports the same error when the amount of data sent as a reply = to an=20 R2T does not match the amount requested. (0B/0C/0D – Write = Error, Incorrect=20 Amount of Data). This should work.

The only issue = here is that=20 the definition of the sense code does not match the definition in = SPC-3 which=20 says 0Ch 0Dh - WRITE ERROR - NOT ENOUGH UNSOLICITED DATA), which is = not quite=20 what the iSCSI=20 says.

=

I'd say go with what the RFC says. 
<PAT> When we wrote that, IMO, we were mainly = addressing the=20 case where the initiator didn't send enough data because when = the=20 command starts we need to know how much unsolicited data there = will be=20 so we can construct the first R2T. There really is no reason that the = initiator=20 should be sending more than was requested. I have no problem with = deciding to do=20 b) instead of a).

b)   =20 Treat=20 this as a really bad error and assume that I have an initiator that = does not=20 play well and drop the session and kill the = command.

I am leaning = towards (b).=20 = Help!!!

I think (a) is enough. Actually, I think it's not (a) or (b), but = (a) or=20 (a) and (b); I think you really need to do the processing in (a). Even = if you=20 slam the session down, there are internal processing consequences of = (a).=20 :-)

Take care,

Bill
------_=_NextPart_001_01C6633D.D4FCE065-- --===============1451534815== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1451534815==-- From ips-bounces@ietf.org Thu Apr 20 10:33:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWaE7-0003rJ-P2; Thu, 20 Apr 2006 10:33:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWH7E-0002kK-Qs for ips@ietf.org; Wed, 19 Apr 2006 14:09:24 -0400 Received: from [64.238.111.98] (helo=thoth.ivivity.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWH7A-0007tm-GI for ips@ietf.org; Wed, 19 Apr 2006 14:09:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Apr 2006 14:09:17 -0400 Message-ID: <2EE025E2262D3B43A44884B0EF01C9C354F4EF@thoth.ivivity.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DDP message interleaving Thread-Index: AcZj3F+peuDtl8wKRnysoOLVlHhzxQ== From: "Ben Sum" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd X-Mailman-Approved-At: Thu, 20 Apr 2006 10:33:46 -0400 Subject: [Ips] DDP message interleaving X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0366994592==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0366994592== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C663DC.5FF7251D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C663DC.5FF7251D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is sender ever multiplexing messages? Considering following message: Message1: =20 FPDU frame MSN =3D 0, MO =3D 0, L =3D 0, T=3D 0=20 FPDU frame MSN =3D 0, MO =3D 1000, L =3D 1, T=3D 0=20 Message2: =20 FPDU frame T =3D 1, TO =3D 0, L =3D 0=20 FPDU frame T =3D 1, TO =3D 1000, L =3D 1=20 =20 Can the sender transmit as following:=20 1) FPDU frame MSN =3D 0, MO =3D 0, L =3D 0, T =3D 0=20 2) FPDU frame T =3D 1, TO =3D 0, L =3D 0=20 3) FPDU frame MSN =3D 0, MO =3D 1000, L =3D 1, T =3D 0=20 4) FPDU frame T =3D 1, TO =3D 1000, L =3D 1 =20 Regards, Ben =20 Want to help me make miracles? www.active.com/donate/tntga/tntgabsum =20 Any content within this email is provided "AS IS" for informational purposes only. No contract will be formed between the parties by virtue of this email. =20 =20 ------_=_NextPart_001_01C663DC.5FF7251D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is sender ever multiplexing messages?  = Considering following message:

Message1:    

FPDU frame MSN =3D 0, MO =3D 0, L =3D 0, T=3D 0 =

FPDU frame MSN =3D 0, MO =3D 1000, L =3D 1, T=3D = 0
Message2:     

FPDU frame T =3D 1, TO =3D 0, L =3D 0 =
FPDU frame T =3D 1, TO =3D 1000, L =3D 1
 
Can the sender transmit as following:
1)   =     FPDU frame MSN =3D 0, MO =3D 0, L =3D 0, T =3D = 0
2)   =     FPDU frame T =3D 1, TO =3D 0, L =3D 0 =
3)   =     FPDU frame MSN =3D 0, MO =3D 1000, L =3D 1, T =3D = 0
4)   =     FPDU frame T =3D 1, TO =3D 1000, L =3D = 1

 

Regards,

Ben

 

Want to help me make = miracles?

www.active.com/dona= te/tntga/tntgabsum

 

Any content within this email is = provided “AS IS” for informational purposes only.  No contract = will be formed between the parties by virtue of this email. 

 

------_=_NextPart_001_01C663DC.5FF7251D-- --===============0366994592== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0366994592==-- From ips-bounces@ietf.org Thu Apr 20 11:25:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWb1j-0005Wz-Je; Thu, 20 Apr 2006 11:25:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWb1i-0005Wu-IJ for ips@ietf.org; Thu, 20 Apr 2006 11:25:02 -0400 Received: from webmail4.speakeasy.net ([69.17.117.51] helo=webmail4.sea5.speakeasy.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWb1i-0005WV-6y for ips@ietf.org; Thu, 20 Apr 2006 11:25:02 -0400 Received: (qmail 27563 invoked from network); 20 Apr 2006 15:25:01 -0000 Received: from localhost (HELO webmail4) ([127.0.0.1]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 20 Apr 2006 15:25:01 -0000 Received: from 216.31.211.11 (unverified [216.31.211.11]) by webmail4 (VisualMail 4.0) with WEBMAIL id 25539; Thu, 20 Apr 2006 15:25:01 +0000 From: "Caitlin Bestler" To: "Ben Sum" , ips@ietf.org Importance: Normal Sensitivity: Normal Message-ID: X-Mailer: Mintersoft VisualMail, Build 4.0.111601 X-Originating-IP: [216.31.211.11] Date: Thu, 20 Apr 2006 15:25:01 +0000 Subject: Re: [Ips] DDP message interleaving MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.5 (+) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org > -----Original Message----- > From: Ben Sum [mailto:bens@ivivity.com] > Sent: Wednesday, April 19, 2006 06:09 PM > To: ips@ietf.org > Subject: [Ips] DDP message interleaving > > Is sender ever multiplexing messages? Considering following message: > > Message1: > > FPDU frame MSN = 0, MO = 0, L = 0, T= 0 > > FPDU frame MSN = 0, MO = 1000, L = 1, T= 0 > Message2: > > FPDU frame T = 1, TO = 0, L = 0 > FPDU frame T = 1, TO = 1000, L = 1 > > Can the sender transmit as following: > 1) FPDU frame MSN = 0, MO = 0, L = 0, T = 0 > 2) FPDU frame T = 1, TO = 0, L = 0 > 3) FPDU frame MSN = 0, MO = 1000, L = 1, T = 0 > 4) FPDU frame T = 1, TO = 1000, L = 1 > > > > Regards, > > Ben > There are two issues here: what you should accept, and what you should send. On the receive side, if you are processing the incoming packets optimally you will not even notice this type of anomolous ordering. A receiver definitely SHOULD NOT add extra steps to attempt to detect something of this nature. On the other hand this is definitely something that a sender SHOULD NOT send, possibly MUST NOT send. The DDP spec clarifies that the DDP layer segments messages and submits them to the LLP. It is clear that the DDP layer MUST submit all of the segments for a message in sequence and non-interleaved. What is not clear is if the LLP layer MUST assign these segments successive LLP sequences, or if it can interleave in ways that do change the sequence of L flags or the fact that the L flag is the last segment of the message. Nobody has identified a reason why a MPA layer would do such a thing, and assigning the expected TCP sequencing is at the minimum an implied SHOULD. But this is not explicitly a constraint. The SCTP Adaptation, which is under the exact same constraints as the MPA/TCP adaptation explicitly recognizes that SCTP stacks are allowed to re-order Data Chunks in order to optimize transmission. IF DDP does not impose a MUST behavior on SCTP, then it does not impose it on MPA/TCP. But SCTP has a valid "SHOULD trumping" reason for reordering packets, MPA/TCP does not. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sun Apr 23 04:47:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXaFL-0007hy-Cb; Sun, 23 Apr 2006 04:47:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXaFK-0007ht-ED for ips@ietf.org; Sun, 23 Apr 2006 04:47:10 -0400 Received: from taurus.voltaire.com ([193.47.165.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXaFJ-0007tI-9K for ips@ietf.org; Sun, 23 Apr 2006 04:47:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] MPA alignment Date: Sun, 23 Apr 2006 11:47:02 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] MPA alignment Thread-Index: AcZi5mdxG+AaU3IYTD+P4zcY/aHSUAAMRZ/gAOavAjA= From: "Dan Bar Dov" To: "John Hufferd" , "Eddy Quicksall" , "Mike Ko" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9361ae25efd9cff62e36f70ef966350e Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0805603212==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0805603212== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C666B2.7E04DE86" This is a multi-part message in MIME format. ------_=_NextPart_001_01C666B2.7E04DE86 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I just wanted to note in addition to what John said, that ISER is not a = symmetric protocol. Only the target side performs the RDMA operations. The initiator does = only the setup. =20 Dan ________________________________ From: John Hufferd [mailto:jhufferd@Brocade.COM]=20 Sent: Tuesday, April 18, 2006 9:56 PM To: Eddy Quicksall; Mike Ko Cc: ips@ietf.org Subject: RE: [Ips] MPA alignment =09 =09 Eddy, I agree with your statement about software RDMA being a bit silly, but = only when the thought is about implementations on servers. There is at least one type of environment where using RDMA with a = software iWARP stack may not be too silly, and that is when the object = of the interconnect is to optimize the over all costs and save Server = Cycles. In that case is may make sense to operate with a software RDMA = stack on the desktop systems or workstations. Those environments often = have a plentiful amount of available CPU cycles on the = desktop/workstation. So, the approach is to burn CPU cycles at the = desktop/workstation and save CPU cycles on the servers, which have = RNICs. This type of a configuration actually seems to be a useful = configuration. =20 The same argument can be used with iSCSI and iSER, but only in the case = where there are RNICs in the target. It is a little bit strange, as you = point out, to have the storage controller implement a software version = of iSER, except perhaps for some type of compatibility or migration = reasons. =20 . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 =20 =09 ________________________________ From: Eddy Quicksall [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net]=20 Sent: Tuesday, April 18, 2006 5:48 AM To: Mike Ko Cc: ips@ietf.org Subject: Re: [Ips] MPA alignment =20 Thanks, =20 Here is my feeling on this. If one were to use a standard TCP/IP stack = (that does copying) then it is a bit silly to use iSER. If one were to = use a software implementation and write/modify the stack to get the = desired effects of DDP then he will probably heed to the alignment notes = in the spec. So if one were to support misaligned segments using a = slower method then it would be OK. =20 Eddy ----- Original Message -----=20 From: Mike Ko =20 To: Eddy Quicksall =20 Cc: ips@ietf.org=20 Sent: Tuesday, April 18, 2006 2:16 AM Subject: Re: [Ips] MPA alignment =20 =09 Eddy,=20 =09 If your question is about MPA behavior in general, then it should be = directed to the rddp forum.=20 =09 Assuming your question is related to iSER, then if iWARP is = implemented in software and uses the existing TCP/IP stack, then it = cannot guarantee that FPDU's will be aligned with TCP segments. For the = general case where iWARP is implemented in an RNIC with an integrated = TCP/IP stack, then it is to the RNIC vendor's advantage to optimize his = product's performance and therefore FPDU's should be aligned with TCP = segments. However, the receiver can still receive FPDU's which are not = aligned with TCP segments if there are resegmenting middleboxes = somewhere in the connection path.=20 =09 Mike =20 To: =20 cc: =20 Subject: [Ips] MPA alignment=20 =09 =09 It is preferable to have TCP sender to align MPA header where a TCP = segment begins and to keep the MPA FPDU within a TCP segment, so that = the receiver hardware doesn't need to temporarily buffer the FPDU for = the CRC checking. =20 =20 Does anyone know of any software or hardware that is not an FPDU = alignment sender?=20 Does anyone have a feel for the likelihood of software or hardware to = not align FPDU's on a TCP segment?=20 =20 Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips =09 ________________________________ _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------_=_NextPart_001_01C666B2.7E04DE86 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I just wanted to note in addition to = what John=20 said, that ISER is not a symmetric protocol.
Only the target side performs the RDMA = operations. The=20 initiator does only the setup.
 
Dan

From: John Hufferd=20 [mailto:jhufferd@Brocade.COM]
Sent: Tuesday, April 18, 2006 = 9:56=20 PM
To: Eddy Quicksall; Mike Ko
Cc:=20 ips@ietf.org
Subject: RE: [Ips] MPA = alignment

Eddy,

I agree = with your=20 statement about software RDMA being a bit silly, but only when the = thought is=20 about implementations on servers.

There is at = least one=20 type of environment where using RDMA with a software iWARP stack may = not be=20 too silly, and that is when the object of the interconnect is to = optimize the=20 over all costs and save Server Cycles.  In that case is may make = sense to=20 operate with a software RDMA stack on the desktop systems or=20 workstations.  Those environments often have a plentiful amount = of=20 available CPU cycles on the desktop/workstation.  So, the = approach is to=20 burn CPU cycles at the desktop/workstation and save CPU cycles on the = servers,=20 which have RNICs.  This type of a configuration actually seems to = be a=20 useful configuration.

 

The same = argument can=20 be used with iSCSI and iSER, but only in the case where there are = RNICs in the=20 target.  It is a little bit strange, as you point out, to have = the=20 storage controller implement a software version of iSER, except = perhaps for=20 some type of compatibility or migration = reasons.

 

.

.

.

John L = Hufferd

Sr. Executive Director of=20 Technology

Brocade Communications Systems, = Inc

jhufferd@brocade.com

Office Phone: (408) 333-5244; = eFAX: (408)=20 904-4688

Alt Office Phone: (408) = 997-6136; Cell:=20 (408) 627-9606

 

From: Eddy=20 Quicksall [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net] =
Sent: Tuesday, April 18, 2006 = 5:48=20 AM
To: Mike = Ko
Cc: ips@ietf.org
Subject: Re: [Ips] MPA=20 alignment

 

Thanks,

 

Here is my feeling on this. If one were to = use a=20 standard TCP/IP stack (that does copying) then it is a bit silly = to use=20 iSER. If one were to use a software implementation and write/modify = the stack=20 to get the desired effects of DDP then he will probably heed to the = alignment=20 notes in the spec. So if one were to support misaligned segments using = a=20 slower method then it would be OK.

 

Eddy

----- Original Message = -----=20

From: Mike Ko=20

To: Eddy = Quicksall=20

Cc: ips@ietf.org=20

Sent:=20 Tuesday, April 18, 2006 2:16 AM

Subject: Re:=20 [Ips] MPA alignment

 


Eddy,=20

If your question = is about=20 MPA behavior in general, then it should be directed to the rddp=20 forum.

Assuming your = question is=20 related to iSER, then if iWARP is implemented in software and uses = the=20 existing TCP/IP stack, then it cannot guarantee that FPDU's will be = aligned=20 with TCP segments.  For the general case where iWARP is = implemented in=20 an RNIC with an integrated TCP/IP stack, then it is to the RNIC = vendor's=20 advantage to optimize his product's performance and therefore FPDU's = should=20 be aligned with TCP segments.  However, the receiver can still = receive=20 FPDU's which are not aligned with TCP segments if there are = resegmenting=20 middleboxes somewhere in the connection path. =

Mike =  =20

To:  =20      <ips@ietf.org>=20
cc:  =20      
Subject:=20        [Ips] MPA=20 alignment


It is preferable to = have TCP=20 sender to align MPA header where a TCP segment begins and to keep = the MPA=20 FPDU within a TCP segment, so that the receiver hardware doesn=92t = need to=20 temporarily buffer the FPDU for the CRC checking. =  =20
 
Does anyone know of = any software=20 or hardware that is not an FPDU alignment sender? =
Does=20 anyone have a feel for the likelihood of software or hardware to not = align=20 FPDU's on a TCP segment?
 
Eddy_______________________________________________<= FONT=20 face=3D"Courier New" size=3D2>
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips=

_______________________________________________
Ips=20 mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

------_=_NextPart_001_01C666B2.7E04DE86-- --===============0805603212== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0805603212==-- From ips-bounces@ietf.org Sun Apr 23 16:03:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXknw-0002tX-Gb; Sun, 23 Apr 2006 16:03:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXknv-0002tS-TA for ips@ietf.org; Sun, 23 Apr 2006 16:03:35 -0400 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXknv-0006Az-ES for ips@ietf.org; Sun, 23 Apr 2006 16:03:35 -0400 Received: from ivvtdkv0981 (unknown[218.75.77.238]) by comcast.net (sccrmhc11) with SMTP id <2006042320033201100qehide>; Sun, 23 Apr 2006 20:03:33 +0000 Message-ID: <006001c66775$93ab7600$2e01a8c0@ivivity.com> From: "Eddy Quicksall" To: "Pat Thaler" , "William Studenmund" , References: <710F16C36810444CA2F5821E5EAB7F23036362@NT-SJCA-0752.brcm.ad.broadcom.com> Subject: Re: [Ips] Target Behavior Clarifications (with corrections) Date: Mon, 24 Apr 2006 04:03:27 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 1.2 (+) X-Scan-Signature: 9a9ddb14fac983e71b59f23b52a45b4e Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0328319054==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0328319054== Content-Type: multipart/alternative; boundary="----=_NextPart_000_005D_01C66754.0A58E6B0" This is a multi-part message in MIME format. ------=_NextPart_000_005D_01C66754.0A58E6B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In most cases I feel that if the initiator is going to violate the spec = then the connection should just be dropped (a reject or UA could still = be used before the drop). I feel this way because to continue after a = protocol error will probably lead to other problems that may in fact be = more serious. Also I prefer a reject because these errors are usually detected at the = iSCSI layer and for the iSCSI layer to give a UA means more logic to = understand the SCSI semantics. For something like the errors you have mentioned the initiator is not = going to correct itself and do it right the 2nd time. Eddy ----- Original Message -----=20 From: Pat Thaler=20 To: William Studenmund ; Jacob_Cherian@Dell.com=20 Cc: ips@ietf.org=20 Sent: Tuesday, April 18, 2006 7:14 PM Subject: RE: [Ips] Target Behavior Clarifications (with corrections) -------------------------------------------------------------------------= ----- From: William Studenmund [mailto:wrstuden@wasabisystems.com]=20 Sent: Tuesday, April 18, 2006 2:00 PM To: Jacob_Cherian@Dell.com Cc: ips@ietf.org Subject: Re: [Ips] Target Behavior Clarifications (with corrections) =20 2) What should the target behavior be if the initiator sends it more = data than MaxBurstLength? 3) What should the target behavior be if the initiator sends more = data than FirstBurstLength? I have two options here: a) As per the spec: The target reports the "Incorrect amount of = data" condition if during data output the total data length to output is = greater than FirstBurstLength and the initiator sent unsolicited = non-immediate data but the total amount of unsolicited data is different = than FirstBurstLength. The target reports the same error when the amount = of data sent as a reply to an R2T does not match the amount requested. = (0B/0C/0D - Write Error, Incorrect Amount of Data). This should work. The only issue here is that the definition of the sense code does = not match the definition in SPC-3 which says 0Ch 0Dh - WRITE ERROR - NOT = ENOUGH UNSOLICITED DATA), which is not quite what the iSCSI says. I'd say go with what the RFC says.=20 When we wrote that, IMO, we were mainly addressing the case = where the initiator didn't send enough data because when the command = starts we need to know how much unsolicited data there will be so we can = construct the first R2T. There really is no reason that the initiator = should be sending more than was requested. I have no problem with = deciding to do b) instead of a). b) Treat this as a really bad error and assume that I have an = initiator that does not play well and drop the session and kill the = command. I am leaning towards (b). Help!!! I think (a) is enough. Actually, I think it's not (a) or (b), but (a) = or (a) and (b); I think you really need to do the processing in (a). = Even if you slam the session down, there are internal processing = consequences of (a). :-) Take care, Bill -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_005D_01C66754.0A58E6B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In most cases I feel that if the initiator is going = to violate=20 the spec then the connection should just be dropped (a reject or = UA could=20 still be used before the drop). I feel this way because to continue = after a=20 protocol error will probably lead to other problems that may in fact be = more=20 serious.
 
Also I prefer a reject because these errors are = usually=20 detected at the iSCSI layer and for the iSCSI layer to give a UA means = more=20 logic to understand the SCSI semantics.
 
For something like the errors you have mentioned the = initiator=20 is not going to correct itself and do it right the 2nd = time.
 
Eddy
----- Original Message -----
From:=20 Pat=20 Thaler
Sent: Tuesday, April 18, 2006 = 7:14=20 PM
Subject: RE: [Ips] Target = Behavior=20 Clarifications (with corrections)

 

From: William Studenmund=20 [mailto:wrstuden@wasabisystems.com]
Sent: Tuesday, April = 18, 2006=20 2:00 PM
To: Jacob_Cherian@Dell.com
C= c:=20 ips@ietf.org
Subject: = Re: [Ips]=20 Target Behavior Clarifications (with corrections)

 <snip> 

2) = What should=20 the target behavior be if = the=20 initiator sends it more data than = MaxBurstLength?

3) What=20 should the target = behavior=20 be if the initiator sends more data than = FirstBurstLength?

<JC> I = have two=20 options here:

a)   =20 As per=20 the spec: The target reports the "Incorrect amount of data" = condition if=20 during data output the total data length to output is greater than=20 FirstBurstLength and the initiator sent unsolicited non-immediate = data but=20 the total amount of unsolicited data is different than = FirstBurstLength. The=20 target reports the same error when the amount of data sent as a = reply to an=20 R2T does not match the amount requested. (0B/0C/0D =96 Write Error, = Incorrect=20 Amount of Data). This should work.

The only issue = here is=20 that the definition of the sense code does not match the definition = in SPC-3=20 which says 0Ch 0Dh - WRITE ERROR - NOT ENOUGH UNSOLICITED DATA), = which is=20 not quite what the iSCSI=20 = says.

=

I'd say go with what the RFC says. 
<PAT> When we wrote that, IMO, we were mainly = addressing the=20 case where the initiator didn't send enough data because = when the=20 command starts we need to know how much unsolicited = data there will=20 be so we can construct the first R2T. There really is no reason that = the=20 initiator should be sending more than was requested. I have no problem = with=20 deciding to do b) instead of a).

b)   =20 Treat=20 this as a really bad error and assume that I have an initiator that = does not=20 play well and drop the session and kill the=20 command.

I am leaning = towards (b).=20 = Help!!!

I think (a) is enough. Actually, I think it's not (a) or (b), but = (a) or=20 (a) and (b); I think you really need to do the processing in (a). Even = if you=20 slam the session down, there are internal processing consequences of = (a).=20 :-)

Take care,

Bill

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_005D_01C66754.0A58E6B0-- --===============0328319054== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0328319054==-- From ips-bounces@ietf.org Mon Apr 24 03:46:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXvlg-0000DA-LC; Mon, 24 Apr 2006 03:46:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXvlf-0000Cf-3V for ips@ietf.org; Mon, 24 Apr 2006 03:45:59 -0400 Received: from mail53.messagelabs.com ([216.82.249.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FXvXV-0004BY-LE for ips@ietf.org; Mon, 24 Apr 2006 03:31:28 -0400 X-VirusChecked: Checked X-Env-Sender: jhufferd@Brocade.COM X-Msg-Ref: server-4.tower-53.messagelabs.com!1145863879!60741242!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [66.243.153.112] Received: (qmail 28203 invoked from network); 24 Apr 2006 07:31:19 -0000 Received: from f112.brocade.com (HELO blasphemy.brocade.com) (66.243.153.112) by server-4.tower-53.messagelabs.com with SMTP; 24 Apr 2006 07:31:19 -0000 Received: from hq-ex-6.corp.brocade.com (hq-ex-6 [192.168.38.36]) by blasphemy.brocade.com (Postfix) with ESMTP id 7ECC914269; Mon, 24 Apr 2006 00:31:19 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] MPA alignment Date: Mon, 24 Apr 2006 00:31:19 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] MPA alignment thread-index: AcZi5mdxG+AaU3IYTD+P4zcY/aHSUAAMRZ/gAOavAjAAL4JxgA== From: "John Hufferd" To: "Dan Bar Dov" , "Eddy Quicksall" , "Mike Ko" X-Spam-Score: 0.0 (/) X-Scan-Signature: 908e7c498db66256d5e0db08ac2f5506 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1986061786==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1986061786== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66771.1401ECFE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66771.1401ECFE Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Well, the initiator side must still field the RDMA messages sent by the target (RDMA Read & RDMA write). And that means that the RDMA Read response must be handled by initiator side, and of course the RDMA write must be handled and data moved into the appropriate buffers when the RDMA write message is received from the target. =20 =20 The software RDMA stack on the Initiator is really quite busy. =20 . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 =20 _____ =20 From: Dan Bar Dov [mailto:danb@voltaire.com]=20 Sent: Sunday, April 23, 2006 1:47 AM To: John Hufferd; Eddy Quicksall; Mike Ko Cc: ips@ietf.org Subject: RE: [Ips] MPA alignment =20 I just wanted to note in addition to what John said, that ISER is not a symmetric protocol. Only the target side performs the RDMA operations. The initiator does only the setup. =20 Dan =20 =09 _____ =20 From: John Hufferd [mailto:jhufferd@Brocade.COM]=20 Sent: Tuesday, April 18, 2006 9:56 PM To: Eddy Quicksall; Mike Ko Cc: ips@ietf.org Subject: RE: [Ips] MPA alignment Eddy, I agree with your statement about software RDMA being a bit silly, but only when the thought is about implementations on servers. There is at least one type of environment where using RDMA with a software iWARP stack may not be too silly, and that is when the object of the interconnect is to optimize the over all costs and save Server Cycles. In that case is may make sense to operate with a software RDMA stack on the desktop systems or workstations. Those environments often have a plentiful amount of available CPU cycles on the desktop/workstation. So, the approach is to burn CPU cycles at the desktop/workstation and save CPU cycles on the servers, which have RNICs. This type of a configuration actually seems to be a useful configuration. =20 The same argument can be used with iSCSI and iSER, but only in the case where there are RNICs in the target. It is a little bit strange, as you point out, to have the storage controller implement a software version of iSER, except perhaps for some type of compatibility or migration reasons. =20 . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 =20 =09 _____ =20 From: Eddy Quicksall [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net]=20 Sent: Tuesday, April 18, 2006 5:48 AM To: Mike Ko Cc: ips@ietf.org Subject: Re: [Ips] MPA alignment =20 Thanks, =20 Here is my feeling on this. If one were to use a standard TCP/IP stack (that does copying) then it is a bit silly to use iSER. If one were to use a software implementation and write/modify the stack to get the desired effects of DDP then he will probably heed to the alignment notes in the spec. So if one were to support misaligned segments using a slower method then it would be OK. =20 Eddy ----- Original Message -----=20 From: Mike Ko =20 To: Eddy Quicksall =20 Cc: ips@ietf.org=20 Sent: Tuesday, April 18, 2006 2:16 AM Subject: Re: [Ips] MPA alignment =20 =09 Eddy,=20 =09 If your question is about MPA behavior in general, then it should be directed to the rddp forum.=20 =09 Assuming your question is related to iSER, then if iWARP is implemented in software and uses the existing TCP/IP stack, then it cannot guarantee that FPDU's will be aligned with TCP segments. For the general case where iWARP is implemented in an RNIC with an integrated TCP/IP stack, then it is to the RNIC vendor's advantage to optimize his product's performance and therefore FPDU's should be aligned with TCP segments. However, the receiver can still receive FPDU's which are not aligned with TCP segments if there are resegmenting middleboxes somewhere in the connection path.=20 =09 Mike =20 To: =20 cc: =20 Subject: [Ips] MPA alignment=20 =09 =09 It is preferable to have TCP sender to align MPA header where a TCP segment begins and to keep the MPA FPDU within a TCP segment, so that the receiver hardware doesn't need to temporarily buffer the FPDU for the CRC checking. =20 =20 Does anyone know of any software or hardware that is not an FPDU alignment sender?=20 Does anyone have a feel for the likelihood of software or hardware to not align FPDU's on a TCP segment?=20 =20 Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips =09 _____ =20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------_=_NextPart_001_01C66771.1401ECFE Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Well, the initiator side must still = field the RDMA messages sent by the target (RDMA Read & RDMA write). And = that means that the RDMA Read response must be handled by initiator side, and = of course the RDMA write must be handled and data moved into the = appropriate buffers when the RDMA write message is received from the target. =  

 

The software RDMA stack on the = Initiator is really quite busy.

 

.

.

.

John L Hufferd

Sr. Executive Director of = Technology

Brocade Communications Systems, = Inc

jhufferd@brocade.com

Office Phone: (408) 333-5244; = eFAX: (408) 904-4688

Alt Office Phone: (408) 997-6136; = Cell: (408) 627-9606

 

From: = Dan = Bar Dov [mailto:danb@voltaire.com]
Sent: Sunday, April 23, = 2006 1:47 AM
To: John Hufferd; Eddy = Quicksall; Mike Ko
Cc: ips@ietf.org
Subject: RE: [Ips] MPA = alignment

 

I just wanted to note in = addition to what John said, that ISER is not a symmetric = protocol.

Only the target side performs the = RDMA operations. The initiator does only the = setup.

 

Dan

 

From: John Hufferd [mailto:jhufferd@Brocade.COM]
Sent: Tuesday, April 18, = 2006 9:56 PM
To: Eddy Quicksall; Mike = Ko
Cc: ips@ietf.org
Subject: RE: [Ips] MPA = alignment

Eddy,

I agree with your statement about = software RDMA being a bit silly, but only when the thought is about = implementations on servers.

There is at least one type of = environment where using RDMA with a software iWARP stack may not be too silly, and = that is when the object of the interconnect is to optimize the over all costs = and save Server Cycles.  In that case is may make sense to operate with a = software RDMA stack on the desktop systems or workstations.  Those = environments often have a plentiful amount of available CPU cycles on the desktop/workstation.  So, the approach is to burn CPU cycles at the desktop/workstation and save CPU cycles on the servers, which have = RNICs.  This type of a configuration actually seems to be a useful = configuration.

 

The same argument can be used with = iSCSI and iSER, but only in the case where there are RNICs in the target. =  It is a little bit strange, as you point out, to have the storage controller implement a software version of iSER, except perhaps for some type of compatibility or migration reasons.

 

.

.

.

John L Hufferd

Sr. Executive Director of = Technology

Brocade Communications Systems, = Inc

jhufferd@brocade.com

Office Phone: (408) 333-5244; = eFAX: (408) 904-4688

Alt Office Phone: (408) 997-6136; = Cell: (408) 627-9606

 

From: Eddy = Quicksall [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net]
Sent: Tuesday, April 18, = 2006 5:48 AM
To: Mike Ko
Cc: ips@ietf.org
Subject: Re: [Ips] MPA = alignment

 

Thanks,

 

Here is my feeling on this. If one were to use a standard TCP/IP = stack (that does copying) then it is a bit silly to use iSER. If one were = to use a software implementation and write/modify the stack to get the desired = effects of DDP then he will probably heed to the alignment notes in the spec. So = if one were to support misaligned segments using a slower method then it would = be OK.

 

Eddy

----- Original Message ----- =

From: Mike = Ko

Cc: ips@ietf.org =

Sent: = Tuesday, April 18, 2006 2:16 AM

Subject: Re: = [Ips] MPA alignment

 


Eddy,

If your question is about MPA behavior in general, then it should be = directed to the rddp forum.

Assuming your question is related to iSER, then if iWARP is implemented in = software and uses the existing TCP/IP stack, then it cannot guarantee that FPDU's = will be aligned with TCP segments.  For the general case where iWARP is implemented in an RNIC with an integrated TCP/IP stack, then it is to = the RNIC vendor's advantage to optimize his product's performance and therefore = FPDU's should be aligned with TCP segments.  However, the receiver can = still receive FPDU's which are not aligned with TCP segments if there are resegmenting middleboxes somewhere in the connection path. =

Mike  

To:   =      <ips@ietf.org>
cc:        
Subject:       =  [Ips] MPA alignment


It is preferable to have TCP sender to align MPA header where a TCP segment = begins and to keep the MPA FPDU within a TCP segment, so that the receiver = hardware doesn’t need to temporarily buffer the FPDU for the CRC checking. =  
 
Does anyone know of any software or hardware that is not an FPDU alignment = sender?
Does anyone have a feel for the likelihood of software or hardware to not = align FPDU's on a TCP segment?
 
Eddy______________________________________________= _
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips=

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

------_=_NextPart_001_01C66771.1401ECFE-- --===============1986061786== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1986061786==-- From ips-bounces@ietf.org Mon Apr 24 09:44:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY1MR-0006be-L3; Mon, 24 Apr 2006 09:44:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY1MQ-0006bZ-MI for ips@ietf.org; Mon, 24 Apr 2006 09:44:18 -0400 Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY1MP-0004eH-FO for ips@ietf.org; Mon, 24 Apr 2006 09:44:18 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id k3ODiEks022058 for ; Mon, 24 Apr 2006 09:44:15 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id k3ODiB3L022053; Mon, 24 Apr 2006 09:44:12 -0400 Received: from PKONING.equallogic.com ([172.16.1.176]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 09:44:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17484.54828.106000.849356@gargle.gargle.HOWL> Date: Mon, 24 Apr 2006 09:44:12 -0400 From: Paul Koning To: eddy_quicksall_iVivity_iSCSI@Comcast.net Subject: Re: [Ips] Target Behavior Clarifications (with corrections) References: <710F16C36810444CA2F5821E5EAB7F23036362@NT-SJCA-0752.brcm.ad.broadcom.com> <006001c66775$93ab7600$2e01a8c0@ivivity.com> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid X-OriginalArrivalTime: 24 Apr 2006 13:44:11.0857 (UTC) FILETIME=[2B318C10:01C667A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Jacob_Cherian@Dell.com, wrstuden@wasabisystems.com, ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org >>>>> "Eddy" == Eddy Quicksall writes: Eddy> In most cases I feel that if the initiator is going to violate Eddy> the spec then the connection should just be dropped ... I agree. If the other side doesn't do what the spec says, why keep talking? There's no reason to believe that will help matters. The other argument is that error paths for obscure errors should be simple, otherwise they are likely to be buggy. Introducing the risk of bugs into an iSCSI implementation for the sake of supporting broken partners it not a good tradeoff. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Apr 27 08:13:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ5ND-0001BD-I0; Thu, 27 Apr 2006 08:13:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ5NB-0001B8-Oe for ips@ietf.org; Thu, 27 Apr 2006 08:13:29 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ5NA-0000Lz-Hk for ips@ietf.org; Thu, 27 Apr 2006 08:13:29 -0400 Received: from ivvtdkv0981 (unknown[218.75.77.238]) by comcast.net (sccrmhc13) with SMTP id <20060427121326013000lrvre>; Thu, 27 Apr 2006 12:13:27 +0000 Message-ID: <000001c66a58$92bc5440$2301a8c0@ivivity.com> From: "Eddy Quicksall" To: Date: Thu, 27 Apr 2006 14:50:28 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 1.3 (+) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [Ips] Targets that don't want to support discovery X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1469907786==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1469907786== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C66A09.ECC2FF10" This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C66A09.ECC2FF10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Appendix D says: A system that contains targets MUST support discovery sessions on each of its iSCSI IP address-port pairs, and MUST support the SendTargets command on the discovery session Suppose I have targets A, B and C. I want target A to be the only target = that can support discovery. Login to targets B and C will be redirected = by A. This is fine except for the fact that once the redirection occurs the = initiator has the address of B and C and could open a discovery session = to B or C. I'm thinking that I could have B and C redirect to A for any discovery = session hence A would become the only target to support discovery (but = that would "break the law"). I'm wondering how the community thinks this should be handled. Eddy ------=_NextPart_000_0003_01C66A09.ECC2FF10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Appendix D says:
   A system that contains targets MUST = support=20 discovery sessions on
   each of its iSCSI IP address-port = pairs,=20 and MUST support the
   SendTargets command on the = discovery=20 session
 
Suppose I have targets A, B and C. I want target A = to be the=20 only target that can support discovery. Login to targets B and C will be = redirected by A.
 
This is fine except for the fact that once the = redirection=20 occurs the initiator has the address of B and C and could open a = discovery=20 session to B or C.
 
I'm thinking that I could have B and C redirect to A = for any=20 discovery session hence A would become the only target to support = discovery (but=20 that would "break the law").
 
I'm wondering how the community thinks this should = be=20 handled.
 
Eddy
------=_NextPart_000_0003_01C66A09.ECC2FF10-- --===============1469907786== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1469907786==-- From ips-bounces@ietf.org Thu Apr 27 19:13:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZFfi-0000k3-Pb; Thu, 27 Apr 2006 19:13:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZFfc-0000Yo-WB for ips@ietf.org; Thu, 27 Apr 2006 19:13:13 -0400 Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZFbn-0001lX-VX for ips@ietf.org; Thu, 27 Apr 2006 19:09:16 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 2397687188; Thu, 27 Apr 2006 19:09:13 -0400 (EDT) In-Reply-To: <000001c66a58$92bc5440$2301a8c0@ivivity.com> References: <000001c66a58$92bc5440$2301a8c0@ivivity.com> Mime-Version: 1.0 (Apple Message framework v749.3) X-Priority: 3 Message-Id: <83C76124-0CAA-49D7-B635-52C072572B28@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Targets that don't want to support discovery Date: Thu, 27 Apr 2006 16:09:04 -0700 To: Eddy Quicksall X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1353136810==" Errors-To: ips-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1353136810== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-368419839" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2-368419839 Content-Type: multipart/alternative; boundary=Apple-Mail-1-368419749 --Apple-Mail-1-368419749 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Apr 27, 2006, at 11:50 AM, Eddy Quicksall wrote: > Appendix D says: > A system that contains targets MUST support discovery sessions on > each of its iSCSI IP address-port pairs, and MUST support the > SendTargets command on the discovery session > > Suppose I have targets A, B and C. I want target A to be the only > target that can support discovery. Login to targets B and C will be > redirected by A. > > This is fine except for the fact that once the redirection occurs > the initiator has the address of B and C and could open a discovery > session to B or C. > > I'm thinking that I could have B and C redirect to A for any > discovery session hence A would become the only target to support > discovery (but that would "break the law"). > > I'm wondering how the community thinks this should be handled. I have a feeling that that'd be breaking the rules. Why do you want to do this? Another option is that while ports B and C should support discovery sessions, they don't have to do it very efficiently. It's fine if they use some sort of proxy to internally route the commands to A for processing. So only A is very smart, but discovery works everywhere. Take care, Bill --Apple-Mail-1-368419749 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Apr 27, 2006, at = 11:50 AM, Eddy Quicksall wrote:

=
Appendix D says:
=A0 =A0A system that contains targets MUST support discovery = sessions on
=A0=A0 each of its iSCSI IP address-port pairs, and MUST = support the
=A0=A0 SendTargets command on the discovery = session
=A0
Suppose I have targets A, B and C. I want target A to be the = only target that can support discovery. Login to targets B and C will be = redirected=A0by A.
=A0
=
This is fine except for the fact that once the = redirection occurs the initiator has the address of B and C and could = open a discovery session to B or C.
=A0
I'm thinking that I = could have B and C redirect to A for any discovery session hence A would = become the only target to support discovery (but that would "break the = law").
=A0
I'm wondering how the community thinks this should be = handled.

I have a feeling that = that'd be breaking the rules.

Why do you want to do = this?

Another = option is that while ports B and C should support discovery sessions, = they don't have to do it very efficiently. It's fine if they use some = sort of proxy to internally route the commands to A for processing. So = only A is very smart, but discovery works everywhere.

Take care,

Bill
= --Apple-Mail-1-368419749-- --Apple-Mail-2-368419839 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEUU8YDJT2Egh26K0RAmcdAJ4izGjSx1xV2vyaJtmDVtnwUtcyfACeIr/Z 82zDMHEMgLpKVwi4MuIVW3E= =pOnm -----END PGP SIGNATURE----- --Apple-Mail-2-368419839-- --===============1353136810== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1353136810==--