- Test - lists.nanog.org

h.gtld-servers.net offline...
by Will Hargrave 15 Jun '06

15 Jun '06

Unless I am mistaken, h.gtld-servers.net is offline and has been for an hour or two. I can't see the containing prefix, 192.54.112.0/24. http://www.ris.ripe.net/perl-risapp/prefixinuse.do?rrc_id=1000&Submit=Submi… Will

4 5

Re: wrt joao damas' DLV talk on wednesday
by Gregory Hicks 15 Jun '06

15 Jun '06

> From: Randy Bush <randy(a)psg.com> > Date: Tue, 13 Jun 2006 15:16:50 -0700 > To: Paul Vixie <paul(a)vix.com> > Cc: nanog(a)merit.edu > Subject: Re: wrt joao damas' DLV talk on wednesday > > > > therefore registrars (like alice's... remember alice? this is a song about > > alice) have no place to go with registrant KSK data at this time. this in > > turn keeps most registrars from bothering to collect or store this "useless" > > data. ISC proposes to accept this KSK data (in the form of DLV RRs) via > > authenticated automated processes whereby "lots of keys" can be sent to us > > by interested/participating registrars. we do not have a good way of knowing > > whether somebody is or isn't the registrant for bankofamerica.com, but we > > think that bank of america's registrar does have a way of authenticating the > > registrant. and we know how to authenticate bankofamerica.com's registrar. > > so there IS a more scalable, untouched-by-human-hands, trust path available. > > thanks for actual technalia. > > ( first, i suspect much of the confusion could come from your > thinking that the place up on skyline is *the* alice's restaurant. > it isn't. the real one was in stockbridge, mass, and rather > short-lived. so you can see why one might wonder about isc's > validation methods. :-) Actually, Paul might have been talking about Alice, Bob, and Mike. Well knows personages in cryptography circles. Alice and Bob want to exchange keys Mike is in the middle trying to figure out what alice and Bob are up to and also trying to thwart the exchange if possible. Or at the very least, gain knowledge of the keys so that Mike can read Alice's and Bob's message traffic. > > i think if you amplified on and detailed the above, and went into > how re-delegation and key changes would handled, it would go a long > way to clarifying the isc dlv registry's security process. > > you're also welcome to use some of the cctlds and other zones i > manage as outlying/strange examples. e.g. NG, which i could sign, > but neither ng nor i have an established relationship to isc. and > then i hope to get rid of it soon (been working with the in-country > folk for five years on this, and the illumination at the end of the > tunnel might be a light as opposed to a train!), and how it would > be rolled would be of interest. and say psg.com, registered > through retsiger, who we might assume, for sake of example, will > not play. > > randy > ------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3400 San Jose, CA 95134 | Internet: ghicks(a)cadence.com I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. "A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision." - Benjamin Franklin "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton

9 13

RE: Interesting new spam technique - getting a lot more popular.
by John van Oppen 15 Jun '06

15 Jun '06

We end up with customers asking for more IPs too. We just add additional subnets to the interface, perhaps they started with a /30 but now need three more IPs, we just add an additional /29 to the interface leaving both blocks. It is not often that anything needs to be explained to the customer other than the correct subnet mask and gateway for the IPs. This makes our configs look like this for each customer vlan: ip address 2.2.2.9 255.255.255.252 ip address 3.3.2.129 255.255.255.224 secondary That being said, I know at least one of our transit customers does hosting exactly how you are describing. Coincidentally, this customer is also one of the customers that asked if we could "give them a class C block." Using this strategy has never been a problem with ARIN for us, in fact I have applied for and received more space at intervals between 6 and 14 months for the last four years without any issue at all. John :) -----Ursprüngliche Nachricht----- Von: Richard A Steenbergen [mailto:ras@e-gerbil.net] Gesendet: Wednesday, June 14, 2006 12:18 AM An: Christopher L. Morrow Cc: NANOG Betreff: Re: Interesting new spam technique - getting a lot more popular. On Wed, Jun 14, 2006 at 04:46:31AM +0000, Christopher L. Morrow wrote: > > is it really that hard to make your foudry/extreme/cisco l3 switch vlan > and subnet??? Is this a education thing or a laziness thing? Is this > perhaps covered in a 'bcp' (not even an official IETF thing, just a > hosters bible sort of thing) ? Simple: Subnets are hard, customers are stupid, and ARIN is not exactly a hosters best friend. When a hosting customer asks for 5 IPs today and 25 IPs tomorrow, it is infinitely easier for the hosting folks to just slap them into /24s and say "ok uhm you are now .69-.94" than to try and explain subnets, cidr, reserving IP space in cidr sized blocks etc to the customer. Hosters are also generally under-equipped in the paperwork and detailed documentation department, so they tend to run their IP allocations into the ground while attempting to explain their need for more space. CIDR allocations are "wasteful" to them, especially when a customer needs to expand from 30 IPs to 35 IPs and crosses a new boundry. Incase you've never seen hoster configs, they generally look a little something like this: ip address 1.1.1.1 255.255.255.0 ip address 1.1.2.1 255.255.255.0 secondary ip address 1.1.3.1 255.255.255.0 secondary ip address 1.1.4.1 255.255.255.0 secondary ip address 1.1.5.1 255.255.255.0 secondary ... Anything else is quite honestly beyond 99% of hosters out there, they're still blissfully calling these things "class c's". I've seen some truly godawful thins configured by hosters, like chains of 3548s all linking back to a single router interface in ways you can't even imagine. If you made it dirt simple for them they would probably be doing something better (I usually point folks who ask to pvlans, then take the opportunity to make a hasty retreat while they are distracted), but otherwise they don't see the benefit in it. Why bother configuring your router better when you can just send your $5/hr monkey over with a redhat cd and have them reinstall, right? :) -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

3 2

IPv6 Transit?
by Mat Sharpe 15 Jun '06

15 Jun '06

Hi, Does anyone have any info on IPv6 deployment at the Tier-1 / Tier-1.5 level? We are multi-homed to both Level3 and Abovenet in the UK and Level3 only in the US. Level3 did have a promising sounding beta program last year but that seems to have stalled. Abovenet apparently have no schedule to deploy v6 at the moment. I would like to be able to v6 enable our network but without a transit provider that’s going to prove a bit tricky. Any thoughts appreciated! Cheers, Mat Sharpe Qube Networks Ltd P.S. I hope I’m not about to re-start the who is/is not a Tier-1 / Tier-2 argument! :)

7 6

Re: Interesting new spam technique - getting a lot more popular
by Hank Nussbacher 15 Jun '06

15 Jun '06

> * A spamware daemon is installed on the dedicated server, to keep >the network interface in promiscuous mode > > * The daemon determines which IP addresses on the local subnet are >not in use. It also determines the addresses of the network routers. >One or more unused IP addresses are commandeered for use by the >spammer. > > * The perp server sends unrequested ARP responses to only the >gateway routers, so that the routers never have to ask for a layer-3 >to layer-2 association -- it's alway in the ARP cache of the routers. >Nobody else sees this traffic in an EtherSwitch fabric, so ARPWATCH >and its kin are defeated. Pings and traceroutes also fail with "host >unreachable.". The daemon then only has to watch on the NIC, in >promiscuous mode, for TCP packets to the hijacked address on port 80, >and pass them down the tunnel to the remote Web server. > > * Finally, GRE and IPIP tunneling is used to connect the stolen IP >addresses to the spammer's real servers hosted elsewhere. > >The end result is that the spammer has created a server at an IP >address which not even the owners of the network are aware of. And if one went to http://www.senderbase.org/ and monitored their own IP block, wouldn't the spammer appear there? Or just plain monitoring spikes in outgoing port 25 traffic should alert someone that something is amiss. -Hank

1 0

RE: Interesting new spam technique - getting a lot more popular.
by Church, Chuck 14 Jun '06

14 Jun '06

Since this technique requires a IPinIP or GRE tunnel, wouldn't blocking these two protocols to/from the hosts be sufficient? Assuming of course the customer's host isn't using that normally. Chuck Netco Government Services has recently acquired Multimax and is changing its name to Multimax Inc. Visit http://www.multimax.com for more information.

3 2

Re: wrt joao damas' DLV talk on wednesday
by Paul Vixie 14 Jun '06

14 Jun '06

> Is there a better way to have handled the situation? Perhaps. indeed, i should have registered as a speaker and sat behind joao while he spoke. > The positive outcome of this issue is that we are discussing how to handle > "drop-ins" (freebie conference attenders?). agreed, there's a salient issue underlying all of this chaff. for example, if someone only wants to come to nanog for the hallway discussions and not attend any of the meetings or bofs (or eat any of the food, or use the wireless), are they welcome? before last week i'd've said "yes." manners in this case means "what should others be allowed to do" rather than "what each of us would like to be able to do", or in other words, "what will scale?" > I still don't see that you fall into this category with regard to this > incident. from my personal e-mail so far, that view is in the minority. ("this is not your grandfather's nanog.") on the other hand i really would rather talk about DLV than "meeting manners."

13 27

wrt joao damas' DLV talk on wednesday
by Paul Vixie 14 Jun '06

14 Jun '06

i intended to be present for the Q&A after joao's DLV talk but i was told that being there without having registered was rude. as i was exiting the room, i heard sam weiler at the Q&A mic repeating his prior comments as to how ISC should not be a DLV registry, and i saw mark kosters in line at another mic probably as a followup to my followup to his earlier question. i apologize for the length of this note, and for the fact that it says more about DNS bits and kibble than anybody really ever wanted to know, and also for my rudeness in attending joao's talk without having registered for nanog. first, sam weiler's question. let me answer, here on the mailing list where rudeness is an art form, that ISC intends to follow through on DLV. while we solicited (and got!) much design input (from sam weiler among others including david conrad who gave me the idea for DLV in the first place), ISC holds "change control". this isn't an IETF effort. just a cooperative based on some source code. both the source code (bind9.3 and bind9.4) and the DLV specification are completely forkable in the BSD tradition-- anyone else who wants to do this differently is welcome to any of the ideas or code ISC has published. and if someone else with similar resources and similar trust tells me that they are going to run a DLV registry (starting immediately-- ours is open NOW) then we would possibly re-evaluate the need to do a DLV registry inside ISC. none of that appears likely. to me, continued nondeployment of dnssec is what seems likely, seasoned with periodic 11th hour "oh no, the secure dns spec isn't done, let's re-open all the issues we thought were closed" parties. sam also wanted to know how ISC planned to verify zone ownership for the purpose of knowing whether or not we should accept a proferred key for, say, "bankofamerica.com". i think sam also echoed randy bush's earlier concern as to how we would secure our DLV registry against data loss, hacking, and so on. joao damas already answered those, and he's the programme manager for DLV, so we can all trust his answers. so i've heard sam's comments before, and had i actually registered for nanog i would surely have answered them as i've answered before, and now you all know what i would have said. second, mark kosters' additional question. i have no idea what mark kosters' additional question was, but if it had to do with my followup to his previous question, it was probably "what's the real difference, if any, between a TLD registry putting their key in ISC's DLV registry vs. running a DLV registry themselves?" if so, then i'm glad he asked, it's a favorite topic of mine. if a TLD registry (such as mark kosters' employer, verisign, for "COM" and some other TLDs) wants to sign their zone but their desire is irrelevant because the root zone is not yet signed, then they could meet some of the same requirements by sending ISC a DLV RR. their customers (VIX.COM in my case) would not have to do anything special -- we could just sign our zones and send our keys to our registrar (alice's registry in my case) who would then forward them to the TLD registry via some proposed EPP extensions. this is the best case scenario since there's only one key held by DLV, which is the one for COM, and once IANA gets around to signing the root zone, the only change will be that verisign will send its COM key to IANA rather than to ISC. no registrar or registrant ("zone holder") would have to know or make any changes to their software or procedures. if on the other hand a TLD registry (such as verisign) was not planning, for reasons such as subdomain enumeration or size-of-metadata (both of which are proposed to be solved by NSEC3, now in early preproduction), to sign their TLD (for example, COM), then that registry would have no key to send to IANA (if the root was signed) or to ISC for the DLV registry (if the root remains unsigned, as appears likely for the near term.) in this less-than-best case, registrars could send ISC blocks of registrant keys for the DLV registry, or registrants could send ISC zone keys directly. the reason this is less-than-best is that ISC would have to verify zone ownership before publishing a zone's key, unless we can get registrars to do this for us and send us blocks of keys). since we aren't charging any fees for DLV registrations, we're currently putting the burden of proof of zone ownership on the zone owners. (they have to contact joao damas or come to ISC's main office and present credentials, ideally using strong-chain PGP.) there is some question in my mind as to why a TLD registry would choose to run a DLV registry rooted at their TLD, rather than just signing their TLD. perhaps it's because DLV, even as ugly as it is, avoids the same subdomain enumeration ("zone walking") and metadata-size problems that NSEC3 avoids, but DLV is in its late stages whereas NSEC3 is in its early stages. or perhaps a TLD registry might not want to see other companies, even 501(c)(3) public benefit companies like ISC, carrying data for their registrants or having direct relationships with their registrants and registrars. i dunno. but to now repeat my earlier answer with this additional context: if every TLD registry wants to run its own DLV registry, then the world's validator population will probably experience "cut and paste fatigue". there are about 250 TLD's, and there are potentially many millions of validators. if one TLD per month needs to update its static DLV validation key, that's a whole lot of cutting and pasting that'll never happen after month 2 or so. that's why a clearinghouse, such as IANA for the root zone as called for in the dnssec-bis specification, or ISC's DLV registry until the root zone is signed, is necessary. ISC's actions in undertaking this without sharing change control in the usual IETF way have been called controversial. my advice to those of you who think we are doing the wrong thing is, pick one of the following and execute: 1. figure out why the root zone isn't signed and fix whatever it is. 2. design your own version of DLV (as sam weiler has done, long before ISC's although i didn't learn this until later), publish it, and urge adoption (find someone to run a DLV registry, implement the validator side, and so on.) 3. rubber-stamp ISC's DLV design, adopt our BSD-licensed source code for the validator side, start your own DLV registry. 4. go to IETF and say "i think something DLV should be a standard but i don't like ISC's, so let's make an RFC together." what you should note in common with all of these things is that ISC could never prevent alternatives from coming into existence (nor would we wish to), and indeed all of our work on DLV is directly forkable/leveragable by any alternative effort, even potentially proprietary or commercial ones. so, go for it! (my concern is, DLV is an evolutionary dead end, a deployment aid, and pissing away even more time and money on it seems like a waste of time compared to finishing NSEC3, signing the root, y'know, important stuff.)

12 20

RE: Interesting new spam technique - getting a lot more popular.
by John van Oppen 14 Jun '06

14 Jun '06

It sure seems like this is a good demo of the best practice of having customers on their own VLANs with their own subnets. We have been doing this since we started offering colo services, is this less common than I thought? John -----Ursprüngliche Nachricht----- Von: Christopher L. Morrow [mailto:christopher.morrow@verizonbusiness.com] Gesendet: Tuesday, June 13, 2006 9:23 PM An: Suresh Ramasubramanian Cc: NANOG Betreff: Re: Interesting new spam technique - getting a lot more popular. On Wed, 14 Jun 2006, Suresh Ramasubramanian wrote: > That was not my advice btw - just forwarding on what I saw. > oh,. apologies, i did cut the message down quite a bit :( I understood you were quoting from the spamdiaries website, I apologize to the other listeners (readers?) if it confused the issue. > What you say does seem like a "must do" all right - but putting ARP > filters in is actually a reasonable idea. > Atleast it'd trim down the 'problem' to the single customer subnet, I assume that dedicated hosting folks don't just drop machines behind a switch on one big flat subnet? That's probably a naive assumption though :( Perhaps this is clue #12 that that is a 'less than good' option? :) > On 6/14/06, Christopher L. Morrow > <christopher.morrow(a)verizonbusiness.com> wrote: > > > > On Wed, 14 Jun 2006, Suresh Ramasubramanian wrote: > > > > > > http://thespamdiaries.blogspot.com/2006/02/new-host-cloaking-technique-used… > > > > > > * Monitor your local network for interfaces transmitting ARP > > > responses they shouldn't be. > > > > how about just mac security on switch ports? limit the number of mac's at > > each port to 1 or some number 'valid' ? > > > > > -- > Suresh Ramasubramanian (ops.lists(a)gmail.com) >

3 2

re" howto deploy DNSSEC [was: Re: wrt joao damas' DLV talk on wednesday]
by Martin Hannigan 14 Jun '06

14 Jun '06

>I'm ashamed to call myself a participant in NANOG, IETF and ICANN. > >every once in a while I get to participate in something that moves >forward the network just a bit; > >please refrain from this thread -- a few folks are attempting to >move DNSSEC ahead; we will fail, but would appreciate any >constructive criticism on the pitfalls to deploy before we are all dead. > > >-rick I'm not. Consensus usually comes after the party, not before. -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan(a)renesys.com

2 1