[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    DHCP and IPsec transport/tunnel mode

    Here's the promised message on why IP Storage protocols differ
    from remote access in not generally needing to allocate IP
    addresses through IPsec tunnels (which requires an IPsec
    extension to run DHCP through an IPsec tunnel).  This is the
    rationale behind the proposal to REQUIRE tunnel mode without
    worrying about DHCP complications; sorry for the length, but
    this stuff is not simple ...
    I've spent some time thinking about this (wasn't
    possible before Salt Lake City, sorry) and am coming to
    the conclusion that I want to question the following
    requirement from Section 5.1 (p.29) of the -06 IPS Security
    [2]  Dynamic address assignment and configuration.  Where IP addresses
         are dynamically assigned (such as with dynamically addressed hosts
         implementing iSCSI), it is necessary to support address assignment
         and configuration within IPsec tunnel mode.  The use of DHCP within
         IPsec tunnel mode has been proposed for this, as described in [55].
         However, this mechanism is not yet widely deployed within IPsec
         security gateways. Existing IPsec tunnel mode servers typically
         implement the desired functionality via proprietary extensions to
    [55] is a reference to draft-ietf-ipsec-dhcp-13.txt in the
    ipsra WG, which has recently been approved for publication as
    a Proposed Standard (IIRC).
    For a remote access situation, I agree with [2] above, the problem
    I'm having is that iSCSI usage doesn't seem to fit the remote
    access scenario.  I think the same is also true for FCIP and iFCP,
    but I'll stick to iSCSI in the discussion for clarity.
    Here's the key diagram from Section 3 (p.5)
    of draft-ietf-ipsec-dhcp-13.txt:
                                           corporate net
     +------------------+                      |
     |    externally    |        +--------+    |   !~~~~~~~~~~!
     |+-------+ visible |        |        |    |   ! rmt host !
     ||virtual| host    |        |security|    |---! virtual  !
     || host  |         |--------|gateway/|    |   ! presence !
     ||       |<================>|  DHCP  |----|   !~~~~~~~~~~!
     |+-------+         |--------| Relay  |    |
     +------------------+   ^    +--------+    |   +--------+
                            |                  |---| DHCPv4 |
                          IPsec tunnel         |   | server |
                          with encapsulated    |   +--------+
                          traffic inside
    In iSCSI terms the IPsec tunnel would connect the Initiator
    to the Target.  The remote access requirement that "the
    the remote host appear to be present on the local corporate
    network" doesn't seem to apply - the "corporate net" would
    be the private connection from the security gateway to the
    iSCSI Target, and the combination of doing address allocation
    separately for it and requiring Initiators to participate
    in that allocation seems worse than pointless, as it introduces
    complexity ...
    For ease of explanation, lets assume that both the Initiator and
    Target are on the same corporate network.  If DHCP is being used
    on that network, then any dynamic address allocation wants to
    participate in that DHCP infrastructure, as opposed to defining
    something separate.  One way to see this is to visualize an
    Initiator that wants to talk to half a dozen different Targets
    built in the above fashion - asking the Initiator to remember
    half a dozen different IP addresses (one per Target, because
    each Target did its own DHCP allocation for the Initiator)
    looks very wrong.  What's actually going on is that the position
    of the corporate net moves in the above diagram for iSCSI to:
                         corporate net   iSCSI internal net
     +------------------+    |                 |
     |    externally    |    |   +--------+    |   !~~~~~~~~~~!
     |+-------+ visible |    |   |        |    |   ! rmt host !
     ||virtual| host    |    |   |security|    |---! virtual  !
     || host  |         |--------|gateway/|    |   ! presence !
     ||       |<================>|  DHCP  |----|   !~~~~~~~~~~!
     |+-------+         |--------| Relay  |    |
     +------------------+   ^    +--------+    |   +---------+
                            |                  |---| DHCPv4  |
                          IPsec tunnel         |   | server??|
                          with encapsulated    |   +---------+
                          traffic inside
    The next step in this journey is to observe that for the
    situation of interest, the iSCSI Initiator on the left hand
    side doesn't even need two IP addresses - the left hand side
    implementation in the above diagram is host-based, and hence
    should be able to use the same IP address for both the inner
    and outer header of the tunnel-mode IPsec packets.  If that
    address has to be dynamic, it can be obtained from DHCP on
    the LAN in the usual fashion (in essence, the externally
    visible host uses DHCP to get an IP address that is used
    by both it and the virtual host).
    Ok, but what about iSCSI implementations that use a security
    gateway in a fashion that the inner and outer IP addresses
    have to be different (e.g., because the gateway "knows" that
    all traffic destined for its IP address is for the gateway
    and won't pass it on to iSCSI)?  One example is the right
    hand side of the above diagram, and lets stick with it for
    consistency, even though it's a Target and dynamic addresses
    for Targets cause some configuration complications (an indirection
    through DNS is one way to address these).
    I suggest that the above observation about DHCP on the corporate
    network still applies:
    	If DHCP is being used on that network, then any dynamic
    	address allocation wants to participate in that DHCP
    	infrastructure, as opposed to defining something
    One way of doing this is to take the box labeled "DHCPv4 server??"
    in the above diagram and make it a DHCP proxy/relay that connects
    to the corporate network on the other side of the security gateway
    (and take out the DHCP relay in the gateway):
                      corporate net
                             |                                   | 
                             |            iSCSI internal         |
     +------------------+    |                 |                 |  
     |    externally    |    |   +--------+    |   !~~~~~~~~~~!  |
     |+-------+ visible |    |   |        |    |   ! rmt host !  |
     ||virtual| host    |    |   |security|    |---! virtual  !  |
     || host  |         |--------|gateway/|    |   ! presence !  |
     ||       |<================>|        |----|   !~~~~~~~~~~!  |
     |+-------+         |--------|        |    |                 | 
     +------------------+   ^    +--------+    |   +---------+   |
                            |                  |---| DHCPv4  |---+
                          IPsec tunnel         |   | Relay   |
                          with encapsulated    |   +---------+
                          traffic inside
    The actual DHCPv4 server would be somewhere out on the corporate
    net.  This will strike some folks as a bit peculiar, as it's
    something that one would NEVER do in a remote access situation,
    because the security domains on the two sides of the gateway are
    very different (one has to protect the corporate net from the wild
    Internet on the other side of the gateway).  I think that the
    situation is less extreme for iSCSI, in that its ok to rely on
    the corporate net for DHCP services even while we want to use
    IPsec to protect iSCSI traffic flowing over it.  OTOH, the
    above diagram is not exactly the preferred way of doing things
    - I could easily see the resulting situation favoring static
    IP address allocation when the DHCP relay is physically
    separate, but it may be viable if the DHCP relay is software
    collocated with the security gateway (software).
    Comments/reactions/etc. please?
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500         Cell: +1 (978) 394-7754


Last updated: Fri Feb 01 13:17:55 2002
8595 messages in chronological order