RE: iSCSI: Stand alone SAN network configuration change notice.

["Douglas Otis" <dotis@sanlight.net>]

David,

Would you describe DNS using UDP as a reliable transport?  A simple single
packet request and response?  The EnterpriseSpecific Trap with SNMP on UDP
port 162 could be used.  How would you implement acknowledgement?  Would you
generate another trap indicating some expected action was not seen at some
interval?  With all the 'below the transport' filtering being suggested for
various IPS protocols, I tend to loose track as where to place these within
the general scheme but I am happy to accept your clue-by-four. :)  I need
all the clues I can get and found your input beneficial.  My concerns within
the statement to Ran was reflecting on his bashing of the methods of
establishing security together with my perception of an indicated need to
change every protocol (which generated this thread).  I am waiting for
further clarifications within the next iteration of iSCSI to see how Ran's
bullets are dodged.  I saw my suggestion of an added ICMP signal as the
lesser of the evils with an easy UDP back door.  Equipment likely to be
generating these messages will be interested in communicating to the general
machine (server) rather than any particular application and not likely tied
directly to the end points of the transport.  I do not see these messages
directly associated with any IPS transport, but rather a general network
status notification.  I tend to view that level of communication rightfully
done using the venerable ICMP.  That I see as the norm, but I could be
wrong.

RFC1157:
4.1.6.7.  The enterpriseSpecific Trap
   A enterpriseSpecific(6) trap signifies that the sending protocol
   entity recognizes that some enterprise-specific event has occurred.
   The specific-trap field identifies the particular trap which
   occurred.

Doug


> > If you feel ICMP is off the table, then consider this suggestion as a
> > general signaling mechanism using UDP.
>
> Like SNMP Notifications?  I'd suggest looking there as one possibility.
>
> > Although the affected programs may
> > be at the application level, the change notification would be changes in
> > assignments or function within the physical networks through a
> SAN bridge,
> > router or switch.  The suggestion that I made included notice
> and reply to
> > overcome your delivery concern.
>
> In other words, a new reliable delivery mechanism.  That's not likely to
> make it through the transport ADs.
>
> > If you look at RFC2521 (1999 experimental)
> > you will see ICMP used to signal security failures.
>
> That's for IPsec, which is layer 3, whereas all the IPS protocols
> are layer
> 5.
> The fact that this can be made to work doesn't make it a good design
> decision from an architectural standpoint.
>
> > As the server and the
> > SAN network is likely inside the firewall, there should be few
> such issues
> > related to ICMP for this type of signaling concerning IPSec and may be
> > viewed as a feature.
>
> Definitely a bad design assumption.  IPS protocols will almost certainly
> run over VPN links that are implemented by IPSec security gateways,
> and ICMP has a poor track record of interaction with such gateways.
>
> >  I have no trouble
> > looking elsewhere such as UDP but I must say I do not agree with your
> > conclusions.  Considering such a signaling mechanism may impact the
> various
> > transports if such signaling is standardized, reflector bandwidth should
> not
> > be a major concern to resolve if changing existing network services are
> the
> > best solution or if a more general and simpler scheme may be of greater
> > utility.
>
> In case I'm not making myself clear - I have no problem with work on
> notification issues and use of the reflector to explore solutions (e.g.,
> see my previous comments on iSNS's ability to handle this).  My issue
> is solely with ICMP - extending it is not an appropriate approach to this
> area and hence I am strongly advising the WG to look elsewhere.
>
> Considering Doug's past complaint that:
>
> 	It would seem that IPS can do anything out of the architectural norm
> they
> 		desire
>
> I'm quite surprised to find Doug pushing something that is clearly
> "out of the architectural norm".  Do I need to get out a bigger
> clue-by-four?
>
> --David
>
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>
>