Wait a minute! You are mixing apples and oranges, and while that's a
good basis for fruit salad, it shouldn't be used to say that token ring
topology poses problems for firewalls. Source route bridging is TR's MAC
layer way of getting communications across the various segments that make
up a site's LAN. I think we are talking about TCP/IP firewalls, which
would mean that any partitioning of a LAN (or separating a LAN from your
Internet providor) calls for distinct IP networks on each side of the
firewall, and hence some routing function. SRB is terminated at the
router. You won't see an RI field that shows packet A coming from
"segment 001 via bridge 1, 002 via *router* XXX.XXX.XXX.XXX".
Now, if you want to tell someone that SRB is not scalable and rather
stinks in a WAN environment......
Frank Senter
Senior Information Specialist
Missouri Highway and Transportation Department
P.O. Box 270
Jefferson City MO 65102
On Thu, 7 Dec 1995, Paul Ferguson wrote:
> At 03:53 PM 12/7/95 EDT, dnewman @
mcgraw-hill .
com wrote:
>
> >
> >>The link layer (Token Ring/Ethernet/PPP) should not make any >difference to
> >>your firewall. If you go for the proxy firewall, it makes 0 difference,
> >>only some packet filter types might have trouble if they've only been
> >>implemented to support Ethernet frames. ie it won't be of concern to your
> >>ciscos if you include them as part of your firewall.
> >
> > Source route bridging is far more prevalent in token ring shops than
> > Ethernet ones. Having seen much ink spilled on the security problems
> > that source routing introduces, I'd be curious to learn how vendors of
> > token ring-capable firewalls deal with the issue. Is the answer simply
> > to block all SRB frames? Is that a secure enough and flexible enough?
> >
>
> Well, I would suggest to you that you simply *not* do SRB at all.
> Route the traffic, or if its currently unroutable, migrate to something
> that *is* routable.
>
> Seriously, the framing does enter into the equation in other ways. For
> instance, the default frame-type in Netware 3.1x environments was one
> thing, now in 4.x it something else. :-)
>
> However, if its *routed* and not bridged, it becomes much more of a
> palatable exercise to filter traffic. I would also suggest that access
> control at layer 3 is much less CPU intensive than at layer 2. To
> generically state that 'it won't be of concern' is the Wrong Thing.
>
> My $.02.
>
> -paul
>
>
> --
> Paul Ferguson || ||
> Consulting Engineering || ||
> Reston, Virginia USA |||| ||||
> tel: +1.703.716.9538 ..:||||||:..:||||||:..
> e-mail: pferguso @
cisco .
com c i s c o S y s t e m s
>
>
Follow-Ups:
|
|
