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