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

Thanks - Fred
[e-mail]

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