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

["Black, David" <[e-mail]>]

> I think this description would also cover the issue you have brought up. Let
> me know if you are OK with this.

Yes, I'm OK - that covers the topic.

Thanks, --David

> -----Original Message-----
> From: Shraddha Hegde [mailto:[e-mail]]
> Sent: Sunday, October 11, 2015 9:08 AM
> To: Black, David; [e-mail]; [e-mail]; [e-mail];
> [e-mail]; General Area Review Team ([e-mail]) ops-
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-07
> 
> David,
> 
> 
> >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.
> 
> <Shraddha> The -08 version contains reference to RFC 4593 and RFC 6863 which
> discuss in-detail on different security vulnerabilities and OSPF
> authentication mechanisms described in RFC 2328,5340 , 7474 and 7166 are sited
> as solution to the problem.
> I think this description would also cover the issue you have brought up. Let
> me know if you are OK with this.
> 
> Rgds
> Shraddha
> 
> 
> -----Original Message-----
> From: Black, David [mailto:[e-mail]]
> Sent: Saturday, October 10, 2015 2:14 AM
> To: Shraddha Hegde <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; General Area Review Team
> ([e-mail]) <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; Black, David
> <[e-mail]>
> Subject: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-07
> 
> 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 done.
> 
> 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.
> 
> Thanks,
> --David
> 
> 
> > -----Original Message-----
> > From: Black, David
> > Sent: Monday, October 05, 2015 7:35 PM
> > To: [e-mail]; [e-mail]; [e-mail];
> > [e-mail]; [e-mail]; General Area Review
> > Team ([e-mail]) ops- [e-mail]
> > Cc: [e-mail]; [e-mail]; Black, David; [e-mail]
> > 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
> > [phone]             FAX: [phone]
> > [e-mail]        Mobile: [phone]
> > ----------------------------------------------------
> >