On 5/7/08, Tomas L. Byrnes [EMAIL PROTECTED] 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
Iljitsch van Beijnum [EMAIL PROTECTED] writes:
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.)
Bjørn Mork wrote:
Iljitsch van Beijnum [EMAIL PROTECTED] writes:
snip
After all, Microsoft must have a reason to block all icmp. Or?
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.
But maybe
On 8 mei 2008, at 9:53, Joel Jaeggli wrote:
Oddly enough there is a draft on the subject of icmp filtering
recomendations is making the rounds.
http://tools.ietf.org/wg/opsec/draft-gont-opsec-icmp-filtering-00.txt
The opsec working group ([EMAIL PROTECTED]) and the authors would
appreciate
On Wed, 7 May 2008, Deepak Jain wrote:
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
-- [EMAIL PROTECTED] wrote: ---
First of all I would like to thank everyone for their support and concern.
We certainly have a lot of things to fix at Microsoft. In fact, I can
tell you that we have several brand new positions open (working on my team
and for teams near
On Wed, 7 May 2008, Michael Sinatra wrote:
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
* [EMAIL PROTECTED] (Janet Sullivan) [Thu 08 May 2008, 23:35 CEST]:
1) Yes, Microsoft blocks ICMP for the most part, which will break Path
MTU Discovery. This is a known issue. If you run into it, its most
likely because the servers you are trying to talk to in MS-land don't
have 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
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
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
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
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
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.
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
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
[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
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
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
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
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
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
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
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
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
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
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
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
Has anyone else here seen problems with microsoft/msn/hotmail/live.com
sites not performing PMTUD correctly?
I used to see it a lot when hosting on windows was popular and people
realised they needed a firewall or decided to add a load balancer
but broke PMTUD by leaving it enabled on the
On 6 mei 2008, at 21:58, Brandon Butterworth wrote:
Has anyone else here seen problems with microsoft/msn/hotmail/
live.com
sites not performing PMTUD correctly?
I used to see it a lot when hosting on windows was popular and people
realised they needed a firewall or decided to add a load
Iljitsch van Beijnum wrote:
A more common approach is to rewrite the MSS option in all TCP SYNs
[snip]
Yeah, we do this now, but the software that we have been using for PPPoE
termination as well as for a huge portion of our clients (MikroTik
RouterOS) doesn't do it correctly in my
Nathan Anderson/FSR wrote:
[...]
connections to that one host? Maybe even send out an MTU - 40 ICMP
:s/40/sized. Brain fart.
--
Nathan Anderson
First Step Internet, LLC
[EMAIL PROTECTED]
___
NANOG mailing list
NANOG@nanog.org
`
Date: Tue, 06 May 2008 14:29:03 -0700
From: Nathan Anderson/FSR [EMAIL PROTECTED]
Subject: Re: [NANOG] Microsoft.com PMTUD black hole?
Now, although that makes sense, in order to avoid issues like the one we
are facing with Microsoft, would it not make _more_ sense for the stack
Message-
From: Robert Bonomi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 06, 2008 3:54 PM
To: [EMAIL PROTECTED]
Subject: Re: [NANOG] Microsoft.com PMTUD black hole?
`
Date: Tue, 06 May 2008 14:29:03 -0700
From: Nathan Anderson/FSR [EMAIL PROTECTED]
Subject: Re: [NANOG] Microsoft.com
: Tuesday, May 06, 2008 3:54 PM
To: [EMAIL PROTECTED]
Subject: Re: [NANOG] Microsoft.com PMTUD black hole?
`
Date: Tue, 06 May 2008 14:29:03 -0700
From: Nathan Anderson/FSR [EMAIL PROTECTED]
Subject: Re: [NANOG] Microsoft.com PMTUD black hole?
Now, although that makes sense, in order
Tomas L. Byrnes wrote:
Interestingly, Windows XP, Sp3, released today, describes changes in
PMTUD behavior.
Black Hole Router detection is now on by default:
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, and it made no
On 6 mei 2008, at 23:48, [EMAIL PROTECTED] wrote:
A more common approach is to rewrite the MSS option in all TCP SYNs
with a smaller value so there won't be TCP segments large enough to
trigger the problem. AFAIK, all boxes that do PPPoE do this.
And just the other day, you were saying:
On 6 mei 2008, at 23:29, Nathan Anderson/FSR wrote:
Now, although that makes sense, in order to avoid issues like the
one we
are facing with Microsoft, would it not make _more_ sense for the
stack
to look at the PMTU cache first, and then adjust its own MSS just for
connections to that
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.
they try that intimidation every time a
39 matches
Mail list logo
