> -----Original Message----- > From: Ron DuFresne [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 21, 2002 23:00 > To: Noonan, Wesley > Cc: [EMAIL PROTECTED] > Subject: RE: beating dead horses: Catalyst 4000 VLAN issues > <snip> > Who got who's attention?
Oh, no doubt you got mine. As I said, I don't like people misrepresenting my statements. You are no exception to this. > Like it or not, you non-stance on the issue in > fact is a stance. Fine, here is my stance. 1) Use hubs. They are cheap and it makes it easy to sniff all the traffic on the DMZ. I like that for things like IDS implementation. 2) If making it easy to sniff all the traffic on the DMZ is a security issue, then use switches. Cheaper the better. Don't get manageable switches unless you need them. 3) If you do use a switch, refrain from using VLANs that include any part of the internal network. Multi-DMZ VLANs aren't as high a priority to me, though if I had my druthers I wouldn't use them either. While there are no current issues related to traffic hopping VLANs (thanks to Ron and Paul for making this point clear), it has happened before (again, thanks to Ron and Paul for making this point clear), so why create a design where you need to worry about it? Follow the KISS principle, which states that physically separate switches are easier to maintain and manage in a DMZ environment than VLANs are. Simplicity of design can often be a security measure in and of itself. > Your rejection of historical issues is a stance. I never rejected historical issues. I rejected the crap you produced as fact when you couldn't prove or support any of it (OK, you were able to back up ONE thing which was valid at one point in time in regards to VLANs and DMZs). I am doing the same thing with this issue as well. Even now, you take a completely unrelated issue, and try to make it sound like it is in some way relevant to VLANs and DMZs. They are so not related to each other, it's pathetic. Just because a bug report uses the term VLAN, doesn't mean that it has something to do with your "VLANs and DMZs are evil" quest. On a side note, you would probably have a lot more success with your position if you left the speculation and rhetoric to the side, and stuck with simple concise facts. A number of other folks on this list did a masterful job of summing the issues and reasons for/not for using VLANs with DMZs when they left the FUD at the door. <snip> > > > > The switch was *not* doing what it was supposed to do, it was working > proper, then not then working proper then not, it was fading in and out > intermittently, often mid tcp stream; > <snip> But Ron, flooding the packets isn't the problem, no matter how hard you want to make it the problem. Flooding the packets is *by design*. > > It doesn't make you wonder how secure VLAN setup is, it makes you wonder > how > > secure switches are... then again, if someone is implementing a switch > > solely for security, they are a fool. > > > > agreed! which includes VLAN segments in a security setting, which is > after all what a DMZ is... Which *may* include VLAN segments... <snip> > > > > Correct. This is the only problem. The switch *should* have learned the > > address. That is the *only* problem. Nothing to do with passing traffic > > between VLANs, nothing to do with buffer overflows, nothing to do with > > spoofing, simply the switch should have learned the address mappings and > > didn't. > > > > had learned the MAC address it would seem, afterall it found a > destination, then the switch *forgot* what it had learned, and a number > of times the posting indicated, this was not a pre-learning issue, nor > was it a one time issue, it seemed to be indicated this was an issue that > popped in and out. Sure, it appears that the switch learns, then forgets. When it forgets, it can do nothing other than flood. Do you understand this point? The flooding isn't the problem, it's the symptom. The problem is the switch forgetting. <snip> > > Ahh, yes, ethernet, but, this was *not* an issue at all related to 802.x > specifications. It was a failing of the switch to deal with ports > properly. Wrong, it is a failing of the switch to deal with it's port to MAC address filtering properly. When that occurs (switch doesn't know what port the destination is on), per basic switch design, the switch defaults to standard Ethernet rules and function. IOW, it acts like a hub, flooding packets to all ports. Do you really not get this? I have been pretty snotty with you about it because, well... because I figured you had to know this and you were simply being an ass about it and I know you have thick skin. The more I read though, the more I am wondering if you really don't know this about switches, and rather than taking cheap shots at you, if I should be trying to teach you how it works... You understand that switches flood data to ports if they don't know what port the destination is on, right? This isn't a bug, it's an intentional design. If you want more info, I will be happy to provide it, seriously. > the packets went where they were not supposed to go, the > switch failed, it's VLAN setup failed. What??!?! Where does it say the VLAN setup failed? At what point does it say anything other than "the traffic floods to all ports on that VLAN". The VLAN has nothing to do with the problem, beyond the fact that the problem does not occur if one uses default VLAN1. The VLAN is simply an environmental variable. > Where was it mentioned that the > port sniffed was setup to read all traffic flowing across the switch, I > think it was pretty clear this was not the setup in question. And this is in response to what? There is no dispute about where the sniffer is located. You are really reaching here. > > And why again would you think this, when the "problem" has nothing to do > > with traffic traversing a VLAN? Having uninformed opinions is not a good > > practice. Making recommendations to others, based on those uniformed > > opinions is even worse. > > > > Yet, it was traversin ports it was not ment to. Wrong, but running with your statement, traversing ports <> traversing VLANs. Read up on how switches work. Besides, in the situation given (the switch does not know what port the destination is on), the switch is actually behaving EXCACTLY like it should. The problem has nothing to do with the passing of data to other ports - this is intentional and by design, and everything to do with the switch losing that port to MAC address mapping in the first place. > If the switch is failing > so, what makes one presume the switch has only those problems? So this is the heart of your position? If a switch has this problem, who says it doesn't have others? Give me a break Ron. Hell, under that logic, you can pick apart anything that has ever been exploited. Might as well go back to using sneakernet and slide rules (rulers? hell I'm too young to know and too lazy to look it up). > The VLAN > in qustion failed to function as it was supposed to do, who knows what > other issues it has, I'm sure you might well agree. No, I wouldn't. The VLAN has nothing to do with the problem, aside from the circumstance that permits the problem to occur (only happens on a VLAN other than VLAN1). The VLAN didn't fail to function as it was supposed to. The more you hammer on this, the more clear it becomes that, while you may know firewalls and Unix, you are really lacking in understanding of switch design and function. <snip> > > It has in the past, so, seeing issues of port hopping makes one feel less > positive that the switch works as designed, yes? Ron, I don't have time to chase ghosts. Apparently you do. I prefer to operate in reality. The switch isn't port hopping. It is sending data as it is designed to, given the circumstance that the switch does not know where the destination host is located. > Past issues have been > documented of packets crossing VLANS, now we are seeing packets hoping to > ports they are not destined for. I think I have addressed this point enough. You clearly do not understand how switches function, much less the nature of the bug report as it relates to switch function. > Perhaps not all the problems supposedly > fixed in past patches fixed all the issues, or then again, perhaps past > fixes introduced new issues. Of course, this is not too surprising this > we'd be seeing problems again. Afterall, switches are fairly new toys as > compared to some of the other devices we all play with, including hubs, > unix systems, that stable windows environment <cough>, and routers, etc. Yes, anything newer than 1962 sucks. Whatever... If all that old stuff was so grand, people wouldn't use new technologies (did you get the pun Ron? Don't want you to think I don't have a sense of humor) > > <chuckle> Wes, you need to inject a sense of humor into the personality > there, it helps keep from getting those fingers so stressed with blood > flow as you pound on the keys. Seriously, it helps one avoid burnout in a > tense industry. I appreciate your concern. I will endeavor to do some yoga or something alleviate my stress? Burnout isn't the issue, any more than stress or your perception that I am busting a vein as a result of this conversation. Truth be told, I think it is quite funny that me, someone that you seem to deem unworthy and lacking of skills, could so readily and easily point out how terribly flawed your statements on this matter are. There, I guess I was a little wrong. I do see some humor in the situation. Perhaps I should use emoticons more often... Oh, and what I have found helps to avoid burnout in a tense industry... is being educated on the stuff I am responsible for. The more educated I am, the less time I find myself chasing ghosts and the unknown. The less time I chase ghosts, the more time I have to goof off on mailing lists and play foosball (trying to get out of the losers bracket... yeah, I choked like the Spurs or the 'stros...) _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
