[dhcwg] RE: AD review of draft-ietf-dhc-isnsoption-05.txt
Charles Monia <cmonia@NishanSystems.com> Thu, 24 April 2003 21:27 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04520 for <dhcwg-archive@odin.ietf.org>; Thu, 24 Apr 2003 17:27:02 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OLTob13305 for dhcwg-archive@odin.ietf.org; Thu, 24 Apr 2003 17:29:50 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OLTn813302 for <dhcwg-web-archive@optimus.ietf.org>; Thu, 24 Apr 2003 17:29:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04498 for <dhcwg-web-archive@ietf.org>; Thu, 24 Apr 2003 17:26:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198oGw-0001gA-00 for dhcwg-web-archive@ietf.org; Thu, 24 Apr 2003 17:28:50 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198oGw-0001g6-00 for dhcwg-web-archive@ietf.org; Thu, 24 Apr 2003 17:28:50 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OLRn813191; Thu, 24 Apr 2003 17:27:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OLOG813077 for <dhcwg@optimus.ietf.org>; Thu, 24 Apr 2003 17:24:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04342 for <dhcwg@ietf.org>; Thu, 24 Apr 2003 17:20:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198oBY-0001dq-00 for dhcwg@ietf.org; Thu, 24 Apr 2003 17:23:16 -0400
Received: from ultrex.nishansystems.com ([12.36.127.195] helo=ariel.nishansystems.com) by ietf-mx with esmtp (Exim 4.12) id 198oBY-0001dG-00 for dhcwg@ietf.org; Thu, 24 Apr 2003 17:23:16 -0400
Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id <JSCZ30SL>; Thu, 24 Apr 2003 14:23:08 -0700
Message-ID: <B300BD9620BCD411A366009027C21D9BE86E1E@ariel.nishansystems.com>
From: Charles Monia <cmonia@NishanSystems.com>
To: "Thomas Narten (E-mail)" <narten@us.ibm.com>
Cc: "'dhcwg@ietf.org'" <dhcwg@ietf.org>, Joshua Tseng <jtseng@NishanSystems.com>, Kevin Gibbons <kgibbons@NishanSystems.com>, "Ips (E-mail)" <ips@ece.cmu.edu>, "David Black (E-mail)" <Black_David@emc.com>, "Elizabeth Rodriguez (E-mail)" <ElizabethRodriguez@ieee.org>
Date: Thu, 24 Apr 2003 14:23:07 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [dhcwg] RE: AD review of draft-ietf-dhc-isnsoption-05.txt
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Hi Thomas: Thanks for your input. I will be making the changes to fix the editorial problems you've pointed out along with adding the section on IANA considerations. I have asked for input from the other co-authors on the technical issues, including vendor specific fields and security and will post responses to those issues when available. -- Charles ----------------------------------------- Charles Monia Senior Technology Consultant Nishan Systems email: cmonia@nishansystems.com voice: (408) 519-3986 fax: (408) 435-8385 > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Tuesday, April 22, 2003 10:30 AM > To: cmonia@nishansystems.com; jtseng@nishansystems.com; > kgibbons@nishansystems.com > Cc: dhcwg@ietf.org > Subject: AD review of draft-ietf-dhc-isnsoption-05.txt > > General issues: > > I'd like to see a justification for the vendor specific fields. I'd > like to understand how these can be safely used without leading to > interoperability issues. Besides, there are other ways in DHC to do > vendor-specific things. Can we just remove them from this > option/document? > > The security considerations section is rather weak. > > General note: this document is inconsitent about bit ordering. Some > picture show bits numbered left-to-right, others right-to-left. Please > pick one and be consistent. > > needs an IANA considerations section. > > I assume a revision of the document would be in order before starting > the IETF LC. > > Specific comments follow. > > > DHCP Options for Internet Storage Name Service > > Would be good for the title to note that this is for DHCP for > IPv4. E.g.: > > The IPv4 DHCP Option for Internet Storage Name Service > > Abstract doesn't satisfy ID nits; e.g., has unexpanded acronyms. > > "iSNS" used before being defined. > > ditto for iSCSI, iFCP, etc. > > The Dynamic Host Configuration Protocol for Ipv4 provides a > > s/Ipv4/IPv4/ > > > Existing DHCP option numbers are not plausible due > to the following > > reasons: > > suggested reword: > > Existing DHCP options cannot be used to find iSNS servers for > the following reasons: > > > Length: the number of bytes that follow the Length > field. The > > minimum value for the Length field is 6 in > order to account > > for the iSNS Functions, Discovery Domain Access, and > > Administrative Flags fields. > > From the picture, it seems like the minimum length is more than > 6. Are some of the fields optional? > > > certificates for the use of iSCSI and iFCP devices. > The format of > > the iSNS Role bit field is shown in Figure 2: > > > > 1 2 3 > > 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |Vendor-Specific |RESERVED |S|A|E| > > +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 2 -- iSNS Functions > > I don't see how a vendor-specific portion of this option facilitates > interoperability. Remove? > > Also, caling it the "iSNS Role" field is confusing, since that is not > used in the previous figure. SHouldn't this be the "iSNS Functions" > field? > > > > Bit field Significance > > --------- ------------ > > 31 Function Fields Enabled > > 30 DD-Based Authorization > > 29 Security policy distribution > > 28 - 24 Reserved > > 23 - 16 Vendor-specific > > You need a transistion sentence saying what field is being talked > about. Presumably, this is "iSNS Server Security Bitmap"? > > > Enabled: This bit specifies the > validity of the > > Spell out "Function Fields Enabled", as that is the name of the field > per the picture. > > > Security: Indicates whether the iSNS > client is to > > spell out field name. > > > Vendor- These bits are used to > indicate the vendor- > > Specific: specific capabilities > supported by the > > indicated iSNS server. > > Again, this does not promote interoperability. There are other ways in > DHC to communicate vendor specific information. > > General note: this document is inconsitent about bit ordering. Some > picture show bits numbered left-to-right, others right-to-left. Please > pick one and be consistent. > > > 3. Security Considerations > > > > DHCP currently provides no authentication or > security mechanisms. > > Potential exposures to attack are discussed in > section 7 of the DHCP > > protocol specification [DHCP]. > > What about RFC 3118? > > > > iSNS security considerations are discussed in > [iSNS] and [SEC-IPS]. > > With regard to security considerations specific to > the use of this > > DHCP option to discover the location of the iSNS > server, exposure to > > a "man-in-the-middle" attack by an hostile entity > modifying or > > replacing the original iSNS option message should > be considered a > > potential security exposure. To prevent an > attacker from weakening > > the required security and potentially tricking the > iSNS client into > > connecting into rogue iSNS servers, reliance on > local security > > policy configuration is an appropriate countermeasure. > > This says almost nothing. What can happen if there is a man-in-the > middle? Really bad things? or just DOS? And what "local security > policy configuration" helps mitigate the threats? > > Thomas > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] AD review of draft-ietf-dhc-isnsoption-05… Thomas Narten
- [dhcwg] RE: AD review of draft-ietf-dhc-isnsoptio… Charles Monia
- [dhcwg] RE: AD review of draft-ietf-dhc-isnsoptio… Charles Monia