Re: [Idr] WG Adoption call for draft-snijders-idr-shutdown (11/16 to 11/30)

[Job Snijders <[e-mail]>]

On Sun, Nov 20, 2016 at 08:04:54PM +0000, Martin Hannigan wrote:
> This is useful. On the security considerations, I’m having a little
> bit of a fail grokking what visual spoofing means in this case? Is
> there way to spoof a cease message from a third party and create a
> message like “tear down, gone forever” in an unsecured (not MD5 or
> other secured mechanism) or is the reference to UTR36 more perfunctory
> and along the lines of “don’t send money to someone sending a request
> in this message including [e-mail] as a target address?

Visual spoofing exists in (at least) two forms, one is on the character
level: where innocuous characters are replaced with variants for
nefarious purposes, for example the following look alike but are
different: Greek Ο, Latin O, and Cyrillic О. The other variant is where
somehow a newline, newpage, feedpage or enough spaces to wrap the line
are inserted, and the receiving side might incorrectly think there are
more than 1 syslog messages where in reality its just 1 message,
containing a communication + syslog-like content.

To counter this the length of the string is limited to be very brief. If
one is allowed to insert say 4000 bytes worth of Shutdown Communication,
you could easily 'visually spoof' half a page worth of fake-syslog. The
receiving side might think his/her router is in big trouble and perform
an emergency reboot or upgrade based on false information.

Further reading: (search bing.com for 'visual spoofing')

    https://en.wikipedia.org/wiki/IDN_homograph_attack
    http://unicode.org/reports/tr36/#visual_spoofing

Another defense is to squash likely garbage and not print that. So one
should replace the garbage with U+FFFD "replacement character" so that
"drã©op table XXX;" becomes "dr�op table XXX;" and not "drop table
XXX;". The next version of the draft will provide more guidance on that.

This draft is breaking a lance for IDR in that it is the first draft (as
far as I know) to carefully consider the security aspects of using UTF-8
at this level.

I think UTF-8 is the right choice, it can be done (many industries have
gone before us), there is more than Roman script in this world, but
we'll need to make implementors aware.

> Any real concern over buffer overflows?

The clearly defined upperbound length of the BGP PDU, the Cease
NOTIFICATION and the length marker for the Shutdown Communication itself
can help mitigate these. I don't think there are any real new
considerations here. Normal printf, strlcpy, strlcat recommendations
apply. It was an explicit choice to not use a NUL-termination.

I welcome feedback from others, I wouldn't dare to proclaim I'm anything
close to an expert.

Kind regards,

Job