RE: Caching a sniffer

["Shawn Jackson" <sjackson () horizonusa com>]

>   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
----------------------------------------------------------------------------