home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / iscsiprj.zip / draft-ietf-ips-iscsi-boot-05.txt < prev    next >
Text File  |  2002-06-02  |  21KB  |  601 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. IPS                                                   Prasenjit Sarkar
  8. Internet Draft                                                     IBM
  9. Document: draft-ietf-ips-iscsi-boot-05.txt             Duncan Missimer
  10. Category: Standards                                                 HP
  11.                                                 Constantin Sapuntzakis
  12.                                                                  Cisco
  13.                                                       22 February 2002
  14.  
  15.  
  16.              Bootstrapping Clients using the iSCSI Protocol
  17.  
  18. Status of this Memo
  19.  
  20.    This document is an Internet-Draft and is in full conformance with
  21.    all provisions of Section 10 of RFC2026 [11].
  22.  
  23.    Internet-Drafts are working documents of the Internet Engineering
  24.    Task Force (IETF), its areas, and its working groups. Note that other
  25.    groups may also distribute working documents as Internet-Drafts.
  26.    Internet-Drafts are draft documents valid for a maximum of six months
  27.    and may be updated, replaced, or made obsolete by other documents at
  28.    any time. It is inappropriate to use Internet- Drafts as reference
  29.    material or to cite them other than as "work in progress."  The list
  30.    of current Internet-Drafts can be accessed at
  31.    http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
  32.    Shadow Directories can be accessed at
  33.    http://www.ietf.org/shadow.html.
  34.  
  35. Abstract
  36.  
  37.    The Small Computer Systems Interface (SCSI) is a popular family of
  38.    protocols for communicating with I/O devices, especially storage
  39.    devices.  iSCSI is a proposed transport protocol for SCSI that
  40.    operates on top of TCP[12].  This memo describes a standard mechanism
  41.    to enable clients to bootstrap themselves using the iSCSI protocol.
  42.    The goal of this standard is to enable iSCSI boot clients to obtain
  43.    the information to open an iSCSI session with the iSCSI boot server,
  44.    assuming this information is not available.
  45.  
  46. 1. Requirements
  47.  
  48.    1. There must be no restriction of network topology between the iSCSI
  49.    boot client and the boot server. Consequently, it is possible for an
  50.    iSCSI boot client to boot from an iSCSI boot server behind gateways
  51.    or firewalls as long as it is possible to establish an iSCSI session
  52.    between the client and the server.
  53.  
  54.    2. The following represents the minimum information required for an
  55.  
  56.  
  57.  
  58. Sarkar                    Expires: August 2002                  [Page 1]
  59.  
  60.  
  61.  
  62.  
  63.  
  64. Standards-Track         iSCSI BootStrapping Draft       22 February 2001
  65.  
  66.  
  67.    iSCSI boot client to contact an iSCSI boot server: (a) the client's
  68.    IP address (IPv6 or IPv4); (b) the server's iSCSI Service Delivery
  69.    Port Name; and (c) mandatory iSCSI initiator capability.
  70.  
  71.    The above assumes that the default LUN for the boot process is 0 and
  72.    the default port for the iSCSI boot server is the well-known iSCSI
  73.    port. However, both may be overridden at the time of configuration.
  74.  
  75.    Additional information may be required at each stage of the boot
  76.    process.
  77.  
  78.    3. It is possible for the iSCSI boot client to have none of the above
  79.    information or capability on starting.
  80.  
  81.    4. The client should be able to complete boot without user
  82.    intervention (for boots that occur during an unattended power-up).
  83.    However, there should be a mechanism for the user to input values so
  84.    as to bypass stages of the boot protocol.
  85.  
  86.    5. Additional protocol software (for example, DHCP) may be necessary
  87.    if the minimum information required for an iSCSI session is not
  88.    provided.
  89.  
  90. 2. Related Work
  91.  
  92.    The Reverse Address Resolution Protocol (RARP)[7](through the
  93.    extensions defined in the Dynamic RARP (DRARP))[4] explicitly
  94.    addresses the problem of network address discovery, and includes an
  95.    automatic IP address assignment mechanism.  The Trivial File Transfer
  96.    Protocol (TFTP)[9] provides for transport of a boot image from a boot
  97.    server. BOOTP[5,8,10] is a transport mechanism for a collection of
  98.    configuration information.  BOOTP is also extensible, and official
  99.    extensions have been defined for several configuration parameters.
  100.    DHCPv4[3,6] and DHCPv6[13] are standards for hosts to be dynamically
  101.    configured in an IP network.  The Service Location Protocol (SLP)
  102.    provides for location of higher level services[1,15].
  103.  
  104. 3. Software stage
  105.  
  106.    Some iSCSI boot clients may lack the resources to boot up with the
  107.    mandatory iSCSI initiator capability. Such boot clients may choose to
  108.    obtain iSCSI initiator software from a boot server.  Currently, there
  109.    are many established protocols that allow such a service to enable
  110.    clients to load software images. For example, BOOTP and DHCP servers
  111.    have the capability to provide software images on requests from boot
  112.    clients. A particular implementation of this approach is the PXE
  113.    protocol[17], which uses DHCP extensions and MTFTP to allow boot
  114.    clients to load software images.
  115.  
  116.  
  117.  
  118. Sarkar                    Expires: August 2002                  [Page 2]
  119.  
  120.  
  121.  
  122.  
  123.  
  124. Standards-Track         iSCSI BootStrapping Draft       22 February 2001
  125.  
  126.  
  127.    It is to be noted that this document does not recommend any of the
  128.    above protocols, and the final decision of which boot protocol is to
  129.    be used to load iSCSI initiator software is left to the discretion of
  130.    the implementor.
  131.  
  132.  
  133. 4. DHCP stage
  134.  
  135.    In order to use an iSCSI boot server, the following pieces of
  136.    information are required.
  137.  
  138.    - The IP address of the iSCSI boot client (IPv4 or IPv6)
  139.  
  140.    - The IP transport endpoint for the iSCSI service delivery port for
  141.    the iSCSI boot server.  If the transport is TCP, for example, this
  142.    has to resolve to an IP address and a TCP port number.
  143.  
  144.    - The eight-byte LUN structure identifying the device within the
  145.    iSCSI boot server.
  146.  
  147.    At boot time, all or none of this information may be stored in the
  148.    firmware of the iSCSI boot client. This section describes techniques
  149.    for obtaining the required information.
  150.  
  151.    An iSCSI boot client which does not know its IP address at power-on
  152.    may acquire its IP address via DHCP.  An iSCSI boot client which is
  153.    capable of using both DHCPv6 and DHCPv4 should first attempt to use
  154.    DHCPv6 to obtain its IP address, falling back on DHCPv4 in the event
  155.    of failure.
  156.  
  157.    Unless otherwise specified here, DHCP fields such as the client ID
  158.    and gateway information are used identically with applications other
  159.    than iSCSI.
  160.  
  161.    A DHCP server (v4 or v6) may instruct an iSCSI client how to reach
  162.    its boot device. This is done using the variable length DHCP option
  163.    named Root Path. The use of the option field is reserved for iSCSI
  164.    boot use by prefacing the string with "iscsi:".
  165.  
  166.    The option field consists of an UTF-8[8] string. The string MUST
  167.    contain only alphanumberic characters, "." , ":" and "-"; no other
  168.    characters are permissible. The string has the following composition:
  169.  
  170.    "iscsi:"<servername>":"<protocol>":"<port>":"<LUN>":"<targetname>
  171.  
  172.    The fields "servername", "port", "protocol" and "LUN" are optional
  173.    and should be left blank if there are no corresponding values. The
  174.    "targetname" field is not optional and must be provided.
  175.  
  176.  
  177.  
  178. Sarkar                    Expires: August 2002                  [Page 3]
  179.  
  180.  
  181.  
  182.  
  183.  
  184. Standards-Track         iSCSI BootStrapping Draft       22 February 2001
  185.  
  186.  
  187.    Thv "servername" is the name of iSCSI server and contains either a
  188.    valid domain name, a literal IPv4 address, or a literal IPv6 address.
  189.  
  190.    If the "servername" field contains a literal IPv4 address, the IPv4
  191.    address is in standard dotted decimal notation as defined in Section
  192.    2.1 of RFC 1123[6].
  193.  
  194.    If the "servername" field contains an IPv6 address, the address is
  195.    represented in the IPv6 address format x.x.x.x.x.x.x.x where the 'x's
  196.    are the hexadecimal values of the eight 16-bit pieces of the address.
  197.    Note that this format representation is specific to iSCSI boot.
  198.  
  199.    If the "servername" is a domain name, the name MUST be a fully
  200.    qualified domian name (FQDN) and SHOULD abide by the rules specified
  201.    in Sections 3.1 and 3.5 of RFC 1034[7] and the reply from the host
  202.    configuration server SHOULD contain the Domain Name Server Option[1].
  203.    It must also be pointed out that the use of DNS for address
  204.    translation in enterprise environments must contain adequate levels
  205.    of fault tolerance and security.
  206.  
  207.    If the "servername" field contains 4 decimal components, the
  208.    "servername" is assumed to be an IPv4 address. If there are more than
  209.    4 decimal components or if there is a hexadecimal component, the the
  210.    "servername" is assumed to be an IPv6 address. If the least
  211.    significant (rightmost) component is an approved domain extension,
  212.    then the "servername" field is assumed to be a domain name.
  213.  
  214.    The "protocol" field is the decimal representation of the IANA-
  215.    approved string for the trasport protocol to be used for iSCSI. If
  216.    the protocol field is left bank, the default value is assumed to be
  217.    "6" for TCP.  The transport protocol MUST have been approved for use
  218.    in iSCSI; currently, the only approved protocol is TCP.
  219.  
  220.    The "port" is the decimal representation of the port on which the
  221.    iSCSI boot server is listening. If not specified, the port defaults
  222.    to the well-known iSCSI port.
  223.  
  224.    The "LUN" field is a 16 byte hexadecimal representation of the 8-byte
  225.    LU number in hex. Digits above 9 may be either lower or upper case,
  226.    and all 16 nibbles must be present. If the LUN field is blank, then
  227.    LUN 0 is assumed.
  228.  
  229.    Note that SCSI targets are allowed to present different LU numberings
  230.    for different SCSI initiators, so that to our knowledge nothing
  231.    precludes a SCSI target from exporting several different devices to
  232.    several different SCSI initiators as their respective LU 0s.
  233.  
  234.    The "targetname" field is an iSCSI Name that is defined by the naming
  235.  
  236.  
  237.  
  238. Sarkar                    Expires: August 2002                  [Page 4]
  239.  
  240.  
  241.  
  242.  
  243.  
  244. Standards-Track         iSCSI BootStrapping Draft       22 February 2001
  245.  
  246.  
  247.    and discovery in Section 2.1 iSCSI Naming and Discovery draft[9] to
  248.    uniquely identify an iSCSI target.  The use of the targetname
  249.    component is also defined by the iSCSI standard[4] and is to be used
  250.    accordingly.
  251.  
  252.    If the "servername" field is left blank, then no default value is
  253.    assumed in its place.  If the "protocol" field is left bank, the
  254.    default value is assumed to be "6" for TCP.  If the "port" field is
  255.    not specified, the port defaults to the well-known iSCSI port.  If
  256.    the LUN field is blank, then LUN 0 is assumed.
  257.  
  258.    If the "servername" field is provided by DHCP, then that field is
  259.    used in conjunction with other associated fields to contact the boot
  260.    server in the Boot stage (Section 6).
  261.  
  262.    However, if the "servername" field is not provided, then the
  263.    "targetname" field is then used in the Discovery Service stage
  264.    (Section 5).
  265.  
  266.  
  267. 5. Discovery Service stage:
  268.  
  269.    This stage is required if the DHCP server (v4 or v6) is unaware of
  270.    the Service Delivery Port Name of the iSCSI boot server.  The
  271.    implemention of the discovery service is to based on the SLP
  272.    protocol[1,24].
  273.  
  274.    The iSCSI boot client may have obtained the targetname of the iSCSI
  275.    boot server in the DHCP stage (Section 4). In that case, the iSCSI
  276.    boot client queries the Discovery Service using query string 1 as
  277.    specified in the iSCSI SLP interaction document[24] to resolve the
  278.    targetname to an IP address and port number. One this is obtained,
  279.    the iSCSI boot client proceeds to the Boot Stage (Section 6).
  280.  
  281.    It is possible that the port number obtained from the Discovery
  282.    Service may conflict with the one obtained from the DHCP service. In
  283.    such a case, the implementor has the option to try both port numbers
  284.    in the Boot stage.
  285.  
  286.    If the iSCSI boot client does not have any targetname information,
  287.    the iSCSI boot client then may query the Discovery Service with query
  288.    string 4 as specified in the iSCSI SLP interaction document[24]. In
  289.    response to this query, the discovery service provides the boot
  290.    client with a list of iSCSI boot servers the boot client is allowed
  291.    to access.
  292.  
  293.    If the list of iSCSI boot servers is empty, subsequent actions are
  294.    left to the discretion of the implementor. Otherwise, the iSCSI boot
  295.  
  296.  
  297.  
  298. Sarkar                    Expires: August 2002                  [Page 5]
  299.  
  300.  
  301.  
  302.  
  303.  
  304. Standards-Track         iSCSI BootStrapping Draft       22 February 2001
  305.  
  306.  
  307.    client may contact any iSCSI boot server in the list. Moreover, the
  308.    the order in which iSCSI boot servers are contacted is also left to
  309.    the discretion of the implementor.
  310.  
  311. 6. Boot Stage
  312.  
  313.    Once the iSCSI boot client has obtained the minimum information to
  314.    open an iSCSI session with the iSCSI boot server, the actual booting
  315.    process can start.
  316.  
  317.    The actual sequence of iSCSI commands needed to complete the boot
  318.    process is left to the implementor. This was done because of varying
  319.    requirements from different vendors and equipments, making it
  320.    difficult to specify a common subset of the iSCSI standard that would
  321.    be acceptable to everybody.
  322.  
  323.    However, the use of a discovery session is not recommended because at
  324.    this stage (i) a boot server has probably been found and (ii) the
  325.    response obtained from the discovery session does not qualify an
  326.    iSCSI boot server from an iSCSI target.
  327.  
  328.    The iSCSI session established for boot may be taken over the booted
  329.    software in the iSCSI boot client.
  330.  
  331. 7. Security
  332.  
  333.  
  334.    The security discussion is centered around each stage of the iSCSI
  335.    boot process.
  336.  
  337.    The software stage can be secured by using public key encryption and
  338.    digitial signatures. This is the approach taken by the popular PXE
  339.    boot framework.
  340.  
  341.    With regards to the DHCP stage, securing the host configuration
  342.    protocol is beyond the scope of this document. Authentication of DHCP
  343.    messages is described in [16].
  344.  
  345.    The security issues in the Discovery Service stage are addressed by
  346.    public key ciphering as stated in the the SLP version 2 document[1].
  347.  
  348.    For the Boot stage, the iSCSI standard supports various methods of
  349.    authenticated login and encrypted and authenticated connections for
  350.    security[12]. How to configure the security parameters of an iSCSI
  351.    boot client is beyond the scope of this document.
  352.  
  353.    The iSCSI boot service may be subjected to denial of service attacks.
  354.    The use of IPSEC as mandated by the iSCSI standard[12] can be used to
  355.  
  356.  
  357.  
  358. Sarkar                    Expires: August 2002                  [Page 6]
  359.  
  360.  
  361.  
  362.  
  363.  
  364. Standards-Track         iSCSI BootStrapping Draft       22 February 2001
  365.  
  366.  
  367.    protect against such attacks. However, ARP is still vulnerable to
  368.    such type of attacks.
  369.  
  370.    Security in the Boot stage is also dependent on the verification of
  371.    the boot image being loaded.  One key difference between the iSCSI
  372.    boot mechanism and BOOTP-based image loading is the fact that the
  373.    identity of a boot image may not be known when the Boot stage starts.
  374.    The identity of certain boot images and their locations are known
  375.    only after examining the contents of a boot disk exposed by the iSCSI
  376.    boot service. Furthermore, images themselves may recursively load
  377.    other images based on both hardware configurations and user input.
  378.  
  379.    Consequently, a practical way to verify loaded boot images is to make
  380.    sure that each image loading software verify the image to be loaded
  381.    using a mechanism of their choice.
  382.  
  383.    Another point to be noted is that if a boot image inherits an iSCSI
  384.    session from a previously loaded boot image, the boot image also
  385.    inherts the security properties of the iSCSI session.
  386.  
  387. Acknowledgments
  388.  
  389.    We wish to thank John Hufferd for taking the initiative to form the
  390.    iSCSI boot team. We also wish to thank Doug Otis, Julian Satran,
  391.    Bernard Aboba, David Robinson and Mark Bakke for helpful suggestions
  392.    and pointers regarding the draft document.
  393.  
  394. References
  395.  
  396.    [1] Guttman, E., Perkins, C., Verizades, J., Day, M., "Service
  397.    Location Protocol v2", RFC 2608, June 1999.
  398.  
  399.    [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
  400.           Extensions", RFC 2132, Lachman Technology, Inc., Bucknell
  401.           University, October 1993.
  402.  
  403.    [3] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131,
  404.           Bucknell University, March 1997.
  405.  
  406.    [4] Brownell, D, "Dynamic Reverse Address Resolution Protocol
  407.           (DRARP)", Work in Progress.
  408.  
  409.    [5] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
  410.           Stanford and SUN Microsystems, September 1985.
  411.  
  412.    [6] Droms, D., "Interoperation between DHCP and BOOTP" RFC 1534,
  413.           Bucknell University, October 1993.
  414.  
  415.  
  416.  
  417.  
  418. Sarkar                    Expires: August 2002                  [Page 7]
  419.  
  420.  
  421.  
  422.  
  423.  
  424. Standards-Track         iSCSI BootStrapping Draft       22 February 2001
  425.  
  426.  
  427.    [7] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
  428.           Address Resolution Protocol", RFC 903, Stanford, June 1984.
  429.  
  430.    [8] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
  431.           USC/Information Sciences Institute, August 1993.
  432.  
  433.    [9] Sollins, K., "The TFTP Protocol (Revision 2)",  RFC 783, NIC,
  434.           June 1981.
  435.  
  436.    [10] Wimer, W., "Clarifications and Extensions for the Bootstrap
  437.           Protocol", RFC 1532, Carnegie Mellon University, October 1993.
  438.  
  439.    [11] Bradner, S., "The Internet Standards Process --
  440.          Revision 3", RFC 2026, October 1996.
  441.  
  442.    [12] Satran, J. et al., "iSCSI", Internet-Draft, July 2001.
  443.  
  444.    [13] Bound, J., Canney, M., and Perkins, C., "Dynamic Host
  445.    Configuration
  446.         Protocol for IPv6", Internet-Draft, June 2001.
  447.  
  448.    [14] Bakke, M. et al., "iSCSI Naming and Discovery", Internet-Draft,
  449.         July 2001.
  450.  
  451.    [15] Veizades, J., Guttman, E., Perkins, C., Kaplan, S., "Service
  452.    Location Protocol", RFC 2165, June 1997.
  453.  
  454.    [16] Droms, R., Arbaugh, W., "Authentication for DHCP Messages",
  455.    Internet-Draft, November 2000.
  456.  
  457.    [17] http://developer.intel.com/ial/WfM/wfm20/design/pxedt/index.htm
  458.  
  459.    [18] Stewart, R., et al. "Stream Control Transmission Protocol", RFC
  460.    2960, October 2000.
  461.  
  462.    [19] Droms, R., "Procedures and IANA Guidelines for Approval of New
  463.    DHCP Options and Message Types", RFC 2939, September 2000.
  464.  
  465.    [20] Yergeau, F., "UTF-8: A Transformation Format for ISO-10646", RFC
  466.    2279, January 1998.
  467.  
  468.    [21] Hinden, R., Deering, S., "IP version 6 Addressing Architecture",
  469.    RFC 2273, July 1998.
  470.  
  471.    [22] Braden, R., "Requirements for Internet Hosts - Application and
  472.    Support", RFC 1123, October 1989.
  473.  
  474.    [23] Mockaopertis, P., "Domain Names - Concepts and Facilities", RFC
  475.  
  476.  
  477.  
  478. Sarkar                    Expires: August 2002                  [Page 8]
  479.  
  480.  
  481.  
  482.  
  483.  
  484. Standards-Track         iSCSI BootStrapping Draft       22 February 2001
  485.  
  486.  
  487.    1034, November 1987.
  488.  
  489.    [24] Bakke, M., et al. "Finding iSCSI Targets and Name Servers using
  490.    SLP", Internet-Draft, July 2001.
  491.  
  492. Author's Addresses
  493.  
  494.    Prasenjit Sarkar
  495.    IBM Almaden Research Center
  496.    650 Harry Road
  497.    San Jose, CA 95120, USA
  498.    Phone: +1 408 927 1417
  499.    Email: psarkar@almaden.ibm.com
  500.  
  501.    Duncan Missimer
  502.    Hewlett-Packard Company
  503.    19420 Homestead Road, M/S 43lo
  504.    Cupertino, CA 95014, USA
  505.    Phone: +1 408 447 5390
  506.    Email: duncan_missimer@hp.com
  507.  
  508.    Constantine Sapuntzakis
  509.    Cisco Systems, Inc.
  510.    170 W. Tasman Drive
  511.    San Jose, CA 95134, USA
  512.    Phone: +1 650 520 0205
  513.    Email: csapuntz@cisco.com
  514.  
  515.  
  516. Full Copyright Statement
  517.  
  518.    "Copyright (C) The Internet Society (date). All Rights Reserved. This
  519.    document and translations of it may be copied and furnished to
  520.    others, and derivative works that comment on or otherwise explain it
  521.    or assist in its implementation may be prepared, copied, published
  522.    and distributed, in whole or in part, without restriction of any
  523.    kind, provided that the above copyright notice and this paragraph are
  524.    included on all such copies and derivative works. However, this
  525.    document itself may not be modified in any way, such as by removing
  526.    the copyright notice or references to the Internet Society or other
  527.    Internet organizations, except as needed for the purpose of
  528.    developing Internet standards in which case the procedures for
  529.    copyrights defined in the Internet Standards process must be
  530.    followed, or as required to translate it into languages other than
  531.    English.
  532.  
  533.    The limited permissions granted above are perpetual and will not be
  534.    revoked by the Internet Society or its successors or assigns.
  535.  
  536.  
  537.  
  538. Sarkar                    Expires: August 2002                  [Page 9]
  539.  
  540.  
  541.  
  542.  
  543.  
  544. Standards-Track         iSCSI BootStrapping Draft       22 February 2001
  545.  
  546.  
  547.    This document and the information contained herein is provided on an
  548.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  549.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  550.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  551.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  552.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598. Sarkar                    Expires: August 2002                 [Page 10]
  599.  
  600.  
  601.