From david.black@emc.com Tue Jan 1 16:20:36 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609A621E8042 for ; Tue, 1 Jan 2013 16:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeNOo4OgNl3b for ; Tue, 1 Jan 2013 16:20:35 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id C261E21E8030 for ; Tue, 1 Jan 2013 16:20:35 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r020KUI6018081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Jan 2013 19:20:33 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Tue, 1 Jan 2013 19:20:17 -0500 Received: from mxhub17.corp.emc.com (mxhub17.corp.emc.com [10.254.93.46]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r020KGZc010227 for ; Tue, 1 Jan 2013 19:20:17 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub17.corp.emc.com ([10.254.93.46]) with mapi; Tue, 1 Jan 2013 19:20:16 -0500 From: "Black, David" To: "storm@ietf.org" Importance: high X-Priority: 1 Date: Tue, 1 Jan 2013 19:20:15 -0500 Thread-Topic: storm WG draft status + No Orlando meeting Thread-Index: Ac3ofu/+OnXFgnZlRnK5nrw46pKEYw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71287DB21E9@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] storm WG draft status + No Orlando meeting X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 00:20:36 -0000 My day job's been demanding too much of my time lately, but I'm finally getting back to storm WG activity after a few months of too many other things to do. Sorry for the hiatus, and here's the status info for the storm WG's five drafts as I understand things: iSCSI Consolidated: Completed IESG evaluation, with a number of issues that need to be resolved. At least two security issues will be sent to this list soon, as they need attention from the working group. iSCSI Features Update (SAM): Completed IETF Last Call. Needs a revised version in order to go to the IESG. I believe that the draft editor understands what needs to be done; with luck that'll go to IESG Evaluation this month. iSCSI MIB: Sent back to MIB Doctors for a re-review of changes. We're waiting on them. RDMAP Extensions: This one's about to expire w/o changes again due to delays in working on other drafts. There won't be time for me to do a detailed technical review and get the new version submitted before the current version expires. OTOH, there are some minor issues with the text that specifies the new IANA registry in section 10.1 - I suggest that the authors update that text based on the text in the final version of the RDDP registries draft: http://tools.ietf.org/id/draft-ietf-storm-rddp-registries-02.txt As part of this: - The registry should be called "RDMAP Message Atomic Operation Subcodes" and change from "Code" to "Subcode" elsewhere in the draft. This avoids confusion with the main RDMAP Opcodes. - Add a sentence to say that an experimental RDMAP opcode has already been allocated, and hence there is no need for an experimental atomic operation subcode. While some of the issues with the Consolidated draft require WG attention, I don't think a meeting will be needed to deal with them, so I don't plan to ask for meeting time in Orlando in March. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From david.black@emc.com Tue Jan 1 17:13:11 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142E621E8041 for ; Tue, 1 Jan 2013 17:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+8tJ1LpXUCA for ; Tue, 1 Jan 2013 17:13:10 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE1121E8030 for ; Tue, 1 Jan 2013 17:13:03 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r021D16r024899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Jan 2013 20:13:01 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Tue, 1 Jan 2013 20:12:46 -0500 Received: from mxhub17.corp.emc.com (mxhub17.corp.emc.com [10.254.93.46]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r021CkO2014011 for ; Tue, 1 Jan 2013 20:12:46 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub17.corp.emc.com ([10.254.93.46]) with mapi; Tue, 1 Jan 2013 20:12:45 -0500 From: "Black, David" To: "storm@ietf.org" Importance: high X-Priority: 1 Date: Tue, 1 Jan 2013 20:12:45 -0500 Thread-Topic: iSCSI consolidated draft: IPsec topics Thread-Index: Ac3ohkVbe490JnOWSJGCGTVjrbWKEg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71287DB21EB@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] iSCSI consolidated draft: IPsec topics X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 01:13:11 -0000 This email is sent as the shepherd for the iSCSI consolidated draft. Three issues have arisen around the iSCSI consolidated draft's IPsec provisions. In rough order from simpler to more complex, they are: a) Need to specify required key lengths b) Scope of update to RFC 3723 (IP Storage Security) c) Encryption Algorithm requirements I don't think the first two are controversial, but the third one may be. -- a) Required key lengths There are a bunch of requirements (MUST or SHOULD) for AES algorithm implementation that don't specify a key length. Proposal: The requirements apply to 128 bit keys. Longer key lengths (192 bits, 256 bits) are MAY requirements and hence don't need to be stated. -- b) Scope of IPsec update to RFC 3723 (IP Storage Security) RFC 3723's IPsec profile was used by a number of protocols beyond iSCSI, including FCIP, iFCP and the RDDP (iWarp) protocols. The effects of the update to that profile aren't obvious. Proposal: List all the RFCs that pick up this update in the consolidated iSCSI draft's "Updates" header and add some text to the Security Considerations section to explain this. -- c) Encryption Algorithm requirements Here's what's currently in the consolidated iSCSI draft: - 3DES in CBC mode MUST be implemented [RFC2451]. - AES in Counter mode SHOULD be implemented [RFC3686]. - Implementations that support IKEv2 [RFC5996] SHOULD also implement AES GCM [RFC4106] Aside from adding the 128 bit key size requirement, there are a couple of other concerns: (1) The MUST for 3DES-CBC has become questionable due to 3DES's 64 bit block size, i.e., the core cipher encrypts or decrypts 64 bits at a time. Things start to go awry cryptographically as one approaches the birthday bound of 32GB (GigaBytes) of data encrypted under the same key. Here are a couple of links: http://www.ietf.org/mail-archive/web/ipsec/current/msg07997.html http://www.ietf.org/mail-archive/web/ipsec/current/msg08031.html How far away to stay from that bound is a judgment call, but 32GB or some fraction thereof is not a lot of data for iSCSI to move. One could deal with this via rekeying, but the result will be rather frequent rekeying if one decides to stay at least an order of magnitude away on a multi-gigabit/sec link. In contrast, AES has a 128 bit blocksize, and so its birthday bound is astronomical (2^69 bytes if I have the math right). AES CBC is the most common mandatory-to-implement mode for interoperability. (2) AES CTR was originally selected for its hardware friendliness (e.g., it pipelines well), even though there was no hardware friendly integrity MAC algorithm to go with it at the time. AES GCM is now the strongly preferred choice, as it provides encryption and a MAC. ... Now comes the fun ... Proposal (w/o RFC citations, all AES requirements are for 128 bit keys): - 3DES in CBC mode MAY be implemented (previously MUST) - AES in CBC mode MUST be implemented (previously implicitly MAY) - AES in Counter mode MAY be implemented (previously SHOULD) - Implementations that support IKEv2 SHOULD also implement AES GCM (new requirement) This would be accompanied by text that explains the birthday bound effect of 3DES's 64 bit blocksize, and suggests that implementations desiring hardware efficiency look to AES GCM rather than AES Counter. The intent is that these requirements are readily met by widely available IPsec implementations. ------------------ Please comment. I'll probably assume that a) key size and b) RFC 3723 IPsec update scope are ok in the absence of objection, but I definitely want to see some discussion of c) encryption algorithm requirements. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From david.black@emc.com Tue Jan 1 17:49:15 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480B621E8041 for ; Tue, 1 Jan 2013 17:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.788 X-Spam-Level: X-Spam-Status: No, score=-102.788 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGdmDJnq6iCa for ; Tue, 1 Jan 2013 17:49:14 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 923B921E8030 for ; Tue, 1 Jan 2013 17:49:14 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r021nDGs015602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Jan 2013 20:49:13 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Tue, 1 Jan 2013 20:48:55 -0500 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r021mtJB003741 for ; Tue, 1 Jan 2013 20:48:55 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Tue, 1 Jan 2013 20:48:55 -0500 From: "Black, David" To: "storm@ietf.org" Importance: high X-Priority: 1 Date: Tue, 1 Jan 2013 20:48:54 -0500 Thread-Topic: iSCSI consolidated draft: Authentication consistency Thread-Index: Ac3oi1IpMQZhkYNmRzWn/pFNQF3Jtg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71287DB21EE@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] iSCSI consolidated draft: Authentication consistency X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 01:49:15 -0000 This email is sent as the shepherd for the iSCSI consolidated draft. Security review has turned up a couple of issues in iSCSI in-band authentication. I want to summarize them for discussion before the effort is invested in writing detailed text. I believe that good implementers will get these right, but some security text appears to be needed. This is not supposed to affect existing implementations, so please speak up if something appears potentially problematic. (1) iSCSI name association with authenticated identity. The iSCSI name is for the initiator or target (e.g., iqn.*); the authenticated identity is the identity used in the inband authentication protocol (e.g., CHAP name). This concern is about how the identity used for authentication aligns with the iSCSI name for the initiator or target. Abstractly, the concern is that someone has to check that Bob is the authenticated identity for an iSC= SI initiator that's accessing Bob's storage, otherwise Alice can claim to be Bob's initiator (iSCSI name) authenticate as herself (Alice as authenticati= on identity) and then freely access Bob's storage, which would be bad. The draft doesn't say much about this, in large part because iSCSI names are not exactly friendly to existing authentication infrastructure, and the original design intent was to allow flexibility in identities used with authentication infrastructure. Proposal: The draft needs to say something - that something might be to say that implementations SHOULD be managing authentication so that impersonation is not possible across iSCSI Names. The preferred approach (SHOULD) would be to manage authentication material as triples: - iSCSI Name - Authentication identity for that name - Authentication credentials for that identity In this case, the name-identity relationship SHOULD be checked in addition to the authentication of the identity. This check is simple if the identit= y and name are the same, or the identity is algorithmically derived from the name. I can think of ways to bind credentials directly to an iSCSI Name, where the identity is a bystander, although this is a particularly bad idea for CHAP, as it will have rather unfortunate results when used with an external server (e.g., RADIUS) that gets the authentication identity, but not the iSCSI name, making this a "SHOULD NOT" requirement with a warning about external authentication servers that don't see the iSCSI Names. (2) Authentication consistency for multi-connection sessions. When an iSCSI session has multiple connections, either concurrently, or sequentially (e.g., TCP connection fails, new connection created to recover the session), it's important that the same initiator be involved in all the connections, *and* that the initiator authenticate as itself every time. There are several pieces to this: - Authentication SHOULD be consistently used across a session. It's not a good idea to mix authenticated and unauthenticated connections in the same session. Mixing authentication mechanisms is probably ok, if someone wants to do that, so it may not need to be mentioned. - The authentication of the iSCSI Name SHOULD be consistent across a sessio= n, preferably by using the same authentication identity. In the end, it's the iSCSI Name that matters, and the same authentication identity (see "triples" above) is the simplest way to get there. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From julian@satran.net Tue Jan 1 22:46:17 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF7321F910D for ; Tue, 1 Jan 2013 22:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.836 X-Spam-Level: X-Spam-Status: No, score=-5.836 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ+dXFla2b14 for ; Tue, 1 Jan 2013 22:46:16 -0800 (PST) Received: from eu1sys200aog104.obsmtp.com (eu1sys200aog104.obsmtp.com [207.126.144.117]) by ietfa.amsl.com (Postfix) with SMTP id F3E3C21F910B for ; Tue, 1 Jan 2013 22:46:15 -0800 (PST) Received: from mail-wg0-f71.google.com ([74.125.82.71]) (using TLSv1) by eu1sys200aob104.postini.com ([207.126.147.11]) with SMTP ID DSNKUOPXtO2Ri7//vz1Gi7asaaJG4OzjDMiD@postini.com; Wed, 02 Jan 2013 06:46:16 UTC Received: by mail-wg0-f71.google.com with SMTP id dr13so11953428wgb.6 for ; Tue, 01 Jan 2013 22:46:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:subject:mime-version:content-type:from :x-priority:in-reply-to:date:cc:content-transfer-encoding:message-id :references:to:x-mailer:x-gm-message-state; bh=FnR1v7VGtfrtHnXWKy+KlEq0KlS8lqQFbGhui4jv3co=; b=a1PqzsklaP2nrGjuKcRwqaUggZbOXhkaCAIj+s9eLpHKhnU4RojgWRnLbQQ+giDX5d zxRbYkbAPBnLr4lu4wQpEyxsq3yZrUV3sR+SPhDm13G8JBlCxEXkPd9zC+CxDvB3uj+2 LOnq9CP6Vg+b1st2DjljxZjT+ShrEUIIqyfpClLpc54CjmMCZaky2MxLxb04TFmM81Ye fpDtU0I4xNlhxPZmDmCYci64Ra1HfELxb0SYPvXuWPDw/dDV+nJAwzwZrrM+LevL+1L+ /tSmIJHLVezUp/VXwJ+ozYHndKSLIH7VcoQqZnubFscSi8ianF1Kq2V3Eii6feMoogeB z5jA== X-Received: by 10.14.221.9 with SMTP id q9mr123507062eep.3.1357108733953; Tue, 01 Jan 2013 22:38:53 -0800 (PST) X-Received: by 10.14.221.9 with SMTP id q9mr123507047eep.3.1357108733784; Tue, 01 Jan 2013 22:38:53 -0800 (PST) Received: from julo-mbpr.infinidat.com (bzq-218-29-26.cablep.bezeqint.net. [81.218.29.26]) by mx.google.com with ESMTPS id d3sm95560278eeo.13.2013.01.01.22.38.51 (version=SSLv3 cipher=OTHER); Tue, 01 Jan 2013 22:38:52 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Julian Satran X-Priority: 1 In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71287DB21EE@MX15A.corp.emc.com> Date: Wed, 2 Jan 2013 08:38:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <536D99C2-EBD3-43B2-BE47-9F53E945FBBC@satran.net> References: <8D3D17ACE214DC429325B2B98F3AE71287DB21EE@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQm1i6R9kGciaN6tynEvUMr38dhEJQbUWy0qcxNLRemY6jQB73AepFsv0gwaMBIINrD6PUL106Q4rTKSsNXDWVzPupjIs6mF4r8cJ3FlGO47iQNI/Zhn3iHPikUyLNgGEYjyq5U2x4p+pPV3aMDWg80lbDChxw== Cc: "storm@ietf.org" Subject: Re: [storm] iSCSI consolidated draft: Authentication consistency X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 06:46:17 -0000 WRT 1 - I always thought that the iSCSI name is/will-become the = authenticated identity and the "tiny bit-strings" used in some = communities will become a thing of the past - or at best will serve as = temporary identifiers (something like short addresses). However if we = want to accommodate them we should suggest a way of deriving the = authenticated identity from the name - e.g., a hash - that binds them = for good. The target may/should verify that the authenticated identity = used in the protocol is correct. Obviously that assumes that = authentication identities are small string that can be "allocated" = arbitrarily - i.e. have no purposeful structure. Julo On Jan 2, 2013, at 3:48 AM, "Black, David" wrote: > >=20 > This email is sent as the shepherd for the iSCSI consolidated draft. >=20 > Security review has turned up a couple of issues in iSCSI in-band > authentication. I want to summarize them for discussion before the > effort is invested in writing detailed text. >=20 > I believe that good implementers will get these right, but some > security text appears to be needed. This is not supposed to affect > existing implementations, so please speak up if something appears > potentially problematic. >=20 > (1) iSCSI name association with authenticated identity. The iSCSI = name > is for the initiator or target (e.g., iqn.*); the authenticated = identity > is the identity used in the inband authentication protocol (e.g., CHAP > name). >=20 > This concern is about how the identity used for authentication aligns = with > the iSCSI name for the initiator or target. Abstractly, the concern = is > that someone has to check that Bob is the authenticated identity for = an iSCSI > initiator that's accessing Bob's storage, otherwise Alice can claim to = be > Bob's initiator (iSCSI name) authenticate as herself (Alice as = authentication > identity) and then freely access Bob's storage, which would be bad. >=20 > The draft doesn't say much about this, in large part because iSCSI = names > are not exactly friendly to existing authentication infrastructure, = and > the original design intent was to allow flexibility in identities used = with > authentication infrastructure. >=20 > Proposal: The draft needs to say something - that something might be = to say > that implementations SHOULD be managing authentication so that > impersonation is not possible across iSCSI Names. The preferred = approach > (SHOULD) would be to manage authentication material as triples: > - iSCSI Name > - Authentication identity for that name > - Authentication credentials for that identity > In this case, the name-identity relationship SHOULD be checked in = addition > to the authentication of the identity. This check is simple if the = identity > and name are the same, or the identity is algorithmically derived from = the > name. >=20 > I can think of ways to bind credentials directly to an iSCSI Name, = where > the identity is a bystander, although this is a particularly bad idea = for > CHAP, as it will have rather unfortunate results when used with an = external > server (e.g., RADIUS) that gets the authentication identity, but not = the > iSCSI name, making this a "SHOULD NOT" requirement with a warning = about > external authentication servers that don't see the iSCSI Names. >=20 > (2) Authentication consistency for multi-connection sessions. >=20 > When an iSCSI session has multiple connections, either concurrently, = or > sequentially (e.g., TCP connection fails, new connection created to = recover > the session), it's important that the same initiator be involved in = all > the connections, *and* that the initiator authenticate as itself every > time. There are several pieces to this: > - Authentication SHOULD be consistently used across a session. It's > not a good idea to mix authenticated and unauthenticated = connections > in the same session. Mixing authentication mechanisms is = probably > ok, if someone wants to do that, so it may not need to be = mentioned. > - The authentication of the iSCSI Name SHOULD be consistent across a = session, > preferably by using the same authentication identity. In the = end, > it's the iSCSI Name that matters, and the same authentication > identity (see "triples" above) is the simplest way to get there. >=20 >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm From internet-drafts@ietf.org Wed Jan 9 23:08:05 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBD021F88E6; Wed, 9 Jan 2013 23:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeipXolPmn4O; Wed, 9 Jan 2013 23:08:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B00021F8864; Wed, 9 Jan 2013 23:07:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130110070736.9993.36722.idtracker@ietfa.amsl.com> Date: Wed, 09 Jan 2013 23:07:36 -0800 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-rdmap-ext-04.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 07:08:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the STORage Maintenance Working Group of the = IETF. Title : RDMA Protocol Extensions Author(s) : Hemal Shah Felix Marti Wael Noureddine Asgeir Eiriksson Robert Sharp Filename : draft-ietf-storm-rdmap-ext-04.txt Pages : 31 Date : 2013-01-09 Abstract: This document specifies extensions to the IETF Remote Direct Memory Access Protocol (RDMAP [RFC5040]). RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol (ULP) Buffers without intermediate data copies. The extensions specified in this document provide the following capabilities and/or improvements: Atomic Operations and Immediate Data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-storm-rdmap-ext There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-storm-rdmap-ext-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-rdmap-ext-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Mon Jan 14 06:13:40 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF5121F882C; Mon, 14 Jan 2013 06:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8sWsLifmWlp; Mon, 14 Jan 2013 06:13:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAD321F86FF; Mon, 14 Jan 2013 06:13:40 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130114141340.12683.79124.idtracker@ietfa.amsl.com> Date: Mon, 14 Jan 2013 06:13:40 -0800 Cc: storm@ietf.org Subject: [storm] Last Call: (Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI)) to Proposed Standard X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:13:40 -0000 The IESG has received a request from the STORage Maintenance WG (storm) to consider the following document: - 'Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP). This document obsoletes RFC4544. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-storm-iscsimib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-storm-iscsimib/ballot/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Tue Jan 15 09:20:31 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F41321F872C; Tue, 15 Jan 2013 09:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkU+8LV7+lFh; Tue, 15 Jan 2013 09:20:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3EDB21F876E; Tue, 15 Jan 2013 09:20:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130115172030.13867.80405.idtracker@ietfa.amsl.com> Date: Tue, 15 Jan 2013 09:20:30 -0800 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-iscsi-cons-08.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 17:20:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the STORage Maintenance Working Group of the = IETF. Title : iSCSI Protocol (Consolidated) Author(s) : Mallikarjun Chadalapaka Julian Satran Kalman Meth David Black Filename : draft-ietf-storm-iscsi-cons-08.txt Pages : 342 Date : 2013-01-13 Abstract: This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI Naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications and a few improvements and corrections to the original iSCSI protocol. This document obsoletes RFCs 3720, 3980, 4850 and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721 and RFC 3723. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics. Note: This version of the draft does not yet incorporate planned resolutions to some Last Call comments regarding Kerberos and IPsec-related security considerations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-cons There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-storm-iscsi-cons-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-iscsi-cons-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cbm@chadalapaka.com Thu Jan 17 13:05:39 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0C121F8942 for ; Thu, 17 Jan 2013 13:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoXp7wVDtb5D for ; Thu, 17 Jan 2013 13:05:39 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id DA29A21F893E for ; Thu, 17 Jan 2013 13:05:38 -0800 (PST) Received: from mail263-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 17 Jan 2013 21:05:35 +0000 Received: from mail263-va3 (localhost [127.0.0.1]) by mail263-va3-R.bigfish.com (Postfix) with ESMTP id 2D0B5F800C2 for ; Thu, 17 Jan 2013 21:05:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.117; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0610HT003.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz9371I936eI542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received-SPF: pass (mail263-va3: domain of chadalapaka.com designates 157.56.240.117 as permitted sender) client-ip=157.56.240.117; envelope-from=cbm@chadalapaka.com; helo=BL2PRD0610HT003.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail263-va3 (localhost.localdomain [127.0.0.1]) by mail263-va3 (MessageSwitch) id 1358456733214066_23059; Thu, 17 Jan 2013 21:05:33 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.245]) by mail263-va3.bigfish.com (Postfix) with ESMTP id 2ECE348004E for ; Thu, 17 Jan 2013 21:05:33 +0000 (UTC) Received: from BL2PRD0610HT003.namprd06.prod.outlook.com (157.56.240.117) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 17 Jan 2013 21:05:31 +0000 Received: from BL2PRD0610MB361.namprd06.prod.outlook.com ([169.254.10.3]) by BL2PRD0610HT003.namprd06.prod.outlook.com ([10.255.101.38]) with mapi id 14.16.0257.004; Thu, 17 Jan 2013 21:05:30 +0000 From: Mallikarjun Chadalapaka To: "storm@ietf.org" Thread-Topic: [storm] I-D Action: draft-ietf-storm-iscsi-cons-08.txt Thread-Index: AQHN80SjTwOLofBsBUmkDG6SSII1R5hOAGLQ Date: Thu, 17 Jan 2013 21:05:29 +0000 Message-ID: References: <20130115172030.13867.80405.idtracker@ietfa.amsl.com> In-Reply-To: <20130115172030.13867.80405.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: chadalapaka.com Subject: Re: [storm] I-D Action: draft-ietf-storm-iscsi-cons-08.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 21:05:39 -0000 All: The changes in this version of the draft are the following, almost all to a= ddress IESG Last Call comments: * Dropped the "MUST NOT" requirement on punctuation/diacritical characters = in iSCSI Names (avoiding these is still a "should avoid" and highly recomme= nded, we simply dropped the "MUST NOT" because it is not enforceable per se= ) * Cleaned up some redundant text regarding PDU lay-outs etc. * Added a formal definition of "Response Fence" pointing to pre-existing no= rmative requirements * Added a handful of forward references to tie the intro/requirement/exampl= e pieces of the same concept together * Done some Unicode-related terminology clean-up * Added additional security considerations guidance related to CHAP (large = randomly generated CHAP secrets), including a forward-looking statement tha= t iSCSI will eventually switch to a stronger authentication mechanism, with= some examples cited * Added some SCSI-level access controls considerations text=20 * Added new acronyms/definitions in a few places * Made a handful of editorial rewrites for clarity in a few places The two known items still pending for a -09 version are: * Kerberos security considerations text for iSCSI authentication (work in p= rogress) * Resolution to a few IPSec-related topics (see David's email to the list o= n January 1, 2013, awaiting WG feedback) The pdf version of the draft includes change bars for easy comparison. Let the authors know if you have follow-up questions. Mallikarjun > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Tuesday, January 15, 2013 9:21 AM > To: i-d-announce@ietf.org > Cc: storm@ietf.org > Subject: [storm] I-D Action: draft-ietf-storm-iscsi-cons-08.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the STORage Maintenance Working Group of th= e > IETF. >=20 > Title : iSCSI Protocol (Consolidated) > Author(s) : Mallikarjun Chadalapaka > Julian Satran > Kalman Meth > David Black > Filename : draft-ietf-storm-iscsi-cons-08.txt > Pages : 342 > Date : 2013-01-13 >=20 > Abstract: > This document describes a transport protocol for SCSI that works > on top of TCP. The iSCSI protocol aims to be fully compliant with > the standardized SCSI Architecture Model (SAM-2). RFC 3720 > defined the original iSCSI protocol. RFC 3721 discusses iSCSI > Naming examples and discovery techniques. Subsequently, RFC 3980 > added an additional naming format to iSCSI protocol. RFC 4850 > followed up by adding a new public extension key to iSCSI. RFC > 5048 offered a number of clarifications and a few improvements and > corrections to the original iSCSI protocol. >=20 >=20 > This document obsoletes RFCs 3720, 3980, 4850 and 5048 by > consolidating them into a single document and making additional > updates to the consolidated specification. This document also > updates RFC 3721 and RFC 3723. The text in this document thus > supersedes the text in all the noted RFCs wherever there is a > difference in semantics. >=20 > Note: This version of the draft does not yet incorporate planned > resolutions to some Last Call comments regarding Kerberos and > IPsec-related security considerations. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-cons >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-storm-iscsi-cons-08 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-iscsi-cons-08 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm From internet-drafts@ietf.org Thu Jan 17 16:49:35 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78B721F8ABA; Thu, 17 Jan 2013 16:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mOaoq0AKvFE; Thu, 17 Jan 2013 16:49:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A3F21F8865; Thu, 17 Jan 2013 16:49:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130118004935.15197.93453.idtracker@ietfa.amsl.com> Date: Thu, 17 Jan 2013 16:49:35 -0800 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-iser-13.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 00:49:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the STORage Maintenance Working Group of the = IETF. Title : iSCSI Extensions for RDMA Specification Author(s) : Michael Ko Alexander Nezhinsky Filename : draft-ietf-storm-iser-13.txt Pages : 97 Date : 2013-01-17 Abstract: iSCSI Extensions for Remote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol. This document obsoletes RFC 5046. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-storm-iser There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-storm-iser-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-iser-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mkosjc@gmail.com Fri Jan 18 11:27:56 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA4A21F84DC for ; Fri, 18 Jan 2013 11:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXPrcnq0ikkn for ; Fri, 18 Jan 2013 11:27:56 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC8E21F84CA for ; Fri, 18 Jan 2013 11:27:55 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id gm6so803220lbb.22 for ; Fri, 18 Jan 2013 11:27:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=vpBOH9tsTYgTAjbEQGJYdDbz/Y/cTSc4azueS+HhU9U=; b=fmULlTqaEVCxmLKTa5V14isSlujggdRYsfcYwZtqe5fzJ+bPPjCzyEAqIN9YY8dIVd +cdc4WGJhinRXt7F+Sq6XWRiJ7ByPw4vfcoCewSFBHvI4cRbJ7h78MdoXFLonx/7ZrZH 739GG/I+YChc1DBvgcAKiF9e+iTFEMRSpTGt8PlxR6cfNOdzhdL23lXIr9UwCN+eYq+R Sx/qOp7U7DYoQVmRAxZcq3vHNo+j56S3m+uCan6wbvY6i6WpClAu1XiQBw2QMDLu9xKf PEZNh+wuRws/VFijLOpsRxAUCWqqe1YWsYLKOwDHx4IU7pWlyKtwDzJirBwqYF/2gu1R 4ItA== MIME-Version: 1.0 X-Received: by 10.152.113.66 with SMTP id iw2mr9409487lab.37.1358537274458; Fri, 18 Jan 2013 11:27:54 -0800 (PST) Received: by 10.152.110.194 with HTTP; Fri, 18 Jan 2013 11:27:54 -0800 (PST) In-Reply-To: <20130118004935.15197.93453.idtracker@ietfa.amsl.com> References: <20130118004935.15197.93453.idtracker@ietfa.amsl.com> Date: Fri, 18 Jan 2013 11:27:54 -0800 Message-ID: From: Michael Ko To: storm@ietf.org Content-Type: multipart/alternative; boundary=f46d04089159a881cd04d3951b62 Subject: Re: [storm] I-D Action: draft-ietf-storm-iser-13.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 19:27:56 -0000 --f46d04089159a881cd04d3951b62 Content-Type: text/plain; charset=ISO-8859-1 This version addreses the conerns raised by Stephen Kent in his secdir review of the draft. For the Security Considerations section, the text on applicability of the IPsec 2401-series and 4301-series RFCs will be added in the next version of this draft pending the resolution of the consolidated iSCSI draft to update RFC 3723 and everything that uses it to a mix of 2401-series and 4301-series IPsec RFCs. Mike On Thu, Jan 17, 2013 at 4:49 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the STORage Maintenance Working Group of the > IETF. > > Title : iSCSI Extensions for RDMA Specification > Author(s) : Michael Ko > Alexander Nezhinsky > Filename : draft-ietf-storm-iser-13.txt > Pages : 97 > Date : 2013-01-17 > > Abstract: > iSCSI Extensions for Remote Direct Memory Access (RDMA) provides the > RDMA data transfer capability to iSCSI by layering iSCSI on top of > an RDMA-Capable Protocol. An RDMA-Capable Protocol provides RDMA > Read and Write services, which enable data to be transferred > directly into SCSI I/O Buffers without intermediate data copies. > This document describes the extensions to the iSCSI protocol to > support RDMA services as provided by an RDMA-Capable Protocol. > > This document obsoletes RFC 5046. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-storm-iser > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-storm-iser-13 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-storm-iser-13 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm > --f46d04089159a881cd04d3951b62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This version addreses the conerns raised by Stephen Kent in his secdir revi= ew of the draft.=A0 For the Security Considerations section, the text on ap= plicability of the IPsec 2401-series and 4301-series RFCs will be added in = the next version of this draft pending the resolution of the consolidated i= SCSI draft to update RFC 3723 and everything that uses it to a mix of 2401-= series and 4301-series IPsec RFCs.

Mike

On Thu, Jan 17, 2013 at 4:49 PM,= <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the STORage Maintenance Working Group of th= e IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : iSCSI Extensions for RDMA Speci= fication
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Michael Ko
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Alexander Nezhinsky
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-storm-iser-13.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 97
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-01-17

Abstract:
=A0 =A0iSCSI Extensions for Remote Direct Memory Access (RDMA) provides the=
=A0 =A0RDMA data transfer capability to iSCSI by layering iSCSI on top of =A0 =A0an RDMA-Capable Protocol. =A0An RDMA-Capable Protocol provides RDMA<= br> =A0 =A0Read and Write services, which enable data to be transferred
=A0 =A0directly into SCSI I/O Buffers without intermediate data copies.
=A0 =A0This document describes the extensions to the iSCSI protocol to
=A0 =A0support RDMA services as provided by an RDMA-Capable Protocol.

=A0 =A0This document obsoletes RFC 5046.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-storm-iser

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-storm-iser-13

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-iser-13<= /a>


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
storm mailing list
storm@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/storm

--f46d04089159a881cd04d3951b62-- From david.black@emc.com Sun Jan 20 18:06:02 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3AC21F8777 for ; Sun, 20 Jan 2013 18:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m+OsTvYgf3W for ; Sun, 20 Jan 2013 18:06:01 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id B539221F879A for ; Sun, 20 Jan 2013 18:05:58 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0L25vIr016302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 20 Jan 2013 21:05:57 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Sun, 20 Jan 2013 21:05:42 -0500 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0L25fdv016476 for ; Sun, 20 Jan 2013 21:05:41 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Sun, 20 Jan 2013 21:05:41 -0500 From: "Black, David" To: "storm@ietf.org" Date: Sun, 20 Jan 2013 21:05:40 -0500 Thread-Topic: storm WG draft status Thread-Index: Ac3ofu/+OnXFgnZlRnK5nrw46pKEYwO+6xZA Message-ID: <8D3D17ACE214DC429325B2B98F3AE71287E877F7@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71287DB21E9@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71287DB21E9@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [storm] storm WG draft status X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 02:06:02 -0000 Quick update on these drafts + the iSER draft iSCSI Consolidated: New -08 version has appeared to resolve most of the comments. There are still some security (and probably other) issues that'l= l require a -09 version, including the IPsec profile update iSCSI Features Update (SAM): New version expected by first week of Feb. That'll need to be checked against the then-current version of the iSCSI consolidated draft before going into IESG Evaluation. iSCSI MIB: Now in IETF Last Call through Jan 28. RDMAP Extensions: Revised version submitted. iSER: The IPsec profile update to RFC 3723 came up in this draft as well, a= nd that update will have to be addressed in the iSCSI Consolidated draft befor= e the iSER draft can go to IESG Evaluation. The current intent is to have the IPsec profile update to RFC 3723 affect a= ll RFCs that use it, including the RDDP (iWARP) RFCs. I will be on vacation with no email (email is among the things that I *real= ly* need a vacation from) for the next couple of weeks, so expect further progr= ess towards the end of the first week of Feb. Thanks, --David > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of > Black, David > Sent: Tuesday, January 01, 2013 7:20 PM > To: storm@ietf.org > Subject: [storm] storm WG draft status + No Orlando meeting > Importance: High >=20 > My day job's been demanding too much of my time lately, but I'm finally > getting back to storm WG activity after a few months of too many other > things to do. Sorry for the hiatus, and here's the status info for > the storm WG's five drafts as I understand things: >=20 > iSCSI Consolidated: Completed IESG evaluation, with a number of issues > that need to be resolved. At least two security issues will be sent to > this list soon, as they need attention from the working group. >=20 > iSCSI Features Update (SAM): Completed IETF Last Call. Needs a revised > version in order to go to the IESG. I believe that the draft editor > understands what needs to be done; with luck that'll go to IESG Evaluatio= n > this month. >=20 > iSCSI MIB: Sent back to MIB Doctors for a re-review of changes. We're > waiting on them. >=20 > RDMAP Extensions: This one's about to expire w/o changes again due to > delays in working on other drafts. There won't be time for me to do a > detailed technical review and get the new version submitted before the > current version expires. OTOH, there are some minor issues with the > text that specifies the new IANA registry in section 10.1 - I suggest > that the authors update that text based on the text in the final version > of the RDDP registries draft: >=20 > http://tools.ietf.org/id/draft-ietf-storm-rddp-registries-02.txt >=20 > As part of this: > - The registry should be called "RDMAP Message Atomic Operation Subcodes" > and change from "Code" to "Subcode" elsewhere in the draft. This > avoids confusion with the main RDMAP Opcodes. > - Add a sentence to say that an experimental RDMAP opcode has already bee= n > allocated, and hence there is no need for an experimental atomic > operation subcode. >=20 > While some of the issues with the Consolidated draft require WG attention= , > I don't think a meeting will be needed to deal with them, so I don't plan > to ask for meeting time in Orlando in March. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm