Jay Pike writes: > Second, the reason for the modification to this changes comes as a > suggestion from Sun's "Solaris Operating Environment Network Settings > for Security" blue print > (http://www.sun.com/blueprints/0603/816-5240.pdf):
That looks like an S9 document, and I'm pretty sure I didn't review its recommendations. I don't know who did. I simply disagree with the author's suggestions in this case. I don't think they do anything worthwhile to improve security, and they obviously do bad things in terms of interoperability and stability. > ... and this could very well be the problem we are seeing. > > "The thought is this, by changing the parameter mentioned previously > (ip_ire_arp_interval) to 1 minute, you were > causing arp entries to timeout, and the IPMP packets were being delayed while > the server waited for its arp request > to be answered." Yes. > > Those disruptions, in turn, can cause IPMP to detect failures and may > > cause other problems. > > Exactly what is happening with our issue. > > But, by changing this value to 20 minutes, aren't we in effect just reducing > our frequency to 1/20th of > what we're currently seeing? Only if it were evenly distributed in time and linear with respect to traffic intensity, I think. > I would expect that if an ARP request was not answered in a specific amount > of time, that the protocol > stack on the source host would retransmit. Why does 1 minute versus 20 > minutes resolve this issue? The main effect it'll have is multiplying the ARP traffic intensity by at least 20. Note that those messages are broadcasts. It's not uncommon for routers and switches to have rate limits on both broadcast messages and on ARP messages -- due to poor behavior on some hosts. I don't have detailed information about your network, but if I had to guess, I'd think you were pushing that rates up to the point where the ARP queries and/or responses were simply being dropped by someone, leaving many of the ARP entries unresolved. Hitting one of those limits is usually a non-linear effect. It's not as though you typically lose one packet at rate X and 20 packets at rate 20X. > > On the other hand, it's hard to see what additional security could be > > bought with a change in this parameter. ARP itself has no security at > > all, so generating more queries on the wire doesn't mean that we'll > > have data that's any less vulnerable to attack by someone with direct > > access to the network and the ability to forge ARP messages. > > Well, I whole-heartedly agree with this observation. If the physical network > has been compromised, the degree of security this provides is near meaningless > given the multitudes of other types of attacks that could be utilized at this > layer in the IP stack. My administration rule is simple: when in doubt, don't tune. It's the vendor's problem to come up with well-thought-out default values, and it's a bug if the system doesn't perform well (in terms of security and other metrics) when everything is left unchanged. It becomes *my* problem if *I* give in and tweak something unnecessarily. ;-} -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
