Re: Ethernet Security exposure???
Rich,
Do you know the difference between "in band" and "out of band" network management?
Thank you,
Roy Bynum
MCI WorldCom
Rich Taborek wrote:
> Roy,
>
> Boy this is a new one! If I hear what you're saying correctly, you are insisting
> that there is a security risk difference between SONET which intersperses management
> information periodically in its byte stream and Ethernet, which transports
> management information on demand. I assume that the equipment (e.g. switch, regen,
> etc.) which "looks" at the data has the same level of "security clearance" in both
> cases. So what exactly is the security exposure difference?
>
> If I stretch this argument the other way,
>
> Best Regards,
> Rich
>
> --
>
> Roy Bynum wrote:
>
> > Gerhold,
> >
> > One of the main reasons that the support functions of SONET/SDH are not part of
> > the data is to allow maintenance functions without having to look at the traffic
> > data. Do you want everybody to have to look at your data in order to support
> > their services? That is what would be required to have a "switch" acting as a
> > repeater/regenerator with only inband support functionality. That is a major
> > security issue that can not be resolved by 802.3 as it currently exists.
> >
> > Thank you,
> > Roy Bynum
> >
> > "Gerhold, Mark" wrote:
> >
> > > All,
> > >
> > > It sounds as if one of the biggest issues here is with the optical
> > > repeaters. If I understand correctly, Sonet repeaters are instrumented so
> > > that the administrator can isolate problems without sending out a truck.
> > >
> > > Consider using a 2-port "LAN" switch instead of a repeater. Switches today
> > > provide lots of remote maintenance features, including
> > >
> > > o Ping (for I'm alive)
> > > o SNMP (for tons of performance statistics, and alarms)
> > > o Browser management (for ease of use)
> > >
> > > With a switch, instead of transporting management info on dedicated
> > > circuits, use TCP/IP and packets. It's the histroric trend, moving up the
> > > protocol stack.
> > >
> > > Here's a question on a similar vein. Are WDM amplifiers instrumented to
> > > isolate BER problems? I thought they did optical amplification. Capturing
> > > BER info sounds tough.
> > >
> > > Thanks,(signing off)
> > >
> > > Mark Gerhold
> > > Unisys
> > >
> > > -----Original Message-----
> > > From: brian.russell@xxxxxxxxxx [mailto:brian.russell@xxxxxxxxxx]
> > > Sent: Monday, August 30, 1999 5:43 AM
> > > To: rtaborek@xxxxxxxxxxxxxxxx; HSSG GbE mail list
> > > Subject: Re: Long distance links
> > >
> > > Hi Rich,
> > >
> > > here are my veiws on the discussion and where I think a few people may not
> > > realise
> > > the break down in costs exist for a system that covers are large area.
> > >
> > > SDH and SONET have used an overhead structure because it saves them money.
> > > Sure
> > > this is at the expense of data, but the leasons learnt from the past in PDH
> > > systems
> > > make this an easy decision.
> > >
> > > From my perspective there is one main difference in what Ethernet has done
> > > in the
> > > past and what it is about to do. That's distance. Ethernet is proposing to
> > > leave
> > > the sanctuary of a building or campus which has full time support staff
> > > ready to
> > > fix any problem when it occurs. As soon as you leave this environment the
> > > cost of
> > > a problem increases exponentially, whether it be during installation,
> > > upgrade or
> > > steady state . This lesson was learnt by the telcos when they first
> > > installed
> > > optical amplifiers over longhaul links. The mantra then was "why waste
> > > bandwidth
> > > with wasteful overhead". The answer was found to be "because men in trucks
> > > going
> > > out to find the problem is expensive!". Take the numerous problems that
> > > arrise
> > > with networks over a working week. Imagine the hassle if the problem is down
> > > the
> > > road somewhere or in another country. Imagine if you are using someone elses
> > > fibre,
> > > you have a high BER and you want to fix it. The system adminisrator will
> > > laugh in
> > > your face if don't have the basic analytical tools at your disposal that
> > > SONET/SDH
> > > gives. This is where the SONET/SDH protocols save money and lots of its.
> > > That's
> > > why they are in business with substantially less people than 15 years ago.
> > > They
> > > have to live with the realisation of JCBs digging up cables, rainwater
> > > shorting out
> > > connections etc. You are not talking about an ideal office situation
> > > anymore.
> > >
> > > Imagine you are trying to place a new optical path through a system running
> > > over
> > > several links around town. If you don't have path tagging (trail trace
> > > identifier
> > > in SDH) in some form this will be a nightmare.
> > >
> > > I beleive one of the reasons why ATM did not take off in the office was
> > > because the
> > > systems people that had to use it already new Ethernet and were not prepared
> > > to
> > > changed to something that looked overly complicated for the job. That
> > > arguement can
> > > hold here in reverse. If you try to use an overly simplistic system to save
> > > a few
> > > dollars and end up with a system that is very expensive to manage and run
> > > then you
> > > will loose. If you use a system that takes on board a system that has
> > > evolved to
> > > give the best cost / benefit ratio for that application you will win.
> > >
> > > Another reason I see for using the SONE/SDH rates is that is will allow
> > > system
> > > manufactures to make cheaper systems that will seamlessly work with Ethernet
> > > and
> > > SONET/SDH at the physical layer. If you choose a different rate then thats
> > > another
> > > chipset , another system test round and thats more money and longer time to
> > > market.
> > > I realise this should not be the primary focus of this forum but systems do
> > > need to
> > > be made and the easier the better.
> > >
> > > regards
> > >
> > > brian
> > >
> > > Brian Russell Ph +353 61 49 5745
> > > Analog Devices Fax +353 61 49 5868
> > > Limerick, Ireland brian.russell@xxxxxxxxxx
> > >
> > > Rich Taborek wrote:
> > >
> > > > Andy,
> > > >
> > > > You're right on target with your assessment. I'll kick off a new thread
> > > with
> > > > this note to address the contentious issue of 10 Gbps Ethernet long
> > > distance
> > > > links. I have tried to steer the discussion on the "Deconstructing OAM&P"
> > > kicked
> > > > off by Hon Wah Chin to focus on determining what, if any, functions of
> > > OAM&P are
> > > > not supported by Ethernet. One strong point of view expressed over this
> > > > reflector is that OAM&P is the ONLY way to support long links and that the
> > > rest
> > > > of SONET/SDH is intimately tied in with OAM&P and, therefore, REQUIRED to
> > > > support long links. I'd like to point out an old saying: "There's more
> > > than one
> > > > way to skin a cat". It's crude, but appropriate.
> > > >
> > > > It is important to note that that current HSSG objectives call for support
> > > of
> > > > Ethernet links at distances of up to 40 km. The only media I'm aware of
> > > that can
> > > > achieve these distances in a single Ethernet link (i.e. without
> > > intermediate
> > > > EDFAs, regens, etc.) is singlemode fiber. I'm further assuming that the
> > > fiber
> > > > can be leased, owned, begged, borrowed or stolen as this parameter will
> > > NOT be
> > > > part of the eventual 10 Gbps Ethernet standard. Beyond this objective,
> > > there are
> > > > no related objectives nor sub-objectives to support ANY components of
> > > SONET/SDH
> > > > and/or OAM&P. Any such objectives or sub-objectives must be clearly and
> > > > concisely defined and presented to the HSSG and then voted upon by HSSG
> > > members,
> > > > attaining 75% approval in order to be considered a formal objective.
> > > >
> > > > 802.3 and the HSSG is not a telco standards forum. I'd like to make it
> > > clear
> > > > that the resoponsibility is on proponents of telco-style long distance
> > > links to
> > > > educate the 802.3 committee on aspects of SONET/SDH and OAM&P which are
> > > lacking
> > > > in Etherent and are absolutely required to meet HSSG objectives. What the
> > > 802.3
> > > > committee is very good at is architecting copper and fiber-optic based
> > > links
> > > > capable of reliably and cost effectively transporting data at distances of
> > > up to
> > > > 10s of km. In this respect, Ethernet has no match. Current HSSG objectives
> > > will
> > > > position Ethernet to go much faster and farther than the current Ethernet
> > > > standard.
> > > >
> > > > Ethernet operates significantly differently than does SONET/SDH and OAM&P.
> > > Any
> > > > discussion which points out differences between Ethernet and
> > > SONET/SDH/OAM&P is
> > > > essentially irrelevant to the work of the HSSG unless the differences
> > > cannot be
> > > > effecively acoomodated in 802.3 or elsewhere in the 802 protocol stack.
> > > >
> > > > Best Regards,
> > > > Rich
> > > >
> > > > --
> > > >
> > > > Andy Leigh wrote:
> > > >
> > > > > One of the things that is not be accounted for is that much of
> > > SDH/SONET's
> > > > > OAM&P information is carried as serial bits inside the transport
> > > overhead
> > > > > bytes. These bytes are either in use by OAM&P or are "silent". Not
> > > running
> > > > > SDH/SONET OAM&P doesn't get you back any bandwidth. It's also completely
> > > > > independent of the stream being transported. If a OC192 links is 100%
> > > > > congested carrying Ethernet frames, the OAM&P functions will still
> > > operate
> > > > > perfectly. Although accounted for in the bandwidth, this stuff is really
> > > > > "out of band" as far as the payload is concerned.
> > > > >
> > > > > Now, I think all of this is largely irrelevant. As far as I can see,
> > > what's
> > > > > being debated here is using SDH/SONET engineering to achieve long
> > > distances.
> > > > > What we're really describing is the use of SDH/SONET "repeaters" because
> > > > > these already exist. If, instead we intend 10GBE to run as a service
> > > over a
> > > > > telco's OC192 infrastructure, then just translate (L2 bridge) at the
> > > ends
> > > > > and let the Telco use SDH/SONET management tools to run their
> > > > > infrastructure, If on the other hand, we want to "pinch" chipsets and
> > > > > hardware to make 10GBE go the distance without re-inventing the wheel,
> > > then
> > > > > don't bother implementing SDH/SONET's bells and whistles...
> > > > >
> > > > > This is really not an Ethernet issue, but a Telco standards issue. I'd
> > > avoid
> > > > > it like the plague.
> > > > >
> > > > > Andy Leigh
> > > > > Senior Planning Engineer, Strategic Network Developments, New Technology
> > > > > Tel: +44 (0)171 765 0575
> > > > > Fax: +44 (0)171 765 0557
> > > > > Pager: 01893 323488
> > > > >
>
> -------------------------------------------------------------
> Richard Taborek Sr. Tel: 650 210 8800 x101 or 408 370 9233
> Principal Architect Fax: 650 940 1898 or 408 374 3645
> Transcendata, Inc. Email: rtaborek@xxxxxxxxxxxxxxxx
> 1029 Corporation Way http://www.transcendata.com
> Palo Alto, CA 94303-4305 Alt email: rtaborek@xxxxxxxxxxxxx