[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
job screening question
- Subject: job screening question
- From: eyeronic.design at gmail.com (Mike Hale)
- Date: Thu, 5 Jul 2012 16:53:18 -0700
- In-reply-to: <CAP-guGUTE-x8xqSsN9=w55zX+OEgi9WfDgYnp-yuKFCrD3w29w@mail.gmail.com>
- References: <CAP-guGXoKDfpC_pwaQVxwjMoG29_bmJEM0Bs3KGwjXX-K0_BoA@mail.gmail.com> <[email protected]> <CAAf7Uo=HnAbkCgR6Grd5pJLf2STeFah_Lc0RRkod3gUC1VNHtA@mail.gmail.com> <CAP-guGUTE-x8xqSsN9=w55zX+OEgi9WfDgYnp-yuKFCrD3w29w@mail.gmail.com>
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 at herrin.us> wrote:
> On Thu, Jul 5, 2012 at 5:05 PM, Derek Andrew <Derek.Andrew at 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 at dirtside.com bill at 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