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

Thanks - Fred
[e-mail]

> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
>