Telechat Review of draft-ietf-teas-lsp-diversity-08
review-ietf-teas-lsp-diversity-08-secdir-telechat-kaduk-2017-08-29-00

Hi all,

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.

In summary, I think this document is ready with nits (largely editorial).

The main point of the document is to allow for source nodes to request
path diversity in new LSPs being created, in the case where the source
node does not have full knowledge of the relevant topology.  (The case
where the source node does have such knowledge is already handled via
eXclude Route Objects and Explicit Exclusion Route Subobjects.)  My
understanding is that the main reason to request such path diversity
is to introduce redundancy and improve the system functionality in
the case of (localized) outages, but this does not really seem to
be emphasized in the Introduction -- maybe it should?

Path diversity is effected by the use of a "reference path" that already
exists between a source and destination, and requesting that the new
path is diverse with respect to that reference path.  Similarly to the
above, it may be helpful to explictly introduce the notion of a reference
path instead of introducing it implicitly, in passing.

The security considerations largely refer to/include by reference RFCs
5920, 2205, 3209, 3473, and 4874, though not all of these are listed
as normative references.  (I'm not sure whether there is a convention
for such cases.)  Of those, RFC 3473 also refers to RFC 2747, and there
may (or may not) be value in flattening the chain of references by explicitly
mentioning RFC 2747 here as well.  To a large extent, those references
do seem to cover the relevant security considerations for this document,
as there is little that is conceptually new in this document.  The final
paragraph of the security considerations calls out an exception to
the rule from RFC 4874 that XRO could/should be removed from the Path
message to avoid leaking internal information, because the diversity
subobject needs to be preserved in order to perform its function.  One could
potentially claim that even the diversity subobject is leaking some information
about the internal network in some cases, but since the "leaked" information
is essentially an opaque identifier, the usual case would generally be
that it is worth the minor leak in order to obtain path diversity, as
this document states.

Whenever new identifiers are issued, the corresponding privacy considerations
should also be considered.  Given that the role of a core network is
probably (?) considered to be just transit, I am not very concerned
about path identifiers leaking information (or correlations) about what
physical path a given set of data traverses.

I suppose one could consider potential security/privacy issues inherent
in path diversity as well, which seems mostly limited to the case where
only a subset of nodes/links are compromised in some fashion (monitored
or subject to traffic injection).  In that case, someone knowing that
a reference path is not subject to attack could try to create a new
(diverse) path in an attempt to have the new path traverse the compromised
equipment.  But that seems quite far-fetched as an attack, especially
in the context of the RFC 5920 model where the core is considered to
be equally/globally trusted.

I'm also possibly confused at the requirements introduced in section 2.3
(page 19) for the node performing path computation to take action when
a previously unknown (excluded) path becomes known, or when LSPs (?)
change so that a requested exclusion is no longer satisfied.  This seems
to require that the PCE store all XRO subobjects along with the path
state, so as to be able to do this processing upon (all!) LSP changes.
Is the extra storage and/or computation likely to be a significant burden
on the PCE that might lead to resource-exhaustion and denial of service?

There is also some minor risk in section 1.3 (page 8) where PAS assignment
and distribution is left as out of scope for this document -- certain
assignment schemes could leak information or allow outside parties to guess
"new" values that would be treated as valid by the core network.  But it's
hard to see this leading to a concrete attack, especially when the PAS
number space is only 32 bits wide.


I'll mention a few of the more significant editorial issues here, and
defer the really nitty-gritty stuff to a later message with narrower
scope, in the interest of expediency (as this document is scheduled
for this week's telechat).

It may be worth double-checking that acronyms not listed as "well-known"
at https://www.rfc-editor.org/materials/abbrev.expansion.txt are expanded
at first use; UNI-N and RRO are a couple that I noticed while reviewing.

In the abstract:

   [...] Three different
   mechanisms are supported how LSP diversity can be accomplished in
   the provider or core network: the signaled diversity type, indicates
   whether diversity is based on client, path computation engine (PCE),
   or network assigned identifiers.

am I correct to infer that "indicates whether diversity is based on client"
is supposed to clarify what "signaled diversity type" means, so that
the rest of the sentence is a three-element list corresponding to the
three diversity identifiers introduced by this document?  If so, it's
probably better to put it inside parentheses than offset by commas,
or even to reword it entirely to just be something like "a client-initiated
method".

The next sentence could also be made smoother, something about assuming
that LSPs are created at a slow rate and exist for a long time, so that it
is reasonable to assume that a given (reference) path currently existing,
with a well-known identifier, will continue to exist and can be used
as a reference when creating the new path.

At the top of page 4, "exemplified" should probably be something like
"illustrated" (this particular diagram is not really the epitome of
path exclusion).

In page 4, a "single-homed UNI" is referred to.  My understanding was that
the UNI was akin to an edge in the topology graph, and that "single-homed"
would more commonly apply to an EN (but maybe my understanding is incorrect).

Page 5, first complete paragraph, does "across the UNI boundary" just
mean in the CN to EN direction?

At the end of section 1 (just before section 1.1), the listing
"client-initiated, allocated by the (core) network or managed by a PCE"
should probably have the last two swapped, to match the ordering used
in the rest of the document.

At the bottom of page 5 (last line), should "LSP IS = L1" be
"LSP ID = L2" (S-->D and 1-->2)?  Also, the previous line has
"LSP-IDENTIFIER12" which probably is meant to just be the '2'.

Page 8, third paragraph, "included for exclusion" is a little awkward
of a phrasing; "[i]f a PAS identifier is used as an exclusion identifier"
might be better.

Page 11 just lists the three diversity identifier types created by
this document; should there be consideration of (text for) how to
allocate additional types in the future?

The string "IPv4/ IPv6" appears many times in the text; I believe it's
more conventionally written without the space, as "IPv4/IPv6".

Crossing from page 16 to page 16, "sends [...] request from ingress node to
egress node including diversity constraints to a PCE" is potentially
confusing about what is being sent where, since it's the request for
a path [from ingress node to egress node] that is sent to the PCE.  So,
"path computation request for a path from ingress node to egress node"
might be better, or even reordering things more drastically.

The last two sentences of the Security Considerations are a little hard
to read; I might reword them, potentially as:

However, when the diversity subobjects specified in this document are used,
removing at the administrative boundary an XRO containing these diversity
subobjects would result in the request for diversity being dropped at
the boundary, and path computation would be unlikely to produce the requested
divers path.  As such, diversity subobjects MUST be retained in an XRO
crossing an administrative boundary, even if other subobjects are removed.

-Ben