RE: IPsec Usage Question

["CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>]

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: Black_David@emc.com [mailto:Black_David@emc.com]
|Sent: Friday, February 01, 2002 8:13 AM
|To: ni1d@arrl.net
|Cc: ips@ece.cmu.edu
|Subject: RE: IPsec Usage Question
|
|
|> Excerpt of message (sent 31 January 2002) by Black_David@emc.com:
|> > 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
|black_david@emc.com         Cell: +1 (978) 394-7754
|---------------------------------------------------
|