Re: [quicwg/base-drafts] Do not allow ICMP PTB to increase PMTU (#2161)

[Gorry Fairhurst <[e-mail]>]

On 14/12/2018, 16:30, Magnus Westerlund wrote:
>
> *@gloinul* commented on this pull request.
>
> ------------------------------------------------------------------------
>
> In draft-ietf-quic-transport.md 
> <https://github.com/quicwg/base-drafts/pull/2161#discussion_r241813264>:
>
> >  @@ -3139,7 +3139,8 @@ attacks that successfully guess the IP address 3-tuple and reduce the PMTU to a
>   bandwidth-inefficient value.
>
>   An endpoint MUST ignore an ICMP message that claims the PMTU has decreased below
> -1280 bytes.
> +1280 bytes.  And endpoint MUST ignore an ICMP message that attempts to increase
> +PMTU, unless the ICMP message was received in response to a PMTU probe packet.
>
> Wouldn't the best thing here be to tweak the next paragraph to say 
> that any reactions to ICMP messages should be validated and DPLPMTUD 
> do specify how to do such validation both for increasing and 
> decreasing the PMTU?
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub 
> <https://github.com/quicwg/base-drafts/pull/2161#discussion_r241813264>, 
> or mute the thread 
> <https://github.com/notifications/unsubscribe-auth/AHC1koQJq3mAAm889Dnr6rCmDGrSvVfBks5u49IugaJpZM4ZSdss>.
>
I think terminology needs to be correct. It was really hard to get the 
terminology consistent in DPLPMTUD, and since QUIC has not (yet) adopted 
the same language, this may be tricky to wordsmith, but here is what I 
suggest:

Put simply, I would suggest a PTB message can NEVER increase the PLPMTU, 
even when it reports a value greater than the PLPMTU after a probe 
message. Unless someone explains different, I will continue to assert 
that PTB messages MUST be validated - at least the IP addresses, 
transport, and ports. Accepting arbitrary information to control the 
transport isn't a good start to building a useful protocol.

I have reasons to suggest that endpoints also not to increase their 
PLPMTU based on the PTB reported size:

(1) Because soemtimes the reported MTU size can be garbled, and I would 
encourage being conservative to avoid black-holing.
(2) Because the sender still doesn't know an actual segment larger than 
the PLPMTU would transit the end to end path.
(3) A path that is incosnistent in forwarding would result in more 
corner cases if you start reacting to PTB signals, relying on actual 
probes is simpler.

Therefore, I would trigger a probe for the reported size. That's what 
DPLPMTUD currentl says (you could refer to that spec to explain this.)

Gorry






-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2161#issuecomment-447388870