Subject: RE: Security Gateways

From: [email-masked]
Date: Wed, 1 Aug 2001 19:42:24 -0400

Bob,

An RFC does not tell anyone what can or cannot be built;
it specifies what is required for compliance with the RFC.
If someone builds a protocol implementations that doesn't
comply with the requirements of the RFC, they should not
expect to be able to claim RFC compliance for devices 
based on that implementation.

> The marketplace does demand that
> security be possible and available for a device.  

The compliance requirement here is that "possible and
available" be realizable without having to add anything
to the device.  For the structure of interest here,
an FCIP device plus a security gateway, the complete system
[FCIP device, cable, security gateway] would comply with
the FCIP RFC at its external interface (i.e., the external
interface of the security gateway).  The interface between
the FCIP device and the security gateway would be missing
some required security functionality and hence would
not comply with the RFC.  As a result, the FCIP device by
itself would not comply with the RFC.

> I can understand why the IESG would push back on this
> question, but I would expect that they also believe that
> an FCIP device without optional security implemented
> is still an FCIP device and is compliant with the FCIP RFC. 

If "optional" means "MUST implement, but MAY use", that
expectation would be incorrect.  "MUST implement" (cf.
RFC 2119) is the level of requirement for authentication
and cryptographic integrity that is necessary for FCIP
to be approved as an RFC.  This isn't just "push back"
from the IESG - it is a condition that the IESG required
for its original approval of the IPS WG charter.

> With an edge security device installed 
> in front of it, it is also a
> secure FCIP device, just like the end-point of a 
> virtual private network is a secure device. 

That combination will comply with the RFC.  OTOH, the
IESG will not permit the FCIP RFC to allow an FCIP device
that lacks the basic security mechanisms to be compliant,
and hence the FCIP device *without* the edge security
device will not comply.

> By definition, "man in the middle" attacks are impossible
> for a security edge device, since the only place that the
> "man in the middle" can be placed is in the encrypted path.

"By definition" is not the best wording.  Assuming that the
"security edge device" is an IPsec security gateway, the IKE
and ISAKMP  protocols are to negotiate security functionality
and parameters; those protocols are resistant to man-in-the-
middle attacks, but that resistance is based on careful design.

--David

> -----Original Message-----
> From: Robert Snively [mailto:[email-masked]]
> Sent: Wednesday, August 01, 2001 6:25 PM
> To: [email-masked]'; Robert Snively; [email-masked]
> Subject: RE: Security Gateways
> 
> 
> David,
> 
> I believe this is really a very difficult question, not
> susceptible to a simple SHALL/SHALL NOT response.  
> The technology absolutely allows and encourages
> security edge devices and absolutely allows devices using
> TCP and other protocols to exploit those edge devices or
> not as the system administrator requires.  The marketplace
> absolutely demands those capabilities.  A significant percentage
> of the internet economy is based on separately supplied security.
> I understand that the IETF
> has no interest in devices that are solely for closed
> environments, but the marketplace does not demand that
> a device have security built in to qualify for compliance with a
> protocol.  The marketplace does demand that
> security be possible and available for a device.  
> 
> That is what we have been proposing.
> 
> By definition, "man in the middle" attacks are impossible
> for a security edge device, since the only place that the
> "man in the middle" can be placed is in the encrypted path.
> The physically secured path has no possibility of an
> entry point for such an attack.  
> 
> I can understand why the IESG would push back on this
> question, but I would expect that they also believe that
> an FCIP device without optional security implemented
> is still an FCIP device and is compliant with the FCIP RFC. 
> This should be true whether the TCP path is based on IP,
> HIPPI, IB, a proprietary backplane or any other transport 
> that supports TCP. With an edge security device installed 
> in front of it, it is also a
> secure FCIP device, just like the end-point of a 
> virtual private network is a secure device. 
> 
> That is what we would like the RFC to say.
> 
> Bob
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, August 01, 2001 10:13 AM
> To: [email-masked]; [email-masked]
> Subject: RE: Security Gateways
> 
> 
> Bob,
> 
> You've made a good case for "optional to use", but not
> "optional to implement".  The basic reason is that there
> is no way to ensure that vendors and/or users will
> restrict the use of an implementation that does not
> include security to situations where "paths of a
> storage environment are physically secured and have 
> no requirement for additional security mechanisms".
> Hence security needs to be present so that it
> can be used when FCIP is deployed in an environment
> that requires security.  Further, the IETF has no
> interest in specification of protocols that are
> *solely* for use in the sort of closed environment
> that you describe, and the IPS WG charter contains
> explicit words to that effect.
> 
> Therefore, the basic FCIP security mechanisms MUST be
> implemented, but usage MAY be negotiated.  At the moment,
> "basic security mechanisms" means authentication and
> cryptographic integrity.  Confidentiality can currently
> be optional to implement, but I think it's a very good
> idea to specify the basic confidentiality mechanism
> (*if* confidentiality of any form is implemented, *then*
> <XXX> MUST be implemented).  The design and specification
> of any negotiation mechanism must resist man-in-the-middle
> attacks on negotiation that would result in turning off
> security where that was not the intended outcome - such
> an approach can include restrictions on implementation
> behavior (e.g., if "no authentication" is not acceptable,
> do not offer or accept it during negotiation).
> 
> If the FCIP draft is sent to the IESG without requiring
> implementation of the basic security mechanisms, it will
> be returned to the WG with instructions to correct
> that shortcoming, along with some choice words from the
> ADs wondering how the WG chairs could have overlooked
> something like this.  As a result, an FCIP draft that
> does not require implementation of the basic security
> mechanisms will not be Last Called in the WG until that
> requirement is added.
> 
> Sorry to be blunt, but there is no flexibility on whether
> the basic security mechanisms are mandatory to implement;
> they will be mandatory to implement, period.
> 
> 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
> [email-masked]       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
> 
> 
> > -----Original Message-----
> > From: Robert Snively [mailto:[email-masked]]
> > Sent: Wednesday, August 01, 2001 12:08 PM
> > To: [email-masked]'; [email-masked]
> > Subject: RE: Security Gateways
> > 
> > 
> > Dear David,
> > 
> > I would like to address the rather serious question you have
> > raised here about both architectural layering and market
> > requirements.  After considerable thought, based on the
> > explanations below, I have concluded that the FCIP RFC should
> > specify that security is optional to implement and optional to use.
> > 
> > 1)  Concerning architectural layering:
> > 
> > It is clear that the problems of security are well understood
> > within IETF. Numerous solutions have been proposed and
> > many of those have become standard implementations.  The most
> > successful of those (as an example, IPSec) have used the
> > principles of architectural layering very well.  IPSec
> > provides a secure mechanism for transporting any IP-based
> > protocol if the protocol requires such security.  However,
> > the overlaying protocols (as an example, TCP) have no requirement
> > to actually make use of IPSec, and in fact have no particular
> > requirement to make use of IP.  This is as it should be.
> > Each layer is implemented independently of the other.  The
> > services that each layer implements depend on the market
> > requirements for the environment.  By that logic, it is 
> > unnecessary for FCIP to specify any security mechanism at all, 
> > since so many security mechanisms are available.  However,
> > FCIP has provided the additional guidance that, if security
> > in a TCP environment is used, it shall be provided at a layer
> > below the TCP interface.  In particular, it recommends the
> > use of IPSec for TCP/IP environments (and will recommend the
> > appropriate IPSec options).  This additional guidance has nothing
> > to do with the architecture or definition of FCIP and is 
> > merely a recommendation that should improve interoperability.
> > 
> > 2)  Concerning market requirements:
> > 
> > A very high percentage of storage environments today manage
> > their configurations very carefully.  Such careful management is
> > necessary to guarantee redundant paths for proper availability,
> > to provide sufficient paths to provide the required 
> > performance, and to
> > guarantee known paths to improve reparability and consistency
> > of behavior.  As a side effect, a very high percentage of
> > the paths of a storage environment are physically secured and have
> > no requirement for additional security mechanisms.  At present,
> > the only paths that are using security are those very few paths
> > that leave one physically secure environment to transport data to
> > another physically secure environment.  Those few paths 
> > almost universally
> > use security mechanisms at a lower level (as an example, a virtual
> > private network) to achieve their goals.  As a first guess, such
> > paths are well under 1% of the storage paths being used today.
> > 
> > I do not believe that this paradigm will change significantly over
> > the next several years, although of course the percentage of paths
> > requiring transport security may rise over 1%.  The requirements for
> > storage performance and the desire to maintain the storage devices
> > and many of their primary processors in a physically secure
> > environment will assure similar configurations.
> > 
> > In this environment, the market will demand low cost and high
> > performance for the great majority of interconnects and will demand
> > security for a relatively low percentage of interconnects.  
> > 
> > What this implies for technologies like FCIP is that security
> > be available as a separate option, outside the primary FCIP
> > definition.  While still allowing the integration of security
> > inside an FCIP unit, the IETF draft for FCIP  must also 
> allow security
> > to be provided either not at all or by an outside mechanism.  
> > The most common outside mechanism would be a gateway box of 
> some sort.
> > In many cases, the gateway box will be a secure router placed on the
> > external link and servicing a large number of locally attached
> > unsecured FCIP boxes.
> > 
> > CONCLUSIONS:
> > 
> > The FCIP draft should continue to specify a security mechanism,
> > with IPSec being the appropriate candidate, to guarantee 
> > interoperability
> > when security is provided.  The FCIP draft should be modified to
> > indicate that security is optional to implement and optional to use.
> > In addition, it should explicitly indicate that external gateway
> > boxes are allowed implementation mechanisms for security.
> > 
> > As a side question, note that management of storage area networks
> > and FCIP boxes is a separate question and is outside the scope of
> > the FCIP draft.  Both Fibre Channel and Ethernet management paths
> > have security appropriate to the particular management mechanism.
> > As an example, web-based management mechanisms use web-based
> > security tools. 
> > 
> > Bob Snively                        e-mail:    [email-masked]
> > Brocade Communications Systems     phone:  408 487 8135
> > 1745 Technology Drive
> > San Jose, CA 95110
> > 
> > 
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, July 24, 2001 7:11 PM
> > To: [email-masked]
> > Subject: Security Gateways
> > 
> > 
> > The following issue was hidden in my long set of
> > comments on the -03 version of FCIP:
> > 
> > > > Delete 12 b).  If an FCIP entity is operating with an external
> > > > security gateway, only the interface on the public side of the
> > > > gateway is compliant with this specification.  The interface
> > > > between the FCIP entity and the gateway is not compliant because
> > > > it is lacking required security features - the FCIP entity
> > > > *includes* the security gateway in this structure.
> > > 
> > > Please post this as a separate issue because several of the
> > > FCIP Authors believe it is appropriate for FCIP and I cannot
> > > represent their opinions.
> > 
> > The issue is not whether it's "appropriate".  The issue
> > is that if an implementation uses an FCIP Entity plus
> > an external security gateway, the only interface that
> > conforms to the forthcoming RFC is the public/external
> > interface on the security gateway.  The interface between
> > the FCIP Entity and the security gateway is private
> > and fails to conform to the security that will be
> > required of all FCIP implementations.
> > 
> > The above paragraph also applies to iSCSI (substitute iSCSI
> > for FCIP in all instances).  Let me also note that iSCSI's
> > ability to use a security gateway is not final at this
> > juncture.  The spectrum of security possibilities includes
> > things like SRP keying of ESP and IPsec transport mode that
> > would make external gateways difficult or impossible to use.
> > 
> > Those who care about being able to use security gateways
> > (or think that there's no need to support their use)
> > should speak up on the list, in London, and/or in Orange
> > County (I would expect the decision not to be made prior
> > to Orange County) and *EXPLAIN WHY* [technical rationale].
> > 
> > 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
> > [email-masked]       Mobile: +1 (978) 394-7754
> > ---------------------------------------------------
> >  
> > 
>

---

From: [email-masked]
Date: Wed, 1 Aug 2001 20:47:51 -0400

Bill,

> I believe I have to disagree with you David.  The IESG WILL approve specs
> that do not offically include encryption.  An example might be RFC 2801
> The Internet Open Trading Protocol - IOTP Version 1.0.

Unfortunately, that's a red herring ...

(1) The issue is not encryption - that's OPTIONAL to implement and
	OPTIONAL to use for FCIP at the moment, but should be specified.
	The issue is authentication and cryptographic integrity, which
	RFC 2801 doesn't appear to require either.  This may be because ...

(2) RFC 2801 is Informational.  Informational RFCs generally don't
	state requirements for compliance or conformance, and RFC 2801
	is running somewhat true to that form by not even referencing
	RFC 2119 for definitions of MUST/SHOULD/MAY.  In contrast ...

(3) FCIP will be standards-track, and hence will be held to a higher
	standard by the IESG.  This set of security requirements is
	doubtless one of a number of things that might be acceptable
	in an Informational RFC but not in a Standards-Track RFC.

Also, my description of what the IESG is requiring was specific
to the IPS WG (and my original words were specific to FCIP), so
the fact that an Informational RFC in a different area did something
different is not particularly relevant.

I've received rather direct guidance on this topic from the
Area Directors, and I believe I'm accurately representing the
requirements.  

--David

> From: Bill Strahm [mailto:[email-masked]]
> Sent: Wednesday, August 01, 2001 6:12 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Ok,
> I believe I have to disagree with you David.  The IESG WILL 
> approve specs
> that do not offically include encryption.  An example might 
> be RFC 2801
> The Internet Open Trading Protocol - IOTP Version 1.0.
> 
> From this documents own security section comes the statement
> 5.3 Data Privacy
> 
>    Privacy of information is provided by sending IOTP Messages between
>    the various Trading Roles using a secure channel such as [SSL/TLS].
>    Use of a secure channel within IOTP is optional.
> 
> The security section also talks about why you might or might 
> not want to
> use digital signatures for performing Online transactions.
> 
> It boils down to allowing vendors to create products that 
> customers wish
> to buy.  If it turns out that custommers ARE NOT willing to 
> pay a single
> dime for security, why are you going to burden a vendors 
> implementation
> with security requirements that do not provide value to the 
> customer.  If
> customers value security, you will see a quick rise in the 
> sale of secure
> storage products.
> 
> I think it is perfectly acceptable to point to a security 
> implementation
> (IPsec, TLS, or roll our own in a seperate document), but to 
> require it
> for protocol correctness I do not think is needed for any reason.
> 
> Bill
> 
> On Wed, 1 Aug 2001 [email-masked] wrote:
> 
> > Bob,
> > 
> > > The most common outside mechanism would be a gateway box 
> of some sort.

---

From: Jim McKinney <[email-masked]>
Date: Wed, 1 Aug 2001 22:12:41 -0400 (EDT)

David,

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, August 01, 2001 10:13 AM
To: [email-masked]; [email-masked]
Subject: RE: Security Gateways

Bob,

Thanks,
--David

> inside an FCIP unit, the IETF draft for FCIP  must also allow security
> The most common outside mechanism would be a gateway box of some sort.

---

From: Jim McKinney <[email-masked]>
Date: Thu, 2 Aug 2001 07:26:08 -0400 (EDT)

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01C11ACC.6B6C6140
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

David,
Do your comments also apply to iFCP gateways (i.e. will cryptographic
security be required in iFCP gateways in order for these to confirm to =
spec)?

Saqib Jang
Margalla Communications, Inc.
3301 El Camino Real, Suite 220
Atherton, CA 94027
Tel (650) 298 8462 Fax:( 650)  851 1613
http://www.margallacomm.com

-------------------------------------------------------------------------=
--------------------

                     The issue is not whether it's "appropriate".  The =
issue
                     is that if an implementation uses an FCIP Entity =
plus
                     an external security gateway, the only interface =
that
                     conforms to the forthcoming RFC is the =
public/external
                     interface on the security gateway.  The interface =
between
                     the FCIP Entity and the security gateway is private
                     and fails to conform to the security that will be
                     required of all FCIP implementations.

                     The above paragraph also applies to iSCSI =
(substitute iSCSI
                     for FCIP in all instances).  Let me also note that =
iSCSI's
                     ability to use a security gateway is not final at =
this
                     juncture.  The spectrum of security possibilities =
includes
                     things like SRP keying of ESP and IPsec transport =
mode that
                     would make external gateways difficult or =
impossible to use.

                     Those who care about being able to use security =
gateways
                     (or think that there's no need to support their =
use)
                     should speak up on the list, in London, and/or in =
Orange
                     County (I would expect the decision not to be made =
prior
                     to Orange County) and *EXPLAIN WHY* [technical =
rationale].

                     Thanks,
                     --David

                     =20

------=_NextPart_000_0017_01C11ACC.6B6C6140
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>David,</FONT></DIV>
<DIV><FONT size=3D2>Do your comments also apply to iFCP gateways (i.e. =
will=20
cryptographic</FONT></DIV>
<DIV><FONT size=3D2>security be required in iFCP gateways in order for =
these to=20
confirm to spec)?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Saqib Jang<BR>Margalla Communications, Inc.<BR>3301 =
El Camino=20
Real, Suite 220<BR>Atherton, CA 94027<BR>Tel (650) 298 8462 Fax:( =
650)&nbsp; 851=20
1613<BR><A=20
href=3D"http://www.margallacomm.com">http://www.margallacomm.com</A></FON=
T></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT=20
size=3D2>----------------------------------------------------------------=
-----------------------------</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT=20
size=3D2><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
The issue is not whether it's "appropriate".&nbsp; The=20
issue<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
is that if an implementation uses an FCIP Entity=20
plus<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
an external security gateway, the only interface=20
that<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
conforms to the forthcoming RFC is the=20
public/external<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
interface on the security gateway.&nbsp; The interface=20
between<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
the FCIP Entity and the security gateway is=20
private<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
and fails to conform to the security that will=20
be<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
required of all FCIP implementations.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
The above paragraph also applies to iSCSI (substitute=20
iSCSI<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
for FCIP in all instances).&nbsp; Let me also note that=20
iSCSI's<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
ability to use a security gateway is not final at=20
this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
juncture.&nbsp; The spectrum of security possibilities=20
includes<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
things like SRP keying of ESP and IPsec transport mode=20
that<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
would make external gateways difficult or impossible to =
use.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Those who care about being able to use security=20
gateways<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
(or think that there's no need to support their=20
use)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
should speak up on the list, in London, and/or in=20
Orange<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
County (I would expect the decision not to be made=20
prior<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
to Orange County) and *EXPLAIN WHY* [technical rationale].</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Thanks,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--David</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
---------------------------------------------------<BR>&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
David L. Black, Senior=20
Technologist<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
EMC Corporation, 42 South St., Hopkinton, MA&nbsp;=20
01748<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
+1 (508) 435-1000 x75140&nbsp;&nbsp;&nbsp;&nbsp; FAX: +1 (508)=20
497-8500<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<A=20
href=3D"mailto:[email-masked]">[email-masked]</A>&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
Mobile: +1 (978)=20
394-7754<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
---------------------------------------------------<BR>&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</FONT></DIV></BODY></HTML>

------=_NextPart_000_0017_01C11ACC.6B6C6140--

---

From: Anil Rijhsinghani <[email-masked]>
Date: Thu, 2 Aug 2001 10:16:11 -0600

David:

I believe the security requirements for FCIP may be somewhat different
than those for iSCSI. While it is possible to secure iSCSI end-to-end,
it's not possible to do so for FCIP because of the fact that Fibre Channel
itself has no built-in security protocol. A user of FC needs to physically
secure the FC portion of the SAN in any case so the additional physical
security
for the FCIP device, or the wire between it and a sec gateway, is
much less of an issue.

Regards,
Anil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, August 01, 2001 5:42 PM
To: [email-masked]; [email-masked]
Subject: RE: Security Gateways

Bob,

--David

---

From: Robert Snively <[email-masked]>
Date: Thu, 2 Aug 2001 09:34:28 -0700

David,

As introduction to this phase of our discussion, let me draw
a picture in (gag) ASCII.

  +-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  +  -  -  -  -  -  -  +
     Securely Administered Secure Environment     Public Environment
  |                                             |                    |
     FC  +--------------+   TCP/IP w/o
  |  <-->| FC/FCIP dvc A|<----+ IPSec           |                    |
         +--------------+     |
  |                           |      +--------+ |                    |
     FC  +--------------+     +----->| Secure |     TCP/IP w/ IPSec
  |  <-->| FC/FCIP dvc B|<---------->| Router |<------------>        |
         +--------------+     +----->|        |
  |                           |      +--------+ |                    |
     FC  +--------------+     |
  |  <-->| FC/FCIP dvc C|<----+                 |                    |
         +--------------+
  |                                             |                    |

  +-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  +  -  -  -  -  -  -  +

I believe that the interface provided by FC/FCIP dvc A, B, and C
should be called RFC "FCIP" compliant just as completely as
the public interface from the secure router is called RFC "FCIP"
compliant.  In this environment, the FCIP devices will be routinely
carrying on traffic among themselves without using IPSec, and will
be carrying on traffic with the public environment using
securely protected connections.  The secure protection may be
IPSec as recommended by the RFC "FCIP", but it may also be some
other sort of secure connection.  If there is a performance and
a monetary cost associated with IPSec (which my associates assure
me will be significant for some time in the future), that cost
is paid one time in this picture.  If IPSec was mandatory
to implement for RFC "FCIP" compliance, the financial cost would
be paid three (or maybe four) times in the picture and the
performance cost would be avoided by invoking the optional disabling
of the security feature within the securely administered 
secure environment.

This example will be a common structure in FCIP environments.

The example provides lots of options for various kinds of tradeoffs.
As time goes on, the full integration of security functions in
FCIP chips may increase the percentage of RFC "FCIP" complaint
devices that actually contain the optional to implement IPSec
functions in the FC/FCIP device itself.  At any time, individual
secure interface boxes (IPSec or other) can be attached loosely or 
tightly to those FC/FCIP devices that invoke the option to not install
security internally.  Even the definition of tightly and loosely
connected is an artificial distinction related to how long the 
bolts are and whether adjacent racks constitute tightly coupled
functions.

To meet these requirements, the only solution I can see is to
define the RFC "FCIP" such that security is optional to implement
and optional to use.  While defining the recommended security to
be IPSec, devices that use no security and devices that use
alternative security would also be RFC "FCIP" compliant.  They
of course would list in their manufacturing specifications other 
RFCs that would be supported, typically including TCP, IP, and 
the appropriate IPSec RFCs.

To address the second part of your comments below:

>>  This isn't just "push back"

The closest wording I can find to that in the charter is:

"  The WG will address at least the following: 

    - Security measures, including authentication and privacy, 
      sufficient to defend against threats up to and including 
      those that can be expected on a public network.

   The WG will address security and congestion control as 
   an integral part of bits protocol encapsulation(s); "

I can find no hint that those security measures are mandatory
to implement for compliance with the RFC "FCIP".  They are
certainly mandatory to specify in the RFC, and we will have done
so with big flashy warnings (or at least as flashy as ASCII
allows) that qualify the security limitations for those operating
in RFC "FCIP" compliant devices that elect not to install
the optional security mechanisms internally.  I believe that
our proposal would meet both the letter and spirit of the charter.

The wording in draft-ietf-ips-framework-00.txt, clause 9, 
similarly recognizes the requirement we see with wording like:

"  A partial solution may be obtained by providing enhanced security 
   services at the interfaces from the existing storage network to the 
   IP storage network. There, services such as encryption and 
   authentication may be applied to the non-physically secure portion 
   of the path, without requiring end-station changes.  
         
   Overall security for such a solution may be no better than that of a 
   SAN presumed to be physically secure, but at least it will not be 
   perceived as worse. 
    
   Link-level security need not be the only solution. In many 
   applications, privacy of data transmission across the network may be 
   less significant an issue than controlling who accesses the storage 
   resources. In such situations, access-control solutions such as the 
   resource login provided by iSCSI can add value."

Note that the FC entities making use of the FCIP entities have
a secure authentication mechanism being proposed as part of the
FC activities.

I hope that we have interpreted the wording and intent correctly,
because if not we should probably modify the charter to allow
the FCIP proposal.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, August 01, 2001 4:42 PM
To: [email-masked]; [email-masked]
Subject: RE: Security Gateways

Bob,

--David

---

From: [email-masked]
Date: Thu, 2 Aug 2001 13:11:34 -0400

> than those for iSCSI.

I believe that's true, but that the most important differences
are in the area of authentication.  FCIP need only concern itself with
"machine" authentication, as FCIP is fundamentally connecting two switches.
iSCSI is more complex and involves a granularity of authentication
finer than "machine" (e.g., one might be authenticating the backup
application to the tape drive as opposed to authenticating the server
on which the backup application is running).

> While it is possible to secure iSCSI end-to-end,
> itself has no built-in security protocol.

True, but this actually increases the security requirements for FCIP
because there's no higher level security available.

> A user of FC needs to physically
> security for the FCIP device, or the wire between it and a sec gateway, is
> much less of an issue.

This looks like violent agreement with what I've written.  A system
consisting
of [FCIP device, cable, security gateway] provides sufficient security to
comply with the RFC requirements at the external interface of the gateway.
In such a system, it is both highly advisable and feasible to physically
secure the (short) cable between the FCIP device and the gateway.

Thanks,
--David

---

From: Jim McKinney <[email-masked]>
Date: Thu, 2 Aug 2001 19:18:33 -0400 (EDT)

Date: Thu, 2 Aug 2001 18:02:28 -0400 (EDT)
From: [email-masked]
Message-Id: <[email-masked]>
X-Authentication-Warning: ece.cmu.edu: majordom set sender to [email-masked] using -f
To: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from [Robert Snively <[email-masked]>]

---

From: Robert Snively <[email-masked]>
Date: Thu, 2 Aug 2001 15:02:15 -0700

My first guess, which is admittedly just a guess, is that

	a)  All SCSI paths are physically secure (the longest
		is less than 25 meters).

	b)  All FC N_Port copper and multi-mode paths are 
		physically secure (the longest is less than 
		500 meters and most are on newly installed
		50 micron cable).

That leaves FCIP-like paths and ATM/SONET paths, which are
available, but still rare in the industry.  That is why my
swag is less than 1%.  The metro SAN interconnects typically
have 2 such connections for each fabric island.  Each fabric
island may have dozens of other physically secured connections.

I believe that there will be a paradigm evolution, but nothing
as dramatic as a paradigm shift.  While more bandwidth will
open among glass-fronted rooms, the bandwidth contained within
the rooms will increase as fast.  The low latency, high 
performance, disciplined centralized management, and physical 
protection of valuable assets will maintain the "physically
secure" to "logically secure" ratios a lot higher than might
otherwise be expected.  Secure communication will certainly be mandated 
among the rooms, but within a glass-fronted room, there does not
seem to be the same compelling reason for security, except as it
applies to system management functions.

For telecommuters, I expect secure access will be mandatory, but
I expect that it will not be at the FCIP or iSCSI level, but 
rather at the file level.

Hope that explains why I feel those numbers are important.

-----Original Message-----
From: Mark Winstead [mailto:[email-masked]]
Sent: Thursday, August 02, 2001 7:27 AM
To: 'Jim McKinney'; [email-masked]
Cc: David Blaker
Subject: RE: Security Gateways

On market requirements:

1) Curious, what is your basis for the guess of 1% of storage
environments/paths not being physically secure? While I tend to agree that
currently this is a low percentage, 1% seems too low. Do you have any hard
numbers to justify this your guess?

Large companies and companies experiencing rapid growth often have multiple
locations across a metropolitan area. Do these companies not have some
commonly accessible storage facility for at least some of their data? Don't
other companies have or would like to have workers at multiple locations
across miles if not hundreds of miles to collaborate, requiring access to
the same data, not just mirrored (and thus often dated) data?

2) Even if the % of paths are in single digits, do you think there won't be
a paradigm shift?

With increased capacities for bandwidth (OC-12, 0C-48, faster networks
switches, et al) coming available, it would seem logical that it will become
practical for more and more companies to shift data storage facilities to
lower rent facilities than their office and/or research space, and to
increase collaboration among workers at multiple locations (or even true
telecommuters connected through broadband technologies).

Mark Winstead

NetOctave, Inc.
P.O. Box 14824
RTP, NC 27709
www.netoctave.com
919.463.9903 x328
[email-masked] <mailto:[email-masked]> 

-----Original Message-----
From: Jim McKinney [mailto:[email-masked]]
Sent: Wednesday, August 01, 2001 10:06 PM
To: [email-masked]
Subject: RE: Security Gateways

Dear David,

to provide sufficient paths to provide the required performance, and to
another physically secure environment.  Those few paths almost universally

CONCLUSIONS:

with IPSec being the appropriate candidate, to guarantee interoperability

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 24, 2001 7:11 PM
To: [email-masked]
Subject: Security Gateways

Thanks,
--David

---

From: Robert Snively <[email-masked]>
Date: Thu, 2 Aug 2001 09:34:28 -0700

David,

         

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, August 01, 2001 4:42 PM
To: [email-masked]; [email-masked]
Subject: RE: Security Gateways

Bob,

--David

---

From: Robert Snively <[email-masked]>
Date: Wed, 1 Aug 2001 09:07:57 -0700

Dear David,

CONCLUSIONS:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 24, 2001 7:11 PM
To: [email-masked]
Subject: Security Gateways

Thanks,
--David

---

From: Robert Snively <[email-masked]>
Date: Wed, 1 Aug 2001 15:25:16 -0700

David,

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, August 01, 2001 10:13 AM
To: [email-masked]; [email-masked]
Subject: RE: Security Gateways

Bob,

Thanks,
--David

---

From: Jim McKinney <[email-masked]>
Date: Fri, 3 Aug 2001 14:55:06 -0400 (EDT)

Approved: sskm1

> Bernard Aboba wrote:
> 
> Integrity protection via new MACs such as UMAC is *not* 
> expensive. This is
> a myth. See http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html 
>

Bernard,

Thanks for the pointer to some current research in this area.

That paper gave cycles/byte numbers for their algorithm, on 
a Pentium III and PowerPC.  For now, I'll comment on the PPC 
numbers, because that family is available as an embeddable core
that can be integrated into hardware, while the Pentium III is not. 
For 1500-byte messages, it looks like UMAC will take between 
2.7 and 3.7 CPU clocks per byte (estimates, as no numbers 
were given for the full UMAC function on PPC).  

That indicates that I'd have to run my core at 600-800 Mhz 
to handle a single full duplex Gigabit Ethernet port, assuming
I have the packets in memory that's fast enough to not stall the 
CPU, and that there's some way of getting packets into and out 
of that memory without interfering with the CPU.

I grant you that is "do-able," and it certainly is less expensive 
than HMAC-SHA1, but I wouldn't call it "cheap."  At least for 
some portion of the audience here, "cheap" may be measured by how 
many thousands of gates the implementation adds to the existing 
data path logic, and "fast" by how many gate delays were 
introduced into that path. 

So, I guess that puts me in agreement with Jim William's 
comments; security protocols MUST be supported, and 
supported in the context of a single standard, 
not a "de jure" standard and a "de facto" alternative.
And, if that means the standard must embrace non-monolithic 
"system level" compliance, then let's figure out how to 
do that properly, rather than declaring it illegal and hoping 
it will go away.

- milan

---

From: "Merhar, Milan" <[email-masked]>
Date: Fri, 3 Aug 2001 13:44:07 -0400

Bernard,

- milan

---

From: "Julian Satran" <[email-masked]>
Date: Sun, 5 Aug 2001 18:29:46 +0300

Did somebody attempt to design specialized hardware to do UMAC?

Julo

Jim McKinney <[email-masked]>@ece.cmu.edu on 03-08-2001 21:55:06

Please respond to Jim McKinney <[email-masked]>

Sent by:  [email-masked]

To:   [email-masked]
cc:

Approved: sskm1

Bernard,

- milan