Subject: Re: IPsec Usage Question

From: Paul Koning <[email-masked]>
Date: Fri, 1 Feb 2002 10:50:02 -0500

Excerpt of message (sent 31 January 2002) by [email-masked]:
> In Salt Lake City, I asked folks to become familiar with
> existing IPsec implementations that they plan to (re)use.  I
> now have a specific question about this that I need answers
> to - send the answers to me directly to avoid inadvertently
> revealing implementation plans (I promise to keep them
> private).
> 
> Q: Does the IPsec implementation you plan to use require
> 	that the inner IP address be different from the outer
> 	IP address for traffic that is to pass through IPsec
> 	to the IP Storage (iSCSI, iFCP, FCIP) system?
> Follow-up: If so, how do you plan to configure your system
> 	to securely access a peer IP Storage system from
> 	another vendor that also has this requirement?
> 
> The underlying concern is that requiring that the inner
> and outer IP addresses always be the same would visibly
> simplify the configuration required to use IPsec with
> the IP Storage protocols.

I'm not sure if this is what you intended, but I'm reading this to say
that IPsec as used with IP Storage would mandate the same IP addresses
on inner and outer header.

If so, that is equivalent to prohibiting external security gateways.
This is not good.  I understand that there are people who feel that an
external security gateway is not necessarily the right way to address
security concerns in IP Storage.  But that's a long way from
prohibiting their use entirely.

If that wasn't your intent, could you clarify what you're after?  If
the goal is to *permit* inner == outer, that's fine.  That's commonly
supported because that situation occurs when you tunnel from a single
host to a site protected by an IPsec gateway.  And yes, allowing inner
== outer in that case indeed makes things slightly easier.

     paul

---

From: [email-masked]
Date: Fri, 1 Feb 2002 13:14:25 EST

I can see the existence of an external security gateway as critical to make 
these protocols viable and support real configs. So, I agree that we should 
not mandate the inner and outer IP address to be same...it can be an option, 
and that would be fine. I can see the external security gateways to be 
necessary even for the FCiP and iFCP environments - unless I am missing 
something here...

Subject: RE: IPsec Usage Question
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Date: Fri, 1 Feb 2002 11:13:05 -0500

> == outer in that case indeed makes things slightly easier.

Mandating the same addresses in the inner and outer header is a "big
hammer" that may not be the right course of action.  OTOH, if one
needs to know both the inner and outer IP addresses in order to contact
a target, that has implications for the functionality/usage of Send
Targets, iSNS, and SLP.  My underlying goal is to figure out whether
we need to put support for two IP addresses per target into those
configuration mechanisms (this would apply to FCIP, iFCP, and iSCSI).

I intended to raise the possibility of mandating the same addresses
in the inner and outer header as a possibility as opposed to proposing
it as a course of action as I don't have enough info about what folks
intend to do/think is important to make any proposal in this space.
Paul's input that this would be a bad idea because it would implicitly
ban the use of security gateways is a fine response to that possibility
- and to his credit, Paul was right about the last IPsec-related issue
he brought up (dangling SAs).

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: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Fri, 1 Feb 2002 16:28:04 -0800

I agree with Paul, the association of *any* internal network address to any
external mapping is  an IPSec configuration concern!  To state that another
way, that is a generic IPSec security gateway configuration detail.  I can't
speak for iSNS, but this information does *not* belong in the SendTargets
command or the iSCSI portion of SLP!  That very notion violates
architectural layering principals - iSCSI has no need to know about IPSec
headers which will be stripped off before the iSCSI processing layer
receives the packet.

It is true that security gateways in general have implications to the
accessability of *every* service behind that gateway.  But the solution does
not lie in sprinkling pieces of the IPSec configuration into all of those
service configuration mechanisms!  As Paul suggests, this should be handled
by the IPSec configuration management tools.

We've already agreed that sendTargets should contain only information
directly related to iSCSI configuration (knowledge within the iSCSI
"entity") - see this thread
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg04944.html  Just say No! to
feature creep... :-)

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: [email-masked] 

> -----Original Message-----
> From: Paul Koning [mailto:[email-masked]]
> Sent: Friday, February 01, 2002 12:54 PM
> To: [email-masked]
> Cc: [email-masked]
> Excerpt of message (sent 1 February 2002) by [email-masked]:
> Managing the mapping from the inner address to the outer address is
> a function of IPsec management -- that's the policy database which
> defines which host traffic is protected by what tunnel.
> 
> It's tempting to try to avoid IPsec management by addressing
> restrictions such as you mentioned here, but that does not help.
> There are about a dozen parameters for an IPsec SA, and you can't
> hardware all of them in the standard.  Trying to attack this by the
> restriction you proposed, even if feasible, only takes care of a
> fraction of the IPsec management you need.
> 
> I would think that IP Storage mechanisms such as Send Targets or iSNS
> should concern themselves with storage, not with other components like
> IPsec.  So yes, you need IPsec management (including tunnel
> addressing) but no, it's not the job of IP Storage mechanisms to
> administer those parameters.
> 
>      paul
>

---

From: Joshua Tseng <[email-masked]>
Date: Fri, 1 Feb 2002 17:56:39 -0800

Knowledge of the gateway IP address (first-hop address) is a
common requirement for all IP hosts, not just iSCSI hosts.
In fact, this is information relevant only to the IP
layer below iSCSI.  

If a security gateway were front-ending an iSCSI device in 
a single box, I would imagine the gateway's IP address would
be the first-hop address for the IP configuration.  But once
again, this is below iSCSI and doesn't need to be known to
iSCSI.

I therefore don't see why iSCSI needs to be conscious of the
security gateway's address.  And I agree it's best to keep
this out of sendtargets, iSNS, and SLP.

Josh

> From: CAVANNA,VICENTE V (A-Roseville,ex1)
> [mailto:[email-masked]]
> Sent: Friday, February 01, 2002 4:53 PM
> To: [email-masked]'; 'Paul Koning'
> Cc: [email-masked]; THALER,PAT (A-Roseville,ex1)
> I agree with Paul Koning's comments on this topic; in particular his
> observation that forcing the inner and outer IP addresses to 
> be the same
> forces the security tunnel endpoint to be the same as the 
> communication
> endpoint and thus precludes implementing security in an 
> entity other that
> that which originated the packet. I am one of those who think an IPSEC
> tunnel to a gateway and then an unsecured path to the storage 
> device is not
> enough security for storage traffic but the reality is that 
> this may be the
> only security available initially.
> 
> In fact it is possible that we have nested tunnels and we may 
> be dealing
> with more than two IP addresses.
> 
> I therefore do not agree with mandating both IPs to be the same.
> 
> It seems inevitable to me that if security is implemented by 
> a gateway in
> the path to a storage server, that the clients need to be 
> aware of its IP
> address as well as the IP of the storage server and as Paul 
> has pointed out
> this is a function of Security Policy management.
> 
> Vince Cavanna
> Agilent Technologies
> 
> |-----Original Message-----
> |From: [email-masked] [mailto:[email-masked]]
> |Sent: Friday, February 01, 2002 8:13 AM
> |To: [email-masked]
> |Cc: [email-masked]
> |Subject: RE: IPsec Usage Question
> |
> |
> |> Excerpt of message (sent 31 January 2002) by [email-masked]:
> |> > In Salt Lake City, I asked folks to become familiar with
> |> > existing IPsec implementations that they plan to (re)use.  I
> |> > now have a specific question about this that I need answers
> |> > to - send the answers to me directly to avoid inadvertently
> |> > revealing implementation plans (I promise to keep them
> |> > private).
> |> > 
> |> > Q: Does the IPsec implementation you plan to use require
> |> > 	that the inner IP address be different from the outer
> |> > 	IP address for traffic that is to pass through IPsec
> |> > 	to the IP Storage (iSCSI, iFCP, FCIP) system?
> |> > Follow-up: If so, how do you plan to configure your system
> |> > 	to securely access a peer IP Storage system from
> |> > 	another vendor that also has this requirement?
> |> > 
> |> > The underlying concern is that requiring that the inner
> |> > and outer IP addresses always be the same would visibly
> |> > simplify the configuration required to use IPsec with
> |> > the IP Storage protocols.
> |> 
> |> I'm not sure if this is what you intended, but I'm reading 
> |this to say
> |> that IPsec as used with IP Storage would mandate the same IP 
> |addresses
> |> on inner and outer header.
> |> 
> |> If so, that is equivalent to prohibiting external security 
> gateways.
> |> This is not good.  I understand that there are people who 
> |feel that an
> |> external security gateway is not necessarily the right way 
> to address
> |> security concerns in IP Storage.  But that's a long way from
> |> prohibiting their use entirely.
> |> 
> |> If that wasn't your intent, could you clarify what you're 
> after?  If
> |> the goal is to *permit* inner == outer, that's fine.  
> That's commonly
> |> supported because that situation occurs when you tunnel 
> from a single
> |> host to a site protected by an IPsec gateway.  And yes, 
> |allowing inner
> |> == outer in that case indeed makes things slightly easier.
> |
> |Mandating the same addresses in the inner and outer header is a "big
> |hammer" that may not be the right course of action.  OTOH, if one
> |needs to know both the inner and outer IP addresses in order 
> to contact
> |a target, that has implications for the functionality/usage of Send
> |Targets, iSNS, and SLP.  My underlying goal is to figure out whether
> |we need to put support for two IP addresses per target into those
> |configuration mechanisms (this would apply to FCIP, iFCP, and iSCSI).
> |
> |I intended to raise the possibility of mandating the same addresses
> |in the inner and outer header as a possibility as opposed to 
> proposing
> |it as a course of action as I don't have enough info about what folks
> |intend to do/think is important to make any proposal in this space.
> |Paul's input that this would be a bad idea because it would 
> implicitly
> |ban the use of security gateways is a fine response to that 
> possibility
> |- and to his credit, Paul was right about the last 
> IPsec-related issue
> |he brought up (dangling SAs).
> |
> |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: "CAVANNA,VICENTE V (A-Roseville,ex1)" <[email-masked]>
Date: Tue, 5 Feb 2002 10:40:07 -0700

Hi Ofer

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

Could you elaborate on this. Why would such devices be in violation of the
iSCSI spec? 

Thanks.

Vince

|-----Original Message-----
|From: Ofer Biran [mailto:[email-masked]]
|Sent: Monday, February 04, 2002 9:30 PM
|To: Paul Koning
|Cc: [email-masked]; [email-masked]; [email-masked]
|Subject: RE: IPsec Usage Question
|
|
|
|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: "Ofer Biran" <[email-masked]>
Date: Tue, 5 Feb 2002 23:12:19 +0200

Paul,

I only meant that the 2-site tunnel scenario has nothing to do with the
IPsec protection mandated to be implemented (yes, implemented,
not used) by iSCSI.  So I would not use this scenario at all to conclude
about iSCSI security requirements (outer=inner etc.).

  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 18:52:28

Sent by:  [email-masked]

To:   Ofer Biran/Haifa/IBM@IBMIL
cc:   [email-masked], [email-masked], [email-masked]
Subject:  RE: IPsec Usage Question

Excerpt of message (sent 5 February 2002) by Ofer Biran:
>
> 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.

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

---

From: "Ofer Biran" <[email-masked]>
Date: Tue, 5 Feb 2002 23:19:25 +0200

Vince,

I meant in case "that's their only IPsec protection",
i.e., you can combine your iSCSI with IPsec gateway/device and
the box would be compliant. The 2-site tunnel scenario doesn't
indicate if they are compliant or not - it's simply not relevant, and
doesn't contribute to their compliance.

  Regards,
      Ofer

Ofer Biran

"CAVANNA,VICENTE V (A-Roseville,ex1)" <[email-masked]> on
05/02/2002 19:40:07

To:   Ofer Biran/Haifa/IBM@IBMIL
cc:   [email-masked], [email-masked], [email-masked], Paul
      Koning <[email-masked]>
Subject:  RE: IPsec Usage Question

Hi Ofer

|

Thanks.

Vince

---

From: [email-masked]
Date: Tue, 5 Feb 2002 19:08:46 -0500

IMHO, both Ofer and Paul appear to be right, so let me
attempt to explain ...

We cannot place general constraints on the extent of an IPsec
implementation that happens to be used for IP Storage -
if someone wants to implement full IPsec (e.g., additional
ciphersuites, IKE ID payloads) and use that functionality to
talk to security gateways that are not part of IP Storage
implementations, there's nothing we can do to stop this ...
and we probably should encourage this sort of thing.

The upshot is that the implementation requirements and
usage requirements/restrictions being placed on IPsec for
securing IP Storage protocols apply only to SAs that have
an IP Storage system (e.g., a security gateway that is
part of an IP Storage system) at both ends.  I don't
believe that either of Paul's examples fall into this category
as he described them, hence neither would be prohibited by what
we do here, and I agree with Ofer that at least Paul's VPN
scenario should not be used to motivate iSCSI security
requirements.

OTOH, Paul's second example could fall into this category if
one considered an iSCSI system consisting of multiple initiators
bundled with a security gateway, and based on that example,
I'm inclined to agree with Paul's contention that requiring
inner IP addresses to match outer IP addresses would be a
mistake.

The fact that IPS usage requirements/restrictions for IPsec
only apply to SAs that have IPsec implementations that are
part of IP Storage systems at both ends probably needs to be
stated somewhere for clarity to avoid others jumping to the
conclusion that an IPsec implementation used for IP Storage
cannot use additional features when talking to a peer that
is not an IP Storage system.

Thanks,
--David

> From: Ofer Biran [mailto:[email-masked]]
> Sent: Tuesday, February 05, 2002 4:12 PM
> To: Paul Koning
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: "Ofer Biran" <[email-masked]>
Date: Mon, 11 Feb 2002 22:32:06 +0200

Paul,

"2-site tunnel scenario" is not exactly "2-tunnel scenario". It all
started with my response to your original scenario:

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

But then you resent anyway more suitable scenarios, so I don't think we
have any real disagreement.

   Regards,
      Ofer

Ofer Biran

Paul Koning <[email-masked]> on 11/02/2002 16:34:05

cc:   [email-masked]

>>>>> "Ofer" == Ofer Biran <[email-masked]> writes:

 Ofer> Paul,

 Ofer> I only meant that the 2-site tunnel scenario has nothing to do
 Ofer> with the IPsec protection mandated to be implemented (yes,
 Ofer> implemented, not used) by iSCSI.  So I would not use this
 Ofer> scenario at all to conclude about iSCSI security requirements
 Ofer> (outer=inner etc.).

What 2-tunnel scenario?

My scenario is a one-tunnel scenario, where one end of the tunnel
terminates an an iSCSI device and the other terminates at an IPsec
gateway.  That's a perfectly standard tunnel configuration.  In fact,
it's the most obvious example of why tunnel mode support (in addition
to transport mode) is required for IPsec hosts.

In that scenario, you can have inner==outer for one of the endpoint
addresses (the host) but not for the other.

Unless it is your goal to disallow IPsec gateways talking to iSCSI
devices, you have to support this configuration if you're going to
support IPsec at all.

     paul