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

Job Snijders <job@instituut.net> Fri, 05 May 2017 12:10 UTC

Return-Path: <job@instituut.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C969B128CDB for <idr@ietfa.amsl.com>; Fri, 5 May 2017 05:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFC1bjkpL6SJ for <idr@ietfa.amsl.com>; Fri, 5 May 2017 05:10:42 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8361288B8 for <idr@ietf.org>; Fri, 5 May 2017 05:10:42 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id m123so4358096wma.0 for <idr@ietf.org>; Fri, 05 May 2017 05:10:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=ETau9HJjhXyMDTkwd+ZZxll/aF9C8HxRLIQN9T3nliY=; b=QA6DHABZSPlaaC8r1ntxJ45BTSwAWE3tQFOcigklyFfpsZhFp7pT9RHI0IGpT8dVNS zkIRbfxIUfz2Y0ofb4k7pYzQ6mq7947GDLAvbbTuLLGjOU9ehx36hoBgXSr915mKUc9D IlOh0f2aepRSmlWsUvkpRYGVW6sQuF1CDWbOkcY/BaHRi0RnDbjlo3DxKFMxdyZP+oZt eD7xBQlB1BLal7X94S6Uz2o9j37twnZYGfVwvrDtDQ+wrrdSXe+s/O+fdMiT+0VRrbGf 3oUYW82blL+YAi6myUUV+C3UvettrOuZjPHaD4DxPA3Ezoy3pQvtKCpM78qqJjs92Yoz Jn5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=ETau9HJjhXyMDTkwd+ZZxll/aF9C8HxRLIQN9T3nliY=; b=prwQJvwXmbUwVE2xvnh1WTxzPW3HMVI5XFsG9x5XDrM1VIAtPxu3H/6wfH5uW3a/nJ HQpGjqHC+2OumQCOFPThUKcHjLSRKK3mMuAapf/ZcRjEwwuQuO95Ds90hqhRjTsxj0jK bKYWZ4ugbN/8YKqFjvbbPBV7Dbmbcr1YrazlEkziTnvs7pZII+HnTxQ7YNZqlB3t/0px uoNkhH08tmsxuiDPDofdkYLYLlPpdZ7OS3Q7ZQ3vWzvBtCxNGZeAu6E39kiDlwfDGs4p BwtO5uSCWePDWfux4QmY/FW/WRCI3YtUXb+LETBGYxXnrOYXXj5w7v8I/SbFewICDJ2w T6Yg==
X-Gm-Message-State: AN3rC/4/absZmdKpAkJCyogdYbpUSOkxjHmgdjPxZ1kRPPybKTIqIDvQ uAabgqBYoh17Zg==
X-Received: by 10.80.143.164 with SMTP id y33mr33433495edy.89.1493986241091; Fri, 05 May 2017 05:10:41 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:597:4a36:bb29:1e61]) by smtp.gmail.com with ESMTPSA id d38sm1266106edb.26.2017.05.05.05.10.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 05:10:40 -0700 (PDT)
Date: Fri, 5 May 2017 14:10:32 +0200
From: Job Snijders <job@instituut.net>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>
Cc: "draft-ietf-idr-shutdown@ietf.org" <draft-ietf-idr-shutdown@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, Hares Susan <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Message-ID: <20170505121032.2sdnez3lxemdszsb@Vurt.local>
References: <010A73B6-A030-483F-8D79-3498D92C3335@cisco.com> <20170422101013.4unb4a3ulsq2kueg@Vurt.local> <D0660551-9116-40F2-BBBF-0DEC12A80B54@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D0660551-9116-40F2-BBBF-0DEC12A80B54@cisco.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170306 (1.8.0)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/hk7F2a6R1yEKWvnAImBXKTLkBU0>
Subject: Re: [Idr] AD Review of draft-ietf-idr-shutdown-07
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 May 2017 12:10:45 -0000

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" <job@instituut.net> 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