Subject: RE: IPSEC target and transport mode

From: [email-masked]
Date: Wed, 27 Mar 2002 15:51:34 -0500

> Not recently.  Actually, an interesting wrinkle is that a number of
> security gateways don't implement fine grain (per port) SPDs, in spite
> of RFC 2401.  But apart from that it's pretty straightforward.

I actually checked this in the ipsec WG last week.  Something like 2/3
of the security gateway vendors in the room indicated that they do support
the fine grain (per port) selectors in their SPDs, so the support does
exist, but it's not universal.

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

---

From: Jason R Thorpe <[email-masked]>
Date: Wed, 27 Mar 2002 11:11:06 -0800

First of all, I'm new to the list (my subscription request is pending
approval right now, so please CC me explicitly on any replies..)

Sigh, every time I see a discussion of this nature, it makes me wish that
IPsec Tunnel Mode didn't even exist...

 > ---------- Forwarded message ----------
 > Date: Tue, 26 Mar 2002 19:31:37 -0500
 > From: [email-masked]
 > To: [email-masked], [email-masked]
 > Subject: IPSEC target and transport mode
 > 

 ...

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

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.

-- 
        -- Jason R. Thorpe <[email-masked]>

---

From: [email-masked]
Date: Wed, 27 Mar 2002 17:48:43 -0500

Jason,

With my WG co-chair hat off ...

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

> re-process it, which is something you don't have to do in 

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 30 Mar 2002 05:51:18 -0800

>I really don't like this idea.
>
>While it is true that Tunnel Mode
>tunneling protocol (IP-IP, GRE, etc.).  In the case of >Transport Mode + 
>thus satisfying those who need it (I >suggest that everyone read 

Having worked with transport mode tunnels for a few years now (L2TP), we 
have come to the same conclusion. By linking SA selection to next hop 
forwarding, tunnel mode complicates routing considerably. Transport mode 
tunnels are more compatible with dynamic routing protocols. Today most 
tunnel mode vendors only support either static routing or BGP run down the 
tunnel, and that makes it very difficult for enterprise customers to manage 
and deploy large numbers of tunnels.

Although it can be done, Tunnel mode is also more difficult to implement as 
an interface than Transport mode IP-IP. There already is pushback on iSCSI 
HBAs that cannot act as a full fledged interface; this will ensure that this 
continues to be a problem many years into the future.

>re-process it, which is something you don't have to do in Transport >Mode.

It would seem to me that this additional cost might be a concern in the 10 
Gbps case in particular.

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

---

From: "John Hufferd" <[email-masked]>
Date: Sat, 30 Mar 2002 17:58:24 -0800

These reasons you mentioned here, and the resulting performance were some
of the reasons I thought we voted to make Transport a "Must implement".  It
is also true that David Black may have caused some of the Tunnel folks to
have rolled over on this issue, but I believe, a number of folks understood
various aspects of what you have said here, and wanted to use Tunnel mode,
and wanted it to be a "Must Implement" since if Tunnel mode, is not
implemented by the other side, it can cause your side to have poorer
performance, even if you can support the higher performance that come with
Transport mode.

But more then David's statements, the thing that I understood helped get
agreement on the MUST/MUST for Transport and Tunnel, was the fact that
almost all the IPsec stacks that are available on the market come with both
Transport and Tunnel.  So it is now possible for iSCSI to not only operate
at high speed, and support the key features mentioned below, but can
interoperate with HW that can only pass through Tunnel mode.

I feel that Transport is the most capable and high performance mode, but
feel that tunnel is also needed for firewalls that do not accept Transport
at this time.  But, it seems clear to me, that if we have Transport mode as
a MUST (along with Tunnel), that the various hardware along the way, such
as the firewalls, will be quickly adjusted to support Transport, since each
vendor will see the potential advantages of having their product support
iSCSI traffic in the most efficient manner.  However, we will be able to
operate with Tunnel mode until most vendors HW will be able to support
Transport mode through their equipment (such as firewalls etc.)

So again, I feel that our original vote to support both Transport and
Tunnel as Must implements, was the right decision, and best for iSCSI and
the customer.

I propose we let the original agreement stand.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

"Bernard Aboba" <[email-masked]>@ece.cmu.edu on 03/30/2002
05:51:18 AM

Sent by:    [email-masked]

To:    [email-masked], [email-masked]
cc:
Subject:    Re: IPSEC target and transport mode

Although it can be done, Tunnel mode is also more difficult to implement as
an interface than Transport mode IP-IP. There already is pushback on iSCSI
HBAs that cannot act as a full fledged interface; this will ensure that
this
continues to be a problem many years into the future.

---

From: "John Hufferd" <[email-masked]>
Date: Sat, 30 Mar 2002 21:23:51 -0800

Well, as usual, I replace the term Transport, with Tunnel  until no one can
understand what I intended to say.  Corrections below following the xxxxxx
which crossed out the word Tunnel.

.
.
.
John L. Hufferd

John Hufferd/San Jose/IBM@[email-masked] on 03/30/2002 05:58:24 PM

To:    "Bernard Aboba" <[email-masked]>
cc:    [email-masked], [email-masked]
Subject:    Re: IPSEC target and transport mode

These reasons you mentioned here, and the resulting performance were some
of the reasons I thought we voted to make Transport a "Must implement".  It
is also true that David Black may have caused some of the Tunnel folks to
have rolled over on this issue, but I believe, a number of folks understood
various aspects of what you have said here, and wanted to use xxxxxx
Transport mode,
and wanted it to be a "Must Implement" since if xxxxxx Transport mode, is
not
implemented by the other side, it can cause your side to have poorer
performance, even if you can support the higher performance that come with
Transport mode.

.
.
.
John L. Hufferd