[PATCH 3/3] Drop packets that are too large without dropping connection

[Daniel Lenski]

On Thu, May 11, 2017 at 9:27 AM, Nikolay Martynov <mar.kolya at gmail.com> wrote:
> 2017-05-11 12:20 GMT-04:00 Daniel Lenski <dlenski at gmail.com>:
>> Yeah, that's really my only concern here. It might be safer simply to
>> pass through packets which are larger than the negotiated or estimated
>> MTU, as long as they're otherwise well-formed. I am not sure, however,
>> if this could impede MTU detection by higher levels of the protocol
>> stack.
>>
>> What happens if you keep only this part of your patch but don't drop
>> the packets?
>
>   I'd have to test this and get back to you.
>   But I guess I will have similar question for you here: in your
> setups and your code base when MTU is not known - how is it currently
> handled?

In the GlobalProtect mainloop
(https://github.com/dlenski/openconnect/blob/globalprotect/gpst.c#L615)
I don't pay attention to the size of the packet at all as long as it's
well-formed.

There is no mechanism whatsoever to request or advertise the MTU of
the HTTPS tunnel, so I don't really have another choice. (Clearly,
this is a poor design… but I didn't design it.)

>   I kind of feel that in situation when MTU is not known better/safer
> approach is to just setup interface with MTU equal to largest possible
> MTU - to some definition of 'largest'.

I would agree with your approach 100%, if I hadn't been working on
supporting a VPN protocol which provides absolutely no way to
negotiate the MTU or even figure out a reasonable "largest."

>   But I'm by no means an expert here, so I'm just asking :).

I'm not either. Perhaps David Woodhouse can weigh in on why he decided
to drop the connection when Juniper packets exceed the MTU (this was
added back in a47d69d3544e8d067c08aeb82e770daf8f635348).

Dan