RE: Net-24 top prefix generating bogus RFC-1918 queries
Forgive me.. I thought I understood that 1918 routes were leaking Jim >-Original Message- >From: Sean Donelan [mailto:[EMAIL PROTECTED] >Sent: Monday, June 02, 2003 12:26 AM >To: [EMAIL PROTECTED] >Subject: RE: Net-24 top prefix generating bogus RFC-1918 queries > > > >On Sun, 1 Jun 2003, McBurnett, Jim wrote: >> guys.. I have a thought... >> I am a charter fiber customer.. >> AND they use lots of 1918 address for management even some >customer links. >> I have seen this on all the cable providers.. >> unlike Sprint/MCI/ATT they don't use 100% RW on all their equipment.. >> >> then they leak because the BGP is not filtering properly.. > >Uhm, incorrect. > >A DNS lookup for a RFC1918 in-addr.arpa record is unrelated to BGP or >BGP filters. > >If you want to generate an RFC1918 in-addr.arpa query to the AS112 >servers do the following > >> nslookup >Default Server: localhost >Address: 127.0.0.1 > >> set querytype=any >> 10.in-addr.arpa >Server: localhost >Address: 127.0.0.1 > >Non-authoritative answer: >10.in-addr.arpa >origin = prisoner.iana.org >mail addr = hostmaster.root-servers.org >serial = 2002040800 >refresh = 1800 (30M) >retry = 900 (15M) >expire = 604800 (1W) >minimum ttl = 604800 (1W) > >Authoritative answers can be found from: >10.in-addr.arpa nameserver = BLACKHOLE-1.iana.org >10.in-addr.arpa nameserver = BLACKHOLE-2.iana.org >BLACKHOLE-1.iana.orginternet address = 192.175.48.6 >BLACKHOLE-2.iana.orginternet address = 192.175.48.42 >> > >Your query will then be included in John's statistics. You BGP filters >will not stop it. > > >
Re: Non-GPS derived timing sources (was Re: NTp sources that work in a datacenter)
In a message written on Sun, Jun 01, 2003 at 11:57:21PM -0400, Sean Donelan wrote: > Actually my question wasn't so much about other national standards labs, > but that almost every major Internet backbone worldwide seems to trace > their time source to GPS. Maybe not that surprising for US/North American > providers, but even non-american backbones seem to use GPS. Could it be that providers actually have multiple sources, but for some reason GPS is always picked as the primary source for the public facing function? At least a few providers keep their actual sources (the receivers themselves) "hidden", and provide a unix box syncing to all of them as the front end. From my limited knowledge, that front end box will only show the one source it has picked as "best". -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: AS number consolidation
Does anyone know of case studies of companies collapsing multiple ASes into one on their network? I have the Allegiance Telecom presentation from NANOG 27 but I would like to hear how other people have done it as well. We where a number of people (most mote involve than I was) who did the 286 and 1755 merger around 13 months ago. I doubt that there is any public documentation on this. Then again, I am not sure if there is anyone who would like to claim the ownership of the documentation... - kurtis - PGP.sig Description: PGP signature
Re: Pesky spammers are using my mailbox
On Sat, May 31, 2003 at 07:16:08PM +0100, Stephen J. Wilcox wrote: > seems some spammers are using one of my personal domains as the from > field in their emails, the local-part being random so I cant easily > block it. Block *all* addresses except those actually being used[1]... I had to do this years ago for a customer who has '@foo.com -> mailbox' when some moron spammed about 10e6 messages from @foo.com and the bounces began to hurt. Dumping all but the few legitimate [EMAIL PROTECTED], [EMAIL PROTECTED] or whatever worked pretty well and the load on the system dropped radically as things we stopping early in the SMTP conversation and thus the system wasn't actually having to try to deal with much state most of the time. --cw [1] You probably also want to make sure postmaster@ works (RFC requirement) and probably abuse@ (procmail/vacation auto-responder exclaiming your innocence)
RE: Net-24 top prefix generating bogus RFC-1918 queries
On Sun, 1 Jun 2003, McBurnett, Jim wrote: > guys.. I have a thought... > I am a charter fiber customer.. > AND they use lots of 1918 address for management even some customer links. > I have seen this on all the cable providers.. > unlike Sprint/MCI/ATT they don't use 100% RW on all their equipment.. > > then they leak because the BGP is not filtering properly.. Uhm, incorrect. A DNS lookup for a RFC1918 in-addr.arpa record is unrelated to BGP or BGP filters. If you want to generate an RFC1918 in-addr.arpa query to the AS112 servers do the following > nslookup Default Server: localhost Address: 127.0.0.1 > set querytype=any > 10.in-addr.arpa Server: localhost Address: 127.0.0.1 Non-authoritative answer: 10.in-addr.arpa origin = prisoner.iana.org mail addr = hostmaster.root-servers.org serial = 2002040800 refresh = 1800 (30M) retry = 900 (15M) expire = 604800 (1W) minimum ttl = 604800 (1W) Authoritative answers can be found from: 10.in-addr.arpa nameserver = BLACKHOLE-1.iana.org 10.in-addr.arpa nameserver = BLACKHOLE-2.iana.org BLACKHOLE-1.iana.orginternet address = 192.175.48.6 BLACKHOLE-2.iana.orginternet address = 192.175.48.42 > Your query will then be included in John's statistics. You BGP filters will not stop it.
Re: Net-24 top prefix generating bogus RFC-1918 queries
lol either they deliberately announce rfc1918 via network 10.0.0.0 or redisting igp into bgp... priceless. -hc On Sun, Jun 01, 2003 at 09:20:30PM -0400, McBurnett, Jim wrote: > > guys.. I have a thought... > I am a charter fiber customer.. > AND they use lots of 1918 address for management even some customer links. > I have seen this on all the cable providers.. > unlike Sprint/MCI/ATT they don't use 100% RW on all their equipment.. > > then they leak because the BGP is not filtering properly.. > > > > -Original Message- > From: John Brown [mailto:[EMAIL PROTECTED] > Sent: Sunday, June 01, 2003 1:55 AM > To: Roland Verlander > Cc: [EMAIL PROTECTED] > Subject: Re: Net-24 top prefix generating bogus RFC-1918 queries > > > > > > > Why does 65/8 generate almost as many queries as 24/8? > > because there are lots of cable and DSL users in those > prefix's > > My cable at home is net-65 > -- Sincerely, Haesu C. TowardEX Technologies, Inc WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867
Re: Non-GPS derived timing sources (was Re: NTp sources that workin a datacenter)
On Sun, 1 Jun 2003, Marshall Eubanks wrote: > Every major time service and most national standards labs maintain a > set of clocks of comparable accuracy - US, UK, France, Germany, Russia, > Japan, Australia, etc., so there is no shortage of timing info to > compare it with. Actually my question wasn't so much about other national standards labs, but that almost every major Internet backbone worldwide seems to trace their time source to GPS. Maybe not that surprising for US/North American providers, but even non-american backbones seem to use GPS. To be clear, I'm not talking about individuals syncing things to lots of different clocks. Clock.ORG has lots of clock sources around the world. I'm talking about what network providers use. It was just one of those midnight projects a month or so ago, when I noticed my carefully balanced selection of tickers had slowly over the last few years all changed from other time sources to GPS. Probably not critical, but national standards labs have accidentily flipped the wrong switch in the past and done strange things to their time broadcasts. Yes, lots of people noticed, and it was fixed quickly. NTP has all this great logic for sanity checking time sources, but if they all come from the same origin, what happens?
Re: Non-GPS derived timing sources (was Re: NTp sources that work in a datacenter)
Hello; GPS maintains a set of its own clocks at Falcon AFB and does not really track or steer to TAI - however, they are very close in practice (except that the AF did not know about Leap Seconds when they started out and synced it to UTC in the early 1980's - thus, there is a 19 second offset between the GPS time system and TAI.) Every major time service and most national standards labs maintain a set of clocks of comparable accuracy - US, UK, France, Germany, Russia, Japan, Australia, etc., so there is no shortage of timing info to compare it with. The International GPS Service (IGS - http://igscb.jpl.nasa.gov/ - a collaboration between various geodetic and time service users of GPS - has a rapid service with information including clock offsets with 17 hours latency see http://igscb.jpl.nasa.gov/components/prods_cb.html for data availability. These solutions are NOT based on the official DOD tracking data but instead on the much more accurate carrier phase (and are not affected by either Anti-Spoofing or Selective Availability when these are turned on - see www.timingtechnologies.com/Gpswp1.pdf for a description of these degradations for civilian users). There is no doubt that a major perturbation in the GPS clocks (say, several 100 nanoseconds as is typical with SA) would be detected by the IGS within 24 hours. These was a pilot program set up to use these data for official time transfer - see http://maia.usno.navy.mil/gpst.html for a host of details. I do not know its status since Jim Ray left the USNO. GLONASS maintains another set of clocks and satellites. Of course, once Galileo is launched there will be yet another source of time sync. All of this is important if you need synchronization at 100 nanoseconds or better. LORAN will not give you this by several orders of magnitude - nor will WWVB nor NTP. If you do care about time at this level, get at least a Rubidium clock and sync it to GPS. If you do not, I would not worry about it even at the highest paranoia levels - there are other equally paranoid people who will start screaming well before you notice. On Sunday, June 1, 2003, at 09:57 PM, David G. Andersen wrote: On Sun, Jun 01, 2003 at 08:13:08AM -0700, Peter Lothberg quacked: I don't expect GPS to spin out of control soon.. So GPS tracks TAI and the difference is published (2 months after the fact..) But it's simple to build a 'jamer' that makes GPS reception not work in a limited area, same for Loran-C used in combination with GPS in many Sonet/SDH S1 devices. but I did wonder how hard it is to find a another reliable clock source of similar quality to GPS to double check GPS. For NTP purposes, WWVB is actually just fine, as long as you properly configure your distance from the transmitter. The NTP servers list shows several WWVB synchronized clocks. CDMA clocks synch indirectly to GPS, but are typically locally stabalized by a rubidium or ovenized quartz oscillator with decent holdover capabilities for a few days of GPS outages. But they'll suffer the same fate if GPS went just plain wrong. The NIST timeservers are available over the net, if you can deal with that degree of synch. Lots of them just use ACTS dialup synch to get the offset, and have very good local clocks. ACTS is certainly a good fall-back for GPS, since it uses a wired path instead of a wireless one. So if you're really paranoid: GPS + WWVB + ACTS + internet to tick/tock or one of the NIST primaries. Ultimately, WWVB, ACTS, and ntp to NIST are all synched from pretty much the same source, but the odds that they'd all go bad are pretty slim. GPS is steered from the USNO time, but the clocks on the satellites are pretty good. -Dave -- work: [EMAIL PROTECTED] me: [EMAIL PROTECTED] MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me. Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc. e-mail : [EMAIL PROTECTED] http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/
Re: Non-GPS derived timing sources (was Re: NTp sources that work in a datacenter)
On Sun, Jun 01, 2003 at 08:13:08AM -0700, Peter Lothberg quacked: > > > I don't expect GPS to spin out of control soon.. > > So GPS tracks TAI and the difference is published (2 months after the > fact..) > > But it's simple to build a 'jamer' that makes GPS reception not work > in a limited area, same for Loran-C used in combination with GPS in > many Sonet/SDH S1 devices. > > > but I did wonder how > > hard it is to find a another reliable clock source of similar quality to > > GPS to double check GPS. For NTP purposes, WWVB is actually just fine, as long as you properly configure your distance from the transmitter. The NTP servers list shows several WWVB synchronized clocks. CDMA clocks synch indirectly to GPS, but are typically locally stabalized by a rubidium or ovenized quartz oscillator with decent holdover capabilities for a few days of GPS outages. But they'll suffer the same fate if GPS went just plain wrong. The NIST timeservers are available over the net, if you can deal with that degree of synch. Lots of them just use ACTS dialup synch to get the offset, and have very good local clocks. ACTS is certainly a good fall-back for GPS, since it uses a wired path instead of a wireless one. So if you're really paranoid: GPS + WWVB + ACTS + internet to tick/tock or one of the NIST primaries. Ultimately, WWVB, ACTS, and ntp to NIST are all synched from pretty much the same source, but the odds that they'd all go bad are pretty slim. GPS is steered from the USNO time, but the clocks on the satellites are pretty good. -Dave -- work: [EMAIL PROTECTED] me: [EMAIL PROTECTED] MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
RE: Net-24 top prefix generating bogus RFC-1918 queries
guys.. I have a thought... I am a charter fiber customer.. AND they use lots of 1918 address for management even some customer links. I have seen this on all the cable providers.. unlike Sprint/MCI/ATT they don't use 100% RW on all their equipment.. then they leak because the BGP is not filtering properly.. -Original Message- From: John Brown [mailto:[EMAIL PROTECTED] Sent: Sunday, June 01, 2003 1:55 AM To: Roland Verlander Cc: [EMAIL PROTECTED] Subject: Re: Net-24 top prefix generating bogus RFC-1918 queries > > Why does 65/8 generate almost as many queries as 24/8? because there are lots of cable and DSL users in those prefix's My cable at home is net-65
Internet Surveillance and Infrastructure Protection
Did anyone attend the Telestrategies conference on Internet Surveillance and Infrastructure Protection on May 29-30 2003? http://www.telestrategies.com/internet_surveillance/index.html Internet Surveillance and Infrastructure Protection This keynote session frames the problem facing the Department of Homeland Security, Telecommunications Service Providers, Corporate IT Managers and others regarding lawfully authorized Internet surveillance and infrastructure protection. It addresses why IP surveillance and intelligence gathering is a challenging problem, how to address surveillance and infrastructure protection together, what are service providers, law enforcement officials and corporate user options to protect IP infrastructure, ROI considerations for service providers and more Did any of the speakers say anything interesting at the conference?
Re: SLC Sheraton wireless
On Sun, Jun 01, 2003 at 04:14:13PM -0400, Steven M. Bellovin wrote: > Ah, STSN. I've had to hack dhclient because some of their servers > (encountered often in Marriotts) emit options that are sufficiently > invalid to cause dhclient to discard the packets. My favorite was the STSN-in-room box crashing when presented with an NS RR query for the root. Took a while to figure out that it was crashing (and rebooting - 15-20 sec outage) everytime the nameserver on the laptop tried (unsuccessfully) to prime it's cache. lamont
Re: SLC Sheraton wireless
In message <[EMAIL PROTECTED]>, LaMont Jones writes: >On Sun, Jun 01, 2003 at 04:05:47PM -0400, Steven M. Bellovin wrote: >> I'm in the lobby; it just worked. > >Sitting in the BGP multihoming tutorial - First try had me associated with >something with an SSID of STSN-conf, which (at least then) didn't do squat >for getting out, although it happily gave me a 10.64/16 IP with DHCP. > >Changing the SSID to nanog28 made life much happier... > Ah, STSN. I've had to hack dhclient because some of their servers (encountered often in Marriotts) emit options that are sufficiently invalid to cause dhclient to discard the packets. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)
Re: SLC Sheraton wireless
On Sun, Jun 01, 2003 at 04:05:47PM -0400, Steven M. Bellovin wrote: > I'm in the lobby; it just worked. Sitting in the BGP multihoming tutorial - First try had me associated with something with an SSID of STSN-conf, which (at least then) didn't do squat for getting out, although it happily gave me a 10.64/16 IP with DHCP. Changing the SSID to nanog28 made life much happier... lamont
Re: SLC Sheraton wireless
In message <[EMAIL PROTECTED]>, "Rodney Joffe" writes: > >Is there a trick to the wireless connectivity in the hotel? Or limited coverag >e/blackholes? > I'm in the lobby; it just worked. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)
Re: Net-24 top prefix generating bogus RFC-1918 queries
On Sat, 31 May 2003, John Brown wrote: > > > > > Why does 65/8 generate almost as many queries as 24/8? > > because there are lots of cable and DSL users in those > prefix's > > My cable at home is net-65 My SBC DSL that this email is coming from is in 65. Justin
Re: SLC Sheraton wireless
> Is there a trick to the wireless connectivity in the hotel? Or limited > coverage/blackholes? No trick - you should get wireless in the lobby/bar, terminal room, Olio restaurant, soon hopefully the courtyard. Where are you :)
SLC Sheraton wireless
Is there a trick to the wireless connectivity in the hotel? Or limited coverage/blackholes?
Re: Non-GPS derived timing sources (was Re: NTp sources that work in a datacenter)
> I don't expect GPS to spin out of control soon.. So GPS tracks TAI and the difference is published (2 months after the fact..) But it's simple to build a 'jamer' that makes GPS reception not work in a limited area, same for Loran-C used in combination with GPS in many Sonet/SDH S1 devices. > but I did wonder how > hard it is to find a another reliable clock source of similar quality to > GPS to double check GPS. Short for a lab part of TAI, I really don't knew. GPS price/perfromance is fenomenal. > US clocks account for 40% of the input to TAI. In the month of April 2003; NIST was 4.662% USNO was 44.314% (and we where 0.501%...) -Peter
Re: WTF?? Was: AOL email concerns for pil.net (fwd)
[EMAIL PROTECTED] wrote: I just received 2 copies of this email from AOL's Postmaster, and it looks genuine. We filter via SpamAssassin, but do not bounce spam or virii, but divert them to separate folders. 2) Total percentage of bounces accepted by pil.net (lower than 90% acceptance): 74% I think this one is cute. Do you reject AOL bounces or is someone doing a dictionary attack spoofing your domain with random usernames and the AOL system is unable to deliver the bounced email to your system. You'd think they'd filter out the "User unknown"'s. -Jack
pool.ntp.org NTP servers
This seems like a good time to put in a plug for the pool.ntp.org NTP servers. This is collection of public ntp servers provided by individuals and ISP's placed in a round-robin DNS system. The goal is to provide the general public with a list of NTP servers that they can use without abusing the stratum 1 servers. If you can provide an NTP server to the pool, it would be greatly appreciated. The bandwidth and CPU usage of an NTP server is quite low so you can easily provide NTP services to hundreds or even thousands of users. If you create default NTP setups and you don't have good default NTP servers to use, feel free to use pool.ntp.org for one or more of your NTP sources. (You should have at least 3 NTP sources, although using more than three doesn't usually help much.) For more information, see: http://fortytwo.ch/time/ -wayne
WTF?? Was: AOL email concerns for pil.net (fwd)
I just received 2 copies of this email from AOL's Postmaster, and it looks genuine. We filter via SpamAssassin, but do not bounce spam or virii, but divert them to separate folders. The only strange activity I've seen lately is spammers getting past SA by sending spam to [EMAIL PROTECTED] via their formmail.pl scripts. Note that they're not relaying via formmail.pl; we're using a hacked version of formmail.pl that only allows recipients of domains we host, which is where they're going. This could be unrelated, though. I sent back a reply requesting a copy of an offending bounce, one of the complaints, and for their postmaster to wrap his lines at something less than the 110 characters they're wrapping at now. I've never gotten a response from an AOL postmaster in the past...is there a better way of contacting them? TIA, James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am = -- Forwarded message -- Return-Path: <> Delivered-To: [EMAIL PROTECTED] Received: (qmail 70063 invoked by alias); 1 Jun 2003 13:22:43 - Delivered-To: [EMAIL PROTECTED] Received: (qmail 70056 invoked by uid 85); 1 Jun 2003 13:22:43 - Received: from by mail.pil.net by uid 82 with qmail-scanner-1.16 (spamassassin: 2.54. Clear:SA:0(2.3/6.0):. Processed in 1.494999 secs); 01 Jun 2003 13:22:43 - X-Spam-Status: No, hits=2.3 required=6.0 Received: from unknown (HELO imo-m08.mx.aol.com) (64.12.136.163) by richard2.pil.net with SMTP; 1 Jun 2003 13:22:41 - Received: from mailops.mail.aol.com (mailops.mail.aol.com [172.20.75.176]) by imo-m08.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id JAA13696; Sun, 1 Jun 2003 09:22:38 -0400 (EDT) Received: (from [EMAIL PROTECTED]) by mailops.mail.aol.com (8.11.6+Sun/8.11.6) id h51DMbo06521; Sun, 1 Jun 2003 09:22:37 -0400 (EDT) Date: Sun, 1 Jun 2003 09:22:37 -0400 (EDT) Message-Id: <[EMAIL PROTECTED]> From: [EMAIL PROTECTED] Subject: AOL email concerns for pil.net Content-Type: text/html; charset=us-ascii X-Qmail-Scanner-1.16: added fake MIME-Version header MIME-Version: 1.0 Dear pil.net, You are receiving this message via our automated "Report Card" process (which helps analyze AOL's Internet inbound mail) because pil.net has risen above/below acceptable thresholds in one or more of these three categories: 1) Total percentage of messages bounced (exceeds 10% invalid email addresses in a 24 hour period): 0% 2) Total percentage of bounces accepted by pil.net (lower than 90% acceptance): 74% 3) Total number of AOL member complaints: 732 AOL takes proactive steps to contact owners of mail servers whose e-mail transmissions are impairing the functioning of AOL's proprietary e-mail system, or causing significant levels of AOL customer complaints. AOL requests that you take immediate steps to resolve the issues identified in this AOL Report Card. In the absence of a satisfactory resolution, AOL reserves the right to take measures to protect its email network and its member goodwill from any possible damage. These measures may include declining to accept e-mail transmissions from pil.net through AOL's proprietary e-mail network. AOL strives to provide the best online experience possible for our members, and we pride ourselves on being intensely focused on consumers and their needs. Email is a core feature of the AOL service, and the proper functioning of AOL's e-mail system is vital to our members' goodwill. Please review AOL's e-mail policies and guidelines, as well as other technical details concerning e-mail on the AOL network, at http://postmaster.info.aol.com AOL is eager for you to resolve these issues expeditiously, so we can continue to provide the best possible e-mail service to our members. Thank you for your prompt attention to this important matter.
