+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.