Subject: RE: IPsec Usage Question

From: "Ofer Biran" <[email-masked]>
Date: Tue, 5 Feb 2002 07:29:34 +0200

Paul,

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

This is not Kansas any more... The iSCSI devices on both sites (assuming
that's their only IPsec protection) are not iSCSI compliant. This
definitely
doesn't cover the IPsec protection mandated by iSCSI.

  Regards,
    Ofer

Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
[email-masked]  972-4-8296253

Paul Koning <[email-masked]>@ece.cmu.edu on 05/02/2002 00:17:54

Sent by:  [email-masked]

To:   [email-masked]
cc:   [email-masked], [email-masked]
Subject:  RE: IPsec Usage Question

>>>>> "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: Tue, 5 Feb 2002 11:52:28 -0500

> doesn't cover the IPsec protection mandated by iSCSI.

No, you're mistaken.

I said nothing about what the iSCSI devices IMPLEMENT.  I only talked
about what was IN USE by the customer.  In the example, the customer
chose to USE a different security mechanism for reasons of cost,
convenience, site policy, or whatever.

Remember that the proposed requirement is "required to implement" and
NOT "required to use".

My interpretation of having "use" be optional is that you also have
the option of securing your traffic via other means.  

Am I right?  Or is it the intent of the WG to say that no other
security mechanisms are allowed -- if you want security you MUST use
the one that is mandated in iSCSI nodes?  If so, for what reason?

    paul