Subject: RE: IPSEC target and transport mode

From: [email-masked]
Date: Wed, 27 Mar 2002 13:16:31 -0500

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.

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

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

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
[email-masked]         Cell: +1 (978) 394-7754
---------------------------------------------------

---

From: Bill Studenmund <[email-masked]>
Date: Wed, 27 Mar 2002 10:56:32 -0800 (PST)

> on the (presumably private) link between the IP Storage system and

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?

> interest have the material required to set up the end-to-end SA is

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.

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

---

From: Paul Koning <[email-masked]>
Date: Wed, 27 Mar 2002 15:28:21 -0500

> the other one needs to be internal.

There's no restriction on the "inner" address in a tunnel.  It may be
the same as the outer address (tunnel endpoint address) if the tunnel
terminates at the same node as the source or destination of the
protected traffic.  But even in that case you're allowed to use a
different address if you wish.
 
> the other end that doesn't support the mode you support?

No, because the "MAY" David quoted indicates that a host has a choice
of modes it can pick from.  The more important statement in RFC 2401
is this one, which is the statement of what's mandatory-to-implement:

   In summary,
           a) A host MUST support both transport and tunnel mode.

(RFC 2401, top of page 9).

> What would the SPDs look like?

"from 192.168.1.1, TCP port x, to 192.168.1.3, port <iscsi>, ESP
encryption foo, authentication bar" and the reverse.  It's the same
SPD whether you use tunnel mode or transport mode.

> Have you tried it?

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.

   paul