October 2000 - Test - lists.nanog.org

Trouble ticket for UUNet Toronto Outage...
by Craig Holland 03 Oct '00

03 Oct '00

Sorry...should have put this in my last email. Trouble ticket # for UUNet Toronto outage: 23095. craig

1 0

UUNet outage (probably others) in Toronto...
by Craig Holland 03 Oct '00

03 Oct '00

Due to a Telco power outage in the Toronto area, 5 of UUNet's OC-48's are dark. No ETA as of yet. This will probably affect others as well. craig

1 0

RE: RSA Patent Expired
by Roeland M.J. Meyer 03 Oct '00

03 Oct '00

And as soon as they put in all the features that SSH1 has and can get a functioning SSH2 client, I will do exactly that. > -----Original Message----- > From: Richard Welty [mailto:rwelty@vpnet.com] > Sent: Tuesday, October 03, 2000 9:32 AM > To: Bill Fumerola; Hendrik Visage > Cc: Bradly Walters; nanog(a)merit.edu > Subject: RE: RSA Patent Expired > > > > Bill Fumerola [mailto:billf@chimesnet.com] wrote: > > OpenSSH uses RSA for ssh1, so it too benefited greatly > > from RSA's release of the code into the public domain. > > except that nobody should be using ssh1 for _anything_ if they can > possibly avoid it. even the orginal authors of ssh are strongly > advocating > consigning ssh1 to the trash heap of computer security. > > richard >

1 0

Re: RSA Patent Expired
by Bill Fumerola 03 Oct '00

03 Oct '00

On Tue, Oct 03, 2000 at 09:08:10AM +0200, Hendrik Visage wrote: > > It does allow operating systems to ship with sshd enabled by > > default[1] without having to worry about violating patents. > > Then there are OpenSSH ;^) http://www.openssh.com > which doesn't contain ANY patented/copyrighted algorithms OpenSSH uses RSA for ssh1, so it too benefited greatly from RSA's release of the code into the public domain. -- Bill Fumerola - Network Architect, BOFH / Chimes, Inc. billf(a)chimesnet.com / billf(a)FreeBSD.org

2 2

RE: RSA Patent Expired
by Richard Welty 03 Oct '00

03 Oct '00

Bill Fumerola [mailto:billf@chimesnet.com] wrote: > OpenSSH uses RSA for ssh1, so it too benefited greatly > from RSA's release of the code into the public domain. except that nobody should be using ssh1 for _anything_ if they can possibly avoid it. even the orginal authors of ssh are strongly advocating consigning ssh1 to the trash heap of computer security. richard

2 1

Re: Not so newbie BGP question...
by Danny McPherson 03 Oct '00

03 Oct '00

I can think of a couple of viable options. One approach would be to ask AS65501 to permit _65503$, versus 65502_65503$. This would result in transit behavior for both the "Regional Exchange" path to reach AS65503 destinations under normal behavior, and would also permit use of the AS65502 path should the Regional Exchange path become unavailable. Of course, it could potentially result in odd, or at least non-deterministic behavior, if folks are filtering based on the sequence of ASs in the AS_PATH. Alternatively, AS65501 could do as lots of sensible folks do and always prefer customer routes over peer routes [of the same length] (usually via LOCAL_PREF for "AS wide" scope), though this would mean that the Regional Exchange path would only be used if the AS65502 path becomes unavailable, and even then the direct route would NOT be provided with transit service by AS65501. Or, one other option which would likely seem the most elegant to AS65503, but perhaps annoy some folks (with good reason). Depending on the prefix length, AS65503 could announce the aggregate via the AS65502 session, and announce two following more-specific (i.e. longer prefixes) via the direct peering with AS65501. Presumably, this would result in all the AS65501 traffic preferring the Regional Exchange, with only the aggregate route being propagated to the "Internet", though still resulting in the same transit behavior. However, depending on the relationship with AS65502, additional provisions would perhaps need to be implemented to ensure that AS65502 doesn't prefer the two more specific's via the AS65501-AS65503 path versus the direct path between the two. And yes, IMO, 1 & 3 above are hacks... HTH, -danny > Since the direct (exchange) route to 65503 is selected as the best path it > is passed throughout their network to the edges as the best path. It > doesn't pass through their as-path access-list filters on the edge however > since 65503 isn't a TRANSIT customer of theirs and as such, the > 65501_65502_65503 routes never get announced at the 65501 borders. > > The regional exchange operates in transparent mode. (transparent AS, > transparent nexthop) > > Is there a way to have 65501 see routes in it's core to 65503, yet > announce the 65502_65503 routes to its other bilateral peers on its > borders?

3 4

Re: Not so newbie BGP question...
by Danny McPherson 03 Oct '00

03 Oct '00

> I'm not positive but, is it possible to have 65501 prefer 65502_65503 > (using localpref on the 65501<->65502 transit connection) over 65503 > direct routes learned via the regional exchange? Yep, and you may even be able to do it yourself if they've implemented the RFC1998 stuff. > In this situation, all concerned have agreed that since 65501 is a common > transit provider, it is not expected that they pref routes TO customers or > customers of customers via the regional exchange. > > In a perfect world (someone speak up if you know how to do this!) we could > do this: > > Have 65501 pref regional exchange routes to 65502 and 65503 for traffic > originating inside of 65501 or from other 65501 transit customers. Don't need to do that [typically non-standard thing] if you can do this: > Have 65501 pref the 65501<->65502 transit connection for traffic > originating from outside their AS or their transit customers. Again, the RFC1998 stuff, if supported by AS65501, will enable you [AS65502] to do this yourself. Of course, the above configurations tend to reduce the value of the Regional Exchange peering between AS65501 & AS65503, at least when considering the AS65503 ingress direction. They do still provide AS65503 with egress flexibility, as well as AS65503-AS65501 [non-transit] interconnectivity in the event that the AS65502 path becomes unavailable. -danny

2 1

Not so newbie BGP question...
by John Fraizer 03 Oct '00

03 Oct '00

Can anyone offer any suggestions for the following: ASNs changed to protect the guilty. AS 65501 is a transit provider of AS 65502. AS 65502 is a transit provider of AS 65503. All three (65501, 65502 and 65503) peer to exchange customer routes (no transit) via a regional exchange point. || = transit | = customer routes only Global internet || 65501-------Regional_Exchange || | | 65502------------ | || | 65503------------------ Problem: 65501 sees direct routes to 65503 and selects them as best at their core. (They peer with the route servers of the regional exchange from their core.) Since the direct (exchange) route to 65503 is selected as the best path it is passed throughout their network to the edges as the best path. It doesn't pass through their as-path access-list filters on the edge however since 65503 isn't a TRANSIT customer of theirs and as such, the 65501_65502_65503 routes never get announced at the 65501 borders. The regional exchange operates in transparent mode. (transparent AS, transparent nexthop) Is there a way to have 65501 see routes in it's core to 65503, yet announce the 65502_65503 routes to its other bilateral peers on its borders? Any suggestions are greatly appreciated. --- John Fraizer EnterZone, Inc

1 0

Re: ISPs are not common Carriers
by Robert Cannon 02 Oct '00

02 Oct '00

The FCC's policy with regard to ISPs goes back over 30 years. In 1966, in a proceeding known as Computer I, the FCC first asked "what is the regulatory difference between computers that facilitate communications and computers with which we communication." The FCC divided the universe at that time into pure communications, pure data processing, and hybrid stuff. Pure communications is regulated under title II as common carriers. Data processing was seen at the time as highly competitive and innovated, with very low barriers to entry to the market. There was, therefore, no need to regulate that industry. Therefore the FCC's policy of not regulating what would become the Internet was born. And for the stuff in between, the hybrid stuff, well, the FCC would just figure it out. In the 1970s, the computer networks became distributed (terminals began to get intelligent) and the FCC was overwhelmed figuring out what the hybrid stuff was. Therefore the FCC initiated Computer II. In this proceeding, the FCC refined its definitions and came up with the basic versus enhanced services distinction. Basic telecommunications is where a message crosses the network virtually transparent to the network - There is essentially no interaction between the network and the content of the message. Enhanced services were pretty much anything else - anything which involved data processing or protocol conversion or something where the message returned by the computer is different from the message inputted. ISPs fall under the definition of enhanced service providers. These proceedings did much more than set definitions. Of course they declared that what would be ISPs were not regulated as common carriers by the FCC. They also set restrictions for telephone company (monopolies) entrance into the competitive ESP market and exempt ISPs from the metered access charges (modem taxes) that long distance companies pay. (I am working on a Guide where all of these rules as they exist today are set forth). In response to the CNET article where the challengers say that only Congress has authority to exempt ISPs from common carrier regulation, it should be noted that the US Congress adopted the FCC's regulatory scheme in the Telecom Act of 1996, setting forth the definition of Information Service Providers which included all ESPs and which are unregulated. More information about all this can be found at www.cybertelecom.org. Look at "What is the Enhanced Service Provider Status of ISPs" at http://www.cybertelecom.org/faqs/espart.htm -B >>> Rodney Joffe <rjoffe(a)centergate.com> 10/02/00 04:30PM >>> The list seems quiet. In the interests of noise and testing a new procmail recipe... The SUPREME COURT has spoken again... http://news.cnet.com/news/0-1005-200-2915149.html?tag=st.ne.1002.lthd.1005-… -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"(SM) ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup

3 2

ISP's are not common carriers.
by Rodney Joffe 02 Oct '00

02 Oct '00

The list seems quiet. In the interests of noise and testing a new procmail recipe... The SUPREME COURT has spoken again... http://news.cnet.com/news/0-1005-200-2915149.html?tag=st.ne.1002.lthd.1005-… -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"(SM)

1 0