netdev - Re: [PATCH] net/vlan: withdraw VLAN ID attribute from GVRP on VLAN device stop

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F711958.5060904@ll.mit.edu>
Date:	Mon, 26 Mar 2012 21:35:20 -0400
From:	"Ward, David - 0663 - MITLL" <david.ward@...mit.edu>
To:	David Miller <davem@...emloft.net>
CC:	"jorge@...2.net" <jorge@...2.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] net/vlan: withdraw VLAN ID attribute from GVRP on VLAN
 device stop

On 03/26/2012 05:42 PM, David Miller wrote:
> From: "Ward, David - 0663 - MITLL"<david.ward@...mit.edu>
> Date: Mon, 26 Mar 2012 11:50:16 -0400
>
>> If I create an interface that is initially down, then bring it up, and
>> finally bring it back down, I think it should return to the state it
>> was in initially.  So in my opinion, either the GVRP attribute should
>> exist while the interface is down, or it shouldn't.
> You're whole argument breaks down because we definitely don't do this
> for IPv4 addresses, we'll keep receiving traffic for IPv4 addresses
> configured on that interface when received on other interfaces which
> are still up, even when you bring that interface down.

... but that also seems to work if you never bring the interface up.  I 
can create a dummy interface, set an IP address on it, and immediately 
receive traffic on that IP address from another interface, without ever 
having brought the dummy interface up.  (The behavior after setting the 
interface down is the same as before the interface was ever brought up.)

Instead with GVRP, I create an interface and set the GVRP flag on it, 
but GVRP does not declare the attribute for that VLAN until you bring 
the VLAN interface up the first time.  However it doesn't withdraw the 
attribute when you bring the VLAN interface down, only when you delete it.

So to approach this differently -- would there be anything wrong with 
GVRP declaring the attribute as soon as the GVRP flag is set, even if 
the VLAN interface has not come up yet?  The user might do this to 
deliberately give the switching infrastructure a head start, so that 
(for example) the IPv6 DAD packets that are sent as soon as the VLAN 
interface comes up make it to all participants on the LAN...right now 
you can't do that.  You could still choose not to set the GVRP flag on 
the interface until you bring it up, similar to what you were saying.

Then each attribute declaration event would have an opposite attribute 
withdrawal event.  This means if we tried to create an attribute that 
already existed and wasn't in the "leaving" state, it would alert us to 
a bug.

Thoughts?

David

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4558 bytes)