Re: Layer 2 (stealth) firewalls - PBR?

["Paul D. Robertson" <paul () compuwar net>]

> (My answers below start with--.  This will be my last message on this 
> thread unless someone adds something new.  Rehashing fundamental layer2 
> is not interesting.)
>
> > No, just saying that I'm (a) aware of the differences in layers and (b) 
> > aware of when those differences are not treated as true boundaries.
> I don't think you are.  You do seem to be learning though.  My guess
> is you are doing a lot of research in order to answer my "challenges",
> although they haven't been personal up til now.  

Well, you can guess again, I've followed multicast networking for a number 
of years.

I've networked production traffic over more layer 1 and 2 varieties than 
most people and I'll put my experience up against pretty-much anyone.  
I'll be happy to give you an off-list selection of my directly relevent 
experience if you're interested.

I'm going to try to clean up the quoting because minus signs make it 
difficult to follow.  I'll offset portions by lines of five asterisks 
after attribution, I'll keep some of the mailer-induced quoting, but in 
case we don't get good formatting, hopefully it'll still be readable.

I originally said:
*****
> > I will refer you to RFC 4541, Considerations for Internet Group 
> > Management Protocol (IGMP) and Multicast Listener Discovery (MLD) 
> > Snooping Switches. (May 2006)
> >
> > Which says in part:
> >
> >   In recent years, a number of commercial vendors have introduced
> >   products described as "IGMP snooping switches" to the market.  These
> >   devices do not adhere to the conceptual model that provides the
> >   strict separation of functionality between different communications
> >   layers in the ISO model, and instead utilize information in the upper
> >   level protocol headers as factors to be considered in processing at
> >   the lower levels.  This is analogous to the manner in which a router
> >   can act as a firewall by looking into the transport protocol's header
> >   before allowing a packet to be forwarded to its destination address.
> >
> >   In the case of IP multicast traffic, an IGMP snooping switch provides
> >   the benefit of conserving bandwidth on those segments of the network
> >   where no node has expressed interest in receiving packets addressed
> >   to the group address.  This is in contrast to normal switch behavior
> >   where multicast traffic is typically forwarded on all interfaces.
> >
> >   Many switch datasheets state support for IGMP snooping, but no
> >   recommendations for this exist today.  It is the authors' hope that
> >   the information presented in this document will supply this
> >   foundation.
> >
> >   The suggestions in this document are based on IGMP, which applies
> >   only to IPv4.  For IPv6, Multicast Listener Discovery [MLD] must be
> >   used instead.  Because MLD is based on IGMP, we do not repeat the
> >   entire description and recommendations for MLD snooping switches.
> >   Instead, we point out the few cases where there are differences from
> >   IGMP.
*****

You replied
*****
> Paul, this is a layer 3 switch.  No wonder it can handle specialized 
> layer 3 protocols.  Most L3 switches can handle certain circumstances
> in specific ways to enhance or optimize them.  E.g. route once,
> switch many....
*****
My new reply is:
*****
Patrick, a layer three switch switches based upon layer 3 addressing 
information.  This is perfectly implementable (and has been implemented 
by several companies- links later) in a switch that only switches on layer 
2 addressing.  It's simply a method to optimize multicast performance.  In 
fact, you can Google "MLD snoping and layer 2 switches" and find all sorts 
of documentation of implementation on non-layer-3 switches.
*****
You originally said:
*****
> > but layer 2 devices such as NICs, hubs, bridges, and layer 2 switches do 
> > not rely on IP or any other layer 3 protocol whatsoever for forwarding.
*****
I originally replied:
*****
> > So, you see switch vendors really are looking into layer 3 information 
> > for multicast traffic.  Enough so that someone thought "Hey, we should have 
> > an RFC to cover this!"
*****
You said:
*****
> Yes they are.  That's because there is a huge market for L3 switches.
> Core switches had better be L3 these days.  
*****
I'm replying:
*****
Here, I'll even save you the Googling:

http://www.h3c.com/portal/Products___Solutions/Technology/IP_Multicast/IGMP_Snooping___MLD_Snooping/200702/201356_57_0.htm

(Key phrase "Before and after IGMP Snooping is enabled on the Layer 2 
device")

http://advanced.comms.agilent.com/n2x/docs/appnotes/enterprise/TestingIGMP/5989-0821EN.pdf

(Key phrase "IGMP snooping is a process whereby a Layer-2 switch passively 
listens (or "snoops") the Layer-3 IGMP traffic...")

http://www.net-o2.com/igs.asp

(Key phrase "n the recent years networking devices - specifically layer 2 
switches have been supporting the ability to derive layer 2 multicast 
group forwarding information by processing the layer 3 Internet Group 
Management Protocol (IGMP) packets.")

While I agree that there's a huge market for Layer-3 switches, and that 
core switches should be layer-3 switches, that's really got nothing to do 
with the implementation of IGMP snooping on Layer-2 switches.

*****
You originally said:
*****
> > You state "They also have to forward layer 3 broadcasts out all ports in a 
> > LAN" which is patently false--if a 128 port layer 2 switch has 64 ports on 
> > 10.0.0.0/24 and the other 64 ports on 10.1.0.0/24, then a broadcastsent 
> > to 10.0.0.0/24 will only hit the correct 64 ports.  The switch decides 
*****
I originally replied:
*****
> > That's two LANs the way I've always counted it in terms of addressing 
> > unless your'e supernetting on some devices and not on others, in which 
> > case you can count it several ways.  A dumb switch doesn't always know 
> > your mask either.  I think the algorithm for a dumb switch actually 
> > tends to be "if I don't know the destination MAC address, send it out all the 
> > ports," but I'd have to get some playtime to test it effectively.
*****
You replied:
*****
> No no no.  And no.  Yes for the last sentence--that is the basic 
> fundamental function of an L2 switch; yes yes yes, you are getting it 
> finally!
*****
I reply:
*****
Hey, you're the one who had a switch broadcasting to specific 
ports based on a subnet mask.  In fact, outside of VLANs (which limit 
brodcast domains) I don't see how your "correct 64 ports" happens.  I've 
supernetted a couple of production networks over the years (probably no 
more than three, as it tends to confuse folks) and each time I've done 
that, I've had some devices with different masks than others, so I really 
don't see how your scenerio works in an environment where you're not 
simply using one physical device as if it were two.

*****
You originally said:
*****
> > I think this is the problem.  You are confusing layer 2 unicast/broadcast 
> > frames with layer 3 unicast/multicast/broadcast packets.  Certainly layer 
> > 2 devices do unicast and broadcast, but again NOT based on IP or any other 
> > layer 3 protocol.  Layer 2 Unicast and Broadcast are all in relation to 
*****
I originally replied:
*****
> > No, I'm talking about both types, you're simply missing the case where 
> > the switch vendors peeking up the stack.  Your refusal to acknowlege this 
> > blinds you, and causes you to misinterpret.
*****
You replied:
*****
> I don't refuse to acknowledge it.  I just know the difference between an
> L3 switch and an L2 switch.
*****
I reply:
*****
Well, apparently your differences aren't the same as everyone else's 
differences. 

For instance, switch manufacturer Foundry says:

"Passive - When passive IGMP mode is enabled, the Layer 2 Switch listens 
for IGMP Group Membership reports but does not send IGMP queries. The 
passive mode is sometimes called "IGMP snooping". Use this mode when 
another device in the network is actively sending queries."

http://www.foundrynetworks.co.jp/services/documentation/sribcg/L2_multicast.html

You're telling me that this is a Layer-3 switch:

http://www.etherwan.com/products_detail.php?cat=es&model_no=EX72000

I think your definition of Layer-3 switch isn't correct, you seem to be 
defining Layer-3 switch as "any switch that looks at any Layer-3 data" 
rather than "Any switch that routes data out of a port based on layer 3 
information."

Layer-2 switches which snoop IGMP still swtich multicast data based on 
table entries, not Layer-3 addressing, so they're not acting as layer-3 
switches when they do so, even if they are capable of acting as such, 
which many are not.
*****

You said:

*****
> > IPv6 has nothing to do with layer 2.  I am going to completely ignore this 
> > statement.
*****

I replied:
*****
> > Again, I'll point you to MLD snooping.  Again, I'll admit my term of 
> > "peeking" isn't the common "snooping" that seems to be vogue, but it's 
> > still there and it's still a factor in shipping hardware.
*****

You replied:
*****
> Me chest thump now.  Do a search on ipv6 and my name.  You'll find I am
> part of the public policy making body in ARIN for IPV6, and have been for
> years.  Active too.  IPV6 is medium independant.  Neutral on layer 2.
> As is ipv4: ethernet, token ring, atm (special case here, but mostly 
> true),
> etc. etc. etc.
*****

Which has nothing to do with the fact that MLD snooping looks up the chain 
to layer 3 on a layer 2 device, as IGMP snooping does.  Now you may not be 
able to find implementations of IGMP or MLD discovery for many layer-2 
mediums, but that doesn't make it the Easter Bunny.  Real layer-2 switches 
look at real layer-3 information on real networks- no matter how much you 
want to deny it.  

Some vendors have decided if they're going to go through 
the trouble of making a switch layer-3 aware, they may as well make a 
layer-3 switch, but that's not (a) the entire market, or (b) the case 
necessary for successful implementation.  

Once again, I'll point to actual shipping product:

http://www.pcmall.com/pcmall/shop/detail.asp?dpno=7285636&Redir=1&description=D-Link-Managed%2024-Port%20Gigabit%20Stackable%20Layer%202%20Switch%20+%204%20combo%20SFP%20+%2020%20Gig%20Stacking-Switches%20/%20Hubs

Pleaase note "The DGS-3100-24 switch is a managed Layer 2 Gigabit 
stackable switch designed as feature-rich, low-cost devices in the 
entry-level network management category."

Combined with:

"The switch provides IGMP snooping and MLD snooping to control multicast 
transmission, and port mirroring to facilitate diagnostics."

Layer 2 switch, MLD snooping and IGMP snooping.    

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul () compuwar net       which may have no basis whatsoever in fact."
             http://www.fluiditgroup.com/blog/pdr/
           Art: http://PaulDRobertson.imagekind.com/



_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards