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

[Shraddha Hegde <[e-mail]>]

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