DHCP option for iSNS: The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service
A DHCP option, number 83, that tells storage devices where to find their iSNS server and how to use it.
Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service", RFC 4174, DOI 10.17487/RFC4174, September 2005, <https://www.rfc-editor.org/info/rfc4174>.
@misc{rfc4174,
series = {Request for Comments},
number = 4174,
howpublished = {RFC 4174},
publisher = {RFC Editor},
doi = {10.17487/RFC4174},
url = {https://www.rfc-editor.org/info/rfc4174},
author = {C. Monia and J. Tseng and K. Gibbons},
title = {{The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service}},
pagetotal = 13,
year = 2005,
month = sep,
} RFC text
Contents
Network Working Group C. Monia
Request for Comments: 4174 Consultant
Category: Standards Track J. Tseng
Riverbed Technology
K. Gibbons
McDATA Corporation
September 2005
The IPv4 Dynamic Host Configuration Protocol (DHCP) Option
for the Internet Storage Name Service
Status of This Memo
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.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes the Dynamic Host Configuration Protocol
(DHCP) option to allow Internet Storage Name Service (iSNS) clients
to discover the location of the iSNS server automatically through the
use of DHCP for IPv4. iSNS provides discovery and management
capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel
Protocol (iFCP) storage devices in an enterprise-scale IP storage
network. iSNS provides intelligent storage management services
comparable to those found in Fibre Channel networks, allowing a
commodity IP network to function in a similar capacity to that of a
storage area network.
Table of Contents
1. Introduction ................................................. 2
1.1. Conventions Used in This Document ...................... 2
2. iSNS Option for DHCP ......................................... 3
2.1. iSNS Functions Field ................................... 5
2.2. Discovery Domain Access Field .......................... 6
2.3. Administrative Flags Field ............................. 7
2.4. iSNS Server Security Bitmap ............................ 8
3. Security Considerations ...................................... 9
4. IANA Considerations .......................................... 11
5. Normative References ......................................... 11
6. Informative References ....................................... 11
1. Introduction
The Dynamic Host Configuration Protocol for IPv4 provides a framework
for passing configuration information to hosts. Its usefulness
extends to hosts and devices using the iSCSI and iFCP protocols to
connect to block level storage assets over a TCP/IP network.
The iSNS Protocol provides a framework for automated discovery,
management, and configuration of iSCSI and iFCP devices on a TCP/IP
network. It provides functionality similar to that found on Fibre
Channel networks, except that iSNS works within the context of an IP
network. iSNS thereby provides the requisite storage intelligence to
IP networks that are standard on existing Fibre Channel networks.
Existing DHCP options cannot be used to find iSNS servers for the
following reasons:
a) iSNS functionality is distinctly different from other protocols
using DHCP options. Specifically, iSNS provides a significant
superset of capabilities compared to typical name resolution
protocols such as DNS. It is designed to support client devices
that allow themselves to be configured and managed from a central
iSNS server.
b) iSNS requires a DHCP option format that provides more than the
location of the iSNS server. The DHCP option has to specify the
subset of iSNS services that may be actively used by the iSNS
client.
The DHCP option number for iSNS is used by iSCSI and iFCP devices to
discover the location and role of the iSNS server. The DHCP option
number assigned for iSNS by IANA is 83.
1.1. Conventions Used in This Document
iSNS refers to the Internet Storage Name Service framework, which
consists of the storage network model and associated services.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
All frame formats are in big-endian network byte order. RESERVED
fields SHOULD be set to zero.
This document uses the following terms:
"iSNS Client" - iSNS clients are processes resident in iSCSI and
iFCP devices that initiate transactions with the iSNS server using
the iSNS Protocol.
"iSNS Server" - The iSNS server responds to iSNS protocol query
and registration messages and initiates asynchronous notification
messages. The iSNS server stores information registered by iSNS
clients.
"iSCSI (Internet SCSI)" - iSCSI is an encapsulation of SCSI for a
new generation of storage devices interconnected with TCP/IP.
"iFCP (Internet Fibre Channel Protocol)" - iFCP is a gateway-to-
gateway protocol designed to interconnect existing Fibre Channel
devices using TCP/IP. iFCP maps the Fibre Channel transport and
fabric services to TCP/IP.
2. iSNS Option for DHCP
This option specifies the location of the primary and backup iSNS
servers and the iSNS services available to an iSNS client.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code = 83 | Length | iSNS Functions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD Access | Administrative FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| iSNS Server Security Bitmap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| a1 | a2 | a3 | a4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| b1 | b2 | b3 | b4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . |
| Additional Secondary iSNS Servers |
| . . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. iSNS Server Option
The iSNS Option specifies a list of IP addresses used by iSNS
servers. The option contains the following parameters:
Length: The number of bytes that follow the Length field.
iSNS Functions: A bitmapped field defining the functions supported
by the iSNS servers. The format of this field is described
in section 2.1.
Discovery Domain Access: A bit field indicating the types of iSNS
clients that are allowed to modify Discovery Domains. The
field contents are described in section 2.2.
Administrative Flags field: Contains the administrative settings
for the iSNS servers discovered through the DHCP query. The
contents of this field are described in section 2.3.
iSNS Server Security Bitmap: Contains the iSNS server security
settings specified in section 2.4.
a1...a4: Depending on the setting of the Heartbeat bit in the
Administrative Flags field (see section 2.3), this field
contains either the IP address from which the iSNS heartbeat
originates (see [iSNS]) or the IP address of the primary
iSNS server.
b1...b4: Depending on the setting of Heartbeat bit in the
Administrative Flags field (see section 2.3), this field
contains either the IP address of the primary iSNS server or
that of a secondary iSNS server.
Additional Secondary iSNS Servers: Each set of four octets
specifies the IP address of a secondary iSNS server.
The Code field through IP address field a1...a4 MUST be present in
every response to the iSNS query; therefore the Length field has a
minimum value of 14.
If the Heartbeat bit is set in the Administrative Flags field (see
section 2.3), then b1...b4 MUST also be present. In this case, the
minimum value of the Length field is 18.
The inclusion of Additional Secondary iSNS Servers in the response
MUST be indicated by increasing the Length field accordingly.
2.1. iSNS Functions Field
The iSNS Functions Field defines the iSNS server's operational role
(i.e., how the iSNS server is to be used). The iSNS server's role
can be as basic as providing simple discovery information, or as
significant as providing IKE/IPSec security policies and certificates
for the use of iSCSI and iFCP devices. The format of the iSNS
Functions field is shown in Figure 2.
0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |S|A|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. iSNS Functions Field
Bit Field Significance
--------- ------------
15 Function Fields Enabled
14 DD-Based Authorization
13 Security Policy Distribution
The following are iSNS Functions Field definitions:
Function Fields Specifies the validity of the remaining
Enabled: iSNS Function fields. If it is set to one, then
the contents of all other iSNS Function fields
are valid. If it is set to zero, then the
contents of all other iSNS Function fields MUST
be ignored.
DD-based Indicates whether devices in a common
Authorization: Discovery Domain (DD) are implicitly authorized
to access one another. Although Discovery
Domains control the scope of device discovery,
they do not necessarily indicate whether a domain
member is authorized to access discovered
devices. If this bit is set to one, then devices
in a common Discovery Domain are automatically
allowed access to each other (if successfully
authenticated). If this bit is set to zero, then
access authorization is not implied by domain
membership and must be explicitly performed by
each device. In either case, devices not in a
common discovery domain are not allowed to access
each other.
Security Policy Indicates whether the iSNS client is to
Distribution: download and use the security policy
configuration stored in the iSNS server. If it
is set to one, then the policy is stored in the
iSNS server and must be used by the iSNS client
for its own security policy. If it is set to
zero, then the iSNS client must obtain its
security policy configuration by other means.
2.2. Discovery Domain Access Field
The format of the DD Access bit field is shown in Figure 3.
0 1 1 1 1 1 1
0 ... 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+
| RESERVED | if| tf| is| ts| C | E |
+---+---+---+---+---+---+---+---+---+
Figure 3. Discovery Domain Access Field
Bit Field Significance
--------- ------------
15 Enabled
14 Control Node
13 iSCSI Target
12 iSCSI Initiator
11 iFCP Target Port
10 iFCP Initiator Port
The following are Discovery Domain Access Field definitions:
Enabled: Specifies the validity of the remaining DD
Access bit field. If it is set to one, then
the contents of the remainder of the DD Access
field are valid. If it is set to zero, then
the contents of the remainder of this field
MUST be ignored.
Control Node: Specifies whether the iSNS server allows
Discovery Domains to be added, modified, or
deleted by means of Control Nodes. If it is
set to one, then Control Nodes are allowed to
modify the Discovery Domain configuration. If
it is set to zero, then Control Nodes are not
allowed to modify Discovery Domain
configurations.
iSCSI Target, Determine whether the respective
iSCSI Initiator, registered iSNS client (determined
iFCP Target Port, by iSCSI Node Type or iFCP Port Role)
iFCP Initiator is allowed to add, delete, or modify
Port: Discovery Domains. If they are set to one,
then modification by the specified client type
is allowed. If they are set to zero, then
modification by the specified client type is
not allowed.
(A node may implement multiple node types.)
2.3. Administrative Flags Field
The format of the Administrative Flags bit field is shown in Figure
4.
0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |D|M|H|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Administrative Flags
Bit Field Significance
--------- ------------
15 Enabled
14 Heartbeat
13 Management SCNs
12 Default Discovery Domain
The following are Administrative Flags Field definitions:
Enabled: Specifies the validity of the remainder of the
Administrative Flags field. If it is set to
one, then the contents of the remaining
Administrative Flags are valid. If it is set
to zero, then the remaining contents MUST be
ignored, indicating that iSNS administrative
settings are obtained through means other than
DHCP.
Heartbeat: Indicates whether the first IP address is the
multicast address to which the iSNS heartbeat
message is sent. If it is set to one, then
a1-a4 contains the heartbeat multicast address
and b1-b4 contains the IP address of the
primary iSNS server, followed by the IP
address(es) of any backup servers (see Figure
1). If it is set to zero, then a1-a4 contain
the IP address of the primary iSNS server,
followed by the IP address(es) of any backup
servers.
Management SCNs: Indicates whether control nodes are authorized
to register for receiving Management State
Change Notifications (SCNs). Management SCNs
are a special class of State Change
Notification whose scope is the entire iSNS
database. If this bit is set to one, then
control nodes are authorized to register for
receiving Management SCNs. If it is set to
zero, then control nodes are not authorized to
receive Management SCNs (although they may
receive normal SCNs).
Default Discovery Indicates whether a newly registered
Domain: device that is not explicitly placed into a
Discovery Domain (DD) and Discovery Domain Set
(DDS) should be automatically placed into a
default DD and DDS. If it is set to one, then
a default DD shall contain all devices in the
iSNS database that have not been explicitly
placed into a DD by an iSNS client. If it is
set to zero, then devices not explicitly placed
into a DD are not members of any DD.
2.4. iSNS Server Security Bitmap
The format of the iSNS server security Bitmap field is shown in
Figure 5. If valid, this field communicates to the DHCP client the
security settings that are required to communicate with the indicated
iSNS server.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |T|X|P|A|M|S|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. iSNS Server Security Bitmap
Bit Field Significance
--------- ----------------
31 Enabled
30 IKE/IPSec
29 Main Mode
28 Aggressive Mode
27 PFS
26 Transport Mode
25 Tunnel Mode
The following are iSNS Server Security Bitmap definitions:
Enabled: Specifies the validity of the remainder of the
iSNS server security bitmap. If it is set to
one, then the contents of the remainder of the
field are valid. If it is set to zero, then
the contents of the rest of the field are
undefined and MUST be ignored.
IKE/IPSec: 1 = IKE/IPSec enabled; 0 = IKE/IPSec disabled.
Main Mode: 1 = Main Mode enabled; 0 = Main Mode disabled.
Aggressive Mode: 1 = Aggressive Mode enabled;
0 = Aggressive Mode disabled.
PFS: 1 = PFS enabled; 0 = PFS disabled.
Transport Mode: 1 = Transport Mode preferred; 0 = No
preference.
Tunnel Mode: 1 = Tunnel Mode preferred; 0 = No preference.
If IKE/IPSec is disabled, this indicates that the Internet Key
Exchange (IKE) Protocol is not available to configure IPSec keys for
iSNS sessions to this iSNS server. It does not necessarily preclude
other key exchange methods (e.g., manual keying) from establishing an
IPSec security association for the iSNS session.
If IKE/IPsec is enabled, then for each of the bit pairs <Main Mode,
Aggressive Mode> and <Transport Mode, Tunnel Mode>, one of the two
bits MUST be set to 1, and the other MUST be set to 0.
3. Security Considerations
For protecting the iSNS option, the DHCP Authentication security
option as specified in [RFC3118] may present a problem due to the
limited implementation and deployment of the DHCP authentication
option. The IPsec security mechanisms for iSNS itself are specified
in [iSNS] to provide confidentiality when sensitive information is
distributed via iSNS. See the Security Considerations section of
[iSNS] for details and specific requirements for implementation of
IPsec.
In addition, [iSNS] describes an authentication block that provides
message integrity for multicast or broadcast iSNS messages (i.e., for
heartbeat/discovery messages only). See [RFC3723] for further
discussion of security for these protocols.
If no sensitive information, as described in [iSNS], is being
distributed via iSNS, and an Entity is discovered via iSNS,
authentication and authorization are handled by the IP Storage
protocols whose endpoints are discovered via iSNS; specifically, iFCP
[iFCP] and iSCSI [RFC3720]. It is the responsibility of the
providers of these services to ensure that an inappropriately
advertised or discovered service does not compromise their security.
When no DHCP security is used, there is a risk of distribution of
false discovery information (e.g., via the iSNS DHCP option
identifying a false iSNS server that distributes the false discovery
information). The primary countermeasure for this risk is
authentication by the IP storage protocols discovered through iSNS.
When this risk is a significant concern, IPsec SAs SHOULD be used (as
specified in RFC 3723). For example, if an attacker uses DHCP and
iSNS to distribute discovery information that falsely identifies an
iSCSI endpoint, that endpoint will lack the credentials necessary to
complete IKE authentication successfully, and therefore will be
prevented from falsely sending or receiving iSCSI traffic. When this
risk of false discovery information is a significant concern and
IPsec is implemented for iSNS, IPsec SAs SHOULD also be used for iSNS
traffic to prevent use of a false iSNS server; this is more robust
than relying only on the IP Storage protocols to detect false
discovery information.
When IPsec is implemented for iSNS, there is a risk of a denial-of-
service attack based on repeated use of false discovery information
that will cause initiation of IKE negotiation. The countermeasures
for this are administrative configuration of each iSNS Entity to
limit the peers it is willing to communicate with (i.e., by IP
address range and/or DNS domain), and maintenance of a negative
authentication cache to avoid repeatedly contacting an iSNS Entity
that fails to authenticate. These three measures (i.e., IP address
range limits, DNS domain limits, negative authentication cache) MUST
be implemented for iSNS entities when this DHCP option is used. An
analogous argument applies to the IP storage protocols that can be
discovered via iSNS as discussed in RFC 3723.
In addition, use of the techniques described in [RFC2827] and
[RFC3833] may also be relevant to reduce denial-of-service attacks.
4. IANA Considerations
In accordance with the policy defined in [DHCP], IANA has assigned a
value of 83 for this option.
There are no other IANA-assigned values defined by this
specification.
5. Normative References
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[iSNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and
J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171,
September 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and
E. Zeidner, "Internet Small Computer Systems Interface
(iSCSI)", RFC 3720, April 2004.
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
Travostino, "Securing Block Storage Protocols over IP", RFC
3723, April 2004.
6. Informative References
[iFCP] Monia, C., Mullendore, R., Travostino, F., Jeong, W., and
M. Edwards, "iFCP - A Protocol for Internet Fibre Channel
Storage Networking", RFC 4172, September 2005.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004.
Authors' Addresses
Kevin Gibbons
McDATA Corporation
4555 Great America Parkway
Santa Clara, CA 95054-1208
Phone: (408) 567-5765
EMail: kevin.gibbons@mcdata.com
Charles Monia
7553 Morevern Circle
San Jose, CA 95135
EMail: charles_monia@yahoo.com
Josh Tseng
Riverbed Technology
501 2nd Street, Suite 410
San Francisco, CA 94107
Phone: (650)274-2109
EMail: joshtseng@yahoo.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
ISO Plain Language
On this page
§1Introduction
The Dynamic Host Configuration Protocol for IPv4 provides a framework for passing configuration information to hosts. Its usefulness extends to hosts and devices using the iSCSI and iFCP protocols to connect to block level storage assets over a TCP/IP network.
The iSNS Protocol provides a framework for automated discovery, management and configuration of iSCSI and iFCP devices on a TCP/IP network. It provides functionality similar to that found on Fibre Channel networks, except that iSNS works within the context of an IP network. iSNS thereby provides the requisite storage intelligence to IP networks that are standard on existing Fibre Channel networks.
Existing DHCP options cannot be used to find iSNS servers, for two reasons given in the document. First, iSNS functionality is distinctly different from other protocols using DHCP options. iSNS provides a significant superset of capabilities compared with typical name resolution protocols such as DNS. It is designed to support client devices that allow themselves to be configured and managed from a central iSNS server. Second, iSNS requires a DHCP option format that provides more than the location of the iSNS server. The DHCP option has to specify the subset of iSNS services that may be actively used by the iSNS client.
The DHCP option number for iSNS is used by iSCSI and iFCP devices to discover the location and role of the iSNS server. The DHCP option number assigned for iSNS by IANA is 83. All frame formats in the document are in big-endian network byte order, and RESERVED fields SHOULD be set to zero.
The document uses these terms. An iSNS client is a process resident in an iSCSI or iFCP device that initiates transactions with the iSNS server using the iSNS Protocol. The iSNS server responds to iSNS protocol query and registration messages and initiates asynchronous notification messages, and it stores the information registered by iSNS clients. iSCSI is an encapsulation of SCSI for a new generation of storage devices interconnected with TCP/IP. iFCP is a gateway-to-gateway protocol designed to interconnect existing Fibre Channel devices using TCP/IP, mapping the Fibre Channel transport and fabric services to TCP/IP.
Storage devices need a way to find the service that translates storage names into addresses. DHCP can carry that, but not in an ordinary option, because the service does much more than name lookup. So a new option was needed, and it got the number 83.
- DHCP REQUESTThe client asks for option 83.
- DHCP REPLY WITH THE iSNS OPTIONThe reply carries the server addresses and the four flag fields.
§2The iSNS Option for DHCP
The option specifies the location of the primary and backup iSNS servers and the iSNS services available to an iSNS client. It starts with the DHCP Code field, set to 83, and a Length field, which is the number of bytes that follow it.
The rest of the option is a list of parameters. The iSNS Functions field is a bit-mapped field defining the functions supported by the iSNS servers. The Discovery Domain Access field is a bit field indicating the types of iSNS clients that are allowed to modify Discovery Domains. The Administrative Flags field contains the administrative settings for the iSNS servers discovered through the DHCP query. The iSNS Server Security Bitmap contains the iSNS server security settings. Then come the address fields: a1 to a4 hold either the IP address from which the iSNS heartbeat originates or the IP address of the primary iSNS server, depending on the Heartbeat bit; b1 to b4 hold either the primary server address or a secondary server address, again depending on that bit; and each further set of four octets specifies the IP address of another secondary iSNS server.
The Code field through the a1 to a4 address field MUST be present in every response to the iSNS query, so the Length field has a minimum value of 14. If the Heartbeat bit is set, then b1 to b4 MUST also be present, and the minimum value of the Length field is 18. The inclusion of additional secondary iSNS servers in the response MUST be indicated by increasing the Length field accordingly.
The option carries four groups of flags and then a list of server addresses. The shortest legal reply holds one server address; a second address appears when the heartbeat flag is set, and more can be appended.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
CODE | Code | 1 byte | Always 83 for the iSNS option. | |
LENGTH | Length | 1 byte | Number of bytes that follow. At least 14, or 18 when the Heartbeat bit is set. | |
FUNCTIONS | iSNS Functions | 2 bytes | Which iSNS functions the servers support. | |
DD-ACCESS | DD Access | 2 bytes | Which client types may modify Discovery Domains. | |
ADMIN-FLAGS | Administrative Flags | 2 bytes | Heartbeat, Management SCNs and Default Discovery Domain settings. | |
SECURITY | iSNS Server Security Bitmap | 4 bytes | The IPsec and IKE settings to use with the server. | |
ADDRESS-A | a1 to a4 | 4 bytes | The heartbeat multicast address, or the primary iSNS server address. |
§2.1The iSNS Functions Field
The iSNS Functions Field defines the iSNS server's operational role, that is, how the iSNS server is to be used. The role can be as basic as providing simple discovery information, or as significant as providing IKE/IPSec security policies and certificates for the use of iSCSI and iFCP devices. It is a 16-bit field whose bits 15 to 13 carry the flags and whose remaining bits are reserved.
Bit 15, Function Fields Enabled, specifies the validity of the remaining iSNS Function fields. If it is set to one, the contents of all other iSNS Function fields are valid; if it is set to zero, the contents of all other iSNS Function fields MUST be ignored.
Bit 14, DD-Based Authorization, indicates whether devices in a common Discovery Domain are implicitly authorized to access one another. Discovery Domains control the scope of device discovery, but they do not necessarily indicate whether a domain member is authorized to access discovered devices. If this bit is set to one, devices in a common Discovery Domain are automatically allowed access to each other, if successfully authenticated. If it is set to zero, access authorization is not implied by domain membership and must be explicitly performed by each device. In either case, devices not in a common Discovery Domain are not allowed to access each other.
Bit 13, Security Policy Distribution, indicates whether the iSNS client is to download and use the security policy configuration stored in the iSNS server. If it is set to one, the policy is stored in the iSNS server and must be used by the iSNS client for its own security policy. If it is set to zero, the iSNS client must obtain its security policy configuration by other means.
This field says how much the server does. It can be a simple lookup service, it can hand out security policies, and it can say that being in the same domain is enough to talk to each other.
- 15Function Fields Enabled — If one, the other function bits are valid. If zero, they must be ignored.
- 14DD-Based Authorization — If one, devices in a common Discovery Domain may access each other.
- 13Security Policy Distribution — If one, the client must use the security policy stored in the iSNS server.
§2.2The Discovery Domain Access Field
The Discovery Domain Access bit field says which kinds of client are allowed to change the Discovery Domain configuration. Its bits 15 to 10 carry the flags, with the lower bits reserved.
Bit 15, Enabled, specifies the validity of the remaining DD Access bit field. If it is set to one, the contents of the remainder are valid; if it is set to zero, the contents of the remainder of this field MUST be ignored.
Bit 14, Control Node, specifies whether the iSNS server allows Discovery Domains to be added, modified or deleted by means of Control Nodes. Bits 13 to 10 are iSCSI Target, iSCSI Initiator, iFCP Target Port and iFCP Initiator Port. These determine whether the respective registered iSNS client, determined by iSCSI Node Type or iFCP Port Role, is allowed to add, delete or modify Discovery Domains. If they are set to one, modification by the specified client type is allowed; if they are set to zero, it is not. A node may implement multiple node types.
Who is allowed to change the groups of devices that can see each other? The field has one bit for each kind of device, plus one for the controller.
§2.3The Administrative Flags Field
The Administrative Flags field holds the administrative settings for the iSNS servers discovered through the DHCP query. Bits 15 to 12 carry the flags, with the rest reserved.
Bit 15, Enabled, specifies the validity of the remainder of the Administrative Flags field. If it is set to zero, the remaining contents MUST be ignored, indicating that iSNS administrative settings are obtained through means other than DHCP.
Bit 14, Heartbeat, indicates whether the first IP address is the multicast address to which the iSNS heartbeat message is sent. If it is set to one, a1 to a4 contains the heartbeat multicast address and b1 to b4 contains the IP address of the primary iSNS server, followed by the IP addresses of any backup servers. If it is set to zero, a1 to a4 contains the IP address of the primary iSNS server, followed by the IP addresses of any backup servers.
Bit 13, Management SCNs, indicates whether control nodes are authorized to register for receiving Management State Change Notifications. Management SCNs are a special class of State Change Notification whose scope is the entire iSNS database. If this bit is set to one, control nodes are authorized to register for receiving Management SCNs. If it is set to zero, they are not, although they may receive normal SCNs.
Bit 12, Default Discovery Domain, indicates whether a newly registered device that is not explicitly placed into a Discovery Domain and Discovery Domain Set should be automatically placed into a default DD and DDS. If it is set to one, a default DD shall contain all devices in the iSNS database that have not been explicitly placed into a DD by an iSNS client. If it is set to zero, devices not explicitly placed into a DD are not members of any DD.
These four flags decide where the heartbeat goes, who hears about changes to the whole database, and whether a new device lands in a default group when nobody puts it anywhere.
§2.4The iSNS Server Security Bitmap
The iSNS server security Bitmap field communicates to the DHCP client the security settings that are required to communicate with the indicated iSNS server. It is a 32-bit field with bits 31 to 25 in use and the rest reserved.
Bit 31, Enabled, specifies the validity of the remainder of the field. If it is set to zero, the contents of the rest of the field are undefined and MUST be ignored. Bit 30, IKE/IPSec, is set to 1 when IKE/IPSec is enabled and 0 when it is disabled. Bit 29, Main Mode, bit 28, Aggressive Mode, bit 27, PFS, bit 26, Transport Mode and bit 25, Tunnel Mode, each say whether that option is enabled; for Transport Mode and Tunnel Mode, a value of 1 means that mode is preferred and 0 means no preference.
If IKE/IPSec is disabled, this indicates that the Internet Key Exchange protocol is not available to configure IPSec keys for iSNS sessions to this iSNS server. It does not necessarily preclude other key exchange methods, such as manual keying, from establishing an IPSec security association for the iSNS session. If IKE/IPsec is enabled, then for each of the bit pairs Main Mode and Aggressive Mode, and Transport Mode and Tunnel Mode, one of the two bits MUST be set to 1 and the other MUST be set to 0.
This field says how the session to the iSNS server should be protected, including whether IPsec is used at all and which IKE mode to negotiate.
§3Security Considerations
For protecting the iSNS option, the DHCP Authentication security option specified in RFC 3118 may present a problem due to the limited implementation and deployment of that option. The IPsec security mechanisms for iSNS itself are specified in RFC 4171 to provide confidentiality when sensitive information is distributed via iSNS. RFC 4171 also describes an authentication block that provides message integrity for multicast or broadcast iSNS messages, that is, for heartbeat and discovery messages only.
If no sensitive information is being distributed via iSNS and an entity is discovered via iSNS, authentication and authorization are handled by the IP storage protocols whose endpoints were discovered, specifically iFCP and iSCSI. It is the responsibility of the providers of these services to ensure that an inappropriately advertised or discovered service does not compromise their security.
When no DHCP security is used, there is a risk of distribution of false discovery information, for example an iSNS DHCP option identifying a false iSNS server. The primary countermeasure is authentication by the IP storage protocols discovered through iSNS. If an attacker uses DHCP and iSNS to distribute discovery information that falsely identifies an iSCSI endpoint, that endpoint will lack the credentials necessary to complete IKE authentication successfully, and will therefore be prevented from falsely sending or receiving iSCSI traffic. When the risk of false discovery information is a significant concern and IPsec is implemented for iSNS, IPsec security associations SHOULD also be used for iSNS traffic, which is more robust than relying only on the IP storage protocols.
There is also a risk of a denial-of-service attack based on repeated use of false discovery information that causes the initiation of IKE negotiation. The countermeasures are administrative configuration of each iSNS entity to limit the peers it is willing to communicate with, by IP address range or DNS domain, and maintenance of a negative authentication cache to avoid repeatedly contacting an iSNS entity that fails to authenticate. These three measures MUST be implemented for iSNS entities when this DHCP option is used.
Without protection on the DHCP side, someone could point a device at a fake iSNS server. The defence is that the storage protocols authenticate the far end, and an entity should refuse to talk to peers outside a configured range and remember which ones failed.
§4IANA Considerations
In accordance with the policy defined in RFC 2131, IANA has assigned a value of 83 for this option. There are no other IANA-assigned values defined by this specification.
The only registration is the option number, 83.