- Test - lists.nanog.org

IPSEC server at NANOG30 (fwd)
by Susan Harris 09 Feb '04

09 Feb '04

Hi everyone - here's a note from Duane Wessels, who handles many of our critical services at NANOG meetings (DNS, DHCP, caching, etc.) If you're interested in beta testing and would like to talk FTF, he's wearing a really really bright orange T-shirt and sitting in the front of the ballroom. ---------- Forwarded message ---------- Date: Mon, 9 Feb 2004 14:52:00 -0700 (MST) From: Duane Wessels <wessels(a)packet-pushers.com> Hi, We are experimenting with an IPSEC service that NANOG attendees may be interested in using to encrypt and secure their wireless traffic during the meeting. We have an IPSEC server on the meeting network and are looking for a few beta testers to try it out. We can currently work only with Linux and *BSD systems. In order to use the IPSEC server with Linux, you must have FreeS/WAN and iptables installed. BSD users should have isakmpd installed. If you'd like to try it out, or have any qwestions, please send a message to Duane Wessels, wessels at packet-pushers.com.

1 0

Yahoo DNS issue
by bcm 09 Feb '04

09 Feb '04

I need to get into contact with someone from Yahoo with a DNS related issue affecting Yahoo mail users' ability to send to a domain I manage. Any contact info off-list would be greatly appreciated!

1 0

Dumb users spread viruses
by Sean Donelan 09 Feb '04

09 Feb '04

>The 'nothing to do with me' mob are the major offenders, making up 90 per >cent of the 1,000 UK employees surveyed. This vast majority believe that >they have no part to play in preventing the spread of viruses, and that >it is the responsibility of the IT department, Microsoft or the government. >almost two thirds (60 per cent) aren't aware of even the most basic >virus-protection methods and one third claims to be too busy to bother - >even if they knew how. http://www.silicon.com/software/security/0,39024655,39118228,00.htm

18 23

Hardening a control plane
by Frank P. Troy 09 Feb '04

09 Feb '04

Hey Folks, I'm looking for information on various core network architectures that could harden a control plane or prevent/isolate the propagation of say a malformed packet/control plane issue. I know that a part of the problem can be solved with edge filtering, ebgp, defense in depth and MD5 auth, but I am looking for a solution that might involve multi-level IS-IS. Any pointers would be a help. Thanks Frank -- ========================= Frank P. Troy frank(a)troy-networks.com =========================

1 0

RE: SECURITY: Abuse & upnormal traffic in 207.218.250.181 [ev1.net]
by John Obi 09 Feb '04

09 Feb '04

Hello folks, I would like to thank everyone who helped out to get this issue resolved. Many thanks go to Mr. Alif Terranson the OpSec Engineering Manager from Savvis Communications Corporation. Thanks, -J __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

1 0

RE: Dumb users spread viruses
by Michel Py 09 Feb '04

09 Feb '04

> Robert Boyle wrote: > Please help me resist the siren song of Outlook 2003. What I retain from your very good post is that if _you_ are having trouble resisting the siren song, there is nothing to do for the typical non-technical CEO, as all they care about is feature and ease of use. Microsoft may be crap, but as long as the users are screaming for it, no problemo. After you've shown them that they can have their email, calendaring, contacts, etc in their cell phone, that their administrative assistant can manage it from the office, and that it fits in their shirt pocket and is updated quasi real-time, the sale is over. Real story: A month ago I had a non-technical customer that used her windoze cell phone to open a critical m$ word file from the basement of capitol hill. One can whine all they want about Outlook, if one does not provide a solution that looks as good IN THE USER'S MIND, one will continue so see Outlook being the dominant app and Windows being the dominant OS. Michel.

1 0

Applying HD Ratio to all IPv4 allocations
by Michael.Dillon＠radianz.com 09 Feb '04

09 Feb '04

I'm going to present the following policy change at the ARIN meeting in April. In a few days I have to submit the exact wording to ARIN and I'm looking for comments before I do this. Basically this policy loosens the rigid 80% utilization requirement in a progressive fashion to recognize the inevitable overhead of hierarchy in larger networks. 1. All requests for additional IPv4 address space shall require the efficient utilization of the sum total of all existing allocations including all space reassigned to customers, if any. 2. The HD(Host Density) ratio of the sum total of all previous allocations shall be greater than or equal to .966 and the HD ratio of the most recent allocation shall be greater than or equal to .930 in order to receive additional space. 3. The HD ratio is calculated as log(utilized IPv4 addresses) divided by log(total addresses in all previous allocations). In this formula, log refers to the natural logarithm. Rationale: The HD ratio was proposed as a way to determine allocation usage thresholds for IPv6 address allocations. For more details on this, please refer to RFC 3194 <http://www.faqs.org/rfcs/rfc3194.html>. There is some detailed background discussion about applying the HD ratio to IPv4 allocations in a proposal by Paul Wilson posted to the APNIC mailing list on Aug 7, 2003 http://www.apnic.net/mailing-lists/sig-policy/archive/2003/08/msg00000.html and he presented the it to the annual APNIC policy meeting using these slides http://www.apnic.net/meetings/16/programme/sigs/docs/policy/addpol-pres-wil… I am not suggesting that ARIN should adopt the APNIC proposal and although Paul invents a new name for the HD ratio, I prefer to keep the original term. The basic thrust of this proposal is to replace the rigid 80% usage criterion by the more flexible HD ratio and to shift the emphasis away from the last allocated block to include the total allocated address space. To that end, the .930 criterion for the last block is a lot looser than the existing requirements for the last block. This is because the utilization threshold establishes a time buffer between the beginning of an ARIN application for additional addresses and the final deployment of new addresses in the operational network. By using a looser criterion as network size grows, we are also expanding this time buffer. This recognizes that the economy is more dependent than ever on the smooth running of our networks and we should not artificially force larger members to operate with virtually no safety buffers for implementing new addresses. This safety buffer size is important because larger networks have more involved processes for changes to their network and these processes take time. Paul Wilson's paper contains ample discussions of the technical justification for using the HD ratio. I have proposed that we use the .966 number that he suggests, I believe there may be valid arguments for reducing this slightly, perhaps to .960. ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon(a)radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030

2 1

Re: Dumb users spread viruses
by John Payne 09 Feb '04

09 Feb '04

--On Sunday, February 8, 2004 10:46 PM +0000 Paul Vixie <vixie(a)vix.com> wrote: > There is nothing wrong with a user who thinks they should not have to know > how to protect their computer from virus infections. However, someone attending NANOG should at least have cleaned up slammer before connecting to the wireless...

5 5

OT - Special Interest Texas Reunion
by Timothy Brown 09 Feb '04

09 Feb '04

If you don't know what i'm talking about, just ignore this! Those of you who are interested in another Texas Reunion, in the vein of Toronto and last night, drop me a line privately today. Tim

1 0

Re: Stopping open proxies and open relays
by Simon Waters 09 Feb '04

09 Feb '04

NANOG Digest wrote: > > It would help if systems would only execute code that is signed > properly. This would make malware traceable. However the current way of > getting your code signed is in many cases too costly for the casual open > source developer so people are used to running unsigned or selfsigned > application even when the facilities to check signatures would already > exist in the system. (though for example in Windows, signatures are only > checked at install, not runtime) My supply of free software is signed by the developer/maintainer and the trust relationship established through GnuPG, and Keyservers. The OS has facilities to check these at install time if you want. You'd only need to check at run time if root had altered the executables - and he is a pretty solid chap here ;) Similarly when I distribute free software it is always accompanied by signed MD5 hash of each file distributed. So I don't think it is costly to do if you pick a suitable model. The certificate authority approach is pointless until they provide proper support for revocation, which most didn't last time I looked, but I believe it is getting better. (I'm in the cynical group who believes that the Certificate Authorities are a conspiracy to tax encryption). But typically signing only proves the authorship, it doesn't tell you anything about how well written (and thus compromisable) the code is, or how trustworthy the recipient is ('anyone the certificate authority will accept money off' - to paraphrase a comment), or how well protected their keys are. Signing is a fine approach, but I think sandboxing should take priority. Here even if the code is subverted by malformed data, the key stolen, etc etc - the damage is limited. Lots of installed copies of IE seem happy to run any "signed ActiveX" plugin - even when it is Spyware. Although I'm not clear if this is down to a bad choice of defaults, or users not understanding that even signed cheques bounce (indeed unsigned cheques don't get that far usually). One more to check and switch to 'prompt' if you still use IE. Popular spyware seems to go under inspiring names like spy.exe, trojan.exe etc, but relatively knowledgable Internet users still manage to get it installed against their wishes. I'm sure there is a more appropriate forum - but then there are probably web pages discussing it in great details. Of course neither approach excludes the other.

1 0