Check out this link describing 802.1q also http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080094665.shtml
"In 802.1Q, the trunking device inserts a 4-byte tag into the original frame and recomputes the frame check sequence (FCS) before the device sends the frame over the trunk link. At the receiving end, the tag is removed and the frame is forwarded to the assigned VLAN." I take that to mean that even after the outside tag is removed the receiving switch (SW2 in our case) still forwards the frame based on the VLAN of that tag it just removed (VLAN 1 in our case). What makes the double tagging attack work is the fact that by the time SW2 receives the frame it only has a single tag (the inside tag of 10 in our case). This only works because of the way the native VLAN works. That is why tagging the native VLAN solves the problem. Even though the frame arrives with 2 tags, the frame is only switched based on the outside tag. On Mon, Mar 19, 2012 at 2:51 AM, Joe Astorino <[email protected]> wrote: > I'm sure there is a reason why every document ever written on the > subject says that to prevent double tagging vlan hopping attack, one > solution is to tag the native VLAN. The way I understand things, when > SW2 gets the double tagged frame, what would happen is this: > > - It identifies the frame as being in VLAN 1 from the outside dot1q tag > - It looks at the destination MAC address > - It switches the frame based on the destination MAC address and > mapping of the CAM table for VLAN 1 > - It removes the outside dot1q tag just before egress > > I could be wrong on those details, but I'm quite sure the basic > concept is correct. If tagging the native VLAN resulted in a > switching loop I don't think it would be a common solution to this > problem. All I can say beyond that is lab it up and see what happens. > Let us know what happens. > > On Mon, Mar 19, 2012 at 2:31 AM, Kingsley Charles > <[email protected]> wrote: >> Let's not go into the basics, I know that the mac addresses are not in >> 802.1q header :-) >> >> You told me that the frame will be forwarded by sw2 based on the destination >> mac address. Now when sw2 get's the frames, it strips off the outer tag of >> vlan 1 and next what does it see? It sees the inner tag and inside that is >> the actual frames which will have mac addresses. Hence sw2 will forward >> based on the inner tag not the address which means the single tagged frames >> is going to forwarded on all access ports configured for vlan 1 and the >> trunks configured with native vlan of 1. That is going to cause some looping >> of frame. >> >> With regards >> Kings >> >> >> On Mon, Mar 19, 2012 at 2:34 AM, Joe Astorino <[email protected]> >> wrote: >>> >>> MAC addresses are not stored in tags. There is only a single source >>> and destination MAC address in the frame. As far as I understand it, >>> SW2 will get the frame and will forward it based on the destination >>> mac address as usual. I have explained my understanding of the attack >>> and mitigation and that is really all I have left to say about it. If >>> anybody else has something to add I'd be happy to hear it! >>> >>> On Sun, Mar 18, 2012 at 3:59 PM, Kingsley Charles >>> <[email protected]> wrote: >>> > Which destination mac address are you referring? >>> > >>> > sw2 get's a double tagged frame, it's strips the outer tag of vlan1 and >>> > again sends on ports configured for vlan 1 and trunk ports with vlan 1. >>> > I >>> > don't see CAM table address forwarding happening as that is still inside >>> > another tag. sw2 still see that inner tag. If you claim sw2 removes >>> > that >>> > inner tag only when it sees the mac address as you said, then double >>> > vlan >>> > attack happens. >>> > >>> > Or will sw2 it strip vlan 1 as it was the default vlan and again strip >>> > the >>> > inner tag >>> > >>> > >>> > >>> > >>> > With regards >>> > Kings >>> > >>> > >>> > On Sun, Mar 18, 2012 at 11:20 AM, Joe Astorino >>> > <[email protected]> >>> > wrote: >>> >> >>> >> The outside tag was 1, the inside tag was 10 in my example. If both >>> >> switches are set for vlan dot1q tag native when SW2 gets the frame it >>> >> will switch the frame based on the destination MAC address and the CAM >>> >> table for VLAN 1. Once it finds the destination it would strip the >>> >> outside tag of 1. The end result would be you would have some >>> >> destination host or hosts in VLAN 1 get get a frame with a dot1q tag >>> >> of 10 on it, which would be abnormal but fine. >>> >> >>> >> >>> >> >>> >> On Sat, Mar 17, 2012 at 10:48 PM, Kingsley Charles >>> >> <[email protected]> wrote: >>> >> > Now SW2 gets a double tagged frames and it will be also configured >>> >> > for >>> >> > ""vlan dot1q tag native" to accept double tagged. It strips the outer >>> >> > tag >>> >> > and then what will happen to that frames? >>> >> > >>> >> > It will be sent on ports that have vlan 1 or trunk ports that have >>> >> > native >>> >> > vlan 1. So the frame will keeps looping. >>> >> > >>> >> > With regards >>> >> > Kings >>> >> > >>> >> > >>> >> > On Sun, Mar 18, 2012 at 5:49 AM, Joe Astorino >>> >> > <[email protected]> >>> >> > wrote: >>> >> >> >>> >> >> Here is how I understand the attack. Let's imagine the following >>> >> >> setup >>> >> >> >>> >> >> ATTACKER ---- SW1 --- SW2 --- VICTIM HOST >>> >> >> >>> >> >> - The switch port the attacker is connected to is an access port in >>> >> >> VLAN 1 >>> >> >> - The native VLAN from SW1 --> SW2 is the default VLAN 1 >>> >> >> - VICTIM host is in VLAN 10 >>> >> >> >>> >> >> Now, let's look at how the attack works to understand why tagging >>> >> >> the >>> >> >> native vlan helps mitigate it. Assume the attacker sends a frame to >>> >> >> SW1 looks like this: >>> >> >> >>> >> >> [dot1q VLAN 1] [dot1q VLAN 10] [DATA] >>> >> >> >>> >> >> When SW1 receives the frame, it is accepted even though the port is >>> >> >> an >>> >> >> access port because the outer tag matches the VLAN of the switch >>> >> >> port. >>> >> >> SW1 will strip off the outer tag of VLAN 1 just before it is >>> >> >> forwarded >>> >> >> over the trunk to SW2. Why? Because VLAN 1 is the native VLAN, and >>> >> >> frames that are part of the native VLAN should NOT be tagged by >>> >> >> default going over the trunk to SW2. The problem is that when SW2 >>> >> >> gets the frame it looks like this: >>> >> >> >>> >> >> [dot1q VLAN 10] [DATA] >>> >> >> >>> >> >> The frame now gets forwarded to VLAN 10 and we have accomplished our >>> >> >> "vlan hopping attack". BUT , it is important to understand that >>> >> >> this >>> >> >> is only possible if the outside tag in the frames the attacker is >>> >> >> sending is equal to the native VLAN of the trunk between SW1 and >>> >> >> SW2. >>> >> >> Otherwise, SW1 would never strip off the outer tag. This is the >>> >> >> reason why tagging the native VLAN is part of mitigating this attack >>> >> >> So... >>> >> >> >>> >> >> - If we configure the trunk to tag the native VLAN, when SW1 >>> >> >> receives >>> >> >> the double tagged frame, SW1 would never strip the outer tag, it >>> >> >> would >>> >> >> happily send the double tagged frame over to SW2 and SW2 would >>> >> >> receive >>> >> >> the frame tagged as VLAN 1, then forward it to the destination. >>> >> >> >>> >> >> - Alternatively, we can ensure to never assign an access port to the >>> >> >> same VLAN as the native VLAN. Two ways to do this: >>> >> >> - Make the native VLAN of the trunk some VLAN that is NEVER seen >>> >> >> assigned to an access port >>> >> >> - Leave the native VLAN alone, but make sure you never use that >>> >> >> same >>> >> >> VLAN on an access port >>> >> >> >>> >> >> - Additionally, you would want to make sure your end hosts can't >>> >> >> actually negotiate a trunk with the switch port by turning of DTP >>> >> >> using the switchport nonegotiate command and hard coding your edge >>> >> >> ports to be access ports >>> >> >> >>> >> >> >>> >> >> On Sat, Mar 17, 2012 at 4:27 AM, Kingsley Charles >>> >> >> <[email protected]> wrote: >>> >> >> > Hi all >>> >> >> > >>> >> >> > How does "vlan dot1q tag native" help us prevent double tagging >>> >> >> > attack? >>> >> >> > I >>> >> >> > know it can help, but I want to discuss how and where it actually >>> >> >> > does >>> >> >> > the >>> >> >> > job. >>> >> >> > >>> >> >> > Can we have a discussion :-) >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > With regards >>> >> >> > Kings >>> >> >> > _______________________________________________ >>> >> >> > For more information regarding industry leading CCIE Lab training, >>> >> >> > please >>> >> >> > visit www.ipexpert.com >>> >> >> > >>> >> >> > Are you a CCNP or CCIE and looking for a job? Check out >>> >> >> > www.PlatinumPlacement.com >>> >> >> >>> >> >> >>> >> >> >>> >> >> -- >>> >> >> Regards, >>> >> >> >>> >> >> Joe Astorino >>> >> >> CCIE #24347 >>> >> >> http://astorinonetworks.com >>> >> >> >>> >> >> "He not busy being born is busy dying" - Dylan >>> >> > >>> >> > >>> >> >>> >> >>> >> >>> >> -- >>> >> Regards, >>> >> >>> >> Joe Astorino >>> >> CCIE #24347 >>> >> http://astorinonetworks.com >>> >> >>> >> "He not busy being born is busy dying" - Dylan >>> > >>> > >>> >>> >>> >>> -- >>> Regards, >>> >>> Joe Astorino >>> CCIE #24347 >>> http://astorinonetworks.com >>> >>> "He not busy being born is busy dying" - Dylan >> >> > > > > -- > Regards, > > Joe Astorino > CCIE #24347 > http://astorinonetworks.com > > "He not busy being born is busy dying" - Dylan -- Regards, Joe Astorino CCIE #24347 http://astorinonetworks.com "He not busy being born is busy dying" - Dylan _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
