Frankly, I'm very dubious about any security scheme based on MAC
address alone, for wired or wireless networks. At best, it's
controlling which device can plug into a port, using an identifier
that can be spoofed without all that much effort. The MAC address
proves absolutely nothing about the identity of the person using the
device. I'm really not sure what problem, in most cases, it solves.
Once the device is connected, there are no controls.
Data link level encryption does make sense for wireless networks.
If I am concerned about random devices plugging into a LAN and doing
evil, I'd much rather that they have to connect to an authenticating
proxy server, or let them in but control server access, or require
encryption with authentication of the user ID. There are other
methods for controlling broadcast attacks.
>Regarding layer 2 security, it all comes down to how much of an
>administrative load you can handle. We have one customer that locks each
>port down to the MAC address of what is supposed to be there. No
>unauthorized traffic is allowed to touch the network beyond the switch port
>which just drops it. They very rarely if ever have moves, and when they do
>it all has to be coordinated with the lan/switch netadmin. I hate it
>because I can't just come in and plug in my laptop anywhere ;-p
>
>Of course, this wouldn't work with an IP phone install where you're expected
>to be able to move phones all of the time. I'm sure there is some way to
>create a list of MAC addresses (and maybe tag them with an appropriate VLAN,
>like a generic "PUBLIC" VLAN for all unknown MAC addresses, which is
>essentially firewalled from the rest of the network). Still, this same bug
>would have melted a network configured as such.
>
>
>--
>Jason Roysdon, CCNP+Security/CCDP, MCSE, CNA, Network+, A+
>List email: [EMAIL PROTECTED]
>Homepage: http://jason.artoo.net/
>
>
>
>""Priscilla Oppenheimer"" wrote in message
>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>> Taking a step back, she asked, "so what's with this 802.1x standard,
>> anyway?" Is anyone actually using it?
>>
>> Data-link-layer security definitely makes sense for 802.11 wireless
>> networks. Does it really make sense for wired networks? Is the bug
>> happening with wired or wireless networks? It sounds like it's happening
>> with wired networks since the bug is with the Catalyst 5000 EARL, though
>> some of the reports have called 802.1x a wireless standard. That's pretty
>> bad that the switches forward the multicasts out blocked ports. How could
>> that have happened? Just a bug I guess.
>>
>> Back to my original question. Does security at the data-link-layer make
>> sense for wired networks? I guess there could be cases where a person has
>> physical access to an Ethernet port but is not supposed to be able to use
>> the network. Maybe in a conference room or lobby. How does the
>> authentication actually take place? Do you need to use Radius or TACACS
>also?
>>
>> And one more question, is anyone actually using Windows XP yet? I guess
>> people must be for this bug to have been found.
>>
>> Interesting thread. Would anyone care to share some "big picture"
comments
>> on the subject?
>>
>> Priscilla
>>
>> At 11:10 AM 4/17/01, Hornbeck, Timothy wrote:
>> > > Possible solution?
>> > >
>> > > * Operating systems, such as Windows XP, will attempt 802.1X
>> > > authentication by sending frames to the Authenticator PAE on the
>> > > destination multicast address 01-80-c2-00-00-0f and
01-80-c2-00-00-03.
>On
>> > > Catalyst 5000 family switches with EARL1, EARL1+, EARL1++, or
EARL1.1,
>> > > these frames will be forwarded on all ports including spanning tree
>> > > blocking ports. Because these frames are forwarded on blocked ports,
>the
>> > > network will experience a Layer 2 multicast storm.
>> > > Workaround 1: Enter the following commands to configure a permanent
>CAM
>> > > entry for 01-80-c2-00-00-0f and 01-80-c2-00-00-03 to be directed out
>an
>> > > unused port.
>> > > * set cam permanent 01-80-c2-00-00-0f mod/port
> > > > * set cam permanent 01-80-c2-00-00-03 mod/port
>> > > Workaround 2: Follow this procedure to configure Windows XP to not
>send
>> > > these frames:
>> > > a. Cick on the associated Local Area Connection under Network
>> > > Connections.
>> > > b. Click on the Authentication Tab.
>> > > c. Uncheck "Network Access Control using IEEE 802.1x."
>> > > This problem is resolved in software release 6.2(1). (CSCdt62732)
> > >
> ________
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=1003&t=911
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
