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