July 2000 - Test - lists.nanog.org

RE: Wanted: Clueful Individual @ TeleGlobe.net
by Karyn Ulriksen 17 Jul '00

17 Jul '00

Out of curiousity, how does the telco world handle this? When some one signs up for MCI longdistance, I assume that on some calls they will cross off the MCI network (and potentially though several others) that will be piled mile high in static. The customers will complain about their connection to their respective local and long distance companies. But I believe it isn't an option to contact the networks that they may transit mid-stream. However, some QC must be in place to achieve some level of consistancy to get that expected "pin drop" quality we've apparently come to take for granted... Is it cooperation amongst the networks possibly? Cooperation among the NOC's seems in order wherever possible and I rarely run into uncooperative NOCs (unless I find myself in the sad state of being unreasonable). IMHO, it's probably asking too much for every network to answer to every Tom, Dick, & Harry when everyone is fighting for peering b/w, praying for equipment that lives up to expectations, filtering script kiddies, and keeping the typical high b/w access to less than $45.00/month. Of course, I could be wrong and accept that possibility. Karyn > -----Original Message----- > From: Troy Davis [mailto:troy@nack.net] > Sent: Sunday, July 16, 2000 12:44 AM > To: Derek J. Balling > Cc: nanog(a)nanog.org > Subject: Re: Wanted: Clueful Individual @ TeleGlobe.net > > > > On Sat, 15 Jul 2000, Derek J. Balling <dredd(a)megacity.org> wrote: > > > Sample snip from phone call: > > This mirrors my experience with the AT&T NOC on Friday after > seeing latency > between GlobalCenter and AT&T. The GlobalCenter NOC had no > problem opening a > ticket without caring whether I was a customer or not. They > spent a few hours > on it and said it appeared to be an over-loaded AT&T router. > > Not entirely sure of that - and if it was true, wanting to > see what AT&T > was doing about it - I called AT&T, was transferred 3 times > to reach the IP > folks, and was promptly stonewalled. > > The level 1 tech didn't know latency from Adam but wasn't > willing to find > someone who did. He said he couldn't open a ticket for a non-customer > and we argued for 10 minutes about what to do next - hang up > or talk to the > next guy up the chain. I convinced him that it was an actual > issue and that > he should indeed tell his boss - or maybe he just got tired > of talking. > > Anyhow, his boss came on the line and said the same thing, > emphasizing that > they couldn't open tickets for non-customers. Even informing > him that AT&T > customers were calling us to complain and that AT&T users > were affected > didn't help. This guy claimed to be the engineering manager > and said there > was nobody above him to go to. We talked for a while - 10-20 > minutes - and > apparantly he finally got tired too, since he took my name/number. > > A couple minutes later I got a call from a third guy there, > who said that > any issues were between AT&T and GlobalCenter and that I had > no business > calling. I asked if there was an open ticket or even someone > addressing it > and he had no idea. He didn't seem to know any more about > networking than the > first guy. > > The most discouraging part was that the last two people > understood that it was > a service-affecting problem and yet hadn't been given any > procedures to solve > it. It felt like I was asking a secretary - they all stated > that they > understood it was a problem but couldn't do a damn thing. > > I ended up sending a note to noc(a)att.net telling them the > problem, my support > story, and noting that their NOC folks couldn't do any of > these things (all of > which I asked to do): > - open a trouble ticket for a non-customer > - transfer me to someone who could > - transfer me to the IP engineers > - verify/deny that the problem was within AT&T (a > traceroute, perhaps?) > - call GlobalCenter and work on the ticket I had open with them > - provide me with an escalation or complaint path, > either for the original > problem or to complain about the NOC's useless procedures > > .. any of which would have been more useful than hanging up > and sending an > email. I still haven't received a reply or even an automated > ticket #. > > Cheers, > > Troy >

1 0

Re: Wanted: Clueful Individual @ TeleGlobe.net
by Me 17 Jul '00

17 Jul '00

Having worked at a large unnamed backbone provider, I agree with the reasoning behind not opening tickets for non-customers. That having been said however, it is inexcusable to ignore a possible problem on the network you are responisible for. When non-customers would call the NOC, I would listen to them, thank them for the heads up, and investigate the problem, at the same time letting them know I could not open a "customer" ticket on them. If there WAS a problem found(believe it or not, net everyone reporting a problem knew what they were talking about :> ), an internal ticket would be opened and worked as normal. -Sean me(a)mentzer.org

1 0

RE: piracy on parade
by Abrams, Chris 17 Jul '00

17 Jul '00

Agreed. -----Original Message----- From: Dmitri Krioukov [mailto:dima@krioukov.net] Sent: Friday, July 14, 2000 1:25 PM To: nanog(a)merit.edu Subject: RE: piracy on parade wouldn't it to be a right time to get list moderated? thanks, -- dima.

2 1

What Internet Service Providers Need to Know About the Law
by Sean Donelan 17 Jul '00

17 Jul '00

Next week Mark Eckenwiler, a real lawyer in the criminal division at the US Department of Justice, will be discussing "What Internet Service Providers Need to Know About the Law" at the Blackhat Conference in Las Vegas. I've dealt with Mark before. He knows both the legal and technical stuff. ISP or exchange point operators may want to send either a technical or legal person to get a better idea what the DOJ thinks ISPs should know. Its one of those rare opportunities to try to get real answers to those perpetual mailing list topics. I hope his talk doesn't get yanked by DOJ due to the current carnivore flap. http://www.blackhat.com/ for more information.

1 0

slashdot slashdotted?
by Sean Donelan 17 Jul '00

17 Jul '00

Is it only me, or is www.slashdot.org off the air? I've been trying to access it for the last hour or so with no response. I contacted their upstream ISP, but wondered if anyone else had heard anything.

3 3

Re: Path-MTU-discovery
by Richard A. Steenbergen 17 Jul '00

17 Jul '00

On Mon, 17 Jul 2000, Mikael Abrahamsson wrote: > On Mon, 17 Jul 2000, Patrick W. Gilmore wrote: > > > Wow, why would the ICMPs get lost? > > I think it's because of access lists etc. I am not the one who have > set it up so I do not know. We've had this problem from two different > companies (one for our national needs and one for our international > needs). The international one has solved it with what you mention > below. Wouldn't it be unfortunante if the script kiddies decided to do DoS over ICMP Need-Frag... This is a very bad situation we find ourselves in you realize? The quicker we find a way to get rid of this rather bad hack the better. Rate-limits of need-frag can help, but many people are still in a position where their filters leave need-frag wide open and they can't or aren't currently rate limiting. The PMTU-D blackhole detection-type checks help keep this current hack alive a little longer. I'm not currently aware of the extent to which various OS's implement this kind of thing, any ideas? -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: Path-MTU-discovery
by Patrick W. Gilmore 17 Jul '00

17 Jul '00

At 08:26 AM 7/17/00 +0200, Mikael Abrahamsson wrote: >On the other hand, at work we're doing some tunneling using ciscos. Due to >routing etc the ICMP "need-to-frag"-messages get lost and the people >behind those tunnels cannot use 90% of the www sites (so they have to >resort to proxies). Seems to me that PMTUd works better than most people >think. Wow, why would the ICMPs get lost? Also, cisco has a feature on tunnels now where the routers will frag & de-frag making the tunnel MTU effectively 1500 bytes (or whatever you set). >I do believe that NT and Win2k comes default with a registry setting that >makes it send all TCP traffic with the DF flag set (which I can see no >reason for unless M$ IP stack cannot do refragmentation properly). This >setting is changable as far as I know but I cannot seem to find the >information at this time. Anyone? I have no clue if that is really a setting. (Do not run any MS web servers.) However, end stations do not do fragmentation. They do re-assembly, but the receiving station has no control over whether something gets fragmented in transit to it. If the MTU of a path is less than, say, 1500, the end station just sends out smaller packets, not fragments. Since it is likely that you have visited an MS-power site, and you say you can reach all sites, then the MS IP-stack can probably send out packets < 1500 bytes long. If the setting you describe does exist (and it may very well considering MS' history), it is probably just another screw up from the world's black-hole for bad programmers. >Mikael Abrahamsson email: swmike(a)swm.pp.se TTFN, patrick

2 1

Re: Path-MTU-discovery
by Richard A. Steenbergen 17 Jul '00

17 Jul '00

On Mon, 17 Jul 2000, Mikael Abrahamsson wrote: > On Sun, 16 Jul 2000, Greg A. Woods wrote: > > > Experience is beginning to suggest that it's the vast majority of them > > that use PMTUd now. Where it doesn't work _at_all_ on the "client" side > > you quickly find out that perhaps as many as 2/3's (anecdotally > > measured) of the "popular" web servers out there seem to be unusable > > I am behind a tunnel with something like 1446 MTU. It works just nicely, I > have not found any sites so far that won't work. > > On the other hand, at work we're doing some tunneling using ciscos. Due to > routing etc the ICMP "need-to-frag"-messages get lost and the people > behind those tunnels cannot use 90% of the www sites (so they have to > resort to proxies). Seems to me that PMTUd works better than most people > think. > > I do believe that NT and Win2k comes default with a registry setting that > makes it send all TCP traffic with the DF flag set (which I can see no > reason for unless M$ IP stack cannot do refragmentation properly). This > setting is changable as far as I know but I cannot seem to find the > information at this time. Anyone? As much as it saddens me to know the answer to a Win2K question (and believe me I'll never live this down), bust out regedt32.exe, head down to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters and add the dword value EnablePMTUBHDetect = 1. This turns on the PMTU blackhole detection, where if it suspects the ICMP is being blocked because of its PMTU-D it will test the theory by retransmitting with the DF off to see whats up. While you're there, I recommend the following additions/changes as well (since windoze stuff isn't terribly easy to navigate): Tcp1323Opts = 3 (high perf long/fat pipe window scaling & timestamping) SynAttackProtection = 2 (its turned off by default, go figure :P) EnableICMPRedirect = 0 (most people dont filter icmp redirects right) TcpWindowSize = 262144 (turn up tcp windows if you have a good pipe) These are all in decimal btw (tcpwindowsize is the only one where it matters), and all dword. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: RFC 1918
by Steven M. Bellovin 17 Jul '00

17 Jul '00

In message <20000714155415.K19521(a)oven.com>, Bennett Todd writes: > >--u3W6riq+uV6J42Ub >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline > >2000-07-14-15:47:22 Steven M. Bellovin: >> No -- 1918 addresses would only break PMTU if folks did ingress or >> egress filtering for 1918 addresses. > >Wouldn't RFC 1918 addrs on router links only threaten to break >PMTU --- even in the face of 1918 addr filtering --- if one of >the routers with an rfc 1918 interface addr did routing between >interfaces with different MTUs? As best I can see, PMTU discovery >should work fine traversing RFC 1918 links, and the only addrs >that need to be passed on out are those of routers where the MTU >decreases along the path, which would only be routers with different >MTUs on different interfaces. Yup. And with most links handling 1500-byte MTUs or above, we don't see much of that. --Steve Bellovin

6 6

Re: RFC 1918
by Richard A. Steenbergen 16 Jul '00

16 Jul '00

On Fri, 14 Jul 2000, Bennett Todd wrote: > 2000-07-14-15:47:22 Steven M. Bellovin: > > No -- 1918 addresses would only break PMTU if folks did ingress or > > egress filtering for 1918 addresses. > > Wouldn't RFC 1918 addrs on router links only threaten to break > PMTU --- even in the face of 1918 addr filtering --- if one of > the routers with an rfc 1918 interface addr did routing between > interfaces with different MTUs? As best I can see, PMTU discovery > should work fine traversing RFC 1918 links, and the only addrs > that need to be passed on out are those of routers where the MTU > decreases along the path, which would only be routers with different > MTUs on different interfaces. I still have not seen a single compelling arguement which says you gain one bit more security by filtering RFC1918-source'd packets. It is useless at best, and disruptive at worst. For the longest time, the solution to SYN floods and other random sourced attacks published on Cisco's CCO was "filter ingress RFC1918 space". This is utterly useless. Would someone please tell me what you really expect to gain from filtering RFC1918 space at your borders, because its plainly obvious what you can expect to lose. PMTU-D does not really care about WHO couldn't fragment the packet, only that it couldn't, and the degree to which it couldn't. PMTU-D is also acknowledged as a very bad hack which often has problems, though there are effective methods to detect PMTU-D blackholing. The goal of RFC1918 is to create private address space which is not guarenteed to be unique and therefore can not be routed between ASs. It really doesn't matter if you have a 1918-space sourced packet on your network (any more then any other packet you might wish to filter), as long as you don't tell others how to reach it (or let yourself be told). In this respect, RFC1918 needs updating. There is absolutily no reason why you cannot have 1918-space sourced packets on your network. I have found this to be the current best operating practice of most everyone in the modern internet, except for a few who are confused by things like standards. :P You pay the price in unreachability (which for P-t-P links is not necessarily a bad thing) and DNS (which for P-t-P links is quite possibly a very bad thing for traceroute purposes), but that is the choice the network admin makes. Except for traceroute responses, there is little to no compelling reason why non-connection orientied responses to which there should be no reply (ex: ICMP errors) can not be sourced from 1918 space. If you really don't like this, you should be able to source such things from a loopback address. If you can't, pester your vendor (some things you can do this with, some you can't, like domain-lookup source-interface on Cisco). IMHO. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

5 5