DHCP and IPsec transport/tunnel mode

[Black_David@emc.com]

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
draft:

[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
     IKE.

[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
	separate.

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?

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------