At 16:44 01.09.99 +0800, [EMAIL PROTECTED] wrote:
[implementation of 802.1q VLANs on Cisco Catalyst 2900 series]
>This has been
>discussed with Cisco and we believe that it is an issue with the
>802.1q specification rather than an implementation issue.
I disagree. IMHO, the root of the matter is the following, which
is indeed an implementation issue:
>The trunk port, along with all the other ports, must be assigned to a
>VLAN.
The trunk is shared between VLANs. Assigning a trunk port to a specific
VLAN leads to confusion between trunk frames (bearing a VLAN tag) and
non-trunk frames (not bearing a VLAN tag).
> If some non-trunk ports on the switch share the same VLAN as
>the trunk port, then it is possible to inject modified 802.1q frames
>into these non-trunk ports, and have the frames hop to other VLANs on
>another switch.
[...]
>Recommendations
>===============
>Try not to use VLANs as a mechanism for enforcing security policy.
>They are great for segmenting networks, reducing broadcasts and
>collisions and so forth, but not as a security tool.
>
>If you MUST use them in a security context, ensure that the trunking
>ports have a unique native VLAN number.
I think the second recommendation is the correct one. Logically,
the trunking ports should *not* be in any VLAN. If Cisco forces you
to assign it to one, create a separate "trunk" VLAN and assign the
trunk ports to that. This does not completely elliminate the
ambiguity, but it prevents exploiting it from a non-trunk port.
(And if an attacker has access to your trunk you're hosed anyway.)
--
Tilman Schmidt E-Mail: [EMAIL PROTECTED] (office)
Sema Group Koeln, Germany [EMAIL PROTECTED] (private)
"newfs leaves the filesystem in a well known state (empty)."
- Henrik Nordstrom
