Subject: RE: IPsec Usage Question

From: [email-masked]
Date: Mon, 4 Feb 2002 14:08:01 -0500

> I agree with Paul, the association of *any* internal network address
> to any external mapping is  an IPSec configuration concern!

On the one hand, I like this, because it's the simplest way to close
this issue, and I have a strong preference for simple approaches that
allow us to declare victory sooner.  OTOH, I want to make sure that people
understand what the issue is:

	AFAIK, IPsec has no standard or widely deployed mechanism for
	handling gateway discovery or address association dynamically.

This has concrete consequences.  Suppose that:
- An IPsec implementation operating only in tunnel mode and requiring
	different inner and outer IP addresses is used to provide the
	IPsec security required by an IP Storage protocol. AND
- A dynamic discovery mechanism (e.g., Send Targets, SLP, and iSNS) is
	used to discover IP Storage peers.
Then the dynamic discovery mechanism only discovers the IP address
of the IP Storage peer, and does not provide information about the
IP address of the security gateway that must be contacted in order
to talk to that peer.

The current state of the art is to statically pre-configure the gateway
address information (i.e., every peer that wants to communicate with a
specific implementation will have to know that implementation's security
gateway IP address in advance, even though the IP Storage IP address
can be discovered dynamically).  This approach works, but it makes dynamic
discovery much more difficult to use with security gateways.  To the
extent that this biases IP storage against the use of security gateways,
it will make my life easier in dealing with the folks who want to make
absolutely sure that IP Storage uses end-to-end security, but I wanted
to make sure that the practical configuration consequences of this
approach were understood.

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: Paul Koning <[email-masked]>
Date: Mon, 4 Feb 2002 17:17:54 -0500 (EST)

>>>>> "BlackG" == Black David <[email-masked]> writes:

 BlackG> AFAIK, IPsec has no standard or widely deployed mechanism for
 BlackG> handling gateway discovery or address association
 BlackG> dynamically.

True.

But let's consider a very common IPsec deployment scenario.  I think
this is actually the predominant one, but let's not argue about that;
it certainly is quite common.

Scenario: two sites, each with an IPsec gateway, and an IPsec tunnel
set up between the two sites.  All traffic between the two sites goes
through the tunnel.  (This is the classic IPsec based VPN scenario.)

The way this is handled is simply by configuring the routing tables on
the two IPsec gateways to forward to the other site through the
tunnel.  As far as the other nodes on the two sites is concerned, the
other site is simply reachable via ordinary IP mechanisms, and the
existence of the tunnel, or the addresses used in the outer headers,
are none of its concern.  And of course the IP addresses of the inner
header cannot possibly equal those of the outer header in this
example.

This example MUST work.  So you cannot require inner == outer
address, because that translates into saying that IP Storage cannot be
protected by a site to site IPsec tunnel.

Now for a different case: if you use tunnel mode to protect traffic
for a single node (a common case for laptops, so this is often called
the "road warrior" case) then it may well be useful to allow inner ==
outer.  Some road warrior OS types will want that, others don't care
so much, so it can be a simplifying approach.  I have no objection at
all to saying that inner == outer is useful, and for that matter I can
go along with saying inner == outer should be supported.  But, either
way, inner != outer must be supported.

     paul

---

From: Paul Koning <[email-masked]>
Date: Mon, 4 Feb 2002 19:59:01 -0500

Addendum to my previous note about tunnels and IPsec gateways, because
the examples I gave don't make the issue clear.

The issue is: given how security gateways are used, is the inner
address == outer address restriction acceptable?

Consider a situation where a set of initiators are protected by a
(separate) IPsec gateway.  There are plenty of reasons for using that
setup: (1) lower cost than per-HBA high speed crypto, (2) centralized
security management is easier, (3) centralized security management is
required by organization policy, (n) etc.  On the other hand, the
target is an iSCSI node whose built-in IPsec is used.  (Perhaps it's
managed separately; perhaps since there is only one node is it
considered more sensible not to stick an IPsec gateway in front of
it.)  Let's assume that node doesn't need a separate outer IPsec
address. 

In that setting, the I->T packets will have innerDA == outerDA and
innerSA != outerSA, while the T->I packets will have innerSA == outerSA 
and innerDA != outerDA.

Note also that in this scenario it doesn't matter to the initiators
whether the target uses inner == outer.  The initiators talk to the
inner address of the target; only the IPsec gateway needs to know that
that traffic goes into the tunnel to the target, and what the outer
address for the tunnel is.  (And that has to be IPsec management, not
IPS management, since the IPsec gateway doesn't participate in any IPS
mechanisms.)

So in summary: since it's not acceptable to rule out the use of
separate IPsec security gateways at one end of an IPS connection, it
follows that you must allow inner != outer address.

	paul