- Test - lists.nanog.org

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

RE: RFC 1918
by rdobbins＠netmore.net 16 Jul '00

16 Jul '00

>If people don't want whiners niggling them about the RFC 1918 addrs >showing up in traceroutes, they should just put RFC 1918 filters on >their borders, so that the whiners simply won't get returns to their >traceroutes. >-Bennett I don't know if denying folks the use of legitimate testing tools due to deliberate misuse of RFC 1918 addressing - after all, its title is 'Address Allocation for Private Internet' - is such a hot idea. To quote from the RFC: With the proliferation of TCP/IP technology worldwide, including outside the Internet itself, an increasing number of non-connected enterprises use this technology and its addressing capabilities for sole intra-enterprise communications, without any intention to ever directly connect to other enterprises or the Internet itself. I don't see much ambiguity there concerning the intent of the authors, nor the IETF in accepting their premises. --------------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice

1 0

RE: slashdot slashdotted?
by rdobbins＠netmore.net 16 Jul '00

16 Jul '00

Slashdot get DoSed with some regularity. They used to talk about it, but then I guess they figured that was only encouraging the lusers, so they generally don't mentioned it, any more. --------------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice -----Original Message----- From: Steve Sobol [mailto:sjsobol@NorthShoreTechnologies.net] Sent: Sunday, July 16, 2000 8:52 AM To: John Payne Cc: nanog(a)merit.edu Subject: Re: slashdot slashdotted? John Payne wrote: > A couple of people lost access last night... not long after several > messages went out about the Yesmail vs MAPS story... coincidence? yeah, right. MAPS blackholed everyone. :) Cue the black helicopters. -- North Shore Technologies, Cleveland, OH http://NorthShoreTechnologies.net Steve Sobol, BOFH - President, Chief Website Architect and Janitor Pictures of two of my 'children': http://www.WrinkleDogs.com About Spamfighters: "We're not net nazis. We're dot communists." - W. Arnold

1 0

Different customer service reactions (was Re: Wanted: Clueful Individual @ TeleGlobe.net)
by Sean Donelan 16 Jul '00

16 Jul '00

On Sun, 16 July 2000, Troy Davis wrote: > 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. Interesting, neither company solved your problem, but your reaction was very different to how the different companies handled your call. I guess different companies feel it makes business sense to have such policies. I don't know if it is cultural or what. ISPs which were originally independent companies seem to have more open trouble ticket policies than ISPs formed by telcos. Genuity/BBN and UUNET (I distinguish UUNET from the rest of Worldcom) had relatively open trouble ticket policies. Sprint and MCI had restricted trouble ticket policies. Whats even more interesting is the frustration refusing to even look at a problem creates last a long time. Even if they later fix the problem, it won't make up for the difficulty in getting them to look at it. Sprint blackholed one of my customer's routes for three days, and argued with me for days how it wasn't their responsibility and wouldn't open a ticket. After I eventually proved beyond any reasonable doubt it was in fact a Sprint router making the bogus announcement and got a Sprint engineer to fix their router, to this day I still mention how difficult it is to get Sprint to fix a problem in their network because they'll ignore it as long as they can.

3 2

TE Prez during the Last NANOG
by HANSEN CHAN 16 Jul '00

16 Jul '00

Hi folks, During the MPLS TE panel in the NANOG 19, one of the speakers mentioned the scenario of using LDP at the edge and RSVP-TE in the core. I'm interested to get a copy of the slide (it's not on NANOG website). In particular I'm interested to see the slide showing the label swapping during the transition from 1 signalling domain to the other slide. Does anyone know how to get such a copy? Or could the speaker be kind enough to send me a copy? Thanks, Hansen

1 0

Re: solar storm
by Sean Donelan 16 Jul '00

16 Jul '00

I haven't been tracking outages through an entire 11 year sunspot cycle yet, it only seems like forever. I've looked for correlations of unexplained outages or directly attributable outages with previous solar flare warnings, but so far nothing detectable shows up. There are normal satellite outages twice a year as the sun crosses the Clarke belt. I've also noticed a 3,6,9 year technology obsolence cycle when old equipment fails before companies replace it. On Sat, 15 July 2000, smd(a)clock.org wrote: > Forgive this temporary segue into a potential operational issue. > > http://abcnews.go.com/sections/science/DailyNews/sunspot000714.html > > I would find it interesting if any outages observed by Sean Donelan > or others could be attributed to this solar storm; alternatively, > any higher than average incidence of outages and failures would > be interesting from a correlation analysis perspective.

3 2

Gentle reminder
by Susan R. Harris 15 Jul '00

15 Jul '00

Hi everyone - just a reminder to keep our AUP in mind when you post to the NANOG list: http://www.nanog.org/aup.html We'll keep the number of messages down if we stay with issues that require inter-provider cooperation -- network operations, not politics or other topics inconsistent with the NANOG charter. Your messages are seen by many thousands of people throughout the Internet, and are most useful when they deal with subjects of interest to all. Thanks -- Susan Harris, Merit

1 0

RE: RFC 1918
by Jamie Rishaw 15 Jul '00

15 Jul '00

| I claim rather that most routers _never_ have an operational need | to talk directly to random strangers, i.e. to have their interface | addresses leak. So sure, honor RFC 1918 strictly and utterly and to | the letter: put egress filters for the addrs that would guarantee | that anyone who tried to traceroute through you would see timeouts | as the replies were blocked. If that makes whingers happier, groove | on it. If your router doesn't have any different-MTU interfaces that | it routes between, then there's no harm in using RFC 1918 addresses | on the endpoints of inter-router links. Exactly. I think Vix settled that a few years back when we had this discussion (I dont remember specifically, but I remember occasions when he chimes in, he's usually the closing argument) :-) - RFC1918 addressing on *endpoint* or leaf links, is fine. - RFC1918 addressing on transit links, isn't the best idea, but except for PMTUD (which arguably shouldn't even be, um, an argument) holds no technical reasoning(correct me if i'm wrong) to abstain. My biggest complaint is that RFC1918 addresses for the most part don't have in-addr (and if they do, it's generic) and debugging a problem based on just an IP address is hard when you're talking to cluebies at someone else's NOC. While I'm not suggesting that in-addr be created for RFC1918 specific to each provider's arbitrary allocation of IPs (this would defeat a lot of 1918) I do think that, in a global or public/enterprise network, 1918 addressing on a transit link is just a bad idea. OARnet is doing it for "security" last I talked to them (which was several years ago), they've been using RFC1918 on transit links for a while now, CIP ohio-dmz.net. -jamie

4 5