RE: ICMP PTB spoofing attacks (was: RE: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01)

["Templin, Fred L" <[e-mail]>]

Hi Fernando,

> -----Original Message-----
> From: Fernando Gont [mailto:[e-mail]]
> Sent: Friday, February 05, 2016 12:14 PM
> To: Templin, Fred L; Fred Baker (fred)
> Cc: 6man WG; Bob Hinden
> Subject: Re: ICMP PTB spoofing attacks (was: RE: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01)
> 
> On 02/05/2016 03:42 PM, Templin, Fred L wrote:
> > Hi Fernando,
> >
> >> -----Original Message-----
> >> From: Fernando Gont [mailto:[e-mail]]
> >> Sent: Friday, February 05, 2016 10:31 AM
> >> To: Templin, Fred L; Fred Baker (fred)
> >> Cc: Bob Hinden; 6man WG
> >> Subject: Re: ICMP PTB spoofing attacks (was: RE: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01)
> >>
> >> On 02/05/2016 03:25 PM, Templin, Fred L wrote:
> >>> Hi Fernando,
> >>>
> >>>> -----Original Message-----
> >>>> From: Fernando Gont [mailto:[e-mail]]
> >>>> Sent: Friday, February 05, 2016 10:02 AM
> >>>> To: Templin, Fred L; Fred Baker (fred)
> >>>> Cc: 6man WG; Bob Hinden
> >>>> Subject: Re: ICMP PTB spoofing attacks (was: RE: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01)
> >>>>
> >>>> On 02/05/2016 02:46 PM, Templin, Fred L wrote:
> >>>>> Hi Fred,
> >>>>>
> >>>>>> As soon as I say "there is no such attack", one will materialize, so I won't assert that.  However, I am not aware of attacks in
> >> which
> >>>>>> someone creates ICMP PTBs and sends them to someone else in order to reduce their windows unnecessarily.
> >>>>>
> >>>>> RFC4821 Section 11 (Security Considerations) recognizes the potential for spoofed
> >>>>> (i.e., inaccurate) ICMP PTB messages and suggests a mitigation (ignore all ICMP PTBs).
> >>>>> For paths over which any node in the network can inject an inaccurate ICMP PTB
> >>>>> message, an attack vector exists.
> >>>>
> >>>> In theory, you can do some basic validation for ICMP messages. However,
> >>>> in v6, as a result of possible EHs, you may not find any meaningful data
> >>>> in the ICMP payload to apply validity checks on.
> >>>>
> >>>> Anyway, you can implement the countermeasure we implemented in
> >>>> <https://tools.ietf.org/html/rfc5927#section-7.2> -- I implemented it
> >>>> for OpenBSD, and it still runs it... and IIRC it was ported to at least
> >>>> NetBSD later.
> >>>
> >>> Thanks for the reference. It seems to account for the case of paths that may
> >>> deliver inaccurate ICMP PTBs, but does not account for the case of paths that
> >>> fail to deliver accurate ICMP PTBs. Do we know of paths always deliver
> >>> accurate ICMP PTBs but can also deliver inaccurate ICMP PTBs?
> >>
> >> What do you mean by "accurate"?
> >
> > By "accurate" I mean:
> >
> > - the router that sends the ICMP PTB is telling the truth that there is a restricting link
> > - the MTU value that the router writes in the PTB is in fact the true MTU of the
> >    restricting link
> 
> Well, most of these protocols run on "good faith", right? -- If I cannot
> trust the router to tell the truth, why should I trust it to e.g.
> forward my packets?

A router's trustworthiness for forwarding packets and for telling the truth
in any ICMP PTB message it sends are mutually exclusive - the first question
is one of availability and the second is one of integrity.

Plus, it is not necessarily just the on-path routers - any off-path "router"
could also inject spurious PTBs.

Thanks - Fred
[e-mail]