RE: IPSEC target and transport mode

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Wed, 27 Mar 2002 Black_David@emc.com wrote:

> Bill,
>
> > As I understand tunnel mode, you have an IPsec security gateway in the
> > topology. Among other things, that means we won't readily have end-to-end
> > security, since you have security from the gateway to the device, not
> > necessarily the initiator to the device.
>
> The gateway is possible, but not necessary.  RFC 2401, section 4.1 says:
>
> 	Two hosts MAY establish a tunnel mode SA between themselves.
>
> Hence the assertion that end-to-end security is not possible in tunnel
> mode is incorrect.  OTOH, if someone chooses to use a separate security
> gateway packaged with their IP Storage implementation, they
> can only claim compliance with the security requirements of the
> appropriate IP Storage RFC(s) on the secured side of the gateway -
> they have to explain to their customer that there is no IPsec security
> on the (presumably private) link between the IP Storage system and
> the gateway.

The examples I've seen of that are cases where security gateways want to
talk to each other, *and* they end up using internal addresses to use the
tunnel. i.e. not the IP addresses the tunnel is built between. I think
you can slide and have the connection to one of the tunnel addresses, but
the other one needs to be internal.

If we need an extra address, I don't see that mentioned, and I don't want
folks to get surprised whent hey go to try and hook thing up.

Oh, by basing a MUST in iSCSI on a MAY in RFC 2401, aren't we seting
ourselves up for interoperability problems when we hit an IPsec stack on
the other end that doesn't support the mode you support?

> > How do you suggest we achieve end-to-end security without
> > transport mode a MUST?
>
> IPsec security policy (including use and acceptance of ID payloads)
> and decisions about which IKE authentication material is installed
> in what systems and is accepted/required by what other systems.
> Forcing use of transport mode is a poor substitute for putting a
> proper security policy in place.  Ensuring that only the ends of
> interest have the material required to set up the end-to-end SA is
> a good idea.

David, I think we have a disconnect here. I had my example in mind. I
agree that there are places where tunnel mode will be needed to do IPsec
right. And that a topology more complicated than my example will need more
flexability.

> > Specifically the topology I have in mind is I make a dedicated IP SAN, and
> > want ESP from the file servers to the storage boxes. They are all on the
> > same (GigE) subnet. How do I get this level of security (end-to-end) with
> > just tunnel mode?
>
> Negotiate what you want and make sure that no security gateway between the
> file servers and storage boxes has the IKE authentication material that
> the file servers and storage boxes will require.  Negotiation of the
> encapsulation mode (you can still do transport if you want to, it's just
> not REQUIRED) is supported by SA attribute 4 in Section 4.5 of RFC 2407
> (yes, it's well hidden ...).

Let me try that again. I have a file server with an address on the IP SAN
at 192.168.1.1, and the iSCSI device is at 192.168.1.3. They have either a
cross-over cable or a gig swith between them.

What would the SPDs look like?

Have you tried it?

Also, I realize that transport will be a MAY. But as I understand it, I'll
have to look at specs to make sure that devices have it in order to be
able to do what I describe above.

If the answer to those questions just above is, "blah" and "yes," then I'm
happy. It's just my experience with IPsec is that it's not that simple.

Take care,

Bill