- NANOG - lists.nanog.org

Cable Cut: Singapore/Jakarta
by Sean Donelan 21 Nov '00

21 Nov '00

Australias biggest Internet provider Telstra said on Tuesday it lost 65 percent of its international capacity when the SEA-ME-WE 3 cable was cut between Singapore and Jakarta.

1 0

Fw: "...the IPv4 TOS field should be end-to-end...."
by JIM FLEMING 21 Nov '00

21 Nov '00

With the advent of DiffServ, intermediate nodes may modify the Differentiated Services Codepoint (DSCP) [RFC2474] of the IP header to indicate the desired Per-hop Behavior (PHB) [RFC2475, RFC2597, RFC2598]. The DSCP includes the three bits formerly known as the precedence field. Because any modification to those three bits will be considered illegal by endpoints that are precedence-aware, they may cause failures in establishing connections, or may cause established connections to be reset. ----- Original Message ----- From: Alan Hannan <alan(a)mindvision.com> To: JIM FLEMING <jfleming(a)anet.com> Cc: Roeland Meyer <rmeyer(a)mhsc.com>; 'Shawn McMahon' <smcmahon(a)eiv.com>; <nanog(a)merit.edu> Sent: Tuesday, November 21, 2000 12:15 AM Subject: Re: "...the IPv4 TOS field should be end-to-end...." > > This has been addressed in the appropriate standards bodies: > > ftp://ftp.isi.edu/in-notes/rfc2873.txt > > -alan > > Thus spake JIM FLEMING (jfleming(a)anet.com) > on or about Mon, Nov 20, 2000 at 11:33:30PM -0600: > > > > In my opinion, the IPv4 TOS field should be end-to-end.... > > ...clients should set it....routers should leave it alone.... > > > > Jim Fleming > > http://www.unir.com/images/architech.gif > > http://www.unir.com/images/address.gif > > http://www.unir.com/images/headers.gif > > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > > http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp > > > > > > ----- Original Message ----- > > From: Roeland Meyer <rmeyer(a)mhsc.com> > > To: 'Shawn McMahon' <smcmahon(a)eiv.com>; <nanog(a)merit.edu> > > Sent: Monday, November 20, 2000 11:29 PM > > Subject: RE: ISPs as content-police or method-police > > > > > > > > > > Please reference any suit regarding breach of contract. Examples abound. > > > Port filtering may be construed as a material breach when the expectation > > > is, that there is to be no port filtering. Access is access, even when the > > > customer doesn't know that they are being restricted in their access. That > > > just assures you that they will go ballistic when they find out. > > > > > > Face it guys, you KNOW that this is basically dishonest. As such, it is > > > indefensible. I would almost bet <amount> that none of the transit > > providers > > > mentions restrictions, on access, in their contracts. I would almost bet > > > <1/2 amount> that NONE of the access providers mention same in THEIR > > > contracts. The general expectation is for clear and open pipes. Put such > > > restiction into your contracts and you will lose customers. Don't put them > > > in and start filtering anyway and you will lose court cases...big ones. > > > > > > > -----Original Message----- > > > > From: Shawn McMahon [mailto:smcmahon@eiv.com] > > > > Sent: Monday, November 20, 2000 7:21 PM > > > > To: nanog(a)merit.edu > > > > Subject: Re: ISPs as content-police or method-police > > > > > > > > > > > > On Mon, Nov 20, 2000 at 12:03:57PM -0500, Christian Kuhtz wrote: > > > > > > > > > > What doesn't make sense in that argument is why you > > > > couldn't just simply > > > > > upsell the customer to a managed fw solution etc if that's > > > > the concern. > > > > > Educate them, and let them decide based on the education > > > > they received. > > > > > > > > Because it doesn't just affect them; it affects you, your customers, > > > > and your business. > > > > > > > > > I wouldn't be so sure, particularly because of the legal exposure... > > > > > > > > Does anybody have a live example of this supposed legal exposure, to > > > > counter all the many examples those of us who don't believe in it have > > > > given? > > > > > > > > > > > > > > > > >

1 0

RE: ISPs as content-police or method-police
by Roeland Meyer 21 Nov '00

21 Nov '00

> From: joshua stein [mailto:jcs@rt.fm] > Sent: Monday, November 20, 2000 12:02 PM > If users are smart enough to switch the port and encrypt > their traffic, > then obviously there's nothing to worry about. The original > suggestion > was to protect users that probably don't even realize they have shares > open to the world. Lord, please spare me from those who would save me from myself. What do you call someone that promises something and then intentionally doesn't deliver what was promised? What do you call it when that person knew that they would never deliver on the promise when it was made? Is it a crime when they collect money for the false promise? Every upstream I contract, for my clients or otherwise, makes no mention of any restriction except that needed to manage the upstream pipe. Evenso, that is always explicit. Various clients, in aggregate, total to over $120K per month, in hosting and access charges. Almost every one of them depends on SMB, or other protocols, to some degree or another. I also have various proprietary protocols that are used (Yes, some of us do design and write such things). We have enough problems from DOS attacks originating from the script kiddies, we don't need DOS attacks from our upstreams (uncontracted/unrequested port filtering). If a transit provider wants to filter their dial-ins, or anyone else, and they have that in a specified business arrangement, then fine, I have no problems with it. But, they will never get my business and I will never sign such a contract unless there is no competitor with a different policy. In the latter case, my next stop would be my attorney, regarding a restraint of trade suit. ---- R O E L A N D M. J. M E Y E R Managing Architect

3 2

RE: Operational impact of filtering SMB/NETBIOS traffic?
by Roeland Meyer 21 Nov '00

21 Nov '00

How closely have you looked at Samba sources? BTW, I've done it through SSH tunnels too. The problem is that some SAs (a fair large percentage) think that a port labeled "secure" (port 22) means that they have to take special care to make sure that it is blocked (yes, they are the recently lobotomized). So, three-quarters of the time, a VPN is not do-able and you are forced to go plain-text direct. If, in addition, you block the NetBIOS ports then you block application-level access for 80% of internet users. > -----Original Message----- > From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] > Sent: Sunday, November 19, 2000 8:19 AM > To: Roeland Meyer > Cc: 'Scott Call'; nanog(a)nanog.org > Subject: Re: Operational impact of filtering SMB/NETBIOS traffic? > > > On Sat, 18 Nov 2000 20:19:12 PST, Roeland Meyer > <rmeyer(a)mhsc.com> said: > > shares on the internet? We use SMB/Samba INSTEAD of NFS > because we believe > > SMB to be more secure. smb.conf certainly gives more > security options than > > exports does. > > Don't confuse "more options" with "more security". > > A protocol can have dozens of options, but yet be > fundementally insecure. > -- > Valdis Kletnieks > Operating Systems Analyst > Virginia Tech > >

10 11

Re: Trusting BGP sessions
by Sean Donelan 21 Nov '00

21 Nov '00

Ok, let me show why this isn't a valid reason. Me: Will you peer with me on both coasts with this bandwidth using this protocol? BigISP: No, because we don't trust ..... Me: Will you sell me the same, identical connections in multiple locations using the same, identical protocols? BigISP: Of course, yes. Me: If you have systems in place to protect your network against my network as a customer, why don't those exact same systems work when you connect the same network, router and protocol as a peer? BigISP: Its too complicated, and you wouldn't understand. Question: historically have more routing snafus originated in "customer" BGP sessions or in "peer" BGP sessions? On Tue, 14 November 2000, David Diaz wrote: > Sorry, Yes. > My original answer mentioned in the past. I think we all understand > that the "business" side has entered. > > However someone connecting to your peering router can create a create > deal of havoc. Some of the older routers could have a major problem > with floods of tens of thousands or hundreds of thousands of routes > being added or withdrawn quickly. At the same time if the peer is > flapping and rerouting hunderds of megs to different exchange points, > first east coast then west, it could cause a serious problem. I know > you know that Sean. >

7 9

ISI gives up .US to NSI
by jamie rishaw 21 Nov '00

21 Nov '00

</how-do-i-configure-my-router> <political> >From: US Domain Help <usdomhelp(a)verisign-grs.com> To: jamie(a)arpa.com Subject: United States Domain Registry - Important New Information Date: Mon, 20 Nov 2000 19:27:23 -0500 (EST) ========================================================================= To all administrative and technical contacts: As you may already know, since 1993 the Information Sciences Institute of the University of Southern California has administered the .US domain under a subcontract with Network Solutions, Inc. through its cooperative agreement with the U.S. Government. USC has chosen not to renew its subcontract, and therefore VeriSign Global Registry Services, a division of Network Solutions, Inc., will assume direct administration of the .US domain as of Tuesday, November 28, 2000. Please note that no changes will occur to syntax, and the standards established by RFC 1480 located at http://www.isi.edu/in-notes/rfc1480.txt will continue to apply. VeriSign Global Registry Services will forward its revised standard interim service agreement to you via email shortly for your review. We will also post the agreement on our web site at http://www.nic.us. Should you have any questions, you may email them to usdomhelp(a)verisign-grs.com. Best regards, United States Domain Registry VeriSign Global Registry Services www.verisign-grs.com usdomhelp(a)verisign-grs.com =========================================================================

1 0

Summation (SMB filters)
by Scott Call 21 Nov '00

21 Nov '00

I've been reading through the impressive amount of feedback I recieved on the issue of fitlering SMB traffic, so I wanted to share the results of our actions. The day I posted the first message to Nanog I blocked SMB on our Redback customer aggregation routers (DSL customers only). In 24 hours we had two requests to remove the block, and we did for those customers. Over the next week we got maybe 3-5 more requests. Zero cancelations. Our DSL customer base is 75-80% small office/home office DSL with one IP address dynamic assigned at installation and then RFC 1918 space behind a natting router. I don't like filtering any traffic, but we do not have the time/staff to school our customers on safe networking, mostly because our customers are small and w/o any SA type staff. -Scott -- ------------------------------------------------------------------------ Scott Call | Perhaps the best way to keep kids from turning on Router Geek | their classmates is to protect them in the first Advanced Telcom Group| place, -jonkatz

1 0

RE: Operational impact of filtering SMB/NETBIOS traffic?
by Mathew Butler 20 Nov '00

20 Nov '00

Are you going to provide consulting services -- for free -- when what the customer wants to do is not allowed because of your network filtering choices? -Mat -----Original Message----- From: Adam Rothschild [mailto:asr@latency.net] Sent: Monday, November 20, 2000 8:06 AM To: nanog(a)merit.edu Subject: Re: Operational impact of filtering SMB/NETBIOS traffic? On Sat, Nov 18, 2000 at 08:19:12PM -0800, Roeland Meyer wrote: > You'd have LOTs of complaint from me and many of my clients. Many of > us log into our external gateway PDCs from foriegn locations. We > have shares because we want shares. Yikes. Isn't that what secure road-warrior VPNs are for? > You are considering killing off a whole bunch of legitimate use > because some are too brain-dead to not have unintentional shares on > the internet? Intentional or not, sniffing SMB passwords and share info doesn't require much skill. > We use SMB/Samba INSTEAD of NFS because we believe SMB to be more > secure. That's like saying the electrical chair may be far more appealing to some than lethal injection. NFS and SMB are both insecure and inefficient mechanisms for file transfer over the public Internet. SMB may be the lesser of the two evils, but it's really irrelevant. Why not use ssh/sftp, or for the Unix impaired, some https-based file transfer interface, instead? On Sun, Nov 19, 2000 at 09:06:06AM -0800, Roeland Meyer wrote: > [...] in addition, you block the NetBIOS ports then you block > application-level access for 80% of internet users. Howso? Sounds like you'd be promoting responsible usage instead. -adam

2 1

Re: Operational impact of filtering SMB/NETBIOS traffic?
by Mike Johnson 20 Nov '00

20 Nov '00

Dennis Glatting [dennis.glatting(a)software-munitions.com] wrote: > > Dumb question: > > Could filtering be considered a violation of First Amendment rights? > Furthermore, when is it and when is it not? Uh, I think that might be taking things a little too far. I really think the only law involved -might- be contractual (IE, 'our contract says they our connect is unfiltered' or some such). You can sign contracts that limit your speech (NDA's, for instance), so I don't really see this as a First Amendment thing. Mike -- Mike Johnson Network Engineer / iSun Networks, Inc. Morrisville, NC All opinions are mine, not those of my employer

2 1

Various types of filtering - why not?
by Mark Mentovai 20 Nov '00

20 Nov '00

Why doesn't the community seem to be able to fix its own biggest problems even when technical solutions are available, or could be made available? Anti-spoofing ingress filtering and route advertisement filtering can be implemented, and it wouldn't be that hard, so why hasn't anyone stepped up and said "do it?" If I'm not mistaken, a few years back, Sean Doran at Sprint and a few other NANOG members took a look at the Internet and said "something is not right." (Sean, I know you still poke in every now and then, so forgive me for putting you on too high or not high enough a pedestal.) The mess of small routes cluttering up everyone's tables was handled with prefix filtering. Flap dampening was implemented and major carriers began to use it, solving the problems of excessive BGP noise. The community said "fix it" and it was fixed. We can thank them for a more stable, cleaner network than we would otherwise be left with. How come now, five years later, nobody's willing to say "fix it?" Come on, everyone, let's stop joking around and put spoofing and bogus announcements behind us so we can move on to whatever the next big problem is. Corporate maneuvering aside, the major NSPs today are more or less the same as the major NSPs of 1995. Have things really changed so much since then that we won't be rid of spoofing and bad routes until someone creates an agency to regulate us? What does that say about what we've become? So I'll say it: We've got these problems staring us in the face, and we've got the know-how and the means to fix them. Whether that means moving straight to implementation, or if we need to strategize for a while, it can be done. Now let's do it. Mark

2 3