Subject: RE: [Ips] iSNS and iSCSI config

From: [email-masked]
Date: Thu, 19 May 2005 08:09:51 -0400

Bill,

Additionally, the IPSec info available via iSNS fills in the 'gaps' left by
rfc3723.

Meaning two endpoints won't successfully talk if they don't agree on pfs,
ike mode, etc.

The iSNS traffic itself can be protected with ipsec.

So I think that iSNS is an excellent solution, IMO.

Thanks,
Steve

-----Original Message-----
From: Josh Tseng [mailto:[email-masked]] 
Sent: Wednesday, May 18, 2005 11:39 PM
To: William Studenmund; [email-masked]
Cc: [email-masked]
Subject: Re: [Ips] iSNS and iSCSI config

> 
> I think it would be a bad idea for iSNS to be used to distribute 
> security configuration parameters. While I realize it will make life 
> more difficult for a system with a lot of targets and/or initiators, I 
> think any sort of security configuration distribution system should be 
> designed as-such from the ground up. I am not aware that iSNS was 
> designed as such, and so I think it would be a very inappropriate tool 
> for distributing security configuration information.
> 

Hi Bill,

iSNS is a specification; whether a specific iSNS server is secure enough to
be used for communicating security policies really is an implementation
question.  But if the iSNS server is implemented in a secure manner, I don't
see why security policies couldn't be communicated through iSNS.  It can cut
down on unnecessary IKE handshakes and thus improve response time for new
iSCSI devices connecting into the network.

Josh

> Take care,
> 
> Bill
> > _______________________________________________
> Ips mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ips
> 

Discover Yahoo! 
Find restaurants, movies, travel and more fun for the weekend. Check it out!

http://discover.yahoo.com/weekend.html 

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: [email-masked]
Date: Fri, 20 May 2005 10:12:50 -0400

Just as a final note, rfc3723 informs that (2.6.2), 
"Once communication between iSNS clients and the iSNS server are
secured through use of IPsec, iSNS clients have the capability to
discover the security settings required for communication via the
iSCSI and/or iFCP protocols. Use of iSNS for distribution of
security policies offers the potential to reduce the burden of manual
device configuration, and decrease the probability of communications
failures due to incompatible security policies. ... "

So I think iSNS has a real, practical application here.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernard Aboba
Sent: Friday, May 20, 2005 1:49 AM
To: [email-masked]
Subject: Re: [Ips] iSNS and iSCSI config

>I think any sort of security configuration distribution system should 
>be designed as-such from the >ground up. I am not aware that iSNS was 
>designed as such, and so I think it would be a very >inappropriate tool 

Ironically existing "security configuration distribution systems" designed
"from the ground up"  are inferior to iSNS in terms of ease of  use, 
reliability, interoperability, and in the end, security.   They are inferior

in terms of ease of use because they have to provide for a wide array of
configuration options and usage scenarios, most of which are not allowable 
in IP storage security.   One of the explicit goals of RFC 3723 was to 
dramatically simplify security configuration by reducing the range of
potential configurations.

Existing mechanisms are often unreliable because they don't support
transaction semantics and can therefore replicate incomplete configurations.

  They are non-interoperable because there are no standard protocols
designed to solve the general security configuration problem.  And they are
ultimately insecure, because they have not been subjected to security
review, and are difficult to configure correctly.

>iSNS is a specification; whether a specific iSNS server is secure 
>enough to be used for communicating security policies really is an 
>implementation question.  But if the iSNS server is implemented in a 
>secure manner, I don't see why security policies couldn't be 
>communicated through iSNS.  It can cut down on unnecessary IKE 
>handshakes and thus improve response time for new iSCSI devices 
>connecting into the network.

Indeed. iSNS was designed to provide secure "plug and play" configuration
for storage systems.  In general, it provides configuration at the
appropriate level of detail,  utilizes standardized security mechanisms,
provides reliable configuration, and can operate at scale.

As a result, I think one can argue that iSNS is a better match to the
security configuration problems of IP storage than any general purpose
security policy configuration mechanism that exists today.