Re: Layer 2 (stealth) firewalls - PBR?

[Patrick Darden <root () armc org>]

Paul, I will answer below.


On Tue, 8 Apr 2008, Paul D. Robertson wrote:

> On Mon, 7 Apr 2008, Darden, Patrick S. wrote:
>
> > Except that a layer two device can't tell if something is multicast or
> > broadcast or unicast or Anything in ipv4 or ipv6....  That's sorta the
> > definition of a layer two device.  If it could discriminate amongst
> > layer 3 traffic, it would be a layer 3 device--a router, firewall, etc.
>
> I've been doing networking since the broadband/baseband LAN thing a long
> time ago, and I'm pretty cognizant of how it all works...


Chest thumping.  Gotchya.


> Layer 2 devices like switches have to forwrd layer 3 multicast packets out
> ports for the multicast group, so they in essence have to peek up a layer
> even though they're not "routers, firewalls, etc."  They also have to
> forward layer 3 broadcasts out all ports in a LAN or VLAN, once again
> without being "routers, firewalls, etc."

Layer 2 devices forward based on MAC addresses.  End of story.  They do 
NOT peak up the stack.  ARP/RARP bridges the gap between layer 2 and 3, 
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.

You seem to be conflating layer 3 multicast/broadcast/unicast Packets with 
broadcast/unicast Frames.  To begin with, packets are not frames, and 
layer 2 devices cannot interpret packets.

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 broadcast sent 
to 10.0.0.0/24 will only hit the correct 64 ports.  The switch decides 
this on the layer 2 level, not the layer 3 level.  Based on MAC addresses. 
The thing is, the frames the switch gets have MACs in them.  Based on the 
ARP table.  And the switch uses these MACs to forward the frames.


> Finally, there are alyer 2 broadcasts and layer 2 multicast addresses.
> I'd suggest a Google of "layer 2 multicast addresss" for your increased
> edification, and a good read of the IPv6 RFCs- because if you don't think
> this stuff is going to be where "interesting" attacks and "poor
> implementations" happen...


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 
collision domains: a unicast is a frame transmission out one collission 
domain (one port) perhaps multiple times (several unicasts in the case of 
a layer 3 broadcast/multicast), whereas a broadcast is a frame transmision 
out all collission domains (flooding all ports with the frame, usually in 
the case of a frame containing an unknown MAC).

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

This is a quote from Cisco's CCNP literature that might help you 
understand layer 2 a little better:
(http://www.ciscopress.com/articles/article.asp?p=101629&seqNum=2)


A switch is basically a multiport transparent bridge, where each switch 
port is its own Ethernet LAN segment, isolated from the others. Frame 
forwarding is based completely on the MAC addresses contained in each 
frame, such that the switch won't forward a frame unless it knows the 
destination's location.
.
.
.
The entire process of forwarding Ethernet frames then becomes figuring out 
what MAC addresses connect to which switch ports.
.
.
.
Incoming frames also include the destination MAC address. Again, the 
switch looks this address up in the address table, hoping to find the 
switch port and VLAN where the address is attached. If it is found, the 
frame can be forwarded on out that switch port. If the address is not 
found in the table, the switch must take more drastic actionthe frame is 
forwarded in a "best effort" fashion by flooding it out all switch ports 
assigned to the source VLAN.




> 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
_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards