- Test - lists.nanog.org

House panel votes behind closed doors to build in Big Brother
by Declan McCullagh 12 Sep '97

12 Sep '97

---------- Forwarded message ---------- X-FC-URL: Fight-Censorship is at http://www.eff.org/~declan/fc/ Date: Thu, 11 Sep 1997 23:37:39 -0700 (PDT) From: Declan McCullagh <declan(a)well.com> Sender: owner-fight-censorship-announce(a)vorlon.mit.edu To: fight-censorship-announce(a)vorlon.mit.edu Subject: FC: House panel votes behind closed doors to build in Big Brother Software that protects your privacy is a controlled substance that may no longer be sold, a Congressional committee decided today. Meeting behind closed doors this morning, the House Intelligence committee voted to replace a generally pro-encryption bill with an entirely rewritten draft that builds in Big Brother into all future encryption products. (The Senate appears to be moving in a similar direction.) The new SAFE bill -- titled in a wonderfully Orwellian manner the "Security and Freedom through Encryption" act even though it provides neither -- includes these provisions: SELLING CRYPTO: Selling unapproved encryption products (that do not include "immediate access to plaintext") becomes a federal crime, immediately after this bill becomes law. Five years in jail plus fines. Distributing, importing, or manufacturing such products after January 31, 2000 is another crime. NETWORK PROVIDERS: Anyone offering scrambled "network service" including encrypted web servers or even "ssh" would be required to build in a backdoor for the government by January 31, 2000. This backdoor must provide for "immediate decryption or access to plaintext of the data." TECHNICAL STANDARDS: The Attorney General will publish technical requirements for such backdoors in network service and encryption products, within five months after the president signs this bill. LEGAL TO USE CRYPTO: "After January 31, 2000, it shall not be unlawful to use any encryption product purchased or in use prior to such date." GOVERNMENT POWERS: If prosecutors think you may be selling, importing, or distributing non-backdoor'd crypto or are "about" to do so, they can sue. "Upon the filing of the complaint seeking injunctive relief by the Attorney General, the court shall automatically issue a temporary restraining order against the party being sued." Also, there are provisions for holding secret hearings, and "public disclosure of the proceedings shall be treated as contempt of court." You can request an advisory opinion from the government to see if the program you're about to publish violates the law. ACCESS TO PLAINTEXT: Courts can issue orders, ex parte, granting police access to your encrypted data. But all the government has to do to get one is to provide "a factual basis establishing the relevance of the plaintext" to an investigation. They don't have to demonstrate probable cause, which is currently required for a search warrant. More interestingly, this explicitly gives the FISA court jurisdiction (yes, the secret court that has never denied a request for a wiretap). If they decode your messages, they'll tell you within 90 days. GOVERNMENT PURCHASING: Federal government computer purchases must use a key escrow "immediate decryption" backdoor after 1998. Same with networks "purchased directly with Federal funds to provide the security service of data confidentially." Such products can be labeled "authorized for sale to U.S. government" ENCRYPTION EXPORTS: The Defense & Commerce departments will control exports of crypto. Software "without regard to strength" can be exported if it includes a key escrow backdoor and is first submitted to the government. Export decisions aren't subject to judicial review, and the "president may by executive order waive any provision of this act" if he thinks it's a threat to national security. Within 15 days, he must send a classified briefing to Congress. ADVISORY PANEL: Creates the Encryption Industry and Information Security Board, with seven members from Justice, State, FBI, CIA, White House, and six from the industry. INTERNATIONAL: The president can negotiate international agreements and perhaps punish noncompliant governments. Can you say "trade sancation?" (Other provisions barring the use of crypto in a crime and some forms of cryptanalysis are also in the bill.) Next the Commerce Committee will vote on SAFE, and a former FBI agent-turned-Congressman is vowing to ensure that similar language to this is included. (The committees are voting on the bill in parallel, and a four-person team of Congressmen is working to forge a compromise before Commerce votes.) Then the heads of the five committees that have rewritten the legislation will sit down and work out another compromise. If it's acceptable to the House Rules committee -- and if the FBI/NSA get what they want it will be -- the bill can move to the floor for a vote. That's why the encryption outlook in Congress is abysmal. Crypto-advocates have lost, and lost miserably. A month ago, the debate was about export controls. Now the battle is over how strict the //domestic// controls will be. It's sad, really, that so many millions of lobbyist-dollars were not only wasted, but used to advance legislation that has been morphed into a truly awful proposal. I wrote more about this at: http://cgi.pathfinder.com/netly/opinion/0,1042,1385,00.html -Declan -------------------------------------------------------------------------- This list is public. To join fight-censorship-announce, send "subscribe fight-censorship-announce" to majordomo(a)vorlon.mit.edu. More information is at http://www.eff.org/~declan/fc/

2 1

R: not rewriting next-hop, pointing default, ...
by Enke Chen 12 Sep '97

12 Sep '97

For ISPs with a lot of direct (i.e., private) peers, on the public NAP routers you may want to consider not installing the routes from the private peers. This approach could reduce the damage to your private links by default-pointing attack. It may also make you less likely a target due to black-holing of certain traffic. This approach is not applicable if transit service is provided at the public NAP. -- Enke > Nanog archive > ---------------------------------------------------------------------- > [Prev][Next][Index][Thread] > > Re: not rewriting next-hop, pointing default, ... > > ---------------------------------------------------------------------- > > * To: dlr(a)bungi.com (Dave Rand) > * Subject: Re: not rewriting next-hop, pointing default, ... > * From: Naiming Shen <nshen(a)mci.net> > * Date: Fri, 12 Sep 1997 10:00:23 -0400 > * cc: Randy Bush <randy(a)psg.com>, Naiming Shen <nshen(a)mci.net>, > nanog(a)merit.edu > * In-reply-to: Your message of "Thu, 11 Sep 1997 22:02:35 PDT." > <m0x9NsK-0000LvC(a)daver.bungi.com> > * Sender: owner-nanog(a)merit.edu > > ---------------------------------------------------------------------- > > Ha, it's amazing how fast people learn when they have to. Yesterday > someone send us a traceroute: > > % traceroute -g 192.41.177.98 www.mci.net > .... > 6 core1-hssi3-0-gw.Washington.mci.net (204.70.1.222) 246 ms > Naiming Shen MCI > - MCI Internet Engineering 2100 Reston Parkway > - +1 703-715-7056 fax:703-715-7066 v272-7056 Reston, VA 20191 > > ----------------------------------------------------------------------

1 0

Re: ATM (was Re: too many routes)
by Carmen Hillenburg 12 Sep '97

12 Sep '97

Sean M. Doran wrote: > BTW, your formatting sucks to the point that your note is > unreadable and unquotable without fmt(1) or fill-paragraph. Sorry, bad program to send from ;{ >So anyway, as I was saying, I'm ignorant about such matters. Cute. ;) Its nice to know you have a sense of humor ! >Oh now THERE's a reliable source. "Hi my name is Frank > and ATM will Just Work. Hi my name is Warren and ATM is > fantastic.". Ugh. (kent bait kent bait kent bait) Not my point, I was just quoting my "source" of timings, nothing more. >At higher bandwidths bits are shorter not faster. Yes, but at lower bandwidth they are spaced further apart. >Repeat that several times. Yes, do. >Whether you are signalling at 300bps or at >293875983758917538924372589bps, the start of the first bit >arrives at the same time. I was talking about a total performance increased experienced by more bandwidth, not *just* latency. BTW the total transmission time is still reduced, my original point. I was careful to note the resultant transmission time, not latency. Also, if the cell entered the net to carry the "first bit" before it's natural TAT...... >Um, no it doesn't. As with all demand-cached forwarding >schemes you have to process a packet heavily when you have >a cache miss. You are right. I was not accurate on full implementation detail, but the concept was there. I *really* must remember *not* to use simplifications for brevity in the nanog list. But, the description was not intended as an RFC. I was only noting the advantage to not needing to look up where to send a packet , * every time *. > MPLS is conceptually related, btw. Interesting. PS. I am a supporter. >P.S.: You have some very entertaining and unique expansion > of a number of acronyms in general and relating to > ATM in particular. I'm curious how you expand "PDH". > Personally I favour "Pretty Damn Historical", > although other epithets come to mind. I repeat, I will NEVER, NEVER, NEVER, over simplify for brevity to the nanog again. Bad Richard, Bad! (But each one gave you the general idea, didn't it.) I rather liked your response(s), it was informative. I still hold to my point, though. Now rather than fire a response to all those flames, one at a time.... To One individual: Yes, I used some terms from Frame Relay, instead of ATM. (OOPs! I work with all the above, and it was the end of a 10 hour day) And yes, the acronyms are in error in literal expansion, however, not in concept. They perform the same BASIC function. ---------------------------- Never, never, never again.... ---------------------------- And to another, I did not claim that the speed of light is NOT a factor, just not the only one. And since I cannot change the speed of light ..... ---------------------------- Bad! Never, Never.. ---------------------------- (One guy hated a 12ms difference between my "on the cuff estimate", and his calculation of the RTT.) Boy, THAT invalidates ATM. ---------------------------- Never, Never, Never... ---------------------------- > I wasn't around for the invention of statistical muxing, >but I'm sure there are some people here who could clarify >with first-hand knowledge (and I'll take email from you, >thanks :) ). Neither was I. However, I wasn't being quite that literal. I will accept that I presented an inaccuracy. SDM just allowed more diverse use of a given voice circuit. A lot of this chain-flame is my fault, a little too tired.., and not exacting detail. However, Sorry, I still hold to ATM being superior for WAN, and possibly exchange delivery. This does not mean ATM will hold as well as other technologies when seriously OVERSUBSCRIBED. (Now, what fool would do that .) But, I should note that during the recent "brown outs" it was not the ATM NAP's that were collapsing. (Not that some peoples ports weren't lossy) Many of you picked at details you could find wrong, from spelling to 12ms differences in earth round trip time. etc. I hope some of you noted what was right. Those points never seem to get "cut and pasted." Some times you just can't see the forest for the all tree's in the way.. And boy there were a LOT of tree's. A) ATM is better. B) No its not! A) Yes it is! B) No its not! A) Yes it is ! B) Your hair is died !! A) Uhhh...Its only grecian formula... B) Is that your natural color ? A) Well, no, I told you I use greci... B) uh-huh, SEE! ATM isn't better! A) sigh....... Wasn't this on Monty Python ?

2 1

Re: LSR and packet filters
by rja＠corp.home.net 12 Sep '97

12 Sep '97

On Sep 11 21:06, Sean M. Doran wrote: % Cool, and I now view the 2-hop notion as the first % reasonable argument for encouraging people to totally % flatten their network into a full mesh. Hmm. I wouldn't go that far :-). % Security policy should not under any circumstances prevent % the Internet as a whole from functioning reasonably well, % scaling decently, or make discovering and diagnosing % problems any harder than it already is. A reasonable security policy is focused on maintaining network availability and uptime. If one focuses exclusively on diagnostic tools, one's network will be down much more often than if one strikes a reasonably balanced overall perspective on things. All IMHO. % Your opinion may vary with mine, but I am solidly in line % with Randy's suggestion that enabling LSRR on backbone % routers should be a requirement for peering. (This is not % surprising as I used to require it of a couple of peers in % a previous life, because in practice it is unfortunately % an irreplaceable diagnostic tool). You haven't defined terms (e.g. "backbone router"), so your meaning is not clear. Assuming that "backbone router" is only those within 2 hops of an external connection and that one has a network with nice deep heirarchy (much more than 2 levels), I could agree with you. :-) I will note that its none of someone else's business what one's internal topology looks like. The only _legitimate_ need of a peer is to be able to isolate the problem to one's network (or someone else's network) so that the peer can then come after one (or one's NOC) to fix the problem(s). So I'm not trying to kill off LSR as a diagnostic tool, merely limit the downside operational risks of LSR to a reasonable level. The ultimate goal of my proposal is to _enhance_ network availability. Ran rja(a)home.net Disclaimers from yesterday's note all apply; especially the one about not enough coffee. :-) PS: I've revised the subject line to be more clear.

1 0

Re: too many routes
by Sean M. Doran 12 Sep '97

12 Sep '97

Nathan Stratton <nathan(a)netrail.net> writes: > This is what I beleave sprint is doing. They are using the new Cisco 12000 > GSR with external router servers. It is a smart way of patching the > problem. If you need more CPU or memory you can just add a bigger box and > more RAM. The GSRs are to move bits fast. They are not to act as route servers. Sprint recently announced that they are deploying 622Mbps POS cross-country links, and the GSRs are the only things you can put on the ends of such beasts that are available today. (Someone may point out that it may not be the only choice for very long, however, it's the only one whose design I know and have had any influence upon, and is therefore frankly the only one I trust, although I don't expect the people building the competing box will ship anything but a good product even if they are now rather deeply in bed with the cell-heads and about as transparent to most observers as the Kremlin during the cold war... The box being built by someone who actually worked very close to the Kremlin during the cold war is also something I don't know enough about, however that is much more due to my neglect than due to organizational attitude.) Remember that a current snapshot is not a good indicator of future health. Sure the processing demands of routing are such that the GSR's main CPU is largely idle after converging with its neighbours, however there is still a CPU spike during convergence and the processing load is non-zero. If you increase the growth curve of the number of prefixes, you increase the CPU demands during large-scale convergence. You also statistically increase the CPU demand after convergence unless you reduce the probability of any given prefix transitioning from up to down or vice versa over time. If you have a growth curve where the processing load during large-scale convergence and the processing load to handle background noise increases beyond processing capacity faster than processing capacity can be increased, you lose, no matter how crunchy your box is today relative to today's processing demands. In other words, removing the feedback mechanisms on the growth of the number of globally-visible prefixes and on prefix instability is probably a really bad idea. Sean.

5 5

frac DS3 from PAIX
by andrew khoo 12 Sep '97

12 Sep '97

any contacts for getting a frac DS3 from PAIX to the PanAmSat teleport facility at Napa? ============================================================== andrew khoo - rebel leader gsm: +61-500-555-466 Ourworld Global Network work: +61-2-9223-2777 sushi-eating good guy - wild wookie pager: +61-2-9962-4414 speaks in home-grown tongue - ren usa: +1-415-531-2754 ============================================================== -- We Bite (tm) --

1 0

Re: not rewriting next-hop, pointing default, ...s
by Vincent J. Bono 12 Sep '97

12 Sep '97

Although it is not likely that Avi is wrong, I'm sorry that this whole mess has degenerated to "did-to did-not" loops. Sigh. Avi Freedman wrote: > > You may have been peering with them but you were ALSO default-routing > to them. > > >From 4/96: > > -------------------------------------------------------------- > > NOW TRYING: [e0-10m.mae-east.netrail.net (192.41.177.228)] > > -------------------------------------------------------------- > > -------------------- to mci through [e0-10m.mae-east.netrail.net] > > trace 204.70.57.10 > > Type escape sequence to abort. > Tracing the route to internetmci-ipdev.Washington.mci.net (204.70.57.10) > > 1 e0-10m.mae-east.netrail.net (192.41.177.228) [AS 3491] 376 msec 120 msec 120 > msec > 2 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] 128 msec 136 ms > ec 148 msec > 3 E0-10M.nr-1-Arlington-VA.netrail.net (205.215.4.1) [AS 4006] 148 msec 8 msec > 8 msec > 4 204.70.56.29 [AS 3561] 8 msec 12 msec 8 msec > 5 core1-fddi-0.Washington.mci.net (204.70.2.1) [AS 3561] 20 msec 12 msec 12 ms > ec > 6 border2-fddi-0.Washington.mci.net (204.70.3.2) [AS 3561] 12 msec 12 msec 12 > msec > 7 internetmci-ipdev.Washington.mci.net (204.70.57.10) [AS 3561] 12 msec * 8 m > sec > mae-netaxs# > > -------------------- to sprint through [e0-10m.mae-east.netrail.net] > > trace 204.117.214.13 > > Type escape sequence to abort. > Tracing the route to ftp.sprintlink.net (204.117.214.13) > > 1 e0-10m.mae-east.netrail.net (192.41.177.228) [AS 3491] 4 msec 8 msec 4 msec > 2 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] 8 msec 12 msec > 8 msec > 3 E0-10M.nr-1-Arlington-VA.netrail.net (205.215.4.1) [AS 4006] 8 msec 8 msec 8 > msec > 4 204.70.56.29 [AS 3561] 8 msec 12 msec 12 msec > 5 core1-fddi-0.Washington.mci.net (204.70.2.1) [AS 3561] 12 msec 8 msec 12 mse > c > 6 204.70.3.4 [AS 3561] 104 msec 12 msec 8 msec > 7 204.70.74.118 [AS 3561] 8 msec 8 msec 12 msec > 8 sl-mae-e-f0/0.sprintlink.net (192.41.177.241) [AS 3491] 8 msec 24 msec 12 ms > ec > 9 sl-dc-8-H1/0-T3.sprintlink.net (144.228.10.41) [AS 1239] 32 msec 12 msec 12 > msec > 10 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) [AS 1239] 12 msec 8 msec 8 msec > 11 ftp.sprintlink.net (204.117.214.13) [AS 1239] 8 msec 8 msec 12 msec > mae-netaxs# > > -------------------- to agis through [e0-10m.mae-east.netrail.net] > > trace 205.137.48.30 > > Type escape sequence to abort. > Tracing the route to agisgate.agis.net (205.137.48.30) > > 1 e0-10m.mae-east.netrail.net (192.41.177.228) [AS 3491] 4 msec 4 msec 4 msec > 2 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] 8 msec 8 msec 1 > 2 msec > 3 E0-10M.nr-1-Arlington-VA.netrail.net (205.215.4.1) [AS 4006] 8 msec 8 msec 8 > msec > 4 border1-serial2-5.Washington.mci.net (204.70.56.29) [AS 3561] 4 msec 8 msec > 8 msec > 5 core1-fddi-0.Washington.mci.net (204.70.2.1) [AS 3561] 16 msec 8 msec 8 msec > 6 204.70.1.6 [AS 3561] 80 msec 208 msec 208 msec > 7 204.70.3.18 [AS 3561] 204 msec 16 msec 12 msec > 8 sprint-nap.NewYork.mci.net (204.70.45.6) [AS 3561] 16 msec 16 msec 20 msec > 9 agis.sprint.ep.net (192.157.69.19) [AS 1239] 28 msec 16 msec 20 msec > 10 pennsauken.agis.net (205.137.61.2) [AS 4200] 52 msec 208 msec 212 msec > 11 detroit-trenton.detroit.agis.net (205.137.60.233) [AS 4200] 40 msec 48 msec > 52 msec > 12 agis.detroit.agis.net (205.137.60.66) [AS 4200] 44 msec 64 msec 52 msec > 13 agisgate.agis.net (205.137.48.30) [AS 4200] 60 msec 56 msec 52 msec > mae-netaxs# > > -------------------- to ans through [e0-10m.mae-east.netrail.net] > > trace 192.77.167.33 > > Type escape sequence to abort. > Tracing the route to www.ans.net (192.77.167.33) > > 1 e0-10m.mae-east.netrail.net (192.41.177.228) [AS 3491] 4 msec 4 msec 4 msec > 2 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] 8 msec 12 msec > 4 msec > 3 E0-10M.nr-1-Arlington-VA.netrail.net (205.215.4.1) [AS 4006] 8 msec 8 msec 8 > msec > 4 border1-serial2-5.Washington.mci.net (204.70.56.29) [AS 3561] 8 msec 8 msec > 8 msec > 5 borderx1-fddi0-0.Washington.mci.net (204.70.2.4) [AS 3561] 36 msec 80 msec 8 > msec > 6 mae-east-plusplus.washington.mci.net (204.70.74.102) [AS 3561] 8 msec 8 msec > 12 msec > 7 mae-east.ans.net (192.41.177.140) [AS 3491] 8 msec 8 msec 8 msec > 8 ft3.cnss56.Washington-DC.t3.ans.net (140.222.56.4) [AS 690] 12 msec 12 msec > 8 msec > 9 f0.cnss61.Washington-DC.t3.ans.net (140.222.56.197) [AS 690] 12 msec 8 msec > 12 msec > 10 enss186.t3.ans.net (199.221.107.86) [AS 1327] 192 msec 136 msec 140 msec > 11 www.ans.net (192.77.167.33) [AS 1327] 80 msec * 136 msec > mae-netaxs# > > -------------------- to psi through [e0-10m.mae-east.netrail.net] > > trace 38.8.8.2 > > Type escape sequence to abort. > Tracing the route to www.psi.net (38.8.8.2) > > 1 e0-10m.mae-east.netrail.net (192.41.177.228) [AS 3491] 8 msec 116 msec 4 mse > c > 2 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] 8 msec 8 msec 4 > msec > 3 E0-10M.nr-1-Arlington-VA.netrail.net (205.215.4.1) [AS 4006] 12 msec 8 msec > 8 msec > 4 border1-serial2-5.Washington.mci.net (204.70.56.29) [AS 3561] 8 msec 8 msec > 8 msec > 5 borderx1-fddi0-0.Washington.mci.net (204.70.2.4) [AS 3561] 12 msec 8 msec 12 > msec > 6 mae-east-plusplus.washington.mci.net (204.70.74.102) [AS 3561] 72 msec 8 mse > c 200 msec > 7 mae-east.psi.net (192.41.177.245) [AS 3491] 8 msec 20 msec 12 msec > 8 38.1.2.14 [AS 174] 8 msec 12 msec 12 msec > 9 www.psi.net (38.8.8.2) [AS 174] 12 msec 12 msec 12 msec > mae-netaxs# > > -------------------- to uunet through [e0-10m.mae-east.netrail.net] > > trace 199.170.0.30 > > Type escape sequence to abort. > Tracing the route to charlotte01.va.pubnix.com (199.170.0.30) > > 1 e0-10m.mae-east.netrail.net (192.41.177.228) [AS 3491] 0 msec 4 msec 8 msec > 2 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] 8 msec 12 msec 8 msec > 3 Hssi1/0.GW2.FFX1.Alter.Net (137.39.100.70) [AS 701] 108 msec 40 msec 8 msec > 4 UUNET3-GW.UU.NET (137.39.12.35) [AS 701] 4 msec 4 msec 8 msec > 5 charlotte01.va.pubnix.com (199.170.0.30) [AS 701] 8 msec 8 msec 8 msec > mae-netaxs# > > -------------------- to nowhere through [e0-10m.mae-east.netrail.net] > > trace 3.4.5.6 > > Type escape sequence to abort. > Tracing the route to 3.4.5.6 > > 1 e0-10m.mae-east.netrail.net (192.41.177.228) [AS 3491] 8 msec 4 msec 8 msec > 2 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] 12 msec 12 msec > 8 msec > 3 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] !H !H !H > mae-netaxs# > > conf term > Enter configuration commands, one per line. End with CNTL/Z. > mae-netaxs(config)#no ip route 3.4.5.6 > mae-netaxs(config)#ip route 3.4.5.6 192.41.177.112 > mae-netaxs(config)#no ip route 199.170.0.30 > mae-netaxs(config)#ip route 199.170.0.30 192.41.177.112 > mae-netaxs(config)#no ip route 38.8.8.2 > mae-netaxs(config)#ip route 38.8.8.2 192.41.177.112 > mae-netaxs(config)#no ip route 192.77.167.33 > mae-netaxs(config)#ip route 192.77.167.33 192.41.177.112 > mae-netaxs(config)#no ip route 205.137.48.30 > mae-netaxs(config)#ip route 205.137.48.30 192.41.177.112 > mae-netaxs(config)#no ip route 204.117.214.13 > mae-netaxs(config)#ip route 204.117.214.13 192.41.177.112 > mae-netaxs(config)#no ip route 204.70.57.10 > mae-netaxs(config)#ip route 204.70.57.10 192.41.177.112 > mae-netaxs(config)#end > mae-netaxs# > > Avi > > > > > NO I DID NOT, Just talk to UUNet, I was peering with that at that time. > > > > > > Nathan Stratton President, CTO, NetRail,Inc. > > ------------------------------------------------------------------------ > > Phone (888)NetRail NetRail, Inc. > > Fax (404)522-1939 230 Peachtree Suite 500 > > WWW http://www.netrail.net/ Atlanta, GA 30303 > > ------------------------------------------------------------------------ > > "No king is saved by the size of his army; no warrior escapes by his > > great strength. - Psalm 33:16 > > > > On Fri, 12 Sep 1997, Avi Freedman wrote: > > > > > You did. > > > I saw it. > > > Others saw it. > > > > > > Avi > > > > > > > > > > > I was not, I have never pointed a default route at anyone. I was peering > > > > with UUNet at the time, I did not and never have pointed a default route > > > > at them. > > > > > > > > > > > > Nathan Stratton President, CTO, NetRail,Inc. > > > > ------------------------------------------------------------------------ > > > > Phone (888)NetRail NetRail, Inc. > > > > Fax (404)522-1939 230 Peachtree Suite 500 > > > > WWW http://www.netrail.net/ Atlanta, GA 30303 > > > > ------------------------------------------------------------------------ > > > > "No king is saved by the size of his army; no warrior escapes by his > > > > great strength. - Psalm 33:16 > > > > > > > > On Fri, 12 Sep 1997, Avi Freedman wrote: > > > > > > > > > You were defaulting into UUNET at the time... > > > > > > > > > > Avi > > > > > > > > > > > What was netrail a default violation? > > > > > > > > > > > > Nathan Stratton President, CTO, NetRail,Inc. > > > > > > ------------------------------------------------------------------------ > > > > > > Phone (888)NetRail NetRail, Inc. > > > > > > Fax (404)522-1939 230 Peachtree Suite 500 > > > > > > WWW http://www.netrail.net/ Atlanta, GA 30303 > > > > > > ------------------------------------------------------------------------ > > > > > > "No king is saved by the size of his army; no warrior escapes by his > > > > > > great strength. - Psalm 33:16 > > > > > > > > > > > > > >

1 0

SpamShield
by Deepak Jain 12 Sep '97

12 Sep '97

I didn't see anything about this in the archives, but as far as implementing a reasonably friendly anti-spam policy (http://www.abest.com/~kai/spamshield.html) without forbidding relaying entirely, is there a consensus opinion? Thanks, Deepak

2 1

Re: not rewriting next-hop, pointing default, ...
by dlr＠bungi.com 12 Sep '97

12 Sep '97

[In the message entitled "Re: not rewriting next-hop, pointing default, ..." on Sep 11, 15:23, Randy Bush writes:] > >> no neighbor 192.41.177.73 > > they should not care if you peer with them or not, they can have > > the upstream provider to give them your routes, then: > > ! > > set nexthop 192.41.177.121 > > Yes, folk seem to be doing this kind of thing, as shocking and disgusting as > it seems. Hey, at least they know how to configure routers, now. Give them points for that, at least :-) above.net$ traceroute -g 192.41.177.98 www.mci.net traceroute to www.mci.net (204.70.133.140): 1-30 hops, 78 byte packets 1 gate-96.sjc.above.net (207.126.96.161) 2.16 ms 3.92 ms 2.53 ms 2 mae-west-T3-2.above.net (207.126.96.238) 4.85 ms mae-west-T3-1.above.net ( 207.126.96.245) 4.77 ms mae-west-T3-2.above.net (207.126.96.238) 3.32 ms 3 mae-east-oc3.above.net (207.126.96.66) 74.0 ms 78.1 ms 122 ms 4 mae-east-01.ix.ai.net (192.41.177.98) 81.0 ms !S * 87.9 ms !S -- Dave Rand dlr(a)bungi.com http://www.bungi.com

2 1

Re: not rewriting next-hop, pointing default, ...
by rja＠corp.home.net 12 Sep '97

12 Sep '97

On Sep 11 15:54, Randy Bush wrote: } Subject: Re: not rewriting next-hop, pointing default, ... > LSR is actually a significant security issue. So, while I do > understand and am sympathetic to the operational debugging > issues that LSR addresses, I think that requiring a peer to > enable LSR more than 2 hops inside their network from the > outside world is unreasonable. % So, you're comfortable with asking for LSR at the IX and a hop behind? "Comfortable" isn't the word I'd choose. Ideally, I'd filter out LSR entirely [1], but there are real operational issues. Letting LSR in two hops lets outsiders trying to debug (e.g. some routing problem) at least perform first-level fault-isolation so they know whose NOC to call for further debugging assistance. So I view the 2-hop notion as an attempt at "reasonable compromise". > In a world where SSH were available in cisco routers and/or > IPsec were more widely deployed, I might have different views. % K5 does not give you sufficient warm fuzzies? No, I'm afraid that Kerberos 5 doesn't give me sufficient warm fuzzies. I don't care to be very detailed on a public list such as NANOG. I will note that aside from my non-public concerns, Kerberos-5 is expensive to deploy and maintain. Kerberos can also adversely impact network availability if it isn't installed in exactly the right way (surprisingly few folks seem to do it right). Ran rja(a)home.net [1] DISCLAIMERS: - I'm not a security expert, so my opinion probably doesn't mean very much in the grand scheme of things. - I am NOT with @Home's Security Group, which is ably managed by Mike StJohns, who is a Security Expert. So don't blame them for my comments. - I don't make policy for @Home, so my opinions are just mine not my employer's. - I haven't had enough coffee yet today. :-)

2 1