June 2008 - Test - lists.nanog.org

IPv4 source routing options and IPv6 Type 0 Routing Header
by Fernando Gont 30 Jun '08

30 Jun '08

Hello, folks, Quite a few times it has been mentioned to me that some peering agreements require support for the IPv4 source routing options. I was wondering whether this is still the case for some ISPs, or it is not the case anymore. I was also wondering if it has ever been the case that IPv6 peering agreements have required support for Type 0 Routing Header and, if it has, whether that still happens nowadays. (I guess not, but....) Thanks so much! Kind regards, -- Fernando Gont e-mail: fernando(a)gont.com.ar || fgont(a)acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

7 9

Anyone from Qwest?
by Mehmet Akcin 30 Jun '08

30 Jun '08

Anyone from Qwest senior sales team or VP can please contact me offlist? Thank you Mehmet

2 1

rib dumps
by Randy Bush 30 Jun '08

30 Jun '08

i am looking for date-stamped rib dumps going back years from a peering edge router that is fairly 'stable', i.e. multi-peer dfz but the number of peers changes infrequently. [ routeviews and ris do not meet the above description as they are not at all stable in the number of peers. ] [ your internal router which feeds off route reflectors does not meet the above description, as it is not peered externally to multiple peers. ] thanks! randy

2 1

Re: DNS and potential energy
by Martin Hannigan 29 Jun '08

29 Jun '08

This is currently a mostly capex-less exercise. I agree, the load is on operations, and likely at ICANN, VeriSign, and the DoC. We need way more detail than we have, but I hope all parties and the AC's move in a stewardship -and- commerce friendly direction with this. Even if it causes an evolution in the root -- which I believe it will. Best, Marty "Nothing like having a front row seat on the Internet". ---Mary Reindeau ----- Original Message ----- From: bmanning(a)vacation.karoshi.com <bmanning(a)vacation.karoshi.com> To: Joe Abley <jabley(a)ca.afilias.info> Cc: nanog(a)nanog.org <nanog(a)nanog.org>; Joe Greco <jgreco(a)ns.sol.net> Sent: Sun Jun 29 23:59:58 2008 Subject: DNS and potential energy On Sun, Jun 29, 2008 at 02:14:58PM -0400, Joe Abley wrote: > > The only decision that is required is whether new generic top-level > domains are desired. If not, do nothing. Otherwise, shake as much > energy into the system as possible and sit back and let it find its > own steady state. > > Joe possession and use of classV explosives is regulated in most jurisdictions. but if you think that if we pack enough C4 into the DNS and set it off, that we might find equalibrium, you might be right. :) the result will still be a flat namespace, (perhaps a crater where the namespace was). one might legitimately argue that ICANN is in need of some serious regulation.... that can happen at that national level or on the international level. --bill

2 1

Re: Mail Server best practices - was: Pandora's Box of new TLDs
by Roger Marquis 29 Jun '08

29 Jun '08

Rich Kulawiec wrote: >> Quoting <http://www.postconf.com/docs/spamrep/> : >> >> The only reliable way to avoid false-positives is by monitoring >> the email server or gateway logs and allowing end-users to receive >> a daily report of email sent to their account that was identified >> as spam and filtered. > > First, it is impossible to avoid false positives (unless you turn all > spam filtering off) or false negatives A bit of a Red Herring as nobody expects 100%. > Second, while in principle this isn't a bad approach, in reality it > tends not to work well. Judging by user acceptance, over a decade's use and several thousand users, it works better than any other method, certainly better than silently rejecting and discarding spam on the one hand, or tagging and delivering it on the other. Not that any ISP delivers everything (since ~1996). The ones that try learn a hard lesson in DOS or they lose customers (remember netcom.com) The issue isn't delivery, it's reporting, and only ISPs that inform users about _every_ rejected or discarded email are capable of effectively minimizing false positives. > It requires that users weed through the daily reports Looks like you haven't looked at the reports. Nothing in them is more difficult to parse than a large spam folder. I'm guessing you also don't intend to imply that users look in their spam folder? > and it requires accepting and storing considerable volumes of > mail which are likely spam/phish/virus/etc. You must be talking about some other system. Volumes of mail stored in spam folders are what reports _avoid_. Simple text reports take almost no disk and, for most users, a year's worth of searchable daily reports takes just a few MBs. > can make FP detection difficult, since senders do not get a > reject (mail was accepted, after all; why should they?) and thus > may be unaware that their message was dropped in a probable-spam > folder. You really should read the URL cited above, and have a look at the sample reports. Whether spam is rejected outright or discarded after delivery is not relevant since good reports list both. Users don't make a distinction either, as long as they know what was filtered. Whether to A) reject or B) accept and discard is also a bit of a red herring. Most spam will get reject by RBLs but you still _must_ run everything else through Spamassassin and AV, and there's no way to do those checks pre-queue without SMTP timeouts and DOS. Roger Marquis

1 0

RE: NANOG Digest, Vol 5, Issue 92
by mack 29 Jun '08

29 Jun '08

> > Message: 7 > Date: Sat, 28 Jun 2008 21:31:33 -0500 (CDT) > From: Joe Greco <jgreco(a)ns.sol.net> > Subject: Re: what problem are we solving? (was Re: ICANN opens up > Pandora'sBox of > To: davids(a)webmaster.com > Cc: nanog(a)nanog.org > Message-ID: <200806290231.m5T2VXob020706(a)aurora.sol.net> > Content-Type: text/plain; charset=us-ascii > [snip] > > I don't see what you're saying as supporting ICANN's actions. If DNS > is > irrelevant for these purposes, then why bother "making a bad solution a > bit > worse." Just let it become, over the next 25 years, some mid-level > directory resource that users see less and less of, until it's almost > as > irrelevant as IP address. One could make the argument this is already the case. If I want to find a particular web site for a specific local company, I usually search in google rather than try and find the web site by guessing the name. So in reality the web site name is already irrelevant for local small businesses. For large national and international companies, we can mostly depend on .com mapping correctly as they have spent large sums of money protecting their brands. Ie. mcdonalds.com maps to the fast food joint rather than some other family owned business. In 25 years a name will map to .com or be irrelevant with the current proposal. I would be happy to be proven wrong but time will tell. > > (*I* don't buy that, but then again, I'm making the argument that we've > really screwed up with DNS) > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - > http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] > then I > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > With 24 million small businesses in the US alone, that's way too many > apples. > -- LR Mack McBride Network Administrator Alpha Red, Inc.

2 1

Re: what problem are we solving? (was Re: ICANN opens up Pandora'sBox of
by Brandon Butterworth 29 Jun '08

29 Jun '08

> The problem is > that while I can go and register a "Mycompany LLC" in Wisconsin and a > "Mycompany LLC" in Illinois, there is only one "mycompany.com" available, > though "mycompany.wi.us" and "mycompany.il.us" are both available and do > not collide. 1. register .local [1] 3. n * profit! brandon [1] I know

1 0

Re: the business model, was what problem are we solving? (was Re: ICANN opens
by Brandon Butterworth 28 Jun '08

28 Jun '08

> bbc.co.uk is fine because when you access it, you are aware it is a site > designed for UK residents so when they tell you you can't access parts > of their web site, you understand. But they shouldn't have "bbc.com" for > that web site. No need to tell us we shouldn't do what we're not doing bbc.co.uk is used for UK bbc.com is used for non UK and has adverts as you non UKers don't pay brandon

1 0

Expired SSL cert for mms.nexteldata.net
by Jay R. Ashworth 28 Jun '08

28 Jun '08

According to my Blackberry, it expired last night at midnight UTC. RSA/1024, issued by Verisign. Serial number ends in 73aa 0f08 Is anyone at Nextel/Sprint/RIM listening here? My Blackberry tells me what the problem is, but for everyone on normal phones, it's probably just an error; calling first-tier support seems... unproductive. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin)

2 2

ICANN opens up Pandora's Box of new TLDs
by Tomas L. Byrnes 28 Jun '08

28 Jun '08

I just know who should be held for further processing @ the gate. Which is good enough, in this case. "What is the object of defense? Preservation. It is easier to hold ground than take it. . . defense is the stronger form of waging war" Carl Von Clausewitz > -----Original Message----- > From: Gadi Evron [mailto:ge@linuxbox.org] > Sent: Friday, June 27, 2008 8:33 PM > To: Tomas L. Byrnes > Cc: Christopher Morrow; Roger Marquis; nanog(a)nanog.org > Subject: RE: ICANN opens up Pandora's Box of new TLDs > > On Fri, 27 Jun 2008, Tomas L. Byrnes wrote: > > These issues are not separate and distinct, but rather related. > > > > A graduated level of analysis of membership in any of the sets of: > > > > 1: Recently registered domain. > > > > 2: Short TTL > > > > 3: Appearance in DShield, Shadowserver, Cyber-TA and other > sensor lists. > > > > 4: Invalid/Non-responsive RP info in Whois > > > > Create a pretty good profile of someone you probably don't want to > > accept traffic from. > > > > Conflation is bad, recognizing that each metric has value, and some > > correlation of membership in more than one set has even > more value, as > > indicating a likely criminal node, is good. > > > > YMMV. > > > > I guess, if you have perfect malware signatures, code with > no errors, > > and vigilance the Marines on the wire @ gitmo would envy, you can > > accept traffic from everywhere. > > Not quite, because you still won't know who to send the Marines to > kill. > The Internet is perfect for plausible deniability. > > Gadi. > > > > > > > > >> -----Original Message----- > >> From: Christopher Morrow [mailto:morrowc.lists@gmail.com] > >> Sent: Friday, June 27, 2008 7:23 PM > >> To: Roger Marquis > >> Cc: nanog(a)nanog.org > >> Subject: Re: ICANN opens up Pandora's Box of new TLDs > >> > >> On Fri, Jun 27, 2008 at 4:32 PM, Roger Marquis <marquis(a)roble.com> > >> wrote: > >>> Phil Regnauld wrote: > >>> apply even cursory tests for domain name validity. Phishers and > >>> spammers will have a field day with the inevitable namespace > >>> collisions. It is, however, unfortunately consistent with ICANN's > >>> inability to address other security issues such as fast > flush DNS, > >>> domain tasting (botnets), and requiring valid domain contacts. > >>> > >> > >> Please do not conflate: > >> > >> 1) Fast flux > >> 2) Botnets > >> 3) Domain tasting > >> 4) valid contact info > >> > >> These are separate and distinct issues... I'd point out > that FastFlux > >> is actually sort of how Akamai does it's job (inconsistent dns > >> responses), Double-Flux (at least the traditional DF) isn't though > >> certainly Akamai COULD do something similar to Double-Flux (and > >> arguably does with some bits their services. The particular form > >> 'Double-Flux' is certainly troublesome, but arguably > TOS/AUP info at > >> Registrars already deals with most of this because #4 in your list > >> would apply... That or use of the domain for clearly illicit ends. > >> Also, perhaps just not having Registrar's that solely deal in > >> criminal activities would make this harder to accomplish... > >> > >> Botnets clearly are bad... I'm not sure they are related > to ICANN in > >> any real way though, so that seems like a red herring in the > >> discussion. > >> > >> Domain tasting has solutions on the table (thanks drc for > >> linkages) but was a side effect of some > >> customer-satisfaction/buyers-remorse > >> loopholes placed in the regs... the fact that someone figured out > >> that computers could be used to take advantage of that > loophole on a > >> massive scale isn't super surprising. In the end though, > it's getting > >> fixed, perhaps slower than we'd all prefer, but still. > >> > >>> I have to conclude that ICANN has failed, simply failed, > >> and should be > >>> returned to the US government. Perhaps the DHL would at > >> least solicit > >>> for RFCs from the security community. > >> > >> I'm not sure a shipping company really is the best place > to solicit... > >> or did you mean DHS? and why on gods green earth would you > want them > >> involved with this? > >> > >> -chris > >> > >> > > > > >

2 2