SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: Proxies (was Security in iSCSI)



    David,
    
    I agree with every point you make wholeheartedly and I thing that we should
    not have
    had to deal with them to begin with. But I want this decision to be stated
    as clear as possible
    and not become an issue for a long debate at the last call.
    Your change of subject line goes  in this direction.
    
    Julo
    
    Black_David@emc.com on 23-08-2001 20:14:30
    
    Please respond to Black_David@emc.com
    
    To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
    cc:
    Subject:  iSCSI: Proxies (was Security in iSCSI)
    
    
    
    Julian,
    
    > You seem to missing my main point. I am ready to take out the
    > table but not the general notion of a cryptographic digest.
    > To do the later I have to have the community understand that
    > their are left with no protocol provided means to authenticate
    > data that pass through iSCSI proxies.
    
    Actually, I was hoping that you weren't going there.  Just when
    one thinks one has obtained a good understanding of a network
    technology/protocol/solution/etc., adding the notion of proxies
    is almost certain to restore the previous state of confusion.
    Multicast also has this property, but fortunately, I haven't
    seen anyone in the WG take any serious interest in it (and
    woe betide anyone who takes this as an invitation ;-) ).
    
    My primary concern is one of schedule - if full support for
    proxies is a requirement for the first version of the iSCSI
    RFC, the schedule guesstimate I posted yesterday is probably
    optimistic by 6+ months.  Issues that come up in the area of
    proxies that will take a while to resolve will likely include:
    
    - What's the right scope of proxy support?  How much
         consideration for SCSI level proxies to which other
         transports needs to be reflected in the iSCSI standard?
    - SCSI is not an end-to-end transport independent protocol.
         T10 had the opportunity to go in this direction in the
         SCSI GPP work) and chose not to do so. Extensive iSCSI
         work on proxies risks running into SCSI architecture,
         and our experience with ACA suggests that they'll take
         a while to resolve.
    - Security interaction with proxies is a very complicated
         subject.  IPsec and NATs is a well-known tarpit that
         is finally getting resolved years later.  I hesitate
         to promise that the iSCSI proxy issues will be significantly
         simpler by comparison.
    - There is precedent for proxies adapting to the requirements
         of protocols - TLS requires http proxies to accommodate
         it rather than the other way around.  Whether proxies
         should drive iSCSI security architecture or iSCSI
         security architecture should drive proxy design will
         at the minimum be fodder for serious debate.
    
    If we want to get the iSCSI spec done in a reasonable timeframe,
    I suggest closing the lid on this Pandora's box labeled
    "proxies" and deferring serious work on iSCSI proxy support
    to a future revision.  The separate header and data CRCs are a
    useful step towards making life better for those who want to
    build proxies, but I hesitate to go much further in that
    direction, particularly in the area of security.  As things
    currently stand, one way to authenticate data passing through
    an iSCSI proxy is to have the iSCSI proxy participate in the
    authentication which seems like an acceptable situation (and
    one that has a straightforward security explanation).
    
    Comments?
    
    Thanks,
    --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
    ---------------------------------------------------
    
    
    
    


Home

Last updated: Tue Sep 04 01:03:55 2001
6315 messages in chronological order