- NANOG - lists.nanog.org

Re: Re: Thanks to all--medical emergency under control
by ALAN DORN HETZEL JR 08 Jan '97

08 Jan '97

From: INDIGO::DORN "ALAN DORN HETZEL JR" 8-JAN-1997 08:31:17.05 To: MX%"joe(a)Navigist.Com" CC: DORN Subj: Re: Thanks to all--medical emergency under control > I think the way we would handle privacy issues here is that if we received > such a request to locate one of our customers, we would pass the customers > location information directly to local law enforcement along with the > request we had received. This way, the requestor cannot use such a claim > to learn private information of our customer, but yet our local cops could > provide assistance if it's really required... This would be great if the Police didn't use radios that everyone has scanners for. This is the same as cracking - if you can prompt a legitatimate query which creates a legitimate response then you can snoop the session. ...until the police finally get better radios. Apologies to those of you who live in countries where the police have caught on to this. I think I would be willing to take that risk. Life is not perfect and I cannot prevent every possible leak of data; someone could break into our offices and steal all the computers and the information on it; they could do it with guns and shoot all my employees too; this doesn't mean I won't keep any computers or information in my office... If I give information to the police and they manage to lose control of it, it is unfortunate, but I would just have to consider it outside the scope of what I have available worry cycles for... -Dorn

1 0

Re: Domain names for ISP infrastructure links -Reply
by Alex.Bligh 08 Jan '97

08 Jan '97

> What about when the next hop is determined by dynamic means? You mean like a LAN or a point to multipoint FR cloud? In that case we name the cloud / LAN and stick that at the end. So TH1-E1-2-3-THColo for a colo server ethernet LAN. Alex Bligh Xara Networks

1 0

Re: Thanks to all--medical emergency under control
by Joe Rhett 08 Jan '97

08 Jan '97

> I think the way we would handle privacy issues here is that if we received > such a request to locate one of our customers, we would pass the customers > location information directly to local law enforcement along with the > request we had received. This way, the requestor cannot use such a claim > to learn private information of our customer, but yet our local cops could > provide assistance if it's really required... This would be great if the Police didn't use radios that everyone has scanners for. This is the same as cracking - if you can prompt a legitatimate query which creates a legitimate response then you can snoop the session. ...until the police finally get better radios. Apologies to those of you who live in countries where the police have caught on to this.

1 0

Re: Domain names for ISP infrastructure links
by Vadim Antonov 08 Jan '97

08 Jan '97

That may sound silly, but there's a merit in the idea that domain names can successfully replace the SNMP's object IDs. SNMP and DNS then become the same protocol. In fact, all protocols requiring exchange of some request and getting some reply from a uniquely named object can be made a particular case of a generic protocol. There's no reason for Internet to be a hodge-podge of specialized kludges. In most cases, it only takes an ability for DNS to "hand off" the continuation of name resolution to application programs. See -- i don't think everything Plan 9-ish is pure crap. --vadim From: John Curran <jcurran(a)bbnplanet.com> No... we're going to mandate OID-style router names for the world's Internet providers: <isoc-tree>.<internet-infrastructure branch>. <iso country code>.<city ordinal>.<provider #>. <facility #>.<rack #>.<shelf #>.<router ordinal> Great fun to watch (it could be happening this way in the alternate universe next door.) ;-) /John

3 2

Re: Domain names for ISP infrastructure links
by Rob Liebschutz 08 Jan '97

08 Jan '97

> > > I'm puzzled. Connections go from router to router. How does it help to say > > > routerb-x-y-z-routerc.blah.net when routerc will show up as the next hop in > > > the traceroute? > > > > I think it will help when routerc fails to show up as the next hop :) > > No. Actually yes. At first I had the same thought that you did, but knowing which router the packet was supposed to have come from makes it easy to tell from the output of a traceroute weather the routing changed in the middle. Having to use IP addresses to figure this out is much more work. On the other hand, I do question the idea of trying to cram all this info into the the interface names in the DNS. > > Traceroute gives you the incoming interface on a router. For a given > incoming interface on a router there are multiple next hop routers > (and multiple outgoing interfaces). > > Knowing that the outgoing interface that a packet came from on the > previous hop router is not worth adding to the DNS. > > If this is a point-to-point link, as you seem to be assuming, then it > should be subnetted as a /30 and you can thus subtract or add 1 to the > IP address as appropriate to find the previous hop's outgoing > interface, if that information is important to you. > > If it is a multiple-access link, then there is no chance of the > incoming interface being specific to a particular previous hop anyway, > so this scheme falls apart. > > --jhawk >

1 0

Broken US domain nameserver run by family-names.com
by Bill Sommerfeld 07 Jan '97

07 Jan '97

This is a report of a small-scale, but real, problem. I have attempted to resolve this through channels and haven't gotten anywhere. Roughly 5-6 years ago, I registered orchard.medford.ma.us with the ISI US domain registrar, as an MX record pointing at bloom-beacon.mit.edu. I began using that address shortly thereafter for non-work-related email. At some point last summer, the medford.ma.us domain was delegated to family-names.com. Some time in the last 24 hours, the MX record served up mysteriously changed to point at the non-existant host bloom.beacon.mit.edu and all my incoming mail started bouncing. I became aware of this shortly before noon today. All efforts to contact anyone at family-names.com have failed; they have a phone number (which is answered by an answering machine) and email (which hasn't been answered). I've been calling once an hour or so for the past six hours and haven't yet gotten a response. family-names.com is purportedly located at a business park in Roanoke, VA: % whois family-names.com. Family Names, Inc. (FAMILY-NAMES-DOM) 2018 Electric Road, Suite 174 Roanoke, VA 24018 US Domain Name: FAMILY-NAMES.COM Administrative Contact, Technical Contact, Zone Contact, Billing Contact: Barnes, Jody Jay (JJB18) jody(a)FAMILY-NAMES.COM 540 772-1034 The errant servers are ns1.family-names.com and ns2.family-names.com which appear to both be behind the same MS.UU.NET router in Miami, Florida: traceroute to ns1.family-names.com (208.199.236.8), 30 hops max, 40 byte packets 1 is1.bedfo.MA.tiac.net (199.0.65.27) 70.547 ms 69.026 ms 81.773 ms 2 core-fddi4-0.bedfo.MA.tiac.net (199.0.65.1) 75.132 ms 70.485 ms 67.667 ms 3 903.Hssi3-0.GW1.BOS1.ALTER.NET (137.39.135.113) 68.955 ms 74.218 ms 69.726 ms 4 Fddi0-0.CR1.BOS1.Alter.Net (137.39.35.2) 132.189 ms 77.84 ms 78.156 ms 5 103.Hssi4-0.CR1.ATL1.Alter.Net (137.39.30.70) 116.038 ms 108.339 ms 106.268 ms 6 109.Hssi4-0.GW1.MIA1.Alter.Net (137.39.31.10) 215.531 ms 126.527 ms 129.444 ms 7 Fddi0.AR1.MIA1.Alter.Net (137.39.33.5) 123.469 ms 123.53 ms 123.201 ms 8 Max5.Miami.FL.MS.UU.NET (207.76.6.138) 127.192 ms 126.031 ms 126.636 ms 9 208.199.236.1 171.087 ms 162.706 ms 150.055 ms 10 * * * ^C Alternet customer service has not been helpful. Anyone out there with a clue about this outfit or any suggestions on where to go next? Thanks in advance for any pointers.. - Bill

1 0

Re: Domain names for ISP infrastructure links -Reply
by Rory Young 07 Jan '97

07 Jan '97

What about when the next hop is determined by dynamic means? Rory,

1 0

Re: Thanks to all--medical emergency under control
by Justin W. Newton 07 Jan '97

07 Jan '97

At 09:58 AM 1/7/97 -0500, Jon Zeeff wrote: > >I'd like to point out that such things can be an invasion of privacy. >While person A might claim that person B threatened to commit suicide, >it is possible that person A wants to locate person B for other, >not so good reasons. > >This will happen if all one has to say is "suicide" and everyone will >ignore their normal privacy policies. I have dealt with this in the past and only given out the information to the local EMS system, and had /them/ use the information. I also did things like call back the original caller to make sure that I had valid contact info for them, etc etc (gives some level of ability to track things back if its a prank or harrasment or something.) As a side note, when I lived in Chicago I had a similar experience to the one mentioned above, (except I knew the name and address of the person already), and it took a /lot/ of time to get patched through to EMS and then to get EMS to actually believe me. To their credit the EMS dispatcher did call me back later to apologize for not believing me when it turned out that the person's life was saved. Justin Newton Network Architect Erol's Internet Services

1 0

Re: Thanks to all--medical emergency under control
by ALAN DORN HETZEL JR 07 Jan '97

07 Jan '97

I think the way we would handle privacy issues here is that if we received such a request to locate one of our customers, we would pass the customers location information directly to local law enforcement along with the request we had received. This way, the requestor cannot use such a claim to learn private information of our customer, but yet our local cops could provide assistance if it's really required...

2 1

Thanks to all--medical emergency under control
by Howard C. Berkowitz 07 Jan '97

07 Jan '97

Thanks to everyone who responded. I was eventually able to reach one of the providers, who was able to identify the callers through logs, and passed the information to the local emergency people. The patient is now under treatment, and did not take a lethal dose. Howard Berkowitz

5 5