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

[David Woodhouse]

On Thu, 2017-05-11 at 10:03 -0700, Daniel Lenski wrote:
> On Thu, May 11, 2017 at 9:27 AM, Nikolay Martynov  wrote:
> 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.

We tend to allocate receive buffers big enough for the negotiated MTU,
so I hope you're paying *some* attention to how much data you're
receiving :)

> 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.)

And it looks like Juniper is also sending 1500-byte packets after
negotiating an MTU of 1400. Not negotiating is bad design. Negotiating
and then violating the agreement is worse :)

> 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).

Because it was (supposedly!) a 'can never happen' condition.

If they're actually going to send larger packets then — as long as we
make bloody sure we're not going to overflow our allocations — I
suspect we're better off actually receiving them. If they made them
through, why drop? And if we *are* going to drop, shouldn't we be
sending ICMP back?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4938 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20170512/7539a92d/attachment.bin>