Re: [Idr] AD Review of draft-ietf-idr-shutdown-07

[Job Snijders <[e-mail]>]

Dear Alvaro,

On Mon, Apr 24, 2017 at 09:59:47PM +0000, Alvaro Retana (aretana) wrote:
> On 4/22/17, 6:10 AM, "Job Snijders" <[e-mail]> wrote:
> …
> > > C5. Section 4. (Error Handling): “Any erroneous or malformed Shutdown
> > > Communication received SHOULD be logged for the attention of the
> > > operator and then MAY be discarded.”
> > > 
> > > C5.1. What does “erroneous or malformed” mean?  I guess this is beyond
> > > a bad length, but maybe it refers to invalid UTF-8 sequences, or maybe
> > > something different.   ??
> >
> > Yes, section 2 "A receiving BGP speaker MUST NOT interpret invalid UTF-8
> > sequences." So, what a BGP speaker could do is send a hexdumped version
> > of the received data to syslog after something like "printf("%02x",
> > *p++);", rather then present that data through usual ways (as UTF-8).
> 
> Ok, so “erroneous or malformed” just refers to an “invalid UTF-8
> sequence”?  If so, then just say that and don’t leave it up to
> interpretation.

OLD:
    If an erroneous or malformed Shutdown Communication is received, a
    message indicating this event SHOULD be logged for the attention of
    the operator.

Perhaps:

    If a Shutdown Communication with an invalid Length value, or an
    invalid UTF-8 sequence is received, a message indicating this event
    SHOULD be logged for the attention of the operator.

> > > C7. Section 6.  (Security Considerations)
> > > 
> > > C7.1. REQUIRING is not an rfc2119 keyword.  Please work REQUIRED
> > > in there instead.
> >
> > OK, I got that from RFC 5424, so we might need an errata there.
> 
> It looks like we do.

Done: https://www.rfc-editor.org/errata/eid5010

> > > C7.3. In the Shepherd’s write-up [2], Sue wrote: “The Security-ADs
> > > will look at the ability to send data which indicates specific
> > > details regarding an operator or the operator's topology.”  Given
> > > that the operator can put anything in the string, it would be nice
> > > if you addressed this concern up front (and not wait for the SEC
> > > ADs).  Even if the information is being sent to a “trusted” peer,
> > > I think Sue raises an interesting point as “confidential”
> > > information may be inadvertently sent out.  One way to address
> > > this concern may be with guidance to operators and to reaffirm the
> > > fact that while the information is sent only one hop away (to your
> > > peer), it can be used as the receiver’s discretion.
> > > 
> > > [2] https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/shepherdwriteup/
> >
> > Interesting point. Do you think XMPP, SMTP, NNTP, and SYSLOG,
> > include similar clauses? 
> 
> I don’t know, did you look? ;-)
> 
> All those protocols were standardized before the IAB/IESG acquired a
> new taste for privacy.  Take a look at rfc6973 and at this short
> review [3].
> 
> [3] https://ietf.org/edu/tutorials/89-Privacy-Tschofenig.pdf 
>
> 
> > I personally may want to wait for a security AD to actually make and
> > argue the point rather then 'preempt' the angle with text which
> > borders on legalese.
> 
> No need to be too clever when writing this up; all you need is a
> recognition that secondary use of the data can occur, some
> recommendations about how to mitigate (by not including too much), and
> maybe a pointer to rfc6973.

OK, perhaps the following should be added to the security section?

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