RE: IPSEC target and transport mode

[Black_David@emc.com]

Jason,

With my WG co-chair hat off ...

>  > The sense of the room in Minneapolis (and it was a bit rough,
>  > with visible dissent) was to drop the requirement for IPsec
>  > transport mode.  Tunnel mode would become "MUST implement",
>  > transport mode would become "MAY implement", and this would
>  > override the "host must support both tunnel mode and transport
>  > mode" requirement of RFC 2401.  Any procedural questions or
> 
> I really don't like this idea.  While it is true that Tunnel Mode
> does not require the use of a gateway, Transport Mode is actually
> the more general mode.
> 
> It is possible to combine Transport Mode with any arbitrary
something-in-IP
> tunneling protocol (IP-IP, GRE, etc.).  In the case of Transport Mode +
> IP-IP tunneling, you achieve something that is equivalent to Tunnel Mode,
> thus satisfying those who need it (I suggest that everyone read
> draft-touch-ipsec-vpn-03.txt).

And make sure to pay attention to the following paragraph in Section 4.4:

   With IIPtran, next-hop forwarding is done outside IPsec. For full
   IPsec compliance, IIPtran requires a content-based forwarding
   mechanism that supports all IPsec selectors. On many systems,
   existing firewall mechanisms can be used for that purpose.

IIPtran is IPsec transport mode applied to an IP-in-IP tunnel.  This
creates a practical issue of needing to coordinate the IPsec SPD with
the configuration of the additional content-based forwarding mechanism.
This is probably not that complex for likely IP Storage deployment
scenarios, but it's one more thing to manage.

> Transport Mode is also less expensive from a processing point of view.
> If you use Tunnel Mode with no gateway (i.e. inner-dest==outer-dest,
> outer-source==inner-source), you still have to de-encap the packet and
> re-process it, which is something you don't have to do in 
> Transport Mode.

If I were starting from a clean sheet of paper without regard to existing
IPsec implementations/technology/etc., I would be inclined to do as Jason
suggests.  However, we are not in that situation.

The current situation is that there is significant interest in the WG in
using existing IPsec systems/devices/etc. to address this area of
functionality; the folks with this interest believe that only requiring
tunnel mode will significantly increase their design/implementation
options for doing so and are willing to pay the additional overhead of
tunnel mode encapsulation.

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