[154550] in North American Network Operators' Group
Re: job screening question
daemon@ATHENA.MIT.EDU (Mike Hale)
Thu Jul 5 19:53:53 2012
In-Reply-To: <CAP-guGUTE-x8xqSsN9=w55zX+OEgi9WfDgYnp-yuKFCrD3w29w@mail.gmail.com>
Date: Thu, 5 Jul 2012 16:53:18 -0700
From: Mike Hale <eyeronic.design@gmail.com>
To: William Herrin <bill@herrin.us>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Something tells me you're suddenly going to find yourself with an
influx of correct answers...
On Thu, Jul 5, 2012 at 3:18 PM, William Herrin <bill@herrin.us> wrote:
> On Thu, Jul 5, 2012 at 5:05 PM, Derek Andrew <Derek.Andrew@usask.ca> wrote:
>>> > You implement a firewall on which you block all ICMP packets. What
>>> > part of the TCP protocol (not IP in general, TCP specifically)
>>> > malfunctions as a result?
>>
>> Isn't MTU discovery on IP and not TCP?
>
> If you want to overthink the question, the failure in the TCP protocol
> is that it doesn't adjust the MSS to match the path MTU. It continues
> to rely on the incorrect path MTU estimate, sending too-large packets
> which will never arrive. This happens because TCP doesn't receive a
> notification that the path MTU estimate has changed from the default
> because the lower layer PMTUD algorithm never receives the expected
> ICMP packet.
>
> This is, incidentally, is a detail I'd love for one of the candidates
> to offer in response to that question. Bonus points if you discuss MSS
> clamping and RFC 4821.
>
> The less precise answer, path MTU discovery breaks, is just fine.
>
> Regards,
> Bill Herrin
>
>
>
>
> --
> William D. Herrin ................ herrin@dirtside.com bill@herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
>
--
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
