- Test - lists.nanog.org

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

22 Nov '00

You missed the point. The filters were removed the moment we were able to get a suitably authorized NOC tech (next morning). That didn't change the fact that I incurred losses from paying three expensive contractors, for a full night of over-time, as a direct result of the unannounced filter. The contractors got paid, how do I recover the losses caused by the contract breach? The upstream refuses, therefore we must go to court. > -----Original Message----- > From: Shawn McMahon [mailto:smcmahon@eiv.com] > Sent: Wednesday, November 22, 2000 7:20 AM > To: nanog(a)merit.edu > Subject: Re: ISPs as content-police or method-police > > > On Tue, Nov 21, 2000 at 02:12:38PM -0800, Roeland Meyer wrote: > > > > engineers doing this when it could have been prevented? I > have. Three > > contractors, doing this, in over-time, at Silicon-Valley > rates is well over > > $20K. More than enough to make it worth my while to sue my upstream. > > And did you sue, or did you request the filter be removed? > > You stated earlier in this thread that what you would do, and what > anyone reasonable would do, is immediately call their lawyer. > > Did you call him first, or did you contact the upstream first? > >

3 2

Down under NANOG: Telstra problems and root servers
by Sean Donelan 22 Nov '00

22 Nov '00

In addition the the previously reported cable cut, several folks have written about a fire at an electrical substation cut power for much of eastern Sydney, the location of a major Telstra server facility. As far as I can tell, the fire had little affect on Telstra's servers because backup generators were in place. Although Telstra is the dominant ISP (and telephone company) in Australia, there are other ISPs using other facilities which were not affected by the cable cut. So, if a root server was placed in Australia, to whom's network should it be attached. Would OPTUS and Telstra cooperate and jointly provide connectivity and diversity? Or is the most connected place in the asia-pacific region still the west coast of the US?

7 6

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

22 Nov '00

> From: Stephen Sprunk [mailto:ssprunk@cisco.com] > Sent: Tuesday, November 21, 2000 11:16 AM > To: Roeland Meyer; 'Shawn McMahon'; nanog(a)merit.edu > Subject: Re: ISPs as content-police or method-police > > > Thus spake "Roeland Meyer" <rmeyer(a)mhsc.com> > > > > 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. > > If filtering is in the contract, it's hardly breach of contract to > perform it. That is not the case that I layed out. The expectation is met in the contract. The contract I stipulated had no wording about filtering, only providing unfettered access to the internet. Ergo, it would be a breach. > > 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. > > AT&T, I believe, was the first major provider to start filtering port > 25; here's the relevant part of their contract: > > http://www.att.net/general-info/terms.html > "AT&T reserves the right to block, filter or delete Unsolicited > E-Mails." Again, where is this relevent to the case example? > Ths is also promising: > "don't send materials that contain viruses, worms, or any other > destructive elements; ... You may not use or attempt to use > the Service > to violate its security or the security of systems accessible through > it, ... you should secure your computer equipment so that only > authorized users can gain access to your Service account." > > You could claim that these sections authorize blocking of QAZ et al, > since the activity of worms is prohibited. Also, customers > are required > to secure their computers to prevent intrusion, so leaving > any blatantly > insecure protocol like SMB enabled might be breach of contract. > Wholesale blocking of SMB might even be allowed. Samba is NOT blatantly insecure. A smart admin CAN secure it. The new Win2K stuff is also pretty good, since one must interact with a secured proprietary login host, in order to gain access. That folks leave the default "Everyone" share premissions intact, is not a fault of the protocol. > Of course, I wouldn't want to use that logic in court, but a > good lawyer > could probably pull it off. I'd prefer to insert more > specific wording > into the contract first. Only if he isn't up against another good lawyer... put the specific words in the contract before risking this one. > Then again, nobody here seems to be suggesting mandatory > filtering. Actually, this is not true. More than one have advocated this, both publically and privately. One has even announced that they've implemented this recently, without telling their customer, and it wasn't in the contract. The five cases he mentioned called the same day. How did they find out? When things quit working, that's how. How many of his customers suffered through multiple day outages, because of his action, and are still spending resources to fix things, assuming they had open pipes like the contract stated? > Why > is there such a strong objection to opt-out filters, where a > single call > or email can get the filters turned off? Is using a phone really that > difficult? Have you ever spent all night debugging an application, only to find out, at 0400 that their MIGHT be an upstream filter and can't raise anyone at the upstream NOC? Even if you could, and get the filter removed. You wouldn't have been there all night if the nimrods had put it into the contract so that you knew about it. Have you ever had to pay the bill for three engineers doing this when it could have been prevented? I have. Three contractors, doing this, in over-time, at Silicon-Valley rates is well over $20K. More than enough to make it worth my while to sue my upstream. Discovering contract breaches the hard way is very expensive.

2 1

Definition problem (was Re: Out of band monitoring of equipment)
by Sean Donelan 22 Nov '00

22 Nov '00

On Tue, 21 November 2000, John Leong wrote: > Curious if any operator uses, or have interest in using, out of band > network (e.g. modem, wireless etc.) for remote equipment (routers, > switches, HVAC etc.) monitoring over and above doing it in band on the > Internet. I expect all providers, major and minor, will answer they do. However, this is one of those questions where everyone knows exactly what they mean, but they may not mean what you think. Some providers have a dedicated management network, independent of the IP network, connected to all of their equipment: building, network, security, servers, etc. Some providers have a dedicated management network connected just to their primary network boxes: routers, servers. Some use it for monitoring and maintenance, others only for repair and maintenance. Some providers have dialup (POTS) access connected to a management port for maintenance and repair of a few critical pieces of equipment, but not regularly used for monitoring. Some providers have distributed systems which monitors local equipment and send pages to local technicians. Other providers centralize this function in a single (and sometimes a backup) NOC. The most common system uses an in-band method (normally SNMP and PING) for monitoring and maintaining the network. An out-of-band method (normally POTS to console modems) is used for network repair activities. Building systems (HVAC, UPS, Fire, Security, etc) have some in-band monitoring, but alarms are generally sent by seperate out-of-band networks. A lot of times the decision is based on what types of systems a provider already had in place. But part of the difference may be due to the different accounting and revenue practices. In reality the distinction between "in-band" and "out-of-band" is artificial. The "in-band" network may be considered the revenue-generating or production network; while the "out-of-band" network is the network which doesn't generate revenue. They frequently aren't as seperate or independent as folks may think. The out-of-band network is often just a chunk of bandwidth you aren't using for revenue generating traffic.

2 1

The author of PING is reported dead
by Sean Donelan 22 Nov '00

22 Nov '00

Since many network operators consider PING as one of their essential tools, I thought this would be of interest to the list. I haven't been able to confirm this, but I haven't been able to reach Mike. Forwarded message: >Subject: The Creator of Ping is dead... > >Mike Muuss, the author of the PING program used on networks everywhere, >died last night in a traffic accident on US route 95 in Maryland. He was >an alumnus of Johns Hopkins (BS1978 or 1979 I think). > >Funeral arrangements have not been made yet, but I'll probably be going >back to Maryland almost immediately to attend. http://ftp.arl.army.mil/~mike/ping.html

2 1

Jim's Latest Rant (was Re: Does AT&T provide IPv4HT ?)
by Ron Buchalski 22 Nov '00

22 Nov '00

Jim, Most end applications are concerned with receiving the data in the payload of a packet, and that the headers of the packet remain intact to the extent that the packets are delivered to the proper destination. Did you write an application that uses TOS bits on an end-to-end basis, and now you've found that changing TOS bits within the network is going to break your application? What compelling event brought you to your computer and prompted you to start this rant on NANOG? The S/N ratio _was_ actually increasing... -rb >From: "JIM FLEMING" <jfleming(a)anet.com> >To: "Jesper Skriver" <jesper(a)skriver.dk>, "Daniel Golding" ><dan(a)netrail.net> >CC: <edelman(a)law.harvard.edu>, "!Dr. Joe Baptista" <baptista(a)pccf.net>, ><klensin(a)jck.com>, <mcade(a)att.com>, "Bellovin,Steven M (Steve) - ALRES" ><smb(a)att.com>, <nanog(a)nanog.org>, <karl(a)cavebear.com> >Subject: Re: Does AT&T provide IPv4HT ? >Date: Tue, 21 Nov 2000 15:18:36 -0600 > > >I think we are in agreement. I am assuming that people will want to "touch" >the TOS byte when they "create" a packet. I am also assuming that NANOG, as >a group, would want to support "end-to-end" Internet services. That seems >to imply that the NANOG people would endorse the notion of "what goes in >comes out". That arrangement encourages "stability". It seems odd that we >have all of these ICANN people running around telling everyone that the >"stability" of the Internet needs to be preserved, and then on the other >hand, people are >flippantly claiming to have total disregard for the contents of packets as >they transit the IPv4 "cloud". To top it off, some companies apparently >want to be seen as "proud" or "cool" for changing the contents of >customer's packets. ...and then want to be called...."real operators"...go >figure... > >Jim Fleming >http://www.unir.com >Mars 128n 128e _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com

1 0

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

22 Nov '00

In my opinion, NANOG may want to define itself as a collection of people and companies who endorse, deploy, support, etc. a network which is very SIMPLE, one which supports IPv4 end-to-end with no changing of the bits that historically have not been changed and no dropping of packets in the middle, until the TTL counts to 0. Note, we have to live with the changing checksum field. It seems to me that NANOG could focus on SIMPLE protocols and maximum performance. If NANOG chooses to become a group chasing the protocol-du-jour, then it seems to me that there will be another body of people needed to focus on the simple IPV4 transport, that supplies end-to-end IPv4 service, not some "re-wrote the rules" and re-wrote the bits protocol. If Karl[1] were here, he would probably refer to that as a NotWork, as opposed to a NetWork. [1] - http://www.denninger.net/ It seems to me that NANOG has to choose what it wants to be. If NANOG decides to focus on the SIMPLE IPv4 transport approach, then people might want to start testing to see which vendors conform and which do not. A simple test suite should be able to do that. Those that do not conform, should not have traffic routed to them until they do conform. Why would people continue to allow people to be connected to a NetWork if they are doing things that make it NotWork ? It seems to me it will be hard enough to make it all work, day to day, 24x7 with the SIMPLE approach. If you do not draw the line some place, then, in my opinion NANOG will cease to be what NANOG is famous for, and will gravitate to be one of many "chat rooms" on the net, lost in cyberspace. Maybe that is your fate... 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: Alan Hannan <alan(a)mindvision.com> To: JIM FLEMING <jfleming(a)anet.com> Cc: <vern(a)aciri.org>; <edc(a)explosive.net>; <alan(a)mindvision.com>; <xipeng(a)gblx.net>; <nanog(a)merit.edu> Sent: Tuesday, November 21, 2000 1:32 AM Subject: Re: Fw: "...the IPv4 TOS field should be end-to-end...." > > Jim, > > Thanks for pointing out a blinding glimpse of the obvious. > > The purpose of the RFC is to allow just that; rather, make legal the > changing of the (formerly-known-as) precedence bits. > > Having run an operational network with a large customer set, we found > in operational testing that only certain stacks (effectively only > certain macTCP versions) are actually "precedence-aware". > > This fractionally small minority obstructed our desire to implement > production observance of the precedence bits. > > The greater good of the forward movement of DSCP use is collectively > determined to be of greater importance than the needs of those > inflicted with "precedence-aware" behaviour. > > ( Additionally, the "precedence-aware" stacks can be accomodated by > strictly setting the DSCP in most all cases. ) > > Therefore, we "re-wrote the rules" by introducing the RFC to > accomodate the oversight in considerations. > > I fail to grasp the point of your diatribe, although it seems to be > that you are against any ISPs modifying the internal bits of your IP > packets. I'll assume you are comfortable w/ them modifying TTL. > > Can you concisely state for me and the group exactly what your > objection and/or problem is, please? > > -alan > > > > Thus spake JIM FLEMING (jfleming(a)anet.com) > on or about Tue, Nov 21, 2000 at 01:01:40AM -0600: > > > > 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? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

3 2

Out of band monitoring of equipment
by John Leong 22 Nov '00

22 Nov '00

Curious if any operator uses, or have interest in using, out of band network (e.g. modem, wireless etc.) for remote equipment (routers, switches, HVAC etc.) monitoring over and above doing it in band on the Internet. Regards, John Leong

10 9

RE: Does Jim Fleming provide IPv4CMRN?
by Kavi, Prabhu 21 Nov '00

21 Nov '00

Does Jim Fleming provide a IPv4 Clueful Message Related to NANOG? Nope. Give it up Jim. Prabhu > -----Original Message----- > From: JIM FLEMING [mailto:jfleming@anet.com] > Sent: Tuesday, November 21, 2000 2:33 PM > To: Susan R. Harris > Cc: nanog(a)merit.edu > Subject: Does MERIT provide, "end-to-end", IPv4 Header Transport > (IPv4HT) > > > > http://www.merit.edu/ > Merit Network, Inc. > Michigan's Leading Internet Provider > > Does MERIT provide, "end-to-end", IPv4 Header Transport (IPv4HT) > ....with the TOS field untouched ? > > 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 > > > >

2 1

Does AT&T provide IPv4HT ?
by JIM FLEMING 21 Nov '00

21 Nov '00

Does AT&T provide, "end-to-end" IPv4 IP Header Transport ? ....with the TOS field untouched ? 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: Stephen Sprunk <ssprunk(a)cisco.com> To: Roeland Meyer <rmeyer(a)mhsc.com>; 'Shawn McMahon' <smcmahon(a)eiv.com>; <nanog(a)merit.edu> Sent: Tuesday, November 21, 2000 1:16 PM Subject: Re: ISPs as content-police or method-police > > Thus spake "Roeland Meyer" <rmeyer(a)mhsc.com> > > > > 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. > > If filtering is in the contract, it's hardly breach of contract to > perform it. > > > 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. > > AT&T, I believe, was the first major provider to start filtering port > 25; here's the relevant part of their contract: > > http://www.att.net/general-info/terms.html > "AT&T reserves the right to block, filter or delete Unsolicited > E-Mails." > > While it doesn't explicitly state how they intend to "block, filter or > delete" spam, filtering port 25 by default can be reasonably construed > to fit that definition, and is therefore within the contract. > > Ths is also promising: > "don't send materials that contain viruses, worms, or any other > destructive elements; ... You may not use or attempt to use the Service > to violate its security or the security of systems accessible through > it, ... you should secure your computer equipment so that only > authorized users can gain access to your Service account." > > You could claim that these sections authorize blocking of QAZ et al, > since the activity of worms is prohibited. Also, customers are required > to secure their computers to prevent intrusion, so leaving any blatantly > insecure protocol like SMB enabled might be breach of contract. > Wholesale blocking of SMB might even be allowed. > > Of course, I wouldn't want to use that logic in court, but a good lawyer > could probably pull it off. I'd prefer to insert more specific wording > into the contract first. > > > The general expectation is for clear and open pipes. Put such > restiction > > into your contracts and you will lose customers. > > As long as a user can request the filters be removed (as in AT&T's > case), I doubt anyone will lose customers. In fact, I've seen many ads > for ISPs which promote their filtering service with the belief that it > will bring them more customers. > > > Don't put them in and start filtering anyway and you will lose > > court cases...big ones. > > If an ISP refuses to turn off unrequested filters, and the filters > aren't in the contract, I can see a lawsuit. I can also see the > customer simply taking their business elsewhere and persuing the matter > through the press. As AGIS proved, that turned out to be far more > effective than courts. > > Then again, nobody here seems to be suggesting mandatory filtering. Why > is there such a strong objection to opt-out filters, where a single call > or email can get the filters turned off? Is using a phone really that > difficult? > > S > > | | Stephen Sprunk, K5SSS, CCIE #3723 > :|: :|: Network Design Consultant, GSOLE > :|||: :|||: New office: RCDN2 in Richardson, TX > .:|||||||:..:|||||||:. Email: ssprunk(a)cisco.com > > > >

3 4