RE: saag whyenc draft (was RE: Security Gateways)

["Williams, Jim" <Jim.Williams@emulex.com>]

> 
> 
> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Thursday, August 02, 2001 7:11 PM
> To: bill@strahm.net; ips@ece.cmu.edu
> Subject: saag whyenc draft (was RE: Security Gateways)
> 
> 
> 
> > I also want to be careful about products that are multi
> > gigabit products, but to be "standards compliant" include a software
> > encryption module that runs at 12 Mbit/Sec and is completely useless.  I
> > would rather have that product without security, so that I KNOW that the
> > security isn't there...
> 
> OTOH, this argument may have some merit, as I would definitely expect
> to see things like this sort of brain-damaged software encryption module
> if confidentiality becomes a "MUST implement".  Let me be clear that
> this applies only to confidentiality -- a small amount of thought about
> the consequences of impersonation and a script kiddie's TCP hijack attack
> leads to the conclusion that authentication and cryptographic integrity
> have to be "MUST implement" for iSCSI, FCIP, and iFCP.
> 
> Let us know the results of your discussion.
> 
> Thanks,  --David

I think with regards to both confidentiality and authentication (IPSec
authentication, not login authentication) one can expect three types
of implementations.

1.  Products that claim full RFC compliance in big letters with a 
    small foot note stating that an external gateway is required
    for compliance with the security section of the RFC.

2.  Products that claim full RFC compliance but drop to 1% normal
    throughput whenever security is enabled, and whose customers
    will buy an external gateway anyway when they want security.

3.  Products that can run security at full speed but which are
    not competative in terms of cost/performance with 1 and 2.

I don't have a problem with any of these, but I think it's critically
important that the security protocol for iSCSI doesn't preclude
options 1 and 2.  In terms of actual deployment, I suspect these
will be the most common.  A requirement for keying IPSec in
a way that is not compatable with existing security gateways
would be a serious setback to general acceptance of iSCSI, and
could potentially result in the emergence of a de facto standard
(no security) which diverges from the RFC standard (manditory 
security).  I don't think diverging standards are in anyone's
best interest, especially if there are practical ways to 
aviod it.