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

[Fernando Gont <[e-mail]>]

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?

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