Re: Layer 2 access and Current Practices

[John Kristoff <jtk@northwestern.edu>]

On Thu, 3 Mar 2005 15:01:31 -0500
"Howard C. Berkowitz" <hcb@gettcomm.com> wrote:


> >I think the fact that port security is not  used (per Merike's survey)
> >  in larger ISPs
> >speaks to either A) it's difficulty to use or B) it's lack of 
> >preceieved benfit.
> 
> Agreed that we can drop port security.

I can add some real world experience. Maybe it will be helpful or
maybe it'll just be interesting history to record.

Sorry I haven't been keeping up with this group, but as someone who
originally suggested and sent George some layer 2 stuff, including
some port security text a long time, I can corroborate A.

I implemented it on a number of switches at DePaul based on the
following doc (as far as I know, it's still enabled):

  <http://condor.depaul.edu/~jkristof/technotes/dpunet-rfc4.txt>

However, that doc was written before it was actually deployed and I
ended up learning A the hard way and what I really got out of it (or
B above) was not as interesting as some security folks I worked with
expected.

Determining how many addresses per port is difficult.  On the one
hand, you may need to allow end user attached layer 2 devices.  On
the other hand, your systems may support a limited number of addresses
per port.  I ended up learning up to 16 addresses per port on edge
devices like Cisco Catalyst 35xx boxes and 4 addresses per port on
chassis boxes like a Cisco Catalyst 5509.  The latter was limited to
4, because of the global port security maximum address table size
restriction you ran into with a high port density box.

I also used aging timers so that secured addresses were only locked
in for a short time to allow for hosts to move.  Not using learned
addresses wasn't even an option, because of inherent scaling and network
management issues.  I quickly realized that the minimum of 30 minutes
as recommended in the above document was much too long.  Particularly
problematic were troubleshooting situations, when one would rapidly
move the test device from port to port to verify connectivity.  I
ended up using 5 minute aging timers, which actually seemed to work
reasonably well.  It allowed for hosts to be relatively transient and
typically was enough time for a NIC replacement.  It also seemed to me
that 5 minutes would be enough of a deterrent in actually spoofing
attacks, but...

As for actually protecting anything, I never found that it actually
prevented a intentional security incident.  It did however help limit
and alert me to misconfiguration problems.  Most commonly something
would be connected in parallel or form some type of a loop at layer 2.
Having port security by default reject and log duplicate source
addresses in those cases helped spot and remedy those problems.

Also note, there is a potential problem with port security using
learned addresses, particularly if those timers are set low.  If a
host is relatively idle, the port security aging timer may expire
while the host is still connected.  An attacker on another port can
spoof that MAC address, which in effect will lock-out the legit host
when it tries to send traffic again, because now that MAC address
has been learned on another port.

Was it worth it?  Eh.  It was worth trying, but I can't imagine this
being easy to deploy in most large environments as everyone already
probably agrees with.

John