RE: Caching a sniffer

["David Gillett" <gillettdavid () fhda edu>]

  I've enjoyed this exchange too, but I think it's coming to
the end of its usefulness.

  Some of your mental conceptions of how switches and routers 
work is at odds with both my experience and the CCNA/CCNP materials
I've been studying recently.  (My current CCNA expires in May; I
plan to pass my CCNP before it does.)
  Presumably, this reflects that your experience to date has been
different from mine, and there's nothing either of us can do to
fix that.  It's like trying to reconcile particle physics with
wave physics.

  Probably as a result, your conception of how macoff (macor?)
works requires that it force a catastrophic breakdown of the
switch functionality at all levels, AND that a switch so totally
crashed fall back on operating like a hub.
  Within the conception of a switch as documented by Cisco (and 
every other source I've seen), it is sufficient for macoff/macor 
to fill up a switch's MAC table, and for the switch to stop 
learning source MAC addresses when the table fills, to achieve 
its effects -- without any interruption of the other normal switch 
processes.  This has the obvious advantage of standing some sane
chance of working on ANY switch, not just ones afflicted with a
particular semi-miraculous bug, and the less obvious advantage
of not attracting admin attention by crashing network equipment.

  I don't see any way to reconcile our two different conceptions
of the networking universe.  Do you?  If not, then maybe it's
time to let it rest and talk about something else.

David Gillett


> -----Original Message-----
> From: Shawn Jackson [mailto:sjackson () horizonusa com]
> Sent: Thursday, March 25, 2004 11:09 AM
> To: gillettdavid () fhda edu; security-basics () securityfocus com
> Subject: RE: Caching a sniffer
>
>
> >   A properly-functioning layer 3 router must decrement the 
> > TTL in the IP packet header.  It may make other changes, up 
> > to and including fragmenting the packet if necessary (and 
> permitted).
> >   Then it encapsulates it with new source and destination MAC 
> > addresses, and recalculates the FCS.  The frame that finally 
> > leaves an interface is substantially different from the one 
> > which arrived.
> >   No switch/bridge ever does that -- unless it is ALSO 
> > serving as a layer 3 router.  And while most of the switches 
> > I work with every day include that as a capability, it's 
> > turned off in the "vast majority" of cases, and the other 
> > brands of switches I've worked with have not, generally, included 
> > it by default in every box.
>
> Correct, the TTL will decrement at each hop witch rewrites the IP
> header. But a router won't change the destination or source address,
> it's mealy part of the transport chain. MAC are determined by ARP
> resolution, and are not contained in the IP header. Also routers deal
> with packets, frames exist at a lower level at the OSI which cannot be
> routed. Routers work with the network layer protocols, for 
> that is where
> the address information is stored. Now if the router is a edge router
> you could argue that the router has to rewrite the packet/frame for
> transmit over the async line. But that packet, like it is on the
> switched network is reassembled again and sent on it's way. The Frame
> Check Sequence is for the layer 2 information, the IP header, which a
> router will work on contains the checksum value for the payload. The
> systems dealing with the lower level data might rewrite the 
> FCS for the
> frame, but it's not a operation of the router which is 
> running at layer
> 3. 
>
> Check out http://www.faqs.org/rfcs/rfc791.html for IP (v4) protocol
> specs.
>
> >   Port security has nothing to do with ARP, per se.  It has 
> > to do with the number of different source MAC addresses seen 
> > on an interface. And you're correct that this breaks if you 
> > legitimately have multiple devices on a switch port (breaks, 
> > or becomes unmanageable, which sooner or later amounts to the 
> > same thing).
>
> Or MAC addresses that are not authorized. Or MAC addresses 
> that are tied
> to specific IP addresses.
>
> >   If any of this explanation is true, it describes a BUG in 
> > some specific switch implementation which is likely to be 
> > fixed by replacement with a 
> > different code release, model, or manufacturer.  If macoff 
> > relies on networks to retain buggy equipment, it's a moot 
> > point.  Filling up the MAC table with spurious addresses so 
> > that learned addresses age out and are not 
> > relearned is sufficient and does not require bizarre bugs in 
> > the switch operation.
> >   However, the transition of the port from one active MAC 
> > address to many may be detected as a network topology change, 
> > as if a switch or hub had been plugged into the port.
>
> STP (Spanning-Tree Protocol) in IEEE 802.1D relies on BPDU's (Bridge
> Protocol Data Units) to communicate regarding link statuses. Once the
> Switch (bridge) component of the switch can no longer function it is
> unable to send out BPDU's on link status for discovery to 
> other switches
> and then disable the additional route (usually with the higher cost)
> that causes the loop. If the switch can retain link-state 
> information on
> the additional route then the network would be fine. But 
> without switch
> STP would be unable to discover additional router during that 
> time. It's
> not a bug, it's protocol design and implantation. STP was originally
> intended for bridges, not switches.
>
> >   I don't think so, because I still only have one MAC address 
> > associated with my port.  I never violate the condition that 
> > port security enforces
>
> Good point, your absolutely right.
>
> Though I absolutely love the conversation (getting my butt 
> kicked), I do
> feel a little bad that we (might/are) drifting off topic for 
> a security
> (basics) list.
>
> Shawn Jackson
> Systems Administrator
> Horizon USA
> 1190 Trademark Dr #107
> Reno NV 89521
>
> www.horizonusa.com
> Email: sjackson () horizonusa com
> Phone: (775) 858-2338
>        (800) 325-1199 x338

---------------------------------------------------------------------------
Ethical Hacking at the InfoSec Institute. Mention this ad and get $545 off 
any course! All of our class sizes are guaranteed to be 10 students or less 
to facilitate one-on-one interaction with one of our expert instructors. 
Attend a course taught by an expert instructor with years of in-the-field 
pen testing experience in our state of the art hacking lab. Master the skills 
of an Ethical Hacker to better assess the security of your organization. 
Visit us at: 
http://www.infosecinstitute.com/courses/ethical_hacking_training.html
----------------------------------------------------------------------------