Telechat Review of draft-ietf-ospf-node-admin-tag-04
review-ietf-ospf-node-admin-tag-04-secdir-telechat-kaduk-2015-10-15-00

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 @@
 <keyword>traffic engineering</keyword>

 <abstract>

 <t>

-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. </t>

 <t>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.</t>

 </abstract>

 <note title="Requirements Language">

@@ -118,7 +118,7 @@
 <t>

 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.</t>

@@ -136,12 +136,12 @@
 used to identify a group of nodes in the OSPF domain.

 <vspace blankLines="1" />

 The new TLV defined will be carried within an RI LSA for OSPFV2 and

-OSPFV3. Router information LSA <xref target="RFC4970"/> 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 <xref target="RFC4970"/> 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.

 <vspace blankLines="1" />

 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 @@
 </section>

 <section title='OSPF per-node administrative tag TLV'>

 <section title='TLV format'>

-<t> <xref target="RFC4970"/>, 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

+<t> <xref target="RFC4970"/>, 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:

 <vspace blankLines="2" />

 <figure anchor="OSPF-Admin-tag-TLV" title="OSPF per-node Administrative Tag
 TLV">

@@ -184,17 +184,17 @@
 portion in octets and will be a multiple of 4 octets

 dependent on the number of tags advertised.

 <vspace blankLines="1" />

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

 </t>

 </section>

 <section title='Elements of procedure'>

-<t>Meaning of the Node administrative tags is generally

-opaque to OSPF. Router advertising the per-node

+<t>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.</t>

+the functionality implied by the tag.</t>

 <t>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.</t>

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

 <xref target="RFC4970"/>. </t>

 <t>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.</t>

@@ -240,20 +240,20 @@
 <t> 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.</t>

+node administrative tags from all the TLVs in all instances of RI LSAs
originated by that node.</t>

 <t>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.

 </t>

 </section>

 </section>

 <section title='Applications'>

 <t>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 @@
 <section title='Service auto-discovery'>

 <t>

 <vspace blankLines="1"/>

-Router tagging may be used to automatically discover

+Router tagging may be used to automatically discover a

 group of routers sharing a particular service.

 <vspace blankLines="1"/>

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

 <vspace blankLines="1"/>

 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.

 <list style="format (%c)" hangIndent="4">

 <t>Administrative limitation of LFA scope

 <vspace blankLines="1"/>

 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.

 </t>

 <t>LFA calculation optimization

 <vspace blankLines="1"/>

 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 @@
 <vspace blankLines="1"/>

 <xref target="RFC7490"/> 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).

 <vspace blankLines="1"/>

-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 @@
 <section title='Mobile back-haul network service deployment'>

 <t>

 <vspace blankLines="1"/>

-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 @@
 <vspace blankLines="1"/>

 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 @@
 <section title='Explicit routing policy'>

 <t>

 <vspace blankLines="1"/>

-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 @@
 <?rfc include="reference.I-D.ietf-rtgwg-lfa-manageability"?>

 </references>

 </back>

-</rfc>
\ No newline at end of file
+</rfc>