I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I will preface these comments with a note that my routing background is quite weak, and I needed to read RFC 2328 and RFC 4970 to have enough context to be able to say much useful about what's going on here; I may still be suffering from some misconceptions. On the whole, this document leaves me feeling unsatisfied; it spends maybe three pages talking about the actual new protocol extension and then gives four pages of example usage, all the while claiming that the actual tag values are only meaningful within a single administrative domain/network, are for generic use, and do not require an IANA registry. That is, it is trying to walk a middle line between "this document allocates a value in the OSPF TLVs registry for site-local use, use it as you will" and "this document specifies a complete protocol extension for tagging OSPF nodes for traffic engineering, LFA, and other purposes". That is a hard middle line to follow, and I am not sure that this document does so successfully. I will not try to reopen the question of whether it would be better to take one of the non-middle paths, and continue on the assumption that this document will take the middle path. I think there are a few things that are missing before this document should be published, and that it might be worth considering a more drastic restructuring as well. It would probably be good to include some text with the reasoning behind the choice of the "middle line" -- the current text attempting to enforce it, "new OSPF extensions MUST NOT require use of per-node administrative tags or define well-known tag values", seems unenforcable, as a future RFC updating this one could just remove that restriction. It looks like there's now an -06, but the changes from the -05 are not significant. The security considerations in the -05 correctly note what are essentially privacy considerations regarding the contents of the admin tags. However, it seems like there are also potential security considerations on the actual operation of the network that are not discussed here, nor in RFC 2328 (OSPFv2) or RFC 5340 (OSPFv3). RFC 5340's security considerations explicitly disclaims protections against compromised, malfunctioning, or misconfigured routers, deferring to RFC 4593, "Generic Threats to Routing Protocols". I believe that the security considerations of this document should address, either directly or indirectly, protections against compromised, malfunctioning, or misconfigured routers, and additionally protection against malicious actors with access to the layer-3 network (and maybe lower layers as well). That probably means mentioning RFC 4593 directly, or maybe just pointing out that RFC 5340 does so. There are still additional considerations introduced by this document, though; unfortunately, because the bulk of the interpretation of the admin tags is left to the site administrator, it is hard to give a comprehensive security analysis, but the examples and the protocol description itself do give some areas for consideration. The RI LSAs carrying administrative tags can be at link-, area-, or AS-level scope; an administrator assigning tag values and associated policies should consider what would happen if a given tag was advertised at a different scope than intended. Compliant implementations MUST NOT generate the same tag at different scopes, but a receiver would need to take some action if it happened, whether due to network glitch or malicious action -- what should they do? Another potential issue lies in the "stickiness" of the admin tags -- the text "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" seems to mean that once a tag is set, it cannot (easily) be unset. Would force-expiring an LSA be enough to reset the tag, or something else? How disruptive would that be? It would be helpful to see some discussion of how a tag would be removed. That is particularly easy for an attacker when the null OSPF authentication mechanism is in use (how common is that? I saw some websites indicating it was the default behavior, at least sometimes). I do not see a need to turn this document into "security considerations for OSPF authentication", but maybe it is worth mentioning some things: the md5 scheme seems pretty week at this point (though probably not trivially broken), the hmac-sha scheme of RFC 5709 is only from 2009, and RFC 7474 (only six months old) points out cases where both are susceptible to replay attacks. Just looking at the security considerations of this document and the core OSPF v2/v3 specs does not convey this to the reader, so I would like to see at least a pointer to such considerations. (The stance of RFC 2328 that "all OSPF protocol exchanges are authenticated" seems particularly disingenous given the presence of the null authentication scheme.) There is also the possibility that an attacker could block delivery of an LSA, causing a tag that should be set to not be seen. This seems unlikely for wired point-to-point links, but is more plausible in other environments, such as radio links. I think I can imagine scenarios where this would cause drastic damage to the routing topology. The parenthetical in section 3.2 wherein routers might advertise a per-node aministrative tag "without knowing (or even explicitly supporting) functionality implied by the tag" seems potentially dangerous, since it sounds like the routers in question are lying about their capabilities. Would the document suffer harm if the parenthetical was removed? One reason I am unsatisfied by making the interpretation of the tag values specific to an administrative domain is that a misconfigured border router might erroneously use tag values from one domain on the other side of the border. Perhaps the other damage from a router misconfigured in such a fashion would dwarf the additional damage from the misinterpreted tags and so my concern is invalid; I really can't say. I also have some editorial comments unrelated to the secdir review: Section 3.2 reads rather like a jumbled list and could benefit from some additional structure. Similarly, I would find it helpful if there was some text motivating the "middle patch" mentioned above, towards the beginning of the technical (non-example) portion of the document. For a construction as weakly structured as these administrative tags, preventing any internal structure or dependencies between tags (as this document attempts to do) seems correct. However, this sentiment seems to be expressed differently in several different places in the document, and it would be good to consolidate and coordinate them. In particular, paragraph 3 of section 3.2 explicitly says that tag order has no meaning, but paragraph 4 has the weaker "SHOULD be considered an unordered list". (The word "set" might be appropriate here.) Paragraph 7 of section 3.2 seems to be trying to say that the administrative tags must indicate inherent or administratively configured properties of a node and must not be used to convey attributes of the routing topology. (The word "tie" seems insufficiently clear.) Many (but not all) of the acronyms/abbreviations should be expanded at first use -- the ones marked with a '*' at https://www.rfc-editor.org/materials/abbrev.expansion.txt are assumed to be common knowledge and do not need expansion. Other things, like traffic engineering, router information, link statement advertisement, autonomous system, etc., should be written out in full at their first use, with the abbreviated version in parentheses afterwards. The first paragraph of section 1 contains a list of potential applications; please use some XML markup to preserve the list structure in the rendered document. Plase give an informative reference for Loop Free Alternate backup selection at its first appearance. The divider between the type and length fields in Figure 1 is placed one bit to the left of the correct division for two 16-bit fields. (In many cases the position indicators above the diagram are offset by one space so they land over the '-'s instead of the '+'s, but there is some argument for putting them in their current location, as well.) In the seventh paragraph of section 3.2, I think it would be fine to just remove the "but not limited to" clause, which is not quite correct grammar and is not really needed. The last paragraph of section 3.2 could probably be written more clearly. In particular, "in any instance of the RI-LSA" is not entirely clear to me (but then again, I don't really understand how LSAs normally work). Is it enough to just say that implementations MUST detect when the administrative tags associated with a given node change, and update their state accordingly? In section 4.5, I do not see that the constraint "Traffic from A nodes to I nodes must not go through R and T nodes" can be satisfied for the leftmost pair of A nodes. I am also attaching a diff to the xml sources with some grammar fixes not worth enumerating explicitly. -Ben Kaduk --- draft-ietf-ospf-node-admin-tag-06.xml.orig 2015-10-09 15:14:43.000000000 -0500 +++ draft-ietf-ospf-node-admin-tag-06.xml 2015-10-09 15:45:02.000000000 -0500 @@ -93,17 +93,17 @@ traffic engineering -This document describes an extension to OSPF protocol to +This document describes an extension to the OSPF protocol to add an optional operational capability, that allows tagging and grouping of -the nodes in an OSPF domain. This allows simplification, ease of management and +the nodes in an OSPF domain. This allows simplification, ease of management, and control over route and path selection based on configured policies. -This document describes an extension to OSPF protocol to advertise per-node +This document describes an extension to the OSPF protocol to advertise per-node administrative tags. The node-tags can be used to express and apply locally-defined network policies which is a very useful operational capability. Node tags may be used either by OSPF itself or by other applications consuming information propagated via OSPF. This document describes the protocol extensions to disseminate -per-node administrative-tags to the OSPFv2 and OSPFv3 protocol. It provides example +per-node administrative tags to the OSPFv2 and OSPFv3 protocols. It provides example use cases of administrative node tags. @@ -118,7 +118,7 @@ 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. The per-node administrative tag can be used in -variety of applications, for ex: +variety of applications, for example: - Traffic-engineering applications to provide different path-selection criteria, - Prefer or prune certain paths in Loop Free Alternate (LFA) backup selection via local policies. @@ -136,12 +136,12 @@ used to identify a group of nodes in the OSPF domain. The new TLV defined will be carried within an RI LSA for OSPFV2 and -OSPFV3. Router information LSA can have link, area or AS level -flooding scope. Choosing the flooding scope to flood the group -tags are defined by the policies and is a local matter. +OSPFV3. Router information LSA can have link-, area- or AS-level +flooding scope. The choice of what scope at which to flood the group tags is +a matter of local policy. The TLV specifies one or more administrative tag values. An OSPF -node advertises the set of groups it is part of in the OSPF domain. +node advertises the set of groups it is part of in the OSPF domain (for example, all PE-nodes are configured with certain tag value, all P-nodes are configured with a different tag value in the domain). Multiple TLVs MAY be added in same RI-LSA or @@ -151,12 +151,12 @@
- , defines Router Information (RI) LSA which may be used to -advertise properties of the originating router. Payload of the RI LSA consists of one or + , defines the Router Information (RI) LSA which may be used to +advertise properties of the originating router. The payload of the RI LSA consists of one or more nested Type/Length/Value (TLV) triplets. Node administrative tags are advertised in the Node Administrative Tag TLV. -The format of Node Administrative Tag TLV is: +The format of the Node Administrative Tag TLV is:
@@ -184,17 +184,17 @@ portion in octets and will be a multiple of 4 octets dependent on the number of tags advertised. -Value: A sequence of multiple 4 octets defining the +Value: A sequence of multiple four-octet values defining the administrative tags. At least one tag MUST be carried if this TLV is included in the RI-LSA.
-Meaning of the Node administrative tags is generally -opaque to OSPF. Router advertising the per-node +The meaning of the Node administrative tags is generally +opaque to OSPF. Routers advertising the per-node administrative tag (or tags) may be configured to do so without knowing (or even explicitly supporting) -functionality implied by the tag. +the functionality implied by the tag. Interpretation of tag values is specific to the administrative domain of a particular network operator. The meaning of a per-node administrative tag is defined by the network local policy and is controlled via the configuration. If a receiving node does not @@ -222,17 +222,17 @@ Router (ABR) may advertise the same tag in area-scope RI LSAs in multiple areas connected to the ABR. The per-node administrative tags are not meant to be -extended by the future OSPF standards. The new OSPF +extended by future OSPF standards. New OSPF extensions MUST NOT require use of per-node administrative tags or define well-known tag values. Node administrative tags are for generic use and do not require IANA registry. -The future OSPF extensions requiring well known values MAY +Future OSPF extensions requiring well known values MAY define their own data signalling tailored to the needs of the -feature or MAY use capability TLV as defined in +feature or MAY use the capability TLV as defined in . Being part of the RI LSA, the per-node administrative tag TLV must be reasonably small and stable. In particular, -but not limited to, implementations supporting the per-node +but not limited to, implementations supporting per-node administrative tags MUST NOT tie advertised tags to changes in the network topology (both within and outside the OSPF domain) or reachability of routes. @@ -240,20 +240,20 @@ 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. +node administrative tags from all the TLVs in all instances of RI LSAs originated by that node. 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 +TLV in any instance of an RI-LSA, implementations MUST take appropriate measures to update their state according to the +changed set of tags. The exact actions needed depend on features working with administrative tags and is outside of scope of this specification.
This section lists several examples of how implementations -might use the Node administrative tags. These examples are -given only to demonstrate generic usefulness of the router -tagging mechanism. Implementation supporting this -specification is not required to implement any of the use +might use the per-node administrative tags. These examples are +given only to demonstrate the generic usefulness of the router +tagging mechanism. Implementations supporting this +specification are not required to implement any of these use cases. It is also worth noting that in some described use cases routers configured to advertise tags help other routers in their calculations but do not themselves implement the @@ -261,12 +261,12 @@
-Router tagging may be used to automatically discover +Router tagging may be used to automatically discover a group of routers sharing a particular service. -For example, service provider might desire to establish -full mesh of MPLS TE tunnels between all PE routers in -the area of MPLS VPN network. Marking all PE routers with +For example, a service provider might desire to establish +a full mesh of MPLS TE tunnels between all PE routers in +the area of the MPLS VPN network. Marking all PE routers with a tag and configuring devices with a policy to create MPLS TE tunnels to all other devices advertising this tag will automate maintenance of the full mesh. When new PE @@ -286,13 +286,13 @@ concerns. One of the proposed refinements is to be able to group -the nodes in IGP domain with administrative tags and +the nodes in an IGP domain with administrative tags and engineer the LFA based on configured policies. Administrative limitation of LFA scope Service provider access infrastructure is frequently -designed in layered approach with each layer of +designed in a layered approach with each layer of devices serving different purposes and thus having different hardware capabilities and configured software features. When LFA repair paths are being @@ -305,7 +305,7 @@ be desirable for a Distribution device to compute LFA only via Distribution or Core devices but not via Access devices. This may be due to features enabled -on Access routers; due to capacity limitations or due +on Access routers, due to capacity limitations or due to the security requirements. Managing such a policy via configuration of the router computing LFA is cumbersome and error prone. @@ -314,20 +314,20 @@ assign a tag to each layer and implement LFA policy of computing LFA repair paths only via neighbors which advertise the Core or Distribution tag. This -requires minimal per-node configuration and network +requires minimal per-node configuration and the network automatically adapts when new links or routers are added. LFA calculation optimization Calculation of LFA paths may require significant -resources of the router. One execution of Dijkstra +resources of the router. One execution of Dijkstra's algorithm is required for each neighbor eligible to -become next hop of repair paths. Thus a router with a +become the next hop of repair paths. Thus, a router with a few hundreds of neighbors may need to execute the algorithm hundreds of times before the best (or even valid) repair path is found. Manually excluding from -the calculation neighbors which are known to provide +the calculation neighbors that are known to provide no valid LFA (such as single-connected routers) may significantly reduce number of Dijkstra algorithm runs. @@ -345,22 +345,22 @@ defined a method of tunnelling traffic after connected link failure -to extend the basic LFA coverage and algorithm to find +to extend the basic LFA coverage and an algorithm to find tunnel tail-end routers fitting LFA requirement. In most -cases proposed algorithm finds more than one candidate -tail-end router. In real life network it may be desirable +cases the proposed algorithm finds more than one candidate +tail-end router. In real-life networks it may be desirable to exclude some nodes from the list of candidates based on the local policy. This may be either due to known -limitations of the node (the router does not accept targeted +limitations of the node (the router does not accept the targeted LDP sessions required to implement Remote LFA tunnelling) or due to administrative requirements (for example, it -may be desirable to choose tail-end router among +may be desirable to choose the tail-end router among co-located devices). -The Node administrative tag delivers simple and scalable +The Node administrative tag delivers a simple and scalable solution. Remote LFA can be configured with a policy to accept during the tail-end router calculation as -candidates only routers advertising certain tag. Tagging +candidates only routers advertising a certain tag. Tagging routers allows to both exclude nodes not capable of serving as Remote LFA tunnel tail-ends and to define a region from which tail-end router must be selected. @@ -369,8 +369,8 @@
-The topology of mobile back-haul network usually adopts ring topology -to save fibre resource and it is divided into the aggregate network and +Mobile back-haul networks usually adopt a ring topology +to save fibre resources; it is usually divided into the aggregate network and the access network. Cell Site Gateways(CSGs) connects the eNodeBs and RNC(Radio Network Controller) Site Gateways(RSGs) connects the RNCs. The mobile traffic is transported from CSGs to RSGs. The network takes @@ -408,7 +408,7 @@ A typical mobile back-haul network with access rings and aggregate links is shown in figure above. The mobile back-haul networks deploy -traffic engineering due to the strict Service Level Agreements(SLA). +traffic engineering due to strict Service Level Agreements(SLA). The TE paths may have additional constraints to avoid passing via different access rings or to get completely disjoint backup TE paths. The mobile back-haul networks towards the access side change frequently due to the growing mobile @@ -422,9 +422,9 @@
-Partially meshed network provides multiple paths between any two nodes in the network. +A partially meshed network provides multiple paths between any two nodes in the network. In a data centre environment, the topology is usually highly symmetric with many/all -paths having equal cost. In a long distance network, this is usually less the case for +paths having equal cost. In a long distance network, this is usually less the case, for a variety of reasons (e.g. historic, fibre availability constraints, different distances between transit nodes, different roles ...). Hence between a given source and destination, a path is typically preferred over the others, while between the same source and another @@ -520,4 +520,4 @@ - \ No newline at end of file +