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

From: Job Snijders <[email-masked]>
Date: Fri, 5 May 2017 14:10:32 +0200

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" <[email-masked]> 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

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 5 May 2017 14:35:34 +0000

Hi!

I’m fine with that text.

Thanks!

Alvaro.

On 5/5/17, 8:10 AM, "Job Snijders" <[email-masked]> wrote:

NEW:

---

From: Job Snijders <[email-masked]>
Date: Fri, 5 May 2017 16:49:15 +0200

On Fri, Apr 21, 2017 at 07:05:22PM +0000, Alvaro Retana (aretana) wrote:
> I would like to (at least) see the comments about the Security
> Considerations addressed before starting the IETF Last Call.

Alvaro, ball is in your court! :-)

--------

Date: Fri, 05 May 2017 16:43:49 +0200
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: [Idr] I-D Action: draft-ietf-idr-shutdown-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : BGP Administrative Shutdown Communication
        Authors         : Job Snijders
                          Jakob Heitz
                          John Scudder
        Filename        : draft-ietf-idr-shutdown-08.txt
        Pages           : 7
        Date            : 2017-05-05

Abstract:
   This document enhances the BGP Cease NOTIFICATION message
   "Administrative Shutdown" and "Administrative Reset" subcodes for
   operators to transmit a short freeform message to describe why a BGP
   session was shutdown or reset.  This document updates RFC 4486.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-shutdown-08
https://datatracker.ietf.org/doc/html/draft-ietf-idr-shutdown-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-shutdown-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr