Subject: [Ips] iSNS and iSCSI config

From: [email-masked]
Date: Wed, 18 May 2005 16:41:26 -0400

I have a couple of question regarding usage of iSNS for iSCSI configuration.

In the IPSec area:

1) Is there provision for storing a pre-shared key ?
2) Is there provision for storing the tunnel gateway for esp tunnel mode ?

I looked thru 'draft-ietf-ips-isns-22.txt' and did not see this info.

Thanks in advance,
Steve

Steve Yackey
EMC2 Corporation
1401 Main Street, Suite 350
Columbia, SC 29201
803-231-2632

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

---

From: William Studenmund <[email-masked]>
Date: Wed, 18 May 2005 15:12:07 -0700

> 2) Is there provision for storing the tunnel gateway for esp tunnel 

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.

Take care,

Bill

---

From: Josh Tseng <[email-masked]>
Date: Wed, 18 May 2005 20:24:13 -0700 (PDT)

The answer to both of these questions is 'no' if you
are restricted to the existing IANA-defined
attributes.  However, nothing prevents you from
creating your own private attributes to do either,
although you should consider the security implications
of doing so.

Josh

> https://www1.ietf.org/mailman/listinfo/ips

__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo

---

From: Josh Tseng <[email-masked]>
Date: Wed, 18 May 2005 20:38:49 -0700 (PDT)

> 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

> 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

---

From: "sundara senthil" <[email-masked]>
Date: Thu, 19 May 2005 17:26:48 +0530

Hi All,

 According to the iscsi RFC 3720, mentioned in the section  5.2

"Any key not understood by the acceptor may be ignored by the
acceptor without affecting the basic function. However, the answer
for a key not understood MUST be key=NotUnderstood."

I would like to know that if initiator sends any invalid key name and a value
pair to the iscsi target, should the target  ignore the key pair
without responding or target should respond as invalid key=NotUnderstood.

Thanks
sundar

Disclaimer:

This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies and its customers, privileged or otherwise protected by law. The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer.

---

From: William Studenmund <[email-masked]>
Date: Thu, 19 May 2005 09:39:16 -0700

> 2) Is there provision for storing the tunnel gateway for esp tunnel 

Actually, in re-reading this more, I don't think there is any way 
storing a tunnel address would work; if iSNS indicates preferring 
tunnel mode, you should be establishing tunnel mode to the portal; the 
portal address already is the "gateway" address.

To try to have iSNS include any sort of other esp tunnel gateway would 
require either a lot of knowledge about the intervening network, and 
would need it in the iSNS server. iSNS doesn't convey enough 
information to tell the server what is between the initiator and 
target, so some sort of magic would have to happen. While I can 
envision topologies where it would work out, I don't think they are the 
common case intended for iSNS.

Take care,

Bill

---

From: William Studenmund <[email-masked]>
Date: Thu, 19 May 2005 09:44:19 -0700

> response time for new iSCSI devices connecting into

If we're just talking publicly-available info, then you're right. And 
the stuff in iSNS now is fine. However the initial question, to which I 
was overly-broadly replying above, was asking about distributing 
pre-shared keys.

iSNS is not a pre-shared key distribution protocol. :-)

Take care,

Bill

---

From: William Studenmund <[email-masked]>
Date: Thu, 19 May 2005 15:55:15 -0700

> without responding or target should respond as invalid 

The acceptor (the target could have made the initial offer, after all) 
must reply "invalid_key-NotUnderstood".

Note however that we are assuming the unknown key came with some sort 
of conceivably reasonable initial offer. If the initial offer were 
something like "Reject", "Irrelevant", or "NotUnderstood", then there 
is a protocol error. I'd recommend closing the connection.

Take care,

Bill

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 19 May 2005 22:49:27 -0700

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

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.

>response time for new iSCSI devices connecting into

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.