Last Call Review of draft-ietf-ospf-node-admin-tag-07

Request Review of draft-ietf-ospf-node-admin-tag
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-10-13
Requested 2015-10-08
Authors Shraddha Hegde, Rob Shakir, Anton Smirnov, Zhenbin Li, Bruno Decraene
Draft last updated 2015-10-09
Completed reviews Genart Last Call review of -06 by David Black (diff)
Genart Last Call review of -07 by David Black (diff)
Secdir Telechat review of -04 by Benjamin Kaduk (diff)
Opsdir Last Call review of -05 by David Black (diff)
Assignment Reviewer David Black
State Completed
Review review-ietf-ospf-node-admin-tag-07-genart-lc-black-2015-10-09
Reviewed rev. 07 (document currently at 09)
Review result Ready with Nits
Review completed: 2015-10-09


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 at; rjs at; as at; lizhenbin at;
> bruno.decraene at; General Area Review Team (gen-art at; ops-
> dir at
> Cc: ietf at; ospf at; Black, David; acee at
> 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:
> <>.
> 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
> at        Mobile: +1 (978) 394-7754
> ----------------------------------------------------