Re: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion
Randy Bush <[EMAIL PROTECTED]> writes: > back office software > ip and dns management software > provisioning tools > cpe > measurement and monitoring and billing > > and, of course, backbone and aggregation equipment that can actually > handle real ipv6 traffic flows with acls and chocolate syrup. chiming in late here... the situation on the edge (been looking at a lot of gpon gear lately) is pretty dismal. i won't bother mentioning the vendor who claimed their igmp implementation supported ipv6 "just fine - we're a layer 2 device; it's plug-and-play". srsly. ---rob ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
On 7-May-2008, at 17:07:06, Deepak Jain wrote: > Many non-SP IT folks think they understand TCP, grudgingly accept > UDP for DNS from external sources and think everything else is > bollocks. Many *might* have a fit if they saw Microsoft accepting > ICMPs because that seems inconsistent with their knowledge of turn- > the-knob network security. To their view, their Linksys/Netgear/ > whathaveyou COTS firewalls block everything too. > > I don't think I'm exaggerating here. No, you are not. I have seen the same from "firewall engineers" at large companies, people who, supposedly, have done "network security" for years. Even after showing them numerous Web sites detailing current best practices, especially Rob Thomas's fine site, these folks would not change their practices. Some days it is hard to not give in to the "I give up" feelings. ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
Nathan Anderson/FSR wrote: > Nevertheless, the person I have been in contact with is naturally not > the final decision-maker on this issue and is going to continue to pass > the issue on up the chain of command for me. So although this issue is > not over and I do not have a final verdict from MS yet, I felt that, > given that I don't know how much time to expect to pass between now and > when that final verdict is rendered, it would be appropriate to let > everybody here know what I have learned thus far. Hopefully public > dissemination of this information factoid will prevent others in a > position similar to mine from having to helplessly beat their heads into > their keyboards. Let's also not ignore the generally overworked IT administrator at any small or medium sized enterprise. He/she may not be (as many folks I've run into are) of the mistaken impression that ICMP *is* bad and leaves you vulnerable to all sorts of things like SMURF. There are even tools out there that "test" your vulnerability by "pinging" you and do other investigations. I know of a tool that a major financial institution uses when certifying your networks security -- that scrapes the version number from your ESTMP banner to decide whether you comply or not (and other banners). (Rather than actually testing for a specific vulnerability). Simply blocking all of these packets from their test host gives you a high passing score; possibly a perfect one. [Irony and humor aside...] Many non-SP IT folks think they understand TCP, grudgingly accept UDP for DNS from external sources and think everything else is bollocks. Many *might* have a fit if they saw Microsoft accepting ICMPs because that seems inconsistent with their knowledge of turn-the-knob network security. To their view, their Linksys/Netgear/whathaveyou COTS firewalls block everything too. I don't think I'm exaggerating here. Just a thought, not saying its a good one or whose fault it is... Deepak Jain AiNET ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
Tomas L. Byrnes wrote: > As far as who Iljitsch is, everyone misspeaks from time to time. Even > those of us who have been at this for nearly 3 decades. I was simply LOLing at the fact that you found it necessary to give him a link to the NetHeaven article is all. ;-) -- Nathan Anderson First Step Internet, LLC [EMAIL PROTECTED] ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
Iljitsch van Beijnum wrote: > The problem is in the direction from M$ to you, so you can't fix that > from your end. I wonder if they've installed SP3 on their servers... Ah, you are right. I re-read the section on black-hole detection in http://technet.microsoft.com/en-us/library/bb878081.aspx more closely this time, and found that, yes, it only helps if the host trying to send the large packets has the feature enabled: "When PMTU black hole router detection is enabled, TCP tries to send segments with the DF flag set to 0 after several retransmissions of a segment are not acknowledged. If a segment with the DF flag set to 0 is acknowledged, the MSS is decreased and the DF flag is set to 1 in subsequent segments on the connection. Enabling PMTU black hole detection increases the maximum number of retransmissions that are performed for a given segment, and therefore has an effect on overall performance." I for some reason interpreted the advertisement of the black hole detection feature as being a help to clients impacted by the inability of the server to perform PMTUD. -- Nathan Anderson First Step Internet, LLC [EMAIL PROTECTED] ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
Sorry if I misunderstood what you were saying. I thought you said that they couldn't have their cake and eat it too, as in protect against Ping of death, AND do PMTUD. As for those flames, well, that was a long time ago, in a valley not too far from here ;-). Can we have the 'net before the endless September back? > -Original Message- > From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 07, 2008 2:40 PM > To: Tomas L. Byrnes > Cc: [EMAIL PROTECTED] > Subject: Re: [NANOG] Microsoft.com PMTUD black hole? > > On 7 mei 2008, at 23:20, Tomas L. Byrnes wrote: > > > I was responding to his post that blocking or disabling > PMTUD was the > > way to avoid the ping of death, which is False, nothing > more, nothing > > less. > > I never said that disabling PMTUD will get rid of the ping of > death, what I said was that if your system is susceptible to > a ping of death you may be tempted to filter ICMP but if you > do that then you need to disable PMTUD because PMTUD + ICMP > filtering = breakage. > > > As far as who Iljitsch is, everyone misspeaks from time to > time. Even > > those of us who have been at this for nearly 3 decades. > > After making the jump to academia I often feel a bit long in > the tooth between all these students. But considering that > (apparently) some people have been posting flames on NANOG > for 30 years makes me feel young in comparison. :-) > ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
On 7 mei 2008, at 23:20, Tomas L. Byrnes wrote: > I was responding to his post that blocking or disabling PMTUD was the > way to avoid the ping of death, which is False, nothing more, nothing > less. I never said that disabling PMTUD will get rid of the ping of death, what I said was that if your system is susceptible to a ping of death you may be tempted to filter ICMP but if you do that then you need to disable PMTUD because PMTUD + ICMP filtering = breakage. > As far as who Iljitsch is, everyone misspeaks from time to time. Even > those of us who have been at this for nearly 3 decades. After making the jump to academia I often feel a bit long in the tooth between all these students. But considering that (apparently) some people have been posting flames on NANOG for 30 years makes me feel young in comparison. :-) ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Charter - Southern Oregon routing issues
This issue is now resolved for the time being. It went on for 2+ hours. Sorry for the noise. Regards, Steve S. Ryan wroteth on 5/7/2008 2:05 PM: > I've called Charter and they deny they have an issue. I'm looking to > speak to a Charter engineer who can specifically help with issues in the > Southern Oregon service area. > > Multiple customers cannot check mail on 110 or use port 25 or 587. > > Looks like a loop: > > traceroute to 204.16.46.136 (204.16.46.136), 30 hops max, 40 byte packets > 1 192.168.1.1 (192.168.1.1) 2.143 ms 1.168 ms 0.849 ms > 2 10.218.0.1 (10.218.0.1) 8.523 ms 8.551 ms 14.098 ms > 3 ge5-2.cr01.mdfd.or.charter.com (68.185.17.113) 31.033 ms 10.993 ms > 9.398 ms > 4 68-116-79-133.or.charter.com (68.116.79.133) 11.145 ms 18.148 ms > 10.23 ms > 5 68-116-79-134.or.charter.com (68.116.79.134) 19.288 ms 9.768 ms > 14.054 ms > 6 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 10.881 ms 12.468 ms > 10.898 ms > 7 68-116-79-134.or.charter.com (68.116.79.134) 16.426 ms 10.631 ms > 11.4 > ms > 8 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 9.317 ms 10.047 ms 9.315 > ms > 9 68-116-79-134.or.charter.com (68.116.79.134) 11.117 ms 9.992 ms * > 10 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 10.928 ms 20.391 ms 9.513 > ms > 11 68-116-79-134.or.charter.com (68.116.79.134) 11.349 ms 10.413 ms > 10.222 ms > 12 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 20.722 ms 9.746 ms 9.99 > ms > 13 68-116-79-134.or.charter.com (68.116.79.134) 10.682 ms 11.198 ms > 11.253 ms > 14 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 10.376 ms 21.943 ms > 10.914 ms > 15 68-116-79-134.or.charter.com (68.116.79.134) 11.039 ms 9.778 ms > 17.995 ms > 16 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 13.068 ms 10.622 ms > 13.206 ms > 17 68-116-79-134.or.charter.com (68.116.79.134) 11.783 ms 11.17 ms 9.351 > ms > 18 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 15.859 ms 13.637 ms > 18.188 ms > 19 68-116-79-134.or.charter.com (68.116.79.134) 9.532 ms 14.751 ms > 16.703 ms > 20 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 21.073 ms 11.547 ms > 10.913 ms > 21 68-116-79-134.or.charter.com (68.116.79.134) 18.878 ms 9.844 ms > 17.044 ms > 22 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 17.192 ms 12.964 ms > 10.855 ms > 23 68-116-79-134.or.charter.com (68.116.79.134) 9.931 ms 13.66 ms 17.299 > ms > 24 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 21.794 ms 11.108 ms > 16.129 ms > 25 68-116-79-134.or.charter.com (68.116.79.134) 17.288 ms 14.043 ms > 12.522 ms > 26 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 11.771 ms 14.531 ms > 11.148 ms > 27 68-116-79-134.or.charter.com (68.116.79.134) 11.697 ms 10.318 ms > 9.069 ms > 28 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 9.885 ms 15.104 ms 13.287 > ms > 29 68-116-79-134.or.charter.com (68.116.79.134) 21.404 ms 12.868 ms > 10.294 ms > 30 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 10.807 ms 11.742 ms > 12.197 ms > > Thank you for any assistance. I've even contacted Tier III at Charter > and they're unwilling to help at all. I'm shocked they have a customer > base still. > > Regards, > > Steve Ryan > 541-842-8207 > > ___ > NANOG mailing list > NANOG@nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
I was responding to his post that blocking or disabling PMTUD was the way to avoid the ping of death, which is False, nothing more, nothing less. As far as who Iljitsch is, everyone misspeaks from time to time. Even those of us who have been at this for nearly 3 decades. > -Original Message- > From: Nathan Anderson/FSR [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 07, 2008 2:08 PM > To: [EMAIL PROTECTED] > Subject: Re: [NANOG] Microsoft.com PMTUD black hole? > > Tomas L. Byrnes wrote: > > > The remedy you have below is NOT the only one, and is, in fact, a > > non-sequitur in this case. > > How so? Iljitsch is suggesting that ICMP blockers originate > packets without DF set if they are going to block the ICMP > messages that PMTUD needs in order to work in the first > place. That's what (I think) he means by "disabling path MTU > discovery." > > > The network-level solution to ping of death is to BLOCK fragmented > > packets, and the way to ensure this doesn't self-deny-service is to > > perform PMTUD and Black-Hole Router discovery. > > Which end are you talking about here, the servers or the > client? If the servers, how do you expect them to do PMTUD > if they _can't hear the ICMP messages_? > > Also, for some reason, as I pointed out before, XP black hole > router discovery doesn't seem to be working for me for > whatever reason. Does anybody have any clue why that might > be the case? > > -- > Nathan Anderson > First Step Internet, LLC > [EMAIL PROTECTED] > > ___ > NANOG mailing list > NANOG@nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
On 7 mei 2008, at 23:08, Nathan Anderson/FSR wrote: > How so? Iljitsch is suggesting that ICMP blockers originate packets > without DF set if they are going to block the ICMP messages that PMTUD > needs in order to work in the first place. That's what (I think) he > means by "disabling path MTU discovery." Yes. > Also, for some reason, as I pointed out before, XP black hole router > discovery doesn't seem to be working for me for whatever reason. Does > anybody have any clue why that might be the case? The problem is in the direction from M$ to you, so you can't fix that from your end. I wonder if they've installed SP3 on their servers... ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
Kevin Oberman wrote: >> I agree with Iljitsch that it happens frequently, but I think I am >> justified in expecting more than that from Microsoft. Anything less >> would be unprofessional. > > And you would consider an organization that threatens someone who > complains publicly about its obvious incompetence "professional"? Absolutely not. That was actually the point of my statement, although I admit that it wasn't clear. > Many of Microsoft's people are highly professional, but the corporation, > as a whole, has been found to be large scale law breakers on two > continents and frequently incapable of even the most basic of technical > operations. I'm afraid that I don't see them as at all "professional". I > quit expecting any such behavior from them over a decade ago, probably > closer to two. And mentioning security and Microsoft is inviting bad > jokes and shudders. > > * Speaking only for myself * Agreed. michael ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
Tomas L. Byrnes wrote: > Some Edumacation on the topic is here: You do know who it is that you are responding to, right? :) http://www.oreillynet.com/pub/au/970 -- Nathan Anderson First Step Internet, LLC [EMAIL PROTECTED] ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
Tomas L. Byrnes wrote: > The remedy you have below is NOT the only one, and is, in fact, a > non-sequitur in this case. How so? Iljitsch is suggesting that ICMP blockers originate packets without DF set if they are going to block the ICMP messages that PMTUD needs in order to work in the first place. That's what (I think) he means by "disabling path MTU discovery." > The network-level solution to ping of death is to BLOCK fragmented > packets, and the way to ensure this doesn't self-deny-service is to > perform PMTUD and Black-Hole Router discovery. Which end are you talking about here, the servers or the client? If the servers, how do you expect them to do PMTUD if they _can't hear the ICMP messages_? Also, for some reason, as I pointed out before, XP black hole router discovery doesn't seem to be working for me for whatever reason. Does anybody have any clue why that might be the case? -- Nathan Anderson First Step Internet, LLC [EMAIL PROTECTED] ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
[NANOG] Charter - Southern Oregon routing issues
I've called Charter and they deny they have an issue. I'm looking to speak to a Charter engineer who can specifically help with issues in the Southern Oregon service area. Multiple customers cannot check mail on 110 or use port 25 or 587. Looks like a loop: traceroute to 204.16.46.136 (204.16.46.136), 30 hops max, 40 byte packets 1 192.168.1.1 (192.168.1.1) 2.143 ms 1.168 ms 0.849 ms 2 10.218.0.1 (10.218.0.1) 8.523 ms 8.551 ms 14.098 ms 3 ge5-2.cr01.mdfd.or.charter.com (68.185.17.113) 31.033 ms 10.993 ms 9.398 ms 4 68-116-79-133.or.charter.com (68.116.79.133) 11.145 ms 18.148 ms 10.23 ms 5 68-116-79-134.or.charter.com (68.116.79.134) 19.288 ms 9.768 ms 14.054 ms 6 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 10.881 ms 12.468 ms 10.898 ms 7 68-116-79-134.or.charter.com (68.116.79.134) 16.426 ms 10.631 ms 11.4 ms 8 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 9.317 ms 10.047 ms 9.315 ms 9 68-116-79-134.or.charter.com (68.116.79.134) 11.117 ms 9.992 ms * 10 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 10.928 ms 20.391 ms 9.513 ms 11 68-116-79-134.or.charter.com (68.116.79.134) 11.349 ms 10.413 ms 10.222 ms 12 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 20.722 ms 9.746 ms 9.99 ms 13 68-116-79-134.or.charter.com (68.116.79.134) 10.682 ms 11.198 ms 11.253 ms 14 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 10.376 ms 21.943 ms 10.914 ms 15 68-116-79-134.or.charter.com (68.116.79.134) 11.039 ms 9.778 ms 17.995 ms 16 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 13.068 ms 10.622 ms 13.206 ms 17 68-116-79-134.or.charter.com (68.116.79.134) 11.783 ms 11.17 ms 9.351 ms 18 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 15.859 ms 13.637 ms 18.188 ms 19 68-116-79-134.or.charter.com (68.116.79.134) 9.532 ms 14.751 ms 16.703 ms 20 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 21.073 ms 11.547 ms 10.913 ms 21 68-116-79-134.or.charter.com (68.116.79.134) 18.878 ms 9.844 ms 17.044 ms 22 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 17.192 ms 12.964 ms 10.855 ms 23 68-116-79-134.or.charter.com (68.116.79.134) 9.931 ms 13.66 ms 17.299 ms 24 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 21.794 ms 11.108 ms 16.129 ms 25 68-116-79-134.or.charter.com (68.116.79.134) 17.288 ms 14.043 ms 12.522 ms 26 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 11.771 ms 14.531 ms 11.148 ms 27 68-116-79-134.or.charter.com (68.116.79.134) 11.697 ms 10.318 ms 9.069 ms 28 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 9.885 ms 15.104 ms 13.287 ms 29 68-116-79-134.or.charter.com (68.116.79.134) 21.404 ms 12.868 ms 10.294 ms 30 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 10.807 ms 11.742 ms 12.197 ms Thank you for any assistance. I've even contacted Tier III at Charter and they're unwilling to help at all. I'm shocked they have a customer base still. Regards, Steve Ryan 541-842-8207 ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
Tomas L. Byrnes wrote: > I'm not sure what the issue is here. > > Just about every modern firewall I've used has an option to enable PMTU > on interfaces, while blocking all other ICMP. > > Is MS not running something manufactured in the last 10 years at their > perimeter? Not sure, but you actually entered in here to a subthread of the original conversation, this one about other possible ways of dealing with black hole "ICMP-munchers" in a pre-emptive fashion. I had a brainstorm that I thought would be workable, which is what we were discussing here. Apparently, it turns out my idea was no good. ;-) The original discussion about MS blocking ICMP to their own servers, which is the discussion it sounds like you are looking for, is over that-a-way... *points* -- Nathan Anderson First Step Internet, LLC [EMAIL PROTECTED] ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
Some Edumacation on the topic is here: http://www.netheaven.com/pmtu.html > -Original Message- > From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 07, 2008 1:35 PM > To: Michael Sinatra > Cc: [EMAIL PROTECTED] > Subject: Re: [NANOG] Microsoft.com PMTUD black hole? > > On 7 mei 2008, at 21:46, Michael Sinatra wrote: > > >> MS does in fact block _all_ ICMP > >> at the edge of their network, that they are aware that > this will in > >> fact break PMTUD, and that they have no current plans to > change this > >> practice which they have implemented in the interest of security. > > > Perhaps > > they should also block _all_ TCP and UDP as well, and then > we can move > > on. > > > I agree with Iljitsch that it happens frequently, but I think I am > > justified in expecting more than that from Microsoft. > Anything less > > would be unprofessional. > > Right. > > Now Microsoft is also the company that built the OS that > could be crashed by a maliciously crafted fragmented IP > packet, so maybe there's something to this security policy. > (One hopes that this bug and others like it are now fixed.) > > However, in that case the only workable course of action > would be TO DISABLE PATH MTU DISCOVERY! > > You can't have your cake and eat it too. > > ___ > NANOG mailing list > NANOG@nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
The remedy you have below is NOT the only one, and is, in fact, a non-sequitur in this case. PMTUD uses the DF (for Don't_Fragment) bit, and works by getting an ICMP Fragmentation needed response from the hop on the path where the packet is too large, not a fragmentation and forward, so the union of PMTUD packets and fragmented ones is 0. The network-level solution to ping of death is to BLOCK fragmented packets, and the way to ensure this doesn't self-deny-service is to perform PMTUD and Black-Hole Router discovery. > -Original Message- > From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 07, 2008 1:35 PM > To: Michael Sinatra > Cc: [EMAIL PROTECTED] > Subject: Re: [NANOG] Microsoft.com PMTUD black hole? > > On 7 mei 2008, at 21:46, Michael Sinatra wrote: > > >> MS does in fact block _all_ ICMP > >> at the edge of their network, that they are aware that > this will in > >> fact break PMTUD, and that they have no current plans to > change this > >> practice which they have implemented in the interest of security. > > > Perhaps > > they should also block _all_ TCP and UDP as well, and then > we can move > > on. > > > I agree with Iljitsch that it happens frequently, but I think I am > > justified in expecting more than that from Microsoft. > Anything less > > would be unprofessional. > > Right. > > Now Microsoft is also the company that built the OS that > could be crashed by a maliciously crafted fragmented IP > packet, so maybe there's something to this security policy. > (One hopes that this bug and others like it are now fixed.) > > However, in that case the only workable course of action > would be TO DISABLE PATH MTU DISCOVERY! > > You can't have your cake and eat it too. > > ___ > NANOG mailing list > NANOG@nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
On 7 mei 2008, at 21:46, Michael Sinatra wrote: >> MS does in fact block _all_ ICMP >> at the edge of their network, that they are aware that this will in >> fact >> break PMTUD, and that they have no current plans to change this >> practice >> which they have implemented in the interest of security. > Perhaps > they should also block _all_ TCP and UDP as well, and then we can > move on. > I agree with Iljitsch that it happens frequently, but I think I am > justified in expecting more than that from Microsoft. Anything less > would be unprofessional. Right. Now Microsoft is also the company that built the OS that could be crashed by a maliciously crafted fragmented IP packet, so maybe there's something to this security policy. (One hopes that this bug and others like it are now fixed.) However, in that case the only workable course of action would be TO DISABLE PATH MTU DISCOVERY! You can't have your cake and eat it too. ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
Nathan Anderson/FSR wrote: > Here is a brief update on the situation: > > I have been in contact with someone at Microsoft's service operations > center, who has confirmed for me that MS does in fact block _all_ ICMP > at the edge of their network, that they are aware that this will in fact > break PMTUD, and that they have no current plans to change this practice > which they have implemented in the interest of security. Although the need for your previous apology has already been questioned in this forum, the confirmation that they block not only certain ICMP types, but all ICMP, further vacates the need for any apology for criticizing this behavior in a pubic forum. It is disheartening for those of us who use and support MSFT's products to learn that their understanding of security lacks even the basic nuance to know not to block an entire--critical--portion of the Internet Protocol. Perhaps they should also block _all_ TCP and UDP as well, and then we can move on. I agree with Iljitsch that it happens frequently, but I think I am justified in expecting more than that from Microsoft. Anything less would be unprofessional. *Speaking for myself only, of course!* michael ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
I'm not sure what the issue is here. Just about every modern firewall I've used has an option to enable PMTU on interfaces, while blocking all other ICMP. Is MS not running something manufactured in the last 10 years at their perimeter? > -Original Message- > From: Nathan Anderson/FSR [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 07, 2008 12:39 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [NANOG] Microsoft.com PMTUD black hole? > > [EMAIL PROTECTED] wrote: > > > The usual case where you get screwed over is when the > router trying to > > toss the ICMP FRAG NEEDED is *behind* the ICMP-munching > firewall. And > > in case (2), you still can't assume that path MTU == local MTU, > > because your local MTU is likely 1500, and the fragging > router often > > trying to stuff your 1500 byte packet down an PPPoE tunnel > that's got an MTU of 1492 > > Yes, but my point was precisely that one OR the other side (server OR > client) is going to NOT have the ICMP-munching firewall in > between itself and the "RITM" as I have affectionately been > calling it (although it is definitely possible that there are > two ICMP-munchers on either side of the RITM). > > And case #2 is exactly what is occurring right now _anyway_: > hosts assume that path MTU == local MTU even if there is > already an active PMTU cache entry from a recent earlier > communication with the remote host. So I don't see how > making that assumption _after_ making an honest attempt at > actively determining whether or not it is actually the case > is any more broken than they way things are already being done. > > The problem is that, as I realized at the end of the message > you quoted, there are potentially multiple paths between the > same two hosts, and the path that the packet takes in one > direction is not guaranteed to be the same path that the > packet takes in the opposite direction. > > -- > Nathan Anderson > First Step Internet, LLC > [EMAIL PROTECTED] > > ___ > NANOG mailing list > NANOG@nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
[EMAIL PROTECTED] wrote: > The usual case where you get screwed over is when the router trying to toss > the ICMP FRAG NEEDED is *behind* the ICMP-munching firewall. And in case (2), > you still can't assume that path MTU == local MTU, because your local MTU is > likely 1500, and the fragging router often trying to stuff your 1500 byte > packet down an PPPoE tunnel that's got an MTU of 1492 Yes, but my point was precisely that one OR the other side (server OR client) is going to NOT have the ICMP-munching firewall in between itself and the "RITM" as I have affectionately been calling it (although it is definitely possible that there are two ICMP-munchers on either side of the RITM). And case #2 is exactly what is occurring right now _anyway_: hosts assume that path MTU == local MTU even if there is already an active PMTU cache entry from a recent earlier communication with the remote host. So I don't see how making that assumption _after_ making an honest attempt at actively determining whether or not it is actually the case is any more broken than they way things are already being done. The problem is that, as I realized at the end of the message you quoted, there are potentially multiple paths between the same two hosts, and the path that the packet takes in one direction is not guaranteed to be the same path that the packet takes in the opposite direction. -- Nathan Anderson First Step Internet, LLC [EMAIL PROTECTED] ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
Here is a brief update on the situation: I have been in contact with someone at Microsoft's service operations center, who has confirmed for me that MS does in fact block _all_ ICMP at the edge of their network, that they are aware that this will in fact break PMTUD, and that they have no current plans to change this practice which they have implemented in the interest of security. Nevertheless, the person I have been in contact with is naturally not the final decision-maker on this issue and is going to continue to pass the issue on up the chain of command for me. So although this issue is not over and I do not have a final verdict from MS yet, I felt that, given that I don't know how much time to expect to pass between now and when that final verdict is rendered, it would be appropriate to let everybody here know what I have learned thus far. Hopefully public dissemination of this information factoid will prevent others in a position similar to mine from having to helplessly beat their heads into their keyboards. I, naturally, voiced my strong objection over this security policy, and attempted to make a reasoned argument with the contact I have over there. We will see what comes of this. Some have asked me to post copies of my private communication with my Microsoft contact here. I don't think it is appropriate for me to post copies of private communication without the other party's consent, so I will have to decline unless he first gives me said consent. Others have asked for valid contact information for the Microsoft NOC, since the ARIN records for their 207.46.0.0/16 do not appear to be up to date. I eventually found a working e-mail address from somebody off-list who pointed to the WHOIS lookup from TUCOWS for microsoft.comosoft.com (which I'm still not clear on what exactly this is...). The e-mail address that was gleaned from this lookup was [EMAIL PROTECTED], which goes to the Microsoft Corporate Domains Team. They, in turn, forwarded my message on to [EMAIL PROTECTED], which generated a ticket # for me and is, as I understand it, the e-mail address I was looking for in the first place (leads to their network/system people). I hope this is helpful to others. Regards, -- Nathan Anderson First Step Internet, LLC [EMAIL PROTECTED] ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
Iljitsch van Beijnum wrote: > No. This would add significant delay because you'd have to give the > other side enough time to respond to the large packet (also sending a > large packet on something like GPRS/EDGE is a waste of bandwidth and > battery power) while if there is ICMP filtering, there won't be a > response, which is exactly the reason why we're in this bind in the > first place I admit the idea needs tweaking (at best), and it was just a stray thought :-), but 1) even if there is ICMP filtering happening way at the other end, I (the TCP initiator) will still get a response from the router in the middle (RITM) that is reducing the total path MTU if I try to send a packet through it larger than the actual path MTU, and 2) if I don't get a response to my single large packet (either from a RITM or the other end) in a timely fashion (less than a second?), then the client/initiator may just assume that path MTU == local MTU and will set its MSS accordingly (which is no different than what is happening now), until it has a reason to think differently. Also, if there is already something in the local PMTU cache for a single host address, I'm not sure I follow why it would be a bad idea for the TCP initiator to consult that cache when preparing the SYN. Although, on second thought, I suppose it is possible (and, in more than a few cases, likely) that in instances of route path asymmetry, the PMTU of the path from the initiator to the server may be different than the PMTU of the path back from the server to the client. Hmmm. Okay, scratch that idea then. :-P -- Nathan Anderson First Step Internet, LLC [EMAIL PROTECTED] ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
Thus spake "Nathan Anderson/FSR" <[EMAIL PROTECTED]> > A member of Microsoft's GNS network escalations team saw my > postings on NANOG about this issue and took offense at my use > of this forum to raise this issue with them, and criticized me as > being unprofessional and lacking in business acumen. First, it's "unprofessional and lacking in business acumen" for someone to criticize their customers to their face. As one manager taught me, "The customer may not always be right, but they're never wrong." Second, it's their own damn fault for not maintaining their contact information properly in public databases. If the only option they leave you is to post to NANOG, because they don't respond to (or even accept) direct requests to the listed contacts, then that's what you have to do. Many companies are guilty of the latter, and we all get the benefit of seeing the state of their customer service for reference when making future buying decisions. Very few are arrogant enough to do the former, though. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
[NANOG] Google Contact
All; I am having a bit of difficulty resolving a Google matter. I am hoping to get pointed in the right direction by someone from Google. Thanks -- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
Glen Turner wrote: > Amazing. A fine case study of a person in customer contact undoing the > work of millions of dollars in PR. Whatever you say about Steve Ballmer > he's a great sales person at heart. He must despair at some of his staff. > The rest of us however, despair at having to support their crap. Patrick Giagnocavo [EMAIL PROTECTED] ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
On Tue, May 06, 2008 at 06:12:42PM -0700, Nathan Anderson/FSR wrote: > A member of Microsoft's GNS network escalations team saw my postings on > NANOG about this issue and took offense at my use of this forum to raise > this issue with them, and criticized me as being unprofessional and > lacking in business acumen. This is a typical Microsoft reaction: blame the messenger for their own incompetence, laziness, stupidity, and greed. I think you should post their assinine message so that it can receive the public ridicule it surely deserves. ---Rsk ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
[NANOG] Bob Crooks/SaskTel/CA is out of the office.
I will be out of the office starting 05/07/2008 and will not return until 05/12/2008. ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
Iljitsch van Beijnum <[EMAIL PROTECTED]> writes: > Many years ago I had occasion to terminate dial-up service over L2TP > from modem pools operated by a service provider who shall remain > nameless to protect the guilty. This service had the unfortunate > tendency to drap all packets larger than 576 bytes. So we needed to > negotiate a 576-byte MTU over PPP. > > We then got many complaints from users who dialed in using ISDN > routers (yes this was a while ago) because of broken path MTU > discovery. The behavior that Microsoft exhibits was EXTREMELY common > in those days, and I have no reason to assume it's any less common > today. (I also see it regularly with IPv6.) What I did was clear the > DF bit on packets going out to the L2TP virtual interfaces so the > packets could be fragmented. Right. I once stumbled across a SOHO-router doing just that. I never understood why, but now you've given at least one explanation how it could appear to be a good idea. I can also provide the reason why we found it to be an extremely bad idea at the time: Some (most? all?) systems won't set both the DF flag and the identification field at the same time. If you clear the DF flag without changing the identification field, you might end up with fragmented packets that are impossible to reassemble. Which was why I stumbled across the DF-clearing SOHO-router in the first place. The random problems it generated were extremely difficult to debug, and when we started we truly believed that we had a problem with a layer 4 load balancing switch. Note: There are solutions that will both clear the DF flag and generate a new id. E.g. http://www.openbsd.org/faq/pf/scrub.html This is the proper way to clear DF, if you must. Never just clear it. Bjørn ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
On 07/05/2008, at 4:42 PM, Glen Turner wrote: > Amazing. A fine case study of a person in customer contact undoing the > work of millions of dollars in PR. I wouldn't worry too much about it, Glen. My observation is that the millions of dollars in PR isn't working very well either :-) - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [NANOG] Microsoft.com PMTUD black hole?
Nathan Anderson/FSR wrote: > A member of Microsoft's GNS network escalations team saw my postings on > NANOG about this issue and took offense at my use of this forum to raise > this issue with them, and criticized me as being unprofessional and > lacking in business acumen. Hang on a tick. Aren't you one of their customers.. > As I pointed out in my post earlier today timestamped at 2:29PM, I was > using an XP SP3 host to perform my tests with... ...why yes, you are. I can't think of any other supplier that would be so unprofessional and so lacking in business acumen as to say that their customer was UALIBI. Amazing. A fine case study of a person in customer contact undoing the work of millions of dollars in PR. Whatever you say about Steve Ballmer he's a great sales person at heart. He must despair at some of his staff. -- Glen Turner ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
