- Test - lists.nanog.org

Re: route ingress
by Sean M. Doran 08 Jan '98

08 Jan '98

Vadim Antonov <avg(a)pluris.com> writes: > I quite agree with that (though i'm not convinced that "bottom->top" > allocation combined with recursive NATting is the best architecture). Randy Bush once made the comment that I live in a number of possible future Internets. These are two possibilities, not one. The variable-length bottom->top hierarchical network addressing scheme I prefer eliminates the need for translation of transport addresses. The hard work is in resolving endpoint name to transport address. NAT is only needed in the case where address uniqueness and routability is not inherently guaranteed by the transport addressing structure. Recursive NAT is only needed in the case where the size of a catenet is such that a number of intercommunicating NAT-using routing super domains in aggregate use more than the entire available address space. NAT buys us the time to investigate technologies considerably different from IP while retaining IP as the lingua franca. Recursive NAT buys time in the face of people who try to make the argument (since demolished by HWB's graphics, I think, yes?) that we really are under pressure to increase the number of potentially addressable things. > However, this does not preclude doing authentication with the current > routing system. Yes, I agree completely. However the current routing system sure doesn't make doing that easy. Sean.

1 0

Re: route ingress
by Sean M. Doran 08 Jan '98

08 Jan '98

"John A. Tamplin" <jat(a)Traveller.COM> writes: > I don't understand how the current top-down allocation affects how that > would be done. This is a very broad issue so i will oversimplify. Right now, in order to verify that a particular prefix is being announced properly, one has to be able to associate the prefix with the announcer in two directions. Firstly, one has to walk a tree of registries from the root towards the announcement to make sure the address has been allocated correctly. This means that registries from the root down have to keep some sort of credential scheme for each entity to which it has allocated addresses, and moreover, that those credentials are carried in routing announcements, which is interesting when you consider aggregation. Secondly, one needs a routing registry which indicates that the route has been announced following the proper policy. Then, when you hear an announcement you have to walk back through the policy tree to ensure that not only the policy as registered was followed but also you need to check processing credentials to make sure people aren't faking up a remote AS-to-AS adjacency, for example. With a bottom up allocation scheme, assuming something like IS-IS on steroids as the Internet-wide routing protocol, where there is a flat-routed (or locally-interpreted) part on the extreme right and the address grows leftwards away from the originating area, one does not have to go to a registry to check whether a particular network should be originating a particular address. Moreover, routing will be hierarchical in nature, in verifying policy one will generally make use of a tree of trust in verifying the processing signatures, although one can ask each area recursively if it had intended the announcement to its adjacent (parent or child) area. Policy in a hierarchical network where addressing strictly follows topology will be simpler to describe even in the presence of unusual constraints, and therefore the verification work will be simpler. Moreover, at a distance, all you want to do is verify the presence or absence of an area to area adjacency rather than the presence or abence of a large number of global prefixes. Finally, all you need is a database of unique area-id to credentials, rather than a hierarchical database of prefix-to-entity/entity-to-credential scheme. > As I see it (and I haven't spent any significant time > working on it, but it seems straightforward): > 1) ARIN/whoever signs an address allocation to an entity To make it clearer, try working on defining "whoever". > 2) that entity signs route announcements to peers/upstreams, incuding > who they are announced to What do you do about aggregation, both atomic and proxy? What do you do about pieces of an aggregate when they appear, or more importantly, when they do not appear? > 3) readvertisements are signed by the advertiser What do you do if there is a transient change in topology such that the chain of announcers differs substantially? For instance, suppose you see an AS path of A B C D E for a particular prefix, and later you see F G H I E? How do you know this announcement is correct and should be believed? > Any recipient of a route can verify that the address space was properly > allocated by inspecting the address allocation certificate and verifying > the signature of the registry, and they can verify the path that > advertisement has taken to get to where it is. Thus no one can interject > a route to a network prefix that is not properly allocated, and someone > cannot steal a route advertisement for someone else's prefix. The biggest > problem with something like this is the size of the routing table in > memory (since you have to keep certificates around for readvertisements) > and in the bandwidth required for the updates. Ok, so suppose someone somewhere announces 128.100.251/24. Walk the decision tree of a number of routers, notably ones at big exchange points, or ones at smaller multihomed networks a couple of ASes away from some of the big networks, and tell me what you think needs to happen. Then make it more fun: deaggregate 9/8 at the /24 (or the /30) level and announce it around, or try announcing huge swaths of address space programattically with a modified gated (for example). Where is the huge wave of announcements caught and dealt with, and what has to cope with such a flood of announcements? > I am not familiar with NIMROD, do you have a pointer to it? It's in the usual place for IETF working groups, and specifically http://www.ietf.org/html.charters/nimrod-charter.html is what you want. The likliest evolutionary direction of the Internet now is something like NIMROD married to MPLS (another IETF WG) with translation between the new stuff and old IPv4 hosts (and to-be-considered-old IPv6 hosts) close to the edges of the Internet. Sean.

1 0

exodus?
by Alex "Mr. Worf" Yuriev 08 Jan '98

08 Jan '98

Hi, For about 10 hours we have been having trouble reaching someone at Exodus through the NOC who can properly re-configure their sessions (we're seeing no-next-hop garbage, and our routes are not being preferred). Can someone from Exodus please contact us? Thanks, Alex Net Access NOC 215 864-2360

1 0

mci-rr
by jamie＠intuition.iagnet.net 08 Jan '98

08 Jan '98

Anyone getting similar problems? Message 83/84 Mail Delivery Subsystem Jan 7, 98 04:06:04 pm -0500 Postmaster notify: Cannot send message within 5 days Return-Path: <> Date: Wed, 7 Jan 1998 16:06:04 -0500 (EST) Auto-Submitted: auto-generated (postmaster-notification) [Attach #1: ""] [Type: text/plain, Encoding: 7bit, Size: 370] The original message was received at Fri, 2 Jan 1998 15:45:24 -0500 (EST) from localhost ----- The following addresses had permanent fatal errors ----- <mci-rr(a)RR.mci.net> ----- Transcript of session follows ----- <mci-rr(a)RR.mci.net>... Deferred: Connection timed out with rr.mci.net. Message could not be delivered for 5 days Message will be deleted from queue -- james g.k. rishaw dal/efnet:gavroche __ IAGnet/CIC/netILLINOIS Backoffice DID:216.902.5455 FAX:216.623.3566 \/ 800.637.4IAGx5455 "The man who doesn't read good books has no advantage over the man who can't read them." - Mark Twain

2 2

Netscape sites very slow today
by Tony Torzillo 08 Jan '98

08 Jan '98

This may be of interest to anyone who received complaints of slowness to the Netscape home page yesterday. You can't use anything in this message to configure your router. ---------- Forwarded message ---------- Date: Wed, 07 Jan 1998 14:48:44 -0700 From: Duane Wessels <wessels(a)nlanr.net> To: ircache(a)nlanr.net Cc: Jeff Halper <squid(a)ihot.com> Subject: Re: Netscape sites very slow today Resent-Date: Wed, 7 Jan 1998 13:52:20 -0800 (PST) Resent-From: ircache(a)nlanr.net Yesterday, Jeff Halper asked this on our squid-users list: >I use parent cache sv - noticed it was uusually slow in fetching sites at >netscape.com today - any suggestions? The problem turned out to be sort of interesting, so I thought I'd share it with you... First I thought I'd see if Jeff was imagining things or if there really was a difference. So I looked at the "service time" value for *.netscape.com requests from four days of access logs. The results were: Median Service Date Time (seconds) ----- -------------- Jan 3 2.47 Jan 4 3.47 Jan 5 5.81 Jan 6 76.17 So obviously, something was seriously wrong. The next thing to try was a simple ping: sv-wessels> ping www.netscape.com PING www-uk2.netscape.com (195.44.254.3): 56 data bytes 64 bytes from 195.44.254.3: icmp_seq=5 ttl=248 time=603 ms 64 bytes from 195.44.254.3: icmp_seq=6 ttl=248 time=550 ms Say what? WWW-UK2? sv.cache, located at FIX-West, uses ns.arc.nasa.gov for DNS service. Every time I checked the rest of that day, ns.arc.nasa.gov always returned www-uk2.netscape.com, even though the DNS TTL was quite low (less 15 minutes). dig @ns.arc.nasa.gov www.netscape.com ; <<>> DiG 2.0 <<>> @ns.arc.nasa.gov www.netscape.com ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 10 ;; flags: qr rd ra ; Ques: 1, Ans: 2, Auth: 3, Addit: 3 ;; QUESTIONS: ;; www.netscape.com, type = A, class = IN ;; ANSWERS: www.netscape.com. 94 CNAME www-uk2.netscape.com. www-uk2.netscape.com. 2344 A 195.44.254.3 Looks to me like some DNS smart-resolution feature gone haywire. I sent mail to dns-admin(a)netscape.com, but have yet to get a reply. Since it seemed that ns.arc.nasa.gov was not going to "fix itself" any time soon, I changed sv's resolv.conf to use a different DNS server temporarily. Today, ns.arc.nasa.gov is giving us good answers (www24.netscape.com) Shrug. Duane W.

2 1

RE: A NetSat prospect?
by Jeremy Morrison 07 Jan '98

07 Jan '98

Hank: I hear you are looking for hybrid connectivity into the Middle East. NetSat Express (www.netsatx.net) is looking into the region to begin offering services. I invite you to look through our homepages and send me a line if you would like more information. Best Regards, Jeremy Morrison >Date: Wed, 31 Dec 1997 15:58:51 +0200 >From: Hank Nussbacher <hank(a)ibm.net.il> >To: nanog(a)merit.edu >Subject: Looking for unidirectional simplex satlink > >Can anyone point me at satellite providers who provide Internet >unidirectional (simplex) satellite transmissions at E1 speed (unshared, >non-broadcast), other than Interpacket, that cover the Middle East area? > >Thanks, >Hank

1 0

Governments want to change Net architecture
by Declan McCullagh 07 Jan '98

07 Jan '98

======== Date: Wed, 7 Jan 1998 07:44:57 -0800 (PST) From: Declan McCullagh <declan(a)well.com> To: politech(a)vorlon.mit.edu Subject: FC: Governments want to change Net architecture, from Comm Daily X-URL: Politech is at http://www.well.com/~declan/politech/ [Apologies to Art for not forwarding this earlier. --Declan] ---------- Forwarded message ---------- Date: Thu, 18 Dec 1997 10:28:49 -0500 From: Art Brodsky <arb(a)well.com> To: declan(a)smtp.well.com Subject: comm daily story Declan, Here's the story from Comm Daily, Dec. 17 'Optimistic and Damned Silly' INTERNET CHANGE FOCUS OF INTERNATIONAL LAW ENFORCEMENT Law enforcement officials of U.S. and 7 other industrialized countries want to make fundamental changes in Internet technology in order to aid in their ability to track and catch criminals, Justice Dept. sources said. Program to consider changes in Internet architectures comes as part of agreement announced last week by Attorney Gen. Janet Reno and Justice ministers from around world after meeting in Washington (CD Dec 11 p10). However, one leading Internet authority, MCI Senior Vp Vinton Cerf, said international group's plan wouldn't work. Justice ministers are considering approach similar to that of Communications Assistance to Law Enforcement Act (CALEA) program in U.S., which would make traffic from advanced telecom networks more accessible to law enforcement entities. Representatives of Canada, France, Germany, Italy, Japan, Russia and U.K., as well as U.S., agreed as part of "statement of principles" issued in communique following 2-day session that: "To the extent practicable, information and telecommunications systems should be designed to help prevent and detect network abuse, and should also facilitate the tracing of criminals and the collection of evidence." Several items on "action plan" issued in support of those principles refer to working with new technologies to collect critical evidence, developing standards for authenticating electronic data for use in investigations and encouraging standards-making bodies to provide public and private sectors "with standards for reliable and secure telecommunications and data processing technologies." DoJ officials said Dept. may want to talk later with telephone industry on trap and trace issues, but it's premature to involve them now in follow-up to international summit. Instead, they said, they are looking at broader picture of telecom networks that haven't worked as closely with law enforcement as they could, and have begun thinking about Internet protocols. Internet operates globally with common protocols, currently Internet Protocol version 4. Internet engineers are working on next iteration, version IPv6 (Internet Protocol version 6 -- 5 was experimental attempt that was dropped). Justice official said that one problem now is that it's easy to send and receive e-mail with false address, called "spoofing." It would be helpful to law enforcement if information sent over Internet were tagged, and packets would transmit information reliably as to where they came from, including user and service provider, officials said. Loose analogy would be to compare e-mail messages to tagging of explosives, so law enforcement can track explosive material to its source. DoJ said new protocols could be designed to make it easier to authenticate messages and to make system more reliable. Law enforcement wants to work with industry to accomplish goal, saying it would help "keep people who are abusing information technologies from continuing to do it." There will be substantial obstacles to law enforcement concept, however. Not least of them is that IPv6 will include sophisticated encryption capabilities as part of protocols. Such security isn't built in to Internet now, one of reasons why electronic commerce has yet to take off, said Mark McFadden, communications dir. for Commercial Internet eXchange Assn. (CIX). That feature will make it harder for law enforcement to gain access to information, he said. Cerf, co-inventor of Internet protocols, said in interview that law enforcement's concept of tagging e-mail messages wouldn't work: "To imagine that we would instantly create the infrastructure for that throughout the entire Internet strikes me as optimistic and damned silly, at least in the short term. Anyone who anticipates using tools to guarantee that everything will be traceable is not going to have a successful outcome." Technically, such project could be accomplished, Cerf said, but having administrative infrastructure to administer it is quite different issue. It's possible to have digital signature for every packet of data, but it would take "an enormous amount of processing, and it's not clear we have any network computers and routers that could do that and maintain the traffic flow that's required," Cerf said. It also would require that each sender affix digital signature to each piece of mail, idea that Cerf said couldn't be enforced: "Frankly, the idea of trying to guarantee traceability of that kind is far from implementable." He said he didn't want to be misunderstood that his objections were "an argument in favor of criminality." But Cerf said he worries that "someone relies on what they think is a technical solution without recognizing all of the administrative mechanics that need to be put in place." Law enforcement has some time to work with Internet community. McFadden said IPv6 isn't scheduled to be implemented at consumer level for at least 5 years, possibly as much as 10. There was some urgency when it appeared that reservoir of Internet addresses would dry up, but with progress being made to protect addresses as scarce resource there's less pressure for new set of protocols, he said. posted with permission Warren Publishing -------------------------------------------------------------------------- POLITECH -- the moderated mailing list of politics and technology To subscribe: send a message to majordomo(a)vorlon.mit.edu with this text: subscribe politech More information is at http://www.well.com/~declan/politech/ --------------------------------------------------------------------------

1 0

peering policies and spam
by Jeremy Porter 07 Jan '98

07 Jan '98

Have any providers gone on record as stating that they are going to require anti-spam policies in their future peering agreements? We have the case of a spam attack coming from Cable and Wireless CWIX.NET customer: Here is CWIX saying its ok to send in bulk unsolicited email. We are going to require that our service providers and peers argee to not pass us spam traffic, by whatever means that they want to impelement. As a stop gap, I imaging a route map to map all prefixes arriving out of AS 5683 to Null0 for the time being will a stop gap, until we can get our providers to drop peering with these idiots. I imagine we will also be pursing legal action as these people are located in state. >Here is the official response from CWIX.NET (cable wireless ex) >Patrick >>>>> >><excerpt>Sender: lawrence(a)tipa2.cwix.net >>Date: Mon, 05 Jan 1998 19:20:34 -0500 >>From: Lawrence Guidry >>Organization: Cable & Wireless Internet Exchange (CWIX) >>To: "Patrick Michael O'Leary" >>Subject: [Fwd: Ticket #92258 (craig) Spammed email to our site! >> >> >>Upon investigation, your complaint appears to be without merit. >> >> >>The simple act of sending commercial bulk e-mail to your clientelle is >>not in and of itself a violation of our AUP. >> >> >>Any issues of complaint regarding plagerism towards Roy Bronson are >>between you and he. >> >> >>Of course, please feel free to re-clarify your complaint for further >>consideration by us. --- Jeremy Porter, Freeside Communications, Inc. jerry(a)fc.net PO BOX 80315 Austin, Tx 78708 | 1-800-968-8750 | 512-458-9810 http://www.fc.net

2 1

AOL Web caching?
by Brian Horvitz 07 Jan '98

07 Jan '98

Has anyone else exerienced problems with AOL's web proxy servers? We switched the IP address of a web site about 5 months ago, and we are still getting about 10,000 hits a day from AOL on the old address. We dropped a note to them a ways back but didn't get much of a response. Brian Horvitz Shore.Net

11 11

Wired article: Smurfing Cripples ISP's
by Paul Ferguson 07 Jan '98

07 Jan '98

See: http://www.wired.com/news/news/technology/story/9506.html - paul

1 0