> 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:[email protected]] > Sent: Sunday, October 11, 2015 9:08 AM > To: Black, David; [email protected]; [email protected]; [email protected]; > [email protected]; General Area Review Team ([email protected]); ops- > [email protected] > Cc: [email protected]; [email protected]; [email protected] > 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:[email protected]] > Sent: Saturday, October 10, 2015 2:14 AM > To: Shraddha Hegde <[email protected]>; [email protected]; [email protected]; > [email protected]; [email protected]; General Area Review Team > ([email protected]) <[email protected]>; [email protected] > Cc: [email protected]; [email protected]; [email protected]; Black, David > <[email protected]> > 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: [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; General Area Review > > Team ([email protected]); ops- [email protected] > > Cc: [email protected]; [email protected]; Black, David; [email protected] > > 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 > > [email protected] Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
