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

Job Snijders <job@instituut.net> Sat, 22 April 2017 10: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 66488129476 for <idr@ietfa.amsl.com>; Sat, 22 Apr 2017 03:10:26 -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=unavailable 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 MUpbrYx2QIGG for <idr@ietfa.amsl.com>; Sat, 22 Apr 2017 03:10:22 -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 39189129474 for <idr@ietf.org>; Sat, 22 Apr 2017 03:10:22 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id o81so31020177wmb.1 for <idr@ietf.org>; Sat, 22 Apr 2017 03:10:21 -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=nlDVYy1/PkRVGVUhjVdvjYsNRa901JpYjx0O8PehJPU=; b=atuDQ5vWOaOn84CQKpzqz4tGQUBg4kC//OwPqjpUDvV7hldWDWSAkfqvmx4veRRieW Cxoq4REC369gFbK3qYQ5eVHw8UMJMe7yxTS3FNmeV/4XriuyMjPO9CNQewCrWrb+eaXM u4RSnua2GXrxxMqXgMqckIL4UCbaW8IysbHJA7xJBU3vX2upHy903OI7fVOz4YcUokgh 7+zjKXw3z/aVh5m0A3vNeBW+qEVoVUqtC8aYEiOYhdktJrwXZM+dahshpkppH37tDiSh 1QgOLxgzzEDJLFnBRLK9RVr/3JzPXSM+Up4g+unmy2k09rzP0buPuXwK3MOpwW/wDXyY MiiQ==
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=nlDVYy1/PkRVGVUhjVdvjYsNRa901JpYjx0O8PehJPU=; b=fdjBuzhbUjMOqLOk5z2qIYoR4nc4cAxdZintCjOxlELkYwB/VSAdm9Kk5bBvRdgVaK N7nZ0H+3nWvKWZ5thkz37F9oLgjMPjQ9Uw+mOMtSXVV+yD2hj5Z084+L3l8nYNIHui9z vCqyz7BAbV1Al93e3tykdmT39z2cDoeEKlGI7ov0E0wAZC8wm8nPY5IBUpRjuPIA3oSe SQt45pbFlziIqhGByoo6teXFiydY9nS+VmpKDCi7BbThgz8/GrXllswLNpVKdO3XtHaA QZHD42oi2uSPPlwW7gy/hN3Hrv3V3iaDwZL1i6ZAvBAZi1wA4UcScmsWp3td56PlopEw uXeg==
X-Gm-Message-State: AN3rC/6mV/dwHjrDi3YenQmyI0IOtUAoUvAgUio27onIyMtuvCGg3gNX IGiVMhHd0o1Nzw==
X-Received: by 10.28.227.4 with SMTP id a4mr2391200wmh.50.1492855820353; Sat, 22 Apr 2017 03:10:20 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:81c5:ceb8:25a1:6cb]) by smtp.gmail.com with ESMTPSA id y60sm8578301wrb.39.2017.04.22.03.10.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Apr 2017 03:10:17 -0700 (PDT)
Date: Sat, 22 Apr 2017 12:10:13 +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: <20170422101013.4unb4a3ulsq2kueg@Vurt.local>
References: <010A73B6-A030-483F-8D79-3498D92C3335@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <010A73B6-A030-483F-8D79-3498D92C3335@cisco.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170306 (1.8.0)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/tdFskbT21LVKP4uaMkJtqUFeFUE>
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: Sat, 22 Apr 2017 10:10:26 -0000

Dear Alvaro,

On Fri, Apr 21, 2017 at 07:05:22PM +0000, Alvaro Retana (aretana) wrote:
> This document partially answers the “why did the session go down?”
> question by adding the ability to send other information as part of a
> Cease NOTIFICATION.  I say “partially” because it does so for only 2
> of the existing subcodes.  Except for the draft’s name, there’s no
> justification or explanation of why all the current (or even future!)
> subcodes are not granted the ability to (optionally) send extra
> information.  Why?  I know that this point was brought up on the list
> [1], and the resolution seems to have simply been “that’s out of
> scope”.  Personally (taking my AD hat off!), I think it’s a shame –
> but I guess it’s also an opportunity to write a 1-line update to this
> document.  BTW, I don’t want to necessarily resurrect this point, I’m
> ok being in the rough…  [Putting my AD hat back on…]  It would be very
> nice if there was some text (a paragraph or two) explaining why just 2
> subcodes, or maybe why not the others – I’m sure (or maybe I hope)
> that others will have similar questions.

Following the documents history it is easy to see that originally we
proposed a new Cease subcode (which would mimic 'shutdown'), but were
encouraged to recycle an existing codepoint since there was an
opportunity for permissionless extension, and subsequently the utility
'shutdown' and 'reset' was defined as belonging to the same group.

The choice to 'just' decorate subcode 2 and 4 was driven out of
operational experience with the various shutdown events. 2 and 4 are
human initiated (or humans program a system to do it on their behalf).
The other sub cease codes are either driven out of existing automation
no immediate need to enrich them was identified ("maximum prefix",
"Connection Rejected")), or are poorly understood ("Other Configuration
Change") or rarely used ("Out of Resources").

We also analysed how the concept would fit in currently established CLI
paradigms, and identified that in most operating systems it would be
trivial to enrich the 'shutdown/down/disable' or 'clear/reset' commands
or configuration directives, but less so for the other types of events.

So in short: we looked at what is commonly used, and enriched those.
This leaves room for others to decorate the the other or future
subcodes, if they identified a need to be addressed.

> Besides that rant, I do have some other comments (please see below)
> aimed mostly at clarifying.  I would like to (at least) see the
> comments about the Security Considerations addressed before starting
> the IETF Last Call.

> [1] https://mailarchive.ietf.org/arch/msg/idr/YJPgIdtZg7DrY4PliefkrPm6Kas/?qid=fb7d4b6fce9500d97f5b7ab25a062d53
> 
> C1. s/This document specifies…/This document updates [RFC4486] by specifying…

done.

> C2. s/Cease NOTIFICATION message [RFC4486]/Cease NOTIFICATION message [RFC4271] – or simply take the reference off.

ok, opted for RFC4271 

> C3. Section 2. (Shutdown Communication)
> 
> OLD>
>    … then the BGP speaker MAY send to the neighbor a
>    NOTIFICATION message with the Error Code "Cease" and Error Subcode
>    "Administrative Shutdown" or "Administrative Reset" followed by a
>    length field and an UTF-8 encoded string.
> 
> NEW>
> …and it sends a NOTIFIATION message with the Error Code "Cease" and
> Error Subcode "Administrative Shutdown" or "Administrative Reset"
> [RFC4486], it MAY include an UTF-8 encoded string.
> 
> Objective: move the MAY to indicate that the extra string is optional,
> and not the whole thing.  I know that a BGP speaker may end up not
> sending the Cease because rfc4486 has a SHOULD in it…but I also wanted
> to avoid confusion between that SHOULD and this MAY.

thank you, accepted.

> C4. Please put a Figure number to go with the encoding.

done

> 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).

> C5.2. Does the fact the content is erroneous mean that the
> NOTIFICATION should be ignored?  I would assume not…but the “MAY be
> discarded” part may raise questions.  Do you only discard the
> “Shutdown Communication” part?  Or the whole NOTIFICATION?  Where you
> storing NOTIFICATIONs to start with?  I guess an implementation can
> keep the string around for historical purposes…but that seems an
> implementation detail and nothing like that is specified in the
> document.

Following the Cease NOTIFICATION the TCP session will be torn down, so
even if you ignore the NOTIFICATION, the BGP speaker will have to deal
with a torn down session anyway. But, I'll remove "and then MAY be
discarded". It is indeed up to implementers to decide whether they want
to keep it around. OpenBGPD keeps it around in a 'show bgp
neighbor'-style command, exabgp & pmacct don't.

> C5.3. Section 2 already talks about reporting the contents -- I’m
> assuming the logging requirement here is the same (do whatever you
> want, but syslog SHOULD be used), right?  If so, then how is the
> handling of the “erroneous or malformed” information different than
> that of the one that isn’t?

I envision that in the invalid case one simply logs "received malformed
shutdown communication", with perhaps a hexdump of what was received,
and in the normal situation a bgp speaker decodes the string as UTF-8,
syslogs the result, and perhaps stores it for historic purposes. Do you
have a suggestion how to clarify?

perhaps, NEW:

    """
    If an erroneous or malformed Shutdown Communication is received, a
    message indicating this event SHOULD be logged for the attention of
    the operator.  An erroneous or malformed Shutdown Communication
    itself MAY be logged in a hexdump format.
    """

> C6. Section 5. (IANA Considerations) Why do you want the registry to
> refer to this document?  There’s nothing in this document that
> modifies or affects the registry, the policies or the assignments… I
> think that the Updates tag is enough to show the relationship.

Because 4486 is updated, and 4486 instantiated those entries. I believe
there is benefit in providing this additional way to show the relation.
A developer or debugger might go straight to the registry looking for
just the value mapping, and then be happy to learn that subcode 2 & 4
could be followed by trailing data which is encoded in a specific way.

> 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.

OLD:
    This document guards against the technical issues outlined in UTR36
    by REQUIRING "shortest form" encoding.
NEW:
    UTF-8 "Shortest Form" encoding is REQUIRED to guard against the
    technical issues outlined in UTR36.

> C7.2. I agree on the points about integrity and confidentiality.
> However, neither rfc4486, rfc4271 nor rfc4272 are as specific as
> you’re being here.  I don’t think this is the document where we want
> to have the discussion about explicitly upgrading to TCP-AO, even if
> it’s just mentioned as an example.  Suggestion:  leave the text about
> the potential concern, take both examples out, and point at the
> security considerations in rfc4271/rfc4272.
> 
> NEW>
>    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].

OK, accepted.

> 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 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.

Following your feedback, we'll post an update shortly.

Kind regards,

Job