That helps to clarify it. I don't think that the draft
should require an administrative interface.
Jonathan
-----Original Message-----
From:
Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Monday, July 01, 2002 3:36 PM
To: jtrostle@corp.iready.com
Cc:
ips@ece.cmu.edu
Subject: RE: IPS-All: Reminder -
Security draft last call ends Monday,
Jul y 1 at 8am
EST
> When a target ends up in the negative authentication
cache, does
> that imply that the initiator will
not contact the target while
> it's in the cache,
or does it imply that the initiator can contact
> the target but should not use IPsec (if IPsec failed)? Or
shouldn't
> use app level security if app level
security failed?
The first - initiator will not contact the target while it's
in the
cache under the assumption that
authentication will just fail again.
As Bernard
wrote, this protects against a denial of service attack
where a rogue iSNS server in league with a rogue iSCSI target
causes
an initiator to repeatedly waste its time
trying to talk to the target.
Would it help to require an administrative interface to
clear entries
from the negative cache or the entire
cache?
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
---------------------------------------------------
-----Original Message-----
From:
Jonathan Trostle [mailto:jtrostle@corp.iready.com]
Sent: Monday, July 01, 2002 6:17 PM
To: 'Bernard Aboba'
Cc:
'ips@ece.cmu.edu'
Subject: RE: IPS-All: Reminder -
Security draft last call ends Monday, Jul y
1 at 8am
EST
When a target ends up in the negative authentication cache,
does that imply
that the initiator will not contact
the target while it's in the cache, or
does it
imply that the initiator can contact the target but should not use
IPsec (if IPsec failed)? Or shouldn't use app level
security if app level
security failed?
Jonathan
-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Saturday, June 29, 2002 10:42 PM
To: jtrostle@corp.iready.com; ips@ece.cmu.edu
Subject: RE: IPS-All: Reminder - Security draft last
call ends Monday,
July 1 at 8am EST
>One comment/question on the security draft below:
>
>p. 23: "Where iSNS
is used without security, IP block storage protocol
>implementations MUST support a negative cache for authentication
>failures."
>
>Is it worth pointing out that when iSNS is used
with security, then a
>negative cache MUST NOT be
used? An attacker can cause authentication >to
>fail through a DoS attack which could result in an entry being
>added to
>the negative cache.
There are two orthogonal issues here -- one is iSNS
security, the other is
IPS protocol security. If
iSNS is not secured, then a peer might receive and
accept an iSNS packet from a rogue iSNS server. However, if
the IPS session
is subsequently secured, and
mutually authenticated, the endpoint specified
in
the bogus discovery message will fail to authenticate. The argument is
that this should result in a negative cache entry
within the iSNS
implementation, so as to prevent
continual attempts to authenticate to bogus
peers.
If iSNS is secured, then
presumably this would preclude a rogue iSNS server,
and the negative cache is unnecessary.
Do you have an issue with the negative cache in general, or just its
use
where iSNS is secured?
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
