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

"Alvaro Retana (aretana)" <aretana@cisco.com> Fri, 21 April 2017 19:05 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 54A76129B36; Fri, 21 Apr 2017 12:05:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rsmjfGt34YGK; Fri, 21 Apr 2017 12:05:25 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8BE127286; Fri, 21 Apr 2017 12:05:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26892; q=dns/txt; s=iport; t=1492801525; x=1494011125; h=from:to:cc:subject:date:message-id:mime-version; bh=KHgHOILfDimpZP78wBgtf7Uyo5ekTFrRcdguxOQV53Q=; b=hRcp5EuBW92kIj2C6lCTdIMbSTa3AkPe+SC5AkU4ttdfLwSUIjgIGOwG 0tZobR4h24OLl0TJQWV+5/BRoCLi+5QWDubTRRvc67FRL42zjV8+w6x/Y TWg6qUZ4xiBTdNHSK694OtClzbSqvDdbELyDOBBE/f91+0MP4rcf3+aqw I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.37,230,1488844800"; d="scan'208,217";a="238888201"
Received: from rcdn-core-11.cisco.com ([]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2017 19:05:23 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com []) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v3LJ5NOg010083 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Apr 2017 19:05:23 GMT
Received: from xch-aln-002.cisco.com ( by XCH-RCD-002.cisco.com ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 21 Apr 2017 14:05:22 -0500
Received: from xch-aln-002.cisco.com ([]) by XCH-ALN-002.cisco.com ([]) with mapi id 15.00.1210.000; Fri, 21 Apr 2017 14:05:23 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "draft-ietf-idr-shutdown@ietf.org" <draft-ietf-idr-shutdown@ietf.org>
CC: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, Hares Susan <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: AD Review of draft-ietf-idr-shutdown-07
Thread-Index: AQHSutI62HNkeEG8rUet1MjLuMXn2w==
Date: Fri, 21 Apr 2017 19:05:22 +0000
Message-ID: <010A73B6-A030-483F-8D79-3498D92C3335@cisco.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_010A73B6A030483F8D793498D92C3335ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zgWKw_Pr3nFTDjdfeHWqkvM0ZeU>
Subject: [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, 21 Apr 2017 19:05:27 -0000

Dear authors:

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.

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…

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

C3. Section 2. (Shutdown Communication)

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

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

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

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

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.

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?

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.

C7. Section 6.  (Security Considerations)

C7.1. REQUIRING is not an rfc2119 keyword.  Please work REQUIRED in there instead.

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.

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

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/