[OSPF] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-07

"Black, David" <david.black@emc.com> Fri, 09 October 2015 20:44 UTC

Return-Path: <david.black@emc.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8F4F01AC413; Fri, 9 Oct 2015 13:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id zvkuneJhoDv4; Fri, 9 Oct 2015 13:44:18 -0700 (PDT)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 584A21AC410; Fri, 9 Oct 2015 13:44:17 -0700 (PDT)
Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com []) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t99Ki5mH018749 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 9 Oct 2015 16:44:07 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t99Ki5mH018749
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1444423448; bh=IP4j6NF7I1ZFQEDGCgBAwv9BeZk=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=guQY1Amlp9lziQpoH5dy8Tw0NJd56VrzZKuoKrrilhPANX+F0jylikGqlViGHRAOE Ll5sTOkpKeGMOFVEEVg/62aDBBj57/y2PIKMEVNhykyR+g6FWMrcwWkUo1Wijtscuw fY5t9PYbVkEpd7oSyICh07SRBkwJnvL33oNgQHWk=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t99Ki5mH018749
Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com []) by maildlpprd56.lss.emc.com (RSA Interceptor); Fri, 9 Oct 2015 16:43:10 -0400
Received: from mxhub40.corp.emc.com (mxhub40.corp.emc.com []) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t99Khmgd016853 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Oct 2015 16:43:49 -0400
Received: from MXHUB207.corp.emc.com ( by mxhub40.corp.emc.com ( with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 9 Oct 2015 16:43:48 -0400
Received: from MX104CL02.corp.emc.com ([]) by MXHUB207.corp.emc.com ([]) with mapi id 14.03.0224.002; Fri, 9 Oct 2015 16:43:48 -0400
From: "Black, David" <david.black@emc.com>
To: "shraddha@juniper.net" <shraddha@juniper.net>, "rjs@rob.sh" <rjs@rob.sh>, "as@cisco.com" <as@cisco.com>, "lizhenbin@huawei.com" <lizhenbin@huawei.com>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "General Area Review Team (gen-art@ietf.org)" <gen-art@ietf.org>, "ops-dir@ietf.org" <ops-dir@ietf.org>
Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-07
Thread-Index: AdEC0zGWXF/6DiT8S06I9BPuQhJfXA==
Date: Fri, 9 Oct 2015 20:43:47 +0000
Message-ID: <CE03DB3D7B45C245BCA0D24327794936166B7222@MX104CL02.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com
X-RSA-Classifications: public
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/RR6jIH631V01RfxwG6ZLtLYsEc4>
Cc: "ospf@ietf.org" <ospf@ietf.org>, "Black, David" <david.black@emc.com>, "ietf@ietf.org" <ietf@ietf.org>
Subject: [OSPF] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-07
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2015 20:44:21 -0000

The -07 version of this draft addresses all of the issues raised in the
Gen-ART and OPS-Dir review of the -06 version, with the Operational
Considerations section being a particularly welcome addition.  Many
thanks to the authors for the quick turnaround on everything that was

The following is a possible additional security consideration:

Injection of tag values from the outside (e.g., forge OSPF
traffic that appears to be from a node in the domain and carries
administrative tag values) is at least a possible denial-of-service attack
vector, and could also be used for more nefarious purposes (e.g., reroute
otherwise unobservable [to the attacker] VPN traffic via a route where
the attacker can observe it).  Measures should be taken to prevent
injection of outside OSPF traffic in general to protect not only tags,
but all OSPF routing functionality.


> -----Original Message-----
> From: Black, David
> Sent: Monday, October 05, 2015 7:35 PM
> To: shraddha@juniper.net; rjs@rob.sh; as@cisco.com; lizhenbin@huawei.com;
> bruno.decraene@orange.com; General Area Review Team (gen-art@ietf.org); ops-
> dir@ietf.org
> Cc: ietf@ietf.org; ospf@ietf.org; Black, David; acee@cisco.com
> Subject: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06
> This is a combined Gen-ART and OPS-Dir review.  Boilerplate for both follows
> ...
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at:
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> Please resolve these comments along with any other Last Call comments
> you may receive.
> I have reviewed this document as part of the Operational directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments
> were written primarily for the benefit of the operational area directors.
> Document editors and WG chairs should treat these comments just like any other
> last call comments.
> Document: draft-ietf-ospf-node-admin-tag-06
> Reviewer: David Black
> Review Date: October 5, 2015
> IETF LC End Date: October 8, 2015
> IESG Telechat date: October 15, 2015
> Summary:  This draft is on the right track, but has open issues
>  		described in the review.
> This is a generally well-written draft about adding administrative tags for
> operational use to OSPF.  The draft is clear, and the material on how the
> tags could be used is helpful, although raises a number of concerns about
> the consequences of the intended usage of these tags.
> ---- Major issues: ----
> [1] Operational considerations:  There appears to be more than enough
> enabled by this draft to wreak serious operational havoc, but the draft
> seems to sidestep all operational topics, primarily by treating all
> usage of tags as vendor- or implementation- specific and trusting the
> vendors and operators not to foul things up.  I'm not sure that's wise.
> See end of OPS-Dir review below for more on this concern.
> --- Minor issues: ----
> -- 3.2 Elements of procedure:
> [A] I see what look like some underspecified requirements:
>    Each tag SHOULD be treated as an independent identifier that MAY be
>    used in policy to perform a policy action.
>    The administrative tag list within the
>    TLV SHOULD be considered an unordered list.
> Why are those two not "MUST" requirements?  What happens if either
> is not done?
> [B] Tag set completeness:
>    Multiple node administrative tag TLVs MAY appear in an RI LSA or
>    multiple node administrative tag TLVs MAY be contained in different
>    instances of the RI LSA.  The node administrative tags associated
>    with a node for the purpose of any computation or processing SHOULD
>    be a superset of node administrative tags from all the TLVs in all
>    instances of the RI LSA originated by that node.
> This paragraph is about processing at that node.  It's easy to misread,
> as that implication is buried in the word "originated" in the last line.
> Suggested change:
> 	"for the purpose of any computation or processing SHOULD" ->
> 	"for the purpose of any computation or processing performed
> 		at that node SHOULD"
> Also, it looks like it's acceptable for other nodes to perform such
> computation or processing based on a partial tag set for this node
> (e.g., when some other node has not received all the RI LSAs with all
> the tags).  That should be stated.
> [C] Tag change/removal:
>    When there is a change in the node administrative tag TLV or removal/
>    addition of a TLV in any instance of the RI-LSA, implementations MUST
>    take appropriate measures to update its state according to the
>    changed set of tags.  Exact actions depend on features working with
>    administrative tags and is outside of scope of this specification.
> Inability to interoperably remove a tag value (e.g., distribute the
> update that tag X no longer applies to node Q) seems like a significant
> omission, but I'm not a routing expert, so I'll defer to the WG's and
> ADs' judgment on the importance of this.  At a minimum, the rationale
> for not specifying an interoperable tag value removal mechanism ought
> to be added to this document.
> [D] No management support
> From OPS-Dir Q&A: At a minimum, reporting of tag values ought to be
> defined via an OSPF MIB extension or analogous functionality.
> --- Nits/editorial comments: ----
> -- 1.  Introduction
> The Abstract says that the tags are for "route and path selection"; the
> Introduction should also say that.  Suggestion - at the end of this sentence
> in the first paragraph:
>    It is useful to assign a per-node administrative tag to a router in
>    the OSPF domain and use it as an attribute associated with the node.
> add the text "for route and path selection".  This will help with the
> second sentence in the second paragraph:
>    Path selection is a functional set
>    which applies both to TE and non-TE applications and hence new TLV
>    for carrying per-node administrative tags is included in Router
>    Information LSA [RFC4970] .
> If "path selection" and "functional set" are specific terms with
> specialized meaning in OSPF context, that sentence is fine as-is,
> otherwise it would read better if it began with:
>    Route and path selection functionality applies to both ...
> -- 3.1.  TLV format
>    Type : TBA, Suggested value 10
> Please add an RFC Editor Note asking the RFC Editor to replace this with
> the actual IANA-assigned value.
> -- 3.2.  Elements of procedure
> While it's obvious that tag usage should be confined to the administrative
> domain that understands the tag, it's worth stating.  At the end of this
> sentence:
>    Interpretation of tag values is specific to the administrative domain
>    of a particular network operator.
> I'd suggest adding:
>    , and hence tag values SHOULD NOT be propagated outside the
>    administrative domain to which they apply.
> -- 4.4.  Mobile back-haul network service deployment
> Please expand "eNodeB" acronym on first use.
> -- 4.5.  Explicit routing policy
> In Figure 3:
> - The link from the leftmost pair of A nodes to the pair of T nodes
>    do not have link weights.
> - The link from the left R node to the left T node does not have a
>    link weight
> - The following example of an explicitly routed policy:
>       - Traffic from A nodes to I nodes must not go through R and T
>       	nodes
>     prevents the leftmost pair of A nodes from sending traffic to the
>     I nodes.  Was this "black hole" intended as part of the example?
> Also: "explicitly routed policies" -> "explicit routing policies"
> - 5. Security considerations
> I'd add discussion that advertisement of tag values for one administrative
> domain into another risks misinterpretation of the tag values (if the two
> domains have assigned different meanings to the same values), which may
> have undesirable and unanticipated side effects.
> In addition, injection of tag values from the outside (e.g., forge OSPF
> traffic that appears to be from a node in the domain and carries
> administrative tag values) is at least a possible denial-of-service attack
> vector, and could also be used for more nefarious purposes (e.g., reroute
> otherwise unobservable [to the attacker] VPN traffic via a route where
> the attacker can observe it).
> idnits 2.13.02 did not find any nits.
> ---- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ----
> A.1.2.  Has installation and initial setup been discussed?
> A.1.5.  Has the impact on network operation been discussed?
> A.1.6.  Have suggestions for verifying correct operation been discussed?
> 	No - given the impact that these tags could have on route and path
> 		computation, likely implementations will be powerful "guns"
> 		with which network operators can readily shoot themselves
> 		in far more than just their "feet."  These
> 		considerations would have to be documented based on the
> 		specific uses made of these tags by specific implementations
> 		and deployments.  All of that appears to be outside the scope
> 		of this draft.
> A.1.7.  Has management interoperability been discussed?
> 	No - at a minimum, reporting of tag values ought to be defined
> 		via an OSPF MIB extension or analogous functionality.
> 		This is minor issue [D].
> A.1.8.  Are there fault or threshold conditions that should be reported?
> 	Yes, but they're implementation-specific - see response to
> 		A.1.[2,5,6] above.
> A.2.  Management Considerations
>    Do you anticipate any manageability issues with the specification?
> 	Yes, manageability has been largely ignored.
> A.3.  Documentation
>    Is an operational considerations and/or manageability section part of
>    the document?
> 	No.
>    Does the proposed protocol have a significant operational impact on
>    the Internet?
> 	Yes, the anticipated uses will.
>    Is there proof of implementation and/or operational experience?
> 	Nothing was stated in the draft or shepherd write-up.
> As an OPS-Dir member, I'm concerned by the above RFC 5706 answers,
> and in particular treating all operational issues as vendor- and/or
> operator-specific.  One possible alternative would be to scope the
> draft down to interoperably specify what's needed for LFA, as
> indicated by this answer from the Shepherd write-up:
> (9) How solid is the WG consensus behind this document? Does it
>     represent the strong concurrence of a few individuals, with others
>     being silent, or does the WG as a whole understand and agree with it?
>       There is consensus from the WG and others outside the WG that
>       this document can progress. It complements work done on LFA
>       manageability in the RTG Working Group.
> Another alternative could be Experimental RFC status for the full
> tag mechanism (e.g., to figure out what it'll be used for in practice,
> how and why) rather than Proposed Standard.
> This is major issue [1].
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> david.black@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------