Re: [Idr] Adam Roach's No Objection on draft-ietf-idr-shutdown-08: (with COMMENT)

[Job Snijders <[e-mail]>]

Dear adam,

On Wed, May 24, 2017 at 01:44:12PM -0500, Adam Roach wrote:
> I understand your request for me to send text, but I'm still slightly
> perplexed about the exact issue you are trying to highlight, so I'll
> probably get it somewhat wrong. Here's an attempt:
> 
> 1) Completely remove this text:
> 
>    However, the visual spoofing due to character confusion still
>    persists.  This specification minimizes the effects of visual
>    spoofing by limiting the length of the Shutdown Communication.
> 
> 2) Between the first and second paragraph, add the following:
> 
> "As BGP Shutdown messages are likely to appear in syslog output, there is a
> risk that carefully formed Shutdown Communication fields might be formatted
> by receiving systems in a way to make them appear as additional syslog
> messages. To limit the ability to mount such an attack, the mechanism
> described in this document limits the length of BGP Shutdown Communication
> fields to 128 octets in length."
> 
> To be clear, I don't believe the mitigation proposed is a particularly
> good solution to the problem. I'm just proposing this text as my
> interpretation of what you seem to be claiming the existing text is
> supposed to say. If you can verify that the text I propose above is an
> accurate representation of the concern, then we can open a discussion
> around whether the mitigation is appropriate.

I accepted your suggestion & slightly rewrote the sentences for
readability flow within the context of this document. Thanks!

As to your belief on whether the mitigation proposed helps, the shutdown
communication concept could've been defined in such a way to allow the
communication to fill up to the maximum BGP message size (4000 octets,
so with marker, type, etc a bgp shutdown communication perhaps could've
been ~ 3979 octets). I believe that putting a limit in is useful: with
3979 octets someone can fill up a terminal screen, with 128 you can't.
128 could've been 127, or 129 - it is an arbitrary small value.

The 128 number comes from earlier implementations where there was no
Length field, in later versions of the document on the length field was
added, but the effective shutdown communication message size was not
changed. To keep things byte-aligned a 8 bit length field was used.
"hysterical raisins" :)

BTW, if you want to open an discussion, I don't understand why you cast
your ballot as "no objection". And what outcome are you targetting? It
seems unlikely at this point for the on-the-wire format to change.

Attached is a rfcdiff HTML file to show the differences.

NEW:
--------
    6.  Security Considerations

       This document uses UTF-8 encoding for the Shutdown Communication.
       There are a number of security issues with UNICODE.  Implementers and
       operator are advised to review UNICODE TR36 [UTR36] to learn about
       these issues.  UTF-8 "Shortest Form" encoding is REQUIRED to guard
       against the technical issues outlined in UTR36.

       As BGP Shutdown Communications are likely to appear in syslog output,
       there is a risk that carefully constructed Shutdown Communication
       might be formatted by receiving systems in a way to make them appear
       as additional syslog messages.  To limit the ability to mount such an
       attack, the BGP Shutdown Communication is limited to 128 octets in
       length.

       Users of this mechanism should be aware that unless a transport that
       provides integrity is used for the BGP session in question, a
       Shutdown Communication message could be forged.  Unless a transport
       that provides confidentiality is used, a Shutdown Communication
       message could be snooped by an attacker.  These issues are common to
       any BGP message but may be of greater interest in the context of this
       proposal since the information carried in the message is generally
       expected to be used for human-to-human communication.  Refer to the
       related considerations in [RFC4271] and [RFC4272].

       Users of this mechanism should consider applying data minimization
       practises as outlined in Section 6.1 [RFC6973] as a received Shutdown
       Communication may be used at the receiver's discretion.
-------

Kind regards,

Job