Re: IETF *is* computer crime.

[Salvador Vidal]

Hello Bob,

For Internet improvent and sucess you need the people at this list,
Not because their are brillant
Not because their experince
Not because Intenet need continuity
...
Just because Nobody hate more the actual Intenet degradation, Nobody wants
more that Internet serves for humanity sucess than those who spend their
life working for Internet.

The bill of rights or any other thing that you have in mind are just wet
papers without people fighting for them, and you are in the right place if
you are searching for these people.

As you say the problem is the superestructure that drives Internet for a
very particular ecomic interest, IEFT people are not the problem but part
of the solution.

We need people at this list for an honest Internet evolution, for the
Internet Spirit revival...

We are driven to a deal to balance the actual situation but not without
them, not without you, not without anybody.

Very nice to heard from you again,
Salva

At 11:31 23/05/00 -0400, you wrote:
>
> The manner in which unsanctioned anti-democratic organizations
> control what amounts to the global communications network is a
> crime unto itself. Citizens utilizing this infra-structure posses
> no legal protections, no constitutional safeguards and no basic
> rights or liberties of any variety. We are subject to the chimeric
> whims of technocrats lost in the clouds of their stock options,
> fancy job titles and droll rotation of globe hopping symposiums
> and conferences. Left with no protections we are virtually
> helpless, hapless and hopeless.
>
> The concept of privacy and personal rights and freedoms on the
> net are fully nul and void. The whole convoluted mess rambles on
> generating profits for the lever-controllers and box managers
> and everything is fine and dandy. Except for the pervading fact
> that bloody security, mechanical network integrity and smooth
> technical functioning of the machinery do not supercede precious 
> inalienables and undeniables. Except for the truth that people
> and their intercourses are openly, randomly and completely subject
> to limitless interferances and interventions. 
>
> IETF, ISOC, ICANN, ITU and whatever other unsanctioned, informal
> acretion of pseudo-authority should arise are no places to look
> for solutions. They embody the problem. They ARE the proble. To
> search elsewhere is our only alternative. Tou route around, to
> undermine, to quietly innovate clever detours and innovations.
> Because the moment the unchanging cast of central authorites
> are deposed is the moment a solution becomes workable. Look no
> further than your own self, your own capabilities and capacities.
> Anyone who seeks freedom or solace from those who benifit the most
> from our control and the maintenance of their influence can only
> impede evolution. 
>
> Alive and very much well, all my opinions only, a very insignificant
> observer among the masses of the great unplugged, I remain,
>
> Bob Allisat
>
>
>

"HAAGENS,RANDY (HP-Roseville,ex1)": RE: IETF mailing list question on Storage over Ethernet/IP

[Dave Nagle]

Jon,
  
  A few more comments on SCSI over IP.

 Also, anyone interested in this subject can subscribe to the IPS
reflector?  Info on the IPS reflector:

 IPS
 Name: IP Storage
 Purpose: Semi-official reflector for the IETF IPSWG communication.  Postings
 are made following "authors group" consensus.
 Hosted by: CMU
 Subscribe: Send mail to [EMAIL PROTECTED] with the command subscribe ips

E-mail: [EMAIL PROTECTED]
URL: http://www.ece.cmu.edu/~ips


--- Forwarded Message

Date:Thu, 25 May 2000 21:38:11 -0700
From:"HAAGENS,RANDY (HP-Roseville,ex1)" <[EMAIL PROTECTED]>
To:  "'Dave Nagle'" <[EMAIL PROTECTED]>
cc:  "Scsi-Tcp (E-mail)" <[EMAIL PROTECTED]>
Subject: RE: IETF mailing list question on Storage over Ethernet/IP

Comments
- 

1. I agree with your comments about TCP's being implemented in hardware.  It
will be as fast as any other protocol implemented in hardware.

2. Adaptec should speak for themselves; but I believe that the reference to
STP is a misunderstanding.  At the N+I conference, Adaptec demoed a software
prototype of their SCSI Encapsulation Protocol (SEP).  SEP allows SCSI to be
transported over a lightweight protocol of Adaptec's own design for the the
local area, or over TCP for the wide area.

3. The IP Storage Working Group (IBM, Cisco, HP, Adaptec, Quantum, EMC, and
others) are working on a mapping of SCSI to TCP, for use both in the WAN and
in the LAN.  All of us agree on the use of TCP as the transport for the WAN
and LAN, while a minority would probably favor using a lighter-weight
transport for the LAN.

In summary, TCP is suitable as the transport for the WAN and LAN, and it
will be as fast as any protocol when implemented in hardware.  Using a
single transport for the WAN and LAN removes the artificial barrier between
these two environments, and means that applications (like mirroring) can be
designed to scale seamlessly from the local to the wide area.

Randy Haagens
Networked Storage Architecture
Storage Organization
Hewlett-Packard Co.
e-mail: [EMAIL PROTECTED]
tel: +1 916 785 4578
fax: +1 916 785 1911


> -Original Message-
> From: Dave Nagle [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 25, 2000 4:28 PM
> To: SCSI-over-TCP List
> Subject: IETF mailing list question on Storage over Ethernet/IP
> 
> 
> 
> 
> --- Forwarded Message
> 
> Date:Thu, 25 May 2000 22:55:49 -
> From:Mike Fisk <[EMAIL PROTECTED]>
> To:  Jon William Toigo <[EMAIL PROTECTED]>
> cc:  [EMAIL PROTECTED]
> Subject: Re: Storage over Ethernet/IP
> 
> On Thu, 25 May 2000, Jon William Toigo wrote:
> 
> > I am seeking a few points of clarification:
> > 
> > 1.  Fibre Channel folks have attempted to explain to me why TCP/IP
> > could NEVER be a viable interconnect for block level storage
> > operations.  They claim:
> > 
> > a.  TCP is too CPU intensive and creates too much latency 
> for storage
> > I/O operations.
> > 
> > b.  The IP stack is too top heavy and processing packet 
> headers is too
> > slow to support storage I/O operations.
> >
> > c.  The maximum throughput of a GE TCP/IP connection is 768 
> Mps, which
> > is too slow to support storage I/O operations.
> 
> This is not a theoretical limitation, but is in the ballpark 
> reported by
> many general-purpose operating systems with commodity hardware.  
> 
> >Is any of this true?
> 
> I don't believe that TCP/IP implementations couldn't be optimized to
> support full link rate and low latency.  If you're building a hardware
> adapter that can do SCSI and RAID fast, adding TCP shouldn't be
> prohibitively hard. 
> 
> > 2.  Adaptec has posited a replacement for TCP called STP 
> for use as a
> > transport for storage.  Does anyone know anything about this?
> 
> STP is the Scheduled Transfer protocol being standardized by 
> the ANSI T11
> folks.  ST was designed to run on top of GSN (a.k.a. 
> HIPPI-6400). In my
> opinion, it is as heavy-weight as TCP with respect to most of 
> the things
> stated above.  It does have the potential advantage of being 
> designed from
> scratch to support zero-copy access to user space using specialized
> interface cards.
> 
> > 3.  Current discussions of the SCSI over IP protocol seem to ignore
> > the issue of TCP or any other transport protocol.  Does anyone know
> > definitively what transport is being suggested by the 
> IBM/Cisco crowd?
> 
> I believe the assumption is that you will have a local network with no
> packet loss or significant bit error rate.  Basically, you assume that
> your ethernet is as reliable as your SCSI cable or 
> fiber-channel network.
> For a well engineered, fully-switched LAN, that may be a reasonable
> assumption.
> 
> - -- Mike Fisk, RADIANT Team, Network Engineering Group, Los 
> Alamos National
> Lab See http://home.lanl.gov/mfisk/ for contact information
> 
> 
> --- End of Forwarded Message
> 
> 

IETF mailing list question on Storage over Ethernet/IP

[Dave Nagle]

A few comments about this one.

1. FC does not provide reliable transmission.  It provides for error
detection, but escalates recovery to "upper level protocol".  FCP-2 has
improved this situation, but is not widely implemented yet.  One of the
advantages of using a transport such as TCP is that link errors will be
corrected in a manner that is transparent to the application protocol
(SCSI).

2. Jumbo frames will not be necessary when TCP is implemented in hardware.
Most FC implementations use 1024 byte frames, and performance is very
adequate, given hardware implementation of FCP.

3. The cost of using different transport protocols in the LAN and WAN is
that the two will not interoperate.  Many of us believe that TCP has proven
itself in both the LAN and WAN.  I bet your PC or UN*X workstation is using
TCP for all its protocol needs.

4. The IPS working group is mapping SCSI to TCP.  Another working group is
mapping FC to IP.  These are very different approaches.  The first (ours)
preserves SCSI, but does not include any vestige of Fibre Channel.  It is
intended for use in the LAN, MAN and WAN.  Its best use is for connecting
hosts computers to storage controllers using Ethernet and IP WAN technology.
It will be possible, but non-trivial, to translate between SCSI over TCP/IP
and SCSI over Fibrechannel.  The second is a tunneling scheme for extending
Fibre Channel over the IP WAN.  It does not contemplate Ethernet-based hosts
or storage controllers.

5. Just about any reliable transport will do nicely for transporting SCSI
commands.  We chose TCP because its implementation and behavior are
well-known, and it is well-supported with load-balancing, QoS and security
features.  While another protocol (such as reliable datagram) might be
arguably better suited to storage transport applications, we'll use TCP
"because it's there".  We'll have the benefit of all the other investment
that's going into improving TCP for internet uses.

Randy Haagens
Networked Storage Architecture
Storage Organization
Hewlett-Packard Co.
e-mail: [EMAIL PROTECTED]
tel: +1 916 785 4578
fax: +1 916 785 1911


> -Original Message-
> From: Dave Nagle [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 25, 2000 4:29 PM
> To: SCSI-over-TCP List
> Subject: IETF mailing list question on Storage over Ethernet/IP 
> 
> 
> 
> --- Forwarded Message
> 
> Date:Thu, 25 May 2000 19:27:02 -0400
> From:Dave Nagle <[EMAIL PROTECTED]>
> To:  "Jon William Toigo" <[EMAIL PROTECTED]>
> cc:  [EMAIL PROTECTED]
> Subject: Re: Storage over Ethernet/IP 
> 
> Jon,
> 
> Original Message
> - 
>  >> I am seeking a few points of clarification:
>  >> 
>  >> 1.  Fibre Channel folks have attempted to explain to me 
> why TCP/IP could =
>  >> NEVER be a viable interconnect for block level storage 
> operations.  They =
>  >> claim:
>  >> a.  TCP is too CPU intensive and creates too much latency 
> for storage =
>  >> I/O operations.
>  >> b.  The IP stack is too top heavy and processing packet 
> headers is too =
>  >> slow to support storage I/O operations.
> 
>   There is a lot of work to show that this is not true.  Check out Van
> Meter's 1998 ASPLOS paper "VISA - Netstations virtual internet SCSI
> adaptor."
> 
>  Perhaps more importantly, there are many companies that are building
> TCP in silicon ASICs.  This should make TCP's performance comparable
> to Fibre Channel.  Both TCP/IP and FC provide about the same
> functionality ... reliable, in-order transmission.  
> 
> The bottom line is that FC is done in hardware while TCP has
> traditionally been done in software. Therefore, previous performance
> numbers are not going to be fair.  Once TCP is in silicon, its
> performance should be roughly equal to FC.
> 
>  >> c.  The maximum throughput of a GE TCP/IP connection is 
> 768 Mps, which =
>  >> is too slow to support storage I/O operations.
> 
>  I believe there are higher numbers (especially with Jumbo
> Frames). Alteon's web site show's 920 Mbps.  Microsoft and Duke
> University have both shown TCP performance o 1Gb+/s performance over
> other networks.
> 
>   BTW, why is 768 Mbps too slow for storage.  Many apps (e.g.,
> transaction workloads) are I/O's per second bound, not bandwidth
> bound.  Also, even if storage over IP/ether is a bit slower than FC,
> the benefits of leveraging IP's infrastructure (i.e., routers,
> switches, NICs, network management, networking people) is a huge
> advantage.  
> 
>  There is also the issue of SCSI over TCP/IP in the SAN vs. the
> LAN/WAN.  Some companies, focusing on the SAN, are building
> SCSI/lightweight transport/IP while others, focusing on the WAN,
> propose SCSI/TCP/IP.  It may be the case that SAN and WAN traffic use
> different transport protocols to gain a bit of extra performance in
> the SAN.  
> 
>  >> Is any of this true?
>  >> 
>  >> 2.  Adaptec has posited a replacement for TCP called STP 
> for use as a =
>  >> transport for storage.  Does anyone know anything

Re: Storage over Ethernet/IP

[Keith Moore]

None of the cited limitations of TCP performance are true.
they are also missing the point.

If you're going to run storage access over IP then you are potentially
allowing it to be run over the global Internet.  If you do that you need
good authentication and privacy, and (if you try to do them in software)
authentication and encyption will eat far more in performance than 
anything inherent to TCP or IP.

and no, it's not acceptable to assume that the storage device will be 
behind a firewall.

Keith

Re: IETF mailing list question on Storage over Ethernet/IP

[narakamath]

Thank you all for some excellent discussions on the subject.  For all the reasons 
mentioned, I am mapping TCP/IP to DWDM to create very high performance SANs.  I hope 
to share more on this as we progress and launch products.  You can see more on this at 
www.lightel.com.

On Fri, 26 May 2000, Dave Nagle wrote:

> 
> 
> A few comments about this one.
> 
> 1. FC does not provide reliable transmission.  It provides for error
> detection, but escalates recovery to "upper level protocol".  FCP-2 has
> improved this situation, but is not widely implemented yet.  One of the
> advantages of using a transport such as TCP is that link errors will be
> corrected in a manner that is transparent to the application protocol
> (SCSI).
> 
> 2. Jumbo frames will not be necessary when TCP is implemented in hardware.
> Most FC implementations use 1024 byte frames, and performance is very
> adequate, given hardware implementation of FCP.
> 
> 3. The cost of using different transport protocols in the LAN and WAN is
> that the two will not interoperate.  Many of us believe that TCP has proven
> itself in both the LAN and WAN.  I bet your PC or UN*X workstation is using
> TCP for all its protocol needs.
> 
> 4. The IPS working group is mapping SCSI to TCP.  Another working group is
> mapping FC to IP.  These are very different approaches.  The first (ours)
> preserves SCSI, but does not include any vestige of Fibre Channel.  It is
> intended for use in the LAN, MAN and WAN.  Its best use is for connecting
> hosts computers to storage controllers using Ethernet and IP WAN technology.
> It will be possible, but non-trivial, to translate between SCSI over TCP/IP
> and SCSI over Fibrechannel.  The second is a tunneling scheme for extending
> Fibre Channel over the IP WAN.  It does not contemplate Ethernet-based hosts
> or storage controllers.
> 
> 5. Just about any reliable transport will do nicely for transporting SCSI
> commands.  We chose TCP because its implementation and behavior are
> well-known, and it is well-supported with load-balancing, QoS and security
> features.  While another protocol (such as reliable datagram) might be
> arguably better suited to storage transport applications, we'll use TCP
> "because it's there".  We'll have the benefit of all the other investment
> that's going into improving TCP for internet uses.
> 
> Randy Haagens
> Networked Storage Architecture
> Storage Organization
> Hewlett-Packard Co.
> e-mail: [EMAIL PROTECTED]
> tel: +1 916 785 4578
> fax: +1 916 785 1911
> 
> 
> > -Original Message-
> > From: Dave Nagle [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, May 25, 2000 4:29 PM
> > To: SCSI-over-TCP List
> > Subject: IETF mailing list question on Storage over Ethernet/IP 
> > 
> > 
> > 
> > --- Forwarded Message
> > 
> > Date:Thu, 25 May 2000 19:27:02 -0400
> > From:Dave Nagle <[EMAIL PROTECTED]>
> > To:  "Jon William Toigo" <[EMAIL PROTECTED]>
> > cc:  [EMAIL PROTECTED]
> > Subject: Re: Storage over Ethernet/IP 
> > 
> > Jon,
> > 
> > Original Message
> > - 
> >  >> I am seeking a few points of clarification:
> >  >> 
> >  >> 1.  Fibre Channel folks have attempted to explain to me 
> > why TCP/IP could =
> >  >> NEVER be a viable interconnect for block level storage 
> > operations.  They =
> >  >> claim:
> >  >> a.  TCP is too CPU intensive and creates too much latency 
> > for storage =
> >  >> I/O operations.
> >  >> b.  The IP stack is too top heavy and processing packet 
> > headers is too =
> >  >> slow to support storage I/O operations.
> > 
> >   There is a lot of work to show that this is not true.  Check out Van
> > Meter's 1998 ASPLOS paper "VISA - Netstations virtual internet SCSI
> > adaptor."
> > 
> >  Perhaps more importantly, there are many companies that are building
> > TCP in silicon ASICs.  This should make TCP's performance comparable
> > to Fibre Channel.  Both TCP/IP and FC provide about the same
> > functionality ... reliable, in-order transmission.  
> > 
> > The bottom line is that FC is done in hardware while TCP has
> > traditionally been done in software. Therefore, previous performance
> > numbers are not going to be fair.  Once TCP is in silicon, its
> > performance should be roughly equal to FC.
> > 
> >  >> c.  The maximum throughput of a GE TCP/IP connection is 
> > 768 Mps, which =
> >  >> is too slow to support storage I/O operations.
> > 
> >  I believe there are higher numbers (especially with Jumbo
> > Frames). Alteon's web site show's 920 Mbps.  Microsoft and Duke
> > University have both shown TCP performance o 1Gb+/s performance over
> > other networks.
> > 
> >   BTW, why is 768 Mbps too slow for storage.  Many apps (e.g.,
> > transaction workloads) are I/O's per second bound, not bandwidth
> > bound.  Also, even if storage over IP/ether is a bit slower than FC,
> > the benefits of leveraging IP's infrastructure (i.e., routers,
> > switches, NICs, network management, networking people) is a huge
> > adv

RE: Storage over Ethernet/IP

[Brian . Rubarts]

Encryption will be offloaded to the network interface.  ASICs on the NICs
will greatly improve encryption and authentication performance.  It won't
run over the Internet because of latencies inherent on the public network.
It will run over incredibly fast Packet over SONET Wide Area
Networks--behind firewalls.  OC-192 and soon-to-come OC-768 (terrabit)
switches will be the backbone of WANs and MANs of large networks in a few
years.  Also, IPv6 has significantly improved authentication capabilities
that will help ensure security on the Storage WAN (SWAN?)

Brian

-Original Message-
From: Keith Moore [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 26, 2000 9:23 AM
To: Jon William Toigo
Cc: [EMAIL PROTECTED]
Subject: Re: Storage over Ethernet/IP 


None of the cited limitations of TCP performance are true.
they are also missing the point.

If you're going to run storage access over IP then you are potentially
allowing it to be run over the global Internet.  If you do that you need
good authentication and privacy, and (if you try to do them in software)
authentication and encyption will eat far more in performance than 
anything inherent to TCP or IP.

and no, it's not acceptable to assume that the storage device will be 
behind a firewall.

Keith

Re: Storage over Ethernet/IP

[Keith Moore]

> Encryption will be offloaded to the network interface.  ASICs on the NICs
> will greatly improve encryption and authentication performance.

all well and good, provided that this encryption and authentication
are actually compatible with that specified by higher level protocols
and the authentication actually meets the needs of users.  
(if your network interface needs to use and verify users' credentials,
as opposed to the host's credentials, it might be a stretch.)

> It won't run over the Internet because of latencies inherent on the 
> public network.

at least for some storage applications, latency is not as important
as bandwidth.  e.g. you can do backups over a high-latency medium
as long as your bandwidth is adequate (though recovery from write 
errors gets a bit tricky).

> It will run over incredibly fast Packet over SONET Wide Area
> Networks--behind firewalls.

I'm sure it will be used behind firewalls in some cases but it's 
inappropriate to assume that it will always be used behind firewalls.
Firewalls don't help with the majority of security threats, and
it's less and less the case that network topologies reflect
trust domains.

Keith

RE: Storage over Ethernet/IP

[Brian . Rubarts]

>> Encryption will be offloaded to the network interface.  ASICs on the NICs
>> will greatly improve encryption and authentication performance.

>all well and good, provided that this encryption and authentication
>are actually compatible with that specified by higher level protocols
>and the authentication actually meets the needs of users.  
>(if your network interface needs to use and verify users' credentials,
>as opposed to the host's credentials, it might be a stretch.)

A network server will still authenticate user requests.  Only the host
needs to be authenticated with the disk/disks.

>> It won't run over the Internet because of latencies inherent on the 
>> public network.

>at least for some storage applications, latency is not as important
>as bandwidth.  e.g. you can do backups over a high-latency medium
>as long as your bandwidth is adequate (though recovery from write 
>errors gets a bit tricky).

Backups could go through VPNs, I suppose.  Good point.  That would free your

WAN of the backup jobs.  I wasn't thinking of backups when I ruled out
the Internet as a disk I/O medium.  I suppose infrequently used and low
priority files could also be accessed over the 'net.

>> It will run over incredibly fast Packet over SONET Wide Area
>> Networks--behind firewalls.

>...it's 
>inappropriate to assume that it will always be used behind firewalls...

If the larger network that is employing this technology doesn't hire a
decent
consultant, you might be right.  If they do, it will ALWAYS be behind a
firewall :-)

>Firewalls don't help with the majority of security threats...

True, but whether the server accesses the disks via SCSI over TCP or SCSI
over 
Fibre Channel, the SERVER is still the weak link.  The transport protocol
doesn't
create any inherent weaknesses of the type you are refering to--e-mail borne
viruses, 
internal hackers, etc.  The server would still be the attack point.  Why
goodness, 
the server and storage devices could be in a VLAN or something to deny
direct hack 
attempts against the storage device, but the chink in the armor is how
hardened is
your OS?

Brian

Re: Storage over Ethernet/IP

[Karl Auerbach]

 
> a.  TCP is too CPU intensive and creates too much latency for storage I/O operations.
> 
> b.  The IP stack is too top heavy and processing packet headers is too
> slow to support storage I/O operations.

There were some papers published duing the late '80's or early '90s by
John Romkey and I belive Dave Clark and Van Jacobson about the length of
instruction sequences to handle TCP.  I'm not sure that those ever became
RFCs.

Those papers came up with figures indicating that if one structures code
"correctly" and if the net path is "clean" (i.e. not a lot of packet loss,
reordering, replication, etc) than the per-packet instruction sequences
(sans IP checksum calculation) were potantially very short.

Does anyone have the references to these papers?

--karl--

Re: Storage over Ethernet/IP

[Keith Moore]

> >> It won't run over the Internet because of latencies inherent on the 
> >> public network.
> 
> >at least for some storage applications, latency is not as important
> >as bandwidth.  e.g. you can do backups over a high-latency medium
> >as long as your bandwidth is adequate (though recovery from write 
> >errors gets a bit tricky).
> 
> Backups could go through VPNs, I suppose.  

except that you can't assume the presence of a VPN either.  you need 
authenticity and privacy specified as part of the storage access protocol.

> I suppose infrequently used and low
> priority files could also be accessed over the 'net.

yes, but file access protocols are better for this purpose.  
I don't see wanting to mount a raw disk drive 
across the public Internet very often.  
(except perhaps read-only... virtual cdrom, anyone?)

> >> It will run over incredibly fast Packet over SONET Wide Area
> >> Networks--behind firewalls.
> 
> >...it's 
> >inappropriate to assume that it will always be used behind firewalls...
> 
> If the larger network that is employing this technology doesn't hire a
> decent consultant, you might be right.  If they do, it will ALWAYS 
> be behind a firewall :-)

any consultant who pretends that firewalls provide security cannot
be described as 'decent'.

> >Firewalls don't help with the majority of security threats...
> 
> True, but whether the server accesses the disks via SCSI over TCP or SCSI
> over Fibre Channel, the SERVER is still the weak link.  

un, no.  SCSI has some inherent length/delay/number-of-stations 
limitations.  but if the disk is accessible using TCP,  there is a 
significant probability that it will be accessible from the global 
Internet and/or from local threats who have physical access to the
transmission medium, and the storage access protocol needs to assume 
that this is the case.

> The transport protocol doesn't create any inherent weaknesses of 
> the type you are refering to--e-mail borne viruses, internal hackers, etc.  

you're assuming a different threat model than I am.  I am indeed
assuming that storage devices will be targed, in addition to servers.

> The server would still be the attack point.  Why goodness, 
> the server and storage devices could be in a VLAN or something to deny
> direct hack attempts against the storage device

yes, they *could* be.  but you cannot assume that they *will* be.

> but the chink in the armor is how hardened is your OS?

there's more than one chink in the armor.

IP-based protocols need to be able to work in the global Internet.

Keith

Re: Storage over Ethernet/IP

[Valdis . Kletnieks]

On Fri, 26 May 2000 10:14:03 CDT, [EMAIL PROTECTED] said:
> A network server will still authenticate user requests.  Only the host
> needs to be authenticated with the disk/disks.

Hmm.  

Isn't this security model the cause of most grumbling regarding NFS security?

> If the larger network that is employing this technology doesn't hire a decent
> consultant, you might be right.  If they do, it will ALWAYS be behind a firewall :-)

Double Hmm.. 

Odd.. I thought we had a clue about security.  The guys at SANS just
gave us a 'Technology Leadership Award'.  I just walked across the hallway,
and I didn't see any firewall in our router swamp.

I guess because we don't have a firewall, we don't have a clue.  Or because
we don't have a firewall, we can't deploy this technology.  Somehow, that
doesn't smell right.

> the server and storage devices could be in a VLAN or something to deny direct hack 
> attempts against the storage device, but the chink in the armor is how hardened is
> your OS?

If your OS is hardened enough, a firewall may not be appropriate.

"New from Kellogs - Firewalls cereal - part of this *COMPLETE* and *BALANCED*
security breakfast".
-- 
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech

RE: Storage over Ethernet/IP

[RJ Atkinson]

At 15:40 26-05-00 , [EMAIL PROTECTED] wrote:
>It will run over incredibly fast Packet over SONET Wide Area
>Networks--behind firewalls.  OC-192 and soon-to-come OC-768 (terrabit)
>switches will be the backbone of WANs and MANs of large networks in a few
>years.

 I'll note that at least one vendor has already demonstrated
10 Gig Ethernet switch interfaces at Interop/LV earlier this month.
Such 10 GE boxes are generally much less expensive than OC-192 POS boxes.
Another post indicated that these systems will use frame sizes of 1024 bytes,
which is well within the abilities of any Ethernet interface.

>Also, IPv6 has significantly improved authentication capabilities
>that will help ensure security on the Storage WAN (SWAN?)

 IPv6 has NO authentication capability not already shipping for IPv4,
speaking as the person who designed both AH and ESP.  Marketing aside,
there is nothing in IPv6 that makes it more easily secured than IPv4.
Both support AH and ESP.  Deployed ISAKMP/IKE support IPv4, but might
not support IPv6.

 Note that I have no axe to grind for or against IPv6, but the
disinformation campaign that "IPv6 is secure and IPv4 isn't" is
highly annoying and completely wrong.

Ran
[EMAIL PROTECTED]

RE: Storage over Ethernet/IP

[Brian . Rubarts]

>Odd.. I thought we had a clue about security.  The guys at SANS just
>gave us a 'Technology Leadership Award'.  I just walked across the hallway,
>and I didn't see any firewall in our router swamp.
>I guess because we don't have a firewall, we don't have a clue.  Or because
>we don't have a firewall, we can't deploy this technology.  Somehow, that
>doesn't smell right.
>If your OS is hardened enough, a firewall may not be appropriate.

I am not saying that you don't have a clue if you don't utilize a firewall.

I AM saying that if you have Internet access to your network, a firewall is 
extremely important.  It isn't complete, in and of itself.  OS hardening is
still very important, as are other technologies (as necessary to facilitate
application needs).  

I understand your point that if your OS is perfectly hardened, then a
firewall
isn't going to add any *extra* protection.  You miss the point, though.  You
can prevent
unnecessary processor and bandwidth utilization on the server by filtering
it out at the perimeter of your network.  You might not get a security
advantage
if you are an OS hardening god, but you would CERTAINLY get performance
increases
on your LAN.  

If you are utilizing pure access lists on routers for perimeter security,
then
you are assuming that this technology is as adept at securing a network as 
port filters combined with Network Address Translation or cicuit proxying.
Don't
make that assumption.  

Brian

RE: Storage over Ethernet/IP

[Brian . Rubarts]

>Experience tells us that although we can design and specify for 
>"intra-nets", people will insist on using the results over the public 
>internet.  Pretending this will not happen is akin to burying ones head in 
>the beach sand when one has heard a report of a large wave heading for the 
>beach.

Yeah, okay.  I will grant that.  But, should a good technology be nixed
because some idiots might mis-use it?  I personally don't think so.

Brian

RE: Storage over Ethernet/IP

[Brian . Rubarts]

>IPv6 has NO authentication capability not already shipping for IPv4,
>speaking as the person who designed both AH and ESP.  Marketing aside,
>there is nothing in IPv6 that makes it more easily secured than IPv4.
>Both support AH and ESP.  Deployed ISAKMP/IKE support IPv4, but might
>not support IPv6.

I must admit my error in that statement.  I was reciting something that 
I had read a year ago.  You are correct about AH and ESP
in IPv4 as well as v6.  Thanks for the correction.

Brian

Re: Storage over Ethernet/IP

[ned . freed]

> > Encryption will be offloaded to the network interface.  ASICs on the NICs
> > will greatly improve encryption and authentication performance.

> all well and good, provided that this encryption and authentication
> are actually compatible with that specified by higher level protocols
> and the authentication actually meets the needs of users.
> (if your network interface needs to use and verify users' credentials,
> as opposed to the host's credentials, it might be a stretch.)

FWIW, it has been tried, and it didn't succeed in the market, although whether
that was a matter of timing, insufficient market push, or no market existing
isn't clear.

Specifically, Digital used to make a little gadget called a Cryptonette that
you inserted into your Ethernet cable that did this. (The chip inside was
something called a TANDU, and had DES and two Ethernet ports built in. The
whole thing was the size of a pack of cards.)

And I believe there were at least two other similar gadgets at some point,
although I cannot recall their names...

The demo I saw had the boxes doing IPSEC-style operations (this was before
IPSEC was standardized), with the credential verification being done on the
host side.

OTOH, at least one of the problems with these sorts of things is that it's hard
to change the cryptography embedded in them. So, while I think hardware
cryptographic acceleration of this sort could be quite useful, I'm skeptical
that it will ever be something that is universally deployed.

> > It won't run over the Internet because of latencies inherent on the
> > public network.

> at least for some storage applications, latency is not as important
> as bandwidth.  e.g. you can do backups over a high-latency medium
> as long as your bandwidth is adequate (though recovery from write
> errors gets a bit tricky).

Yep. Backups done over the public Internet (usually with an appalling lack of
security, alas) are actually quite common.

Ned

RE: Storage over Ethernet/IP

[Vernon Schryver]

> Yeah, okay.  I will grant that.  But, should a good technology be nixed
> because some idiots might mis-use it?  I personally don't think so.

This thread started with a question about a TCP technology report, and
wandered into firewall and general security technologies.  Which is the
good technology that is likely to be misused?

 .

It has been at least 10 years since the word "technology" came to mean
"post process male bovine grass and grain."  Whenever someone uses a form
of the T-word, make the appropriate substitution and notice that the user's
intended meaning is far clearer, albeit sometimes more clear than the user
desired.


Vernon Schryver[EMAIL PROTECTED]

wave wrapper!

[qtl]

Hi:
How about digital wrapper(wave wrapper?) now?I want to know it!
Where can I find the document about it?
Thank you!

Re: Storage over Ethernet/IP

[Keith Moore]

>  But, should a good technology be nixed because some idiots might mis-use it? 

no.  but an Internet protocol for accessing storage devices needs to be
able to operate in the Internet.

Keith

p.s. You might as well ask "is an insecure technology for accessing storage
devices a good thing, given that there are large numbers of idiots out 
there who assume that firewalls provide adequate security?"

Re: Storage over Ethernet/IP

[Keith Moore]

> I AM saying that if you have Internet access to your network, a firewall is 
> extremely important.

and you're wrong.  a firewall is just a tool for reducing the difficulty
of your threat analysis.  it doesn't inherently make your network more 
secure.  what makes your network secure (to the extent that it is)
is the the fact that you have done the threat analysis and blocked the 
holes that you've identified through that analysis.  a firewall can
make the job easier by reducing the number of cases that you have to
consider, but it does not make your network secure.  what's more, you
can often do this job better without a firewall than with one, because
firewalls can acutally cause security holes that didn't exist before.

Keith

Re: Storage over Ethernet/IP

[Steve Blake]

> There were some papers published duing the late '80's or early '90s by
> John Romkey and I belive Dave Clark and Van Jacobson about the length of
> instruction sequences to handle TCP.  I'm not sure that those ever became
> RFCs.
> 
> Those papers came up with figures indicating that if one structures code
> "correctly" and if the net path is "clean" (i.e. not a lot of packet loss,
> reordering, replication, etc) than the per-packet instruction sequences
> (sans IP checksum calculation) were potantially very short.
> 
> Does anyone have the references to these papers?

David D. Clark, Van Jacobson, John Romkey, and Howard Salwen, "An Analysis
of TCP Processing Overhead", IEEE Communications, vol. 27, no. 6, June 1989,
pp. 23 - 29.




=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake  <[EMAIL PROTECTED]>
Ericsson IP Infrastructure  (919)472-9913

Re: Storage over Ethernet/IP

[Robert G. Ferrell]

>If your OS is hardened enough, a firewall may not be appropriate.
>
>"New from Kellogs - Firewalls cereal - part of this *COMPLETE* and *BALANCED*
>security breakfast".

Given the recent revelations about Gauntlet, perhaps firewalls aren't quite 
the invincible bastions of unassailability they appear, as well.

RGF

Robert G. Ferrell, CISSP
Information Systems Security Officer
National Business Center, US DoI
[EMAIL PROTECTED]

Nothing I have ever said should be construed as even vaguely
representing an official statement by the NBC or DoI.

IETF Wireless

[Stuart Cheshire]

There's a good chance I may be able to persuade Apple to donate a bunch 
of 11Mb/s IEEE 802.11 Wireless/Ethernet bridges (the things we call 
"AirPort") to IETF, on a permanent basis, for the meetings.

Any interest? How many would we want? A couple for the terminal room and 
one each per meeting room?

These are absolutely standard 11Mb/s IEEE 802.11DS base stations, not 
some proprietary Apple thing. PC users can get 802.11DS cards from 
companies like Lucent: 

Lucent's web site provide a list of resellers: 


I have heard good reports about Brumleynet. They sell 11Mb/s WaveLAN 
cards for $160: 

Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer

Re: IETF Wireless

[Ole J. Jacobsen]

"...not some proprietary Apple thing."

I can verify that this is true, so true in fact that if you take an
AirPort station apart you will find a Lucent Silver WaveLAN card inside.
Only downside with AiPort is:

- You need a Macintosh to configure it

- It has no way to add extenal antennas to boost signal.

These are not necessarily show stoppers given the amount of Mac geeks
at IETFs and if you have enough of them I guess the antenna isn't
much of an issue.

Now, I have heard mentioned that the AirPort has a limit to the number
of users it will support, but I don't know if this is true or how it
compares to the usual kit we use at IETF meetings.

Ole


Ole J. Jacobsen 
Editor and Publisher
The Internet Protocol Journal
Cisco Systems, Office of the CSO
Tel: +1 408-527-8972
e-mail: [EMAIL PROTECTED]
URL: http://www.cisco.com/ipj

* See you at INET 2000, Yokohama, Japan July 18-21
  http://www.isoc.org/inet2000

Cite on DNS-related traffic.

[Craig Simon]

I recall once seeing a graph shown by Christian Huitema indicating that
DNS-related overhead accounted for about 5 to 10 percent of Internet traffic. 

Can anyone provide a link for this or equivalent documentation? 

Thanks.

Craig Simon

Re: IETF Wireless

[Derrell D. Piper]

> I can verify that this is true, so true in fact that if you take an
> AirPort station apart you will find a Lucent Silver WaveLAN card inside.
> Only downside with AiPort is:

Also, this page:

  http://www.msrl.com/airport-gold/

...has information about upgrading an Airport to a Lucent Gold card with
128-bit encryption.

> - You need a Macintosh to configure it

There is a Windows-based configuration utility that I've seen used to
configure the Airport sucessfully.  See the "Karlbridge configurator for
Windows" link on the page listed above.

Derrell

RE: Average Ethernet packet length

[Steve Dispensa]

Here are some stats from an RMON probe on one of our broadband consumer
Internet access networks.  It's sitting between our access network and our
Internet transit connections, so it sees every packet coming from or going
to the subscribers.  This represents about 7TB worth of data over the last
few months.

Packet Size Distribution
All numbers are percentages

  Downstream  Upstream
  --  
0-  64 14.68 58.49
65   -  12713.87 29.73
128  -  255 7.25  1.72
256  -  511 6.44  3.98
512  - 102313.59  3.37
1024 - 151844.17  2.70


It's interesting to note the disparity between the upstream and downstream
distributions.  I was also surprised to see that half of the packets on the
downstream are significantly larger than 576.  I just wish I had a bucket
boundary at 576+18.  Still, there's no ambiguity about the 44% of packets
that are (probably) at Ethernet MTU.

Steve Dispensa
Sr. Network Architect
Sprint Broadband Wireless Group




-Original Message-
From: Stuart Cheshire [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 25, 2000 9:10 PM
To: [EMAIL PROTECTED]
Subject: Re: Average Ethernet packet length

>There are no good, current studies on LAN behavior that I've seen.
>There have been a number of papers on WAN behavior.  The usual result
>of those is that ~40-50% of packets are about 40-44 bytes, but most of
>the bytes are carried by packets of ~500-576 or 1500 bytes.
>
>   --Steve Bellovin

In some traces I did for my PhD work about three years ago, I found that
51% of the packets were 40 or 41 bytes long (i.e. mostly TCP acks or
one-byte TCP payloads). Only 15% of the packets were maximum-sized. The
average packet size was 273 bytes. This workload was probably heavier on
telnet than today's networks; however even when doing bulk file transfer,
one packet in three is still an ack.

Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer

Re: IETF Wireless

[Roger Fajman]

> There's a good chance I may be able to persuade Apple to donate a bunch
> of 11Mb/s IEEE 802.11 Wireless/Ethernet bridges (the things we call
> "AirPort") to IETF, on a permanent basis, for the meetings.
>
> Any interest? How many would we want? A couple for the terminal room and
> one each per meeting room?
>
> These are absolutely standard 11Mb/s IEEE 802.11DS base stations, not
> some proprietary Apple thing. PC users can get 802.11DS cards from
> companies like Lucent: 

Is there a way to turn off the NAT in the AirPort access points?  We've
had trouble here with PCs using them because the NAT implementation
doesn't handle NETBIOS.  Also, given the general dislike of many people
in the IETF for NAT, it may not be something that the IETF wants to use
itself.

Re: IETF Wireless

[Dirk-Willem van Gulik]

On Fri, 26 May 2000, Stuart Cheshire wrote:

> These are absolutely standard 11Mb/s IEEE 802.11DS base stations, not 
> some proprietary Apple thing. PC users can get 802.11DS cards from 
> companies like Lucent: 

I can vouch for this; they work 100% fine with the Nortel, Baystack and
Fallaron cards (which each work on freebsd 3.x and above).

DW

RE: Storage over Ethernet/IP

[Harald Tveit Alvestrand]

At 10:14 26.05.2000 -0500, [EMAIL PROTECTED] wrote:
>True, but whether the server accesses the disks via SCSI over TCP or SCSI
>over Fibre Channel, the SERVER is still the weak link.  The transport 
>protocol doesn't create any inherent weaknesses of the type you are 
>refering to--e-mail borne viruses, internal hackers, etc.  The server 
>would still be the attack point.  Why goodness, the server and storage 
>devices could be in a VLAN or something to deny direct hack attempts 
>against the storage device, but the chink in the armor is how hardened is 
>your OS?
did you hear the story about the MIT students who broke encryption in 
Netscape by replacing the page of the binary containing the crypto 
verification code (sniffing the NFS request and replying faster than the 
real fileserver) while it was being transferred over the network?
Replacing a dedicated medium (such as a SCSI bus) with a shared medium 
(such as an Ethernet cable plant) always opens new chinks.

The point being made, remade and made again here is:
- Any IP technology will be used in contexts where there are security threats
- Any protocol that offers no means of countering such security threats is 
broken, and should not be considered for standardization.

It is perfectly possible that after conducting a threat and modality 
analysis, one ends up with saying that hardware-accelerated IPsec using 
host identities is adequate for the scenarios involving 
otherwise-unprotected Internet links, and that a mode with no protection is 
adequate when the media is physically secured.

But the analysis MUST BE DONE.

   Harald






--
Harald Tveit Alvestrand, EDB Maxware, Norway
[EMAIL PROTECTED]

Re: IETF Wireless

[Keith Moore]

> Is there a way to turn off the NAT in the AirPort access points? 

if not, seems like that would be a showstopper.

Re: IETF Wireless

[Stuart Cheshire]

I'm getting a flood of individual questions here, so I'll stem the flow 
by answering them publicly:

>That would be great. Will they sell them at a discount to the rest of us?

The current retail price of $300 is already a "discount" price. For that 
price you get 11Mb/s wireless, 10Mb/s Ethernet with DHCP client, a 56k 
modem with PPP, DHCP server on both wired and wireless interfaces, DNS 
relay, Ethernet-level bridging, IP-level routing, WEP encryption, nice 
configuration software (that runs on a Mac) and even (ugh!) a NAT 
gateway. I'll let you speculate about how much profit Apple makes on each 
unit.

For details, see .

One word of warning, before you rush out and buy one: Understand that 
Apple makes this product in order to sell more Macs (all Macs, desktop 
and laptop, come with dual antennas moulded into the plastics and a slot 
for the $99 add-on card). If, after you buy a base station, you call the 
Apple support line and start your question with, "I have this Intel 
laptop running Linux...", then they are unlikely to give you much 
sympathy. If this is a problem for you, you should avoid buying a 
wireless base station from Apple. Many other vendors, including Lucent, 
sell them too.

Bill Fenner has a page of unofficial information about the Apple wireless 
base station:


My reason for offering these to the IETF is to help the IETF, and within 
reason I will do as much as I can to help the IETF use them, including 
sitting there with my Mac laptop to configure them if necessary, but 
Apple does not extend that offer in general to every PC owner.

>the "gold" level of encryption may be important to lots of people, but as 
>far as I know, the AirPort basestations only support the weaker crypto.

AirPort base stations are fully 100% compatible with end-to-end IPSEC :-)

Besides, if you tell 3000 people at an IETF meeting the single shared 
network key, it hardly matters how many bits are in it -- it's simply not 
a secret any more.

AirPort uses the Lucent Silver card, which Lucent calls "64-bit RC4", 
even though 24 of the bits are a fixed "seed" value. Apple calls this 
"40-bit RC4", which is a little more honest.

>- It has no way to add extenal antennas to boost signal.

Not true. I know people who've drilled a little hole in the case and 
attached an external Lucent antenna to the card inside.

>Stuart, if I recall, the beacons (base stations) can't be
>configured without an Apple laptop running an appropriate
>version of the software and operating system.  Has that changed?
>If not, I have no idea whether we have such machines available
>or how we would find or scrounge one (and presumably a second as
>backup) to make the donation viable (the Lucent bridges that
>have been most often used of late can be configured from any of
>Win NT, Win95/98, or some U**x flavors).

There are unsupported tools to configure AirPorts from Windows, and I've 
even heard that there's a Java version too.

However, I'd recommend just setting them all to simple Ethernet-level 
bridging, and disabling all the other features, and then you don't ever 
need to reconfigure them again. I have several PC-owning friends who use 
AirPorts like this.

>Is there a way to turn off the NAT in the AirPort access points?  We've
>had trouble here with PCs using them because the NAT implementation
>doesn't handle NETBIOS.  Also, given the general dislike of many people
>in the IETF for NAT, it may not be something that the IETF wants to use
>itself.

Ha! Made me laugh.

Do you seriously think I'd let Apple ship a product that forced you to 
use NAT? Be serious!

Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer

Re: IETF Wireless

[Derrell D. Piper]

> Is there a way to turn off the NAT in the AirPort access points? 

Yes, there is.

Derrell

Re: 48th IETF meeting in Pittsburgh, PA

[Fred Baker]

At 10:15 AM 5/25/00 -0400, Morrisey Matthew J. wrote:
>Where can i find more info?

have you checked www.ietf.org?

Re: IETF Wireless

[Randy Bush]

>> Is there a way to turn off the NAT in the AirPort access points? 
> if not, seems like that would be a showstopper.

actually it might be a feature to torture the anti-nat bigots