Subject: [secdir] secdir review of draft-ietf-ospf-node-admin-tag-05

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 9 Oct 2015 16:52:05 -0400 (EDT)

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>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 10 Oct 2015 19:34:21 +0000

Hi Ben, 

As the document shepherd and a long-time OSPF contributor, I’m going to
try and sort out some of your comments. Note that route tagging has been
in use for decades and this document is merely extending the
administrative policies advertisement to the node level.

>updating this one could just remove that restriction.

The intent here is that this TLV is to be solely for locally defined
policies. If there were to be a TLV for well-known tags and policies, this
could be accomplished with a separate OSPF RI TLV. I agree that the
normative text should be softened from “MUST NOT” to “are not expected
to”. 

>the protocol description itself do give some areas for consideration.

The document could reference RFC 4593/RFC 6863 and state that
authentication as specified in RFC 7474 or RFC 7166 SHOULD be used in
deployments where attackers have access to the physical networks included
in the OSPF domain are vulnerable.

>malicious action -- what should they do?

I’m not an author, but this is what I’d recommend:

   The conflicting tag SHOULD not be used and this situation SHOULD be
logged as an error including the tag with conflicting scopes and the
originator(s). 

There is a case that must be allowed - the same tag could be received by
an ABR at both the AS scope and the area scope in a stub or NSSA area.

>tag, or something else?

Yes - this is standard for any OSPF LSA. However, since the OSPF RI LSA
may include other TLVs or even other tags, a tag could also be withdrawn
by reoriginating the RI LSA without the TLV or with a TLV that doesn’t
include the withdrawn tag.

> How disruptive would that be?  It would be

I may of worked on OSPF for too long but this should be obvious to anyone
implementing the draft from the specification.

>seems particularly disingenous given the presence of the null

I think both RFC 7474 and RFC 7176 should be referenced. The OSPF
vulnerability to replay attacks to OSPFv2/OSPFv3 routers implementing
these specifications is extremely small and has been reduced as much as
practical. If you are still concerned, I suggest you discuss with Sam
Hartman (also once affiliated with MIT).

>this would cause drastic damage to the routing topology.

The description and mitigation of such a generic threat doesn’t belong in
a minor (though important) OSPF specification. The effect of blocking
control traffic is never positive ;^). At least OSPF uses reliable
flooding so it will be retransmitted.

>capabilities.  Would the document suffer harm if the parenthetical was

In my opinion, no harm to remove - misconfiguration is almost always an
issue. 

>border. 
> Perhaps the other damage from a router misconfigured in such a

Again, I don’t think misconfiguration needs to be covered - "emptor
cavete”. 

Thanks for the editorial review as well. Speak as WG chair, I appreciate
this. 

Thanks,
Acee

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 13 Oct 2015 18:27:25 -0400 (EDT)

Thanks, Shraddha and Acee, for helping me find some of the context I was
missing.

On Sun, 11 Oct 2015, Shraddha Hegde wrote:

>
> Thanks Ben for detailed review comments.Thanks Acee for chiming-in.
> Few more explanations in-line.
>
> -----Original Message-----
> From: Acee Lindem (acee) [mailto:[email-masked]]
> Sent: Sunday, October 11, 2015 1:04 AM
> To: Benjamin Kaduk <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: secdir review of draft-ietf-ospf-node-admin-tag-05
>
> Hi Ben,
>

Good to know; I didn't get to look at many updates past the core OSPFv2
spec.

> >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.
> >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.
>
> policies. If there were to be a TLV for well-known tags and policies,
> this could be accomplished with a separate OSPF RI TLV. I agree that the
> <Shraddha> There was a long discussion on the mailing list on whether we
> should allow well defined values for the admin tags majority consensus
> was that we should not allow any standard values for node admin tags and
> in future if such a requirement arises it'll go as new feature in RI TLV
> as Acee already mentioned. I am trying to understand why the text need
> to be softened when any future standardization would need altogether a
> new document and will not require any changes to this document.

I suggested that the text be softened because the current statement does
not have any practical effect.  It's trying to place restrictions on what
{the set of future RFCs that update this document} can do, but any
document in that set could remove such a restriction and override it at
the same time.

I think it would be good to have a note in section 2 to the effect that
"these administrative tags are solely for use within an administrative
domain and are their interpretation is a matter of local policy.  It is
expected that values will not be portable across administrative domains".
I know that this topic is covered later in the document, but having it
early would help set the stage for the rest of the document.

> >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
> >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.
>
> deployments where attackers have access to the physical networks
> included in the OSPF domain are vulnerable.
> <Shraddha> ok. Updating the Security consideration section

Thanks.

> >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?
>
> <Shraddha> Updated the document with above statement.
>
> <Shraddha> Could you pls elaborate the case. I don't quite understand
> why the ABR in a stub/NSSA area would generate or receive RI LSAs with
> different scopes.I think it's perfectly valid to flood the AS scoped RI
> LSAs into the stub / NSSA area.

Acee, I think this is a question for you.

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

I may still be confused, but I did not interpret the text in that way.
That is, the text about "all instances of the RI LSA originated by that
node".  (Which I changed to "instances of RI LSAs" in my grammar edits,
possibly incorrectly if I'm still confused.)  I was interpreting the word
"instances" to include historical ones over time, so that even if an RI
LSA carrying a particular admin tag was replaced by a different RI LSA
for the same advertising router, the old one would still be an instance of
that RI LSA.  Going back to RFC 2328, I'm not sure what exactly I had in
mind in terms of ages and scopes and sequence numbers that would cause
this
situation, but I somehow had it in my mind that there could be multiple RI
LSAs active at the same time that apply to a given node, such as if the
admin just added a new RI LSA containing only the admin tag to augment the
existing RI LSAs being sent.  Is that possible?

If there can only be one RI LSA that is "current" for a given node (at a
given scope?), then it seems like it would be useful to change the text to
explicitly say "all current instances" -- that would have helped me as I
read it.

> > How disruptive would that be?  It would be helpful to see some
> >discussion of how a tag would be removed.
>
> I may of worked on OSPF for too long but this should be obvious to
> anyone implementing the draft from the specification.

If it's simply a matter of re-issuing the RI LSA (I was not sure when I
was writing my review), then I agree it should be obvious.

> <Shraddha> The below paragraph (from -07 version) is clear on this I hope.
>
> "When there is a change or removal of an administrative affiliation of a node,
>    the node MUST re-originate the RI LSA with the latest set of node administrative tags.
>    On the receiver, 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."

This is definitely improved, but it does not do much to address the issue
I had in mind when I was writing my review.  However, it seems like that
issue is not actually an issue, so no further changes to this text would
be needed.

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

I am not especially concerned about this attack, I just noticed that there
was an RFC about it.  Since RFC 7474 was so recent, it made me wonder how
widely deployed the security fixes are today.

> <Shraddha> Security consideration section updated with the reference to
> RFC 7474 and 7176.

Thanks.

> >
> >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 description and mitigation of such a generic threat doesn’t belong in a minor (though important) OSPF specification. The effect of blocking control traffic is never positive ;^). At least OSPF uses reliable flooding so it will be retransmitted.
> <Shraddha> Agree with Acee on this.

I had forgotten that OSPF flooding was reliable; I agree this does not
need to be explicitly called out in this document, since it's a general
routing concern.

> >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?
>
> In my opinion, no harm to remove - misconfiguration is almost always an issue.
> <Shraddha> It's perfectly valid for a node originate a tag when the node
> itself does not Process any tags. I think the sentence needs to be
> rephrased. Changing it as below.
>
> <t>Meaning of the Node administrative tags is generally
> opaque to OSPF. Router advertising the per-node
> without knowing (or even without supporting processing of)
> functionality implied by the tag.</t>

I think there is a question about whether this means that the router
doesn't need to know what feature the tag number means, or whether it
means that the router doesn't need to implement the feature indicated by
that tag value.  I read this text as being in the second case, but I am
interpreting your discussion about this text to mean that you think it is
covering the first case.  (Yes, there can be tag values that just indicate
an administrative grouping and there is no corresponding functionality
needed on the router, but there can also be tag values that indicate "the
router originating this RI LSA supports accepting targeted LDP sessions"
-- a router will cause breakage if it sends such a tag but does not
actually support accepting targeted LDP sessions.)

Based on this discussion, I think that what the parenthetical is trying to
say is that "the router originating the tag may not use that tag in any of
its processing decisions" -- is that correct?

Changing the word "functionality" to "attributes" would cause me to read
the text as being in the first case I described above.

(By the way, this paragraph had a lot of changes in my patch for grammar;
it might have been easier to apply that patch before making further edits,
to reduce the number of merge conflicts.  The grammar in the quoted new
text has several errors.)

> >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.
>
> Again, I don’t think misconfiguration needs to be covered - "emptor cavete”.

A misconfigured router is by definition broken.  Such misconfiguration can
happen either by accident due to operator error, or maliciously, if an
attacker has compromised the system.  While it may not be necessary to say
that a broken router will not pass traffic the way it's supposed to, if a
misconfigured router can emit routing protocol messages that affect the
state of the network as a whole, not just its local surroundings, that
seems like an analysis that is appropriate for the security considerations
of a routing protocol document.  Now, I don't have a good picture of
specific examples of network-wide issues due to the admin tag, but I think
there's a large enough probability that it's possible for such a thing to
happen that I wanted to mention it in my review comments.  Maybe there is
not anything worth mentioning about it in the security considerations
section, but I don't think that "misconfiguration doesn't need to be
covered" addresses the concern I was attempting to raise.

> <Shraddha> -07 version addresses this issue.
>
> "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."

Thank you, that helps.

> Thanks for the editorial review as well. Speak as WG chair, I appreciate this.

You're welcome!

-Ben

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 13 Oct 2015 22:46:55 +0000

See inline. 

On 10/13/15, 6:27 PM, "Benjamin Kaduk" <[email-masked]> wrote:

>> To: Benjamin Kaduk <[email-masked]>; [email-masked]; [email-masked];
>>[email-masked]
>> >and other purposes".  That is a hard middle line to follow, and I am
>>not sure that this document does so successfully.

Yeah - I missed this without E-mail quoting…

Shraddha, 

AS-scoped LSAs are not flooded into stub or NSSA areas. So, if an ABR is
going to advertise tags to its attached areas and the rest of the OSPF
Routing domain, it will need to originate the LSA at different scopes.

>existing RI LSAs being sent.  Is that possible?

In OSPF, a more-recent version or instance of an LSA will always supersede
all previous instances of the same LSA.

>explicitly say "all current instances" -- that would have helped me as I

I see the confusion is between instances of the same LSA in the general
sense and multiple instances of the OSPF RI LSA. Refer to RFC 2328 section
13.1.  

>widely deployed the security fixes are today.

Correct - it is not widely implemented or deployed.

Thanks,
Acee

>> The description and mitigation of such a generic threat doesn’t belong
>>in a minor (though important) OSPF specification. The effect of blocking

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 13 Oct 2015 18:57:50 -0400 (EDT)

> all previous instances of the same LSA.

Thanks for clarifying.  So, this is a non-issue, and the only question is
whether the text could/should be changed to improve clarity.

-Ben

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 13 Oct 2015 23:02:16 +0000

>whether the text could/should be changed to improve clarity.

Let me think about this since it is a generic OSPF RI ambiguity and it
will affect multiple documents. In a WebEx right now though…

Thanks,
Acee

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 13 Oct 2015 22:30:36 -0400 (EDT)

On Tue, 13 Oct 2015, [email-masked] wrote:

> Thanks for the careful review.
>
> My mistake. I missed the left part of the network.
>
> I see 2 options:
>
> a) add some network topology on the left part
>
> b) remove the leftmost pair of A nodes.

Option 'a' sounds good to me.

-Ben

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 14 Oct 2015 12:03:19 +0000

Hi Shraddha, 

On 10/14/15, 12:35 AM, "Shraddha Hegde" <[email-masked]> wrote:

>Acee,
>
><---snipped to open points--->
>
>
>--------------------------------------------------------------------------
>------------------------------------------------------------------------
>
>>> why the ABR in a stub/NSSA area would generate or receive RI LSAs
>>> with different scopes.I think it's perfectly valid to flood the AS
>>> scoped RI LSAs into the stub / NSSA area.
>>
><Shraddha> Acee,  I think restricting  AS scoped RI LSA into NSSA /stub
>areas will have many issues.
>                                      If a non-ABR router from other area
>originates RI LSA with node tag and the specific application needs the
>                                      Tag to be available in the entire
>OPF domain, how will the stub/NSSA area routers receive it?
>                                      I think this discussion is equally
>relevant to 4970bis.
>                                       I don't see a reason why AS scoped
>RI LSA should be restricted in stub/NSSA.
>                                        RI LSAs do not contain any route
>information so it's not going to be huge in number.

By definition, AS-scoped LSAs are NOT flooded into a stub or NSSA area.
Please read stub and NSSA area references in RFC 2328, RFC 5340, RFC 5250,
and RFC 3101. You’ll note that stub and NSSA area have no visibility to
topology or Router IDs of OSPF routers in other areas.

Hope this helps, 
Acee 

>Sent: Wednesday, October 14, 2015 4:17 AM
>To: Benjamin Kaduk <[email-masked]>; Shraddha Hegde <[email-masked]>
>Cc: [email-masked]; [email-masked];
>>Thanks, Shraddha and Acee, for helping me find some of the context I
>>was missing.
>>
>>> As the document shepherd and a long-time OSPF contributor, I’m going
>>> to try and sort out some of your comments. Note that route tagging
>>> has been in use for decades and this document is merely extending 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.
>>> >
>>> >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
>>> >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.
>>> >
>>> >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.
>>>
>>> this could be accomplished with a separate OSPF RI TLV. I agree that
>>> the normative text should be softened from “MUST NOT” to “are not
>>> expected to”.
>>>
>>> <Shraddha> There was a long discussion on the mailing list on whether
>>> we should allow well defined values for the admin tags majority
>>> consensus was that we should not allow any standard values for node
>>> admin tags and in future if such a requirement arises it'll go as new
>>> feature in RI TLV as Acee already mentioned. I am trying to
>>> understand why the text need to be softened when any future
>>> standardization would need altogether a new document and will not
>>>require any changes to this document.
>>
>>I suggested that the text be softened because the current statement
>>does not have any practical effect.  It's trying to place restrictions
>>on what {the set of future RFCs that update this document} can do, but
>>any document in that set could remove such a restriction and override
>>it at the same time.
>>
>>> >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).
>>> >
>>> >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.
>>>
>>> >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?
>>>
>>>    The conflicting tag SHOULD not be used and this situation SHOULD
>>> be logged as an error including the tag with conflicting scopes and
>>> the originator(s).
>>> There is a case that must be allowed - the same tag could be received
>>> by an ABR at both the AS scope and the area scope in a stub or NSSA
>>>area.
>>> why the ABR in a stub/NSSA area would generate or receive RI LSAs
>>> with different scopes.I think it's perfectly valid to flood the AS
>>> scoped RI LSAs into the stub / NSSA area.
>>
>>> >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?
>>>
>>> Yes - this is standard for any OSPF LSA. However, since the OSPF RI
>>> LSA may include other TLVs or even other tags, a tag could also be
>>> withdrawn by reoriginating the RI LSA without the TLV or with a TLV
>>> that doesn’t include the withdrawn tag.
>>
>>possibly incorrectly if I'm still confused.)  I was interpreting the
>>word "instances" to include historical ones over time, so that even if
>>an RI LSA carrying a particular admin tag was replaced by a different
>>RI LSA for the same advertising router, the old one would still be an
>>instance of that RI LSA.  Going back to RFC 2328, I'm not sure what
>>exactly I had in mind in terms of ages and scopes and sequence numbers
>>that would cause this situation, but I somehow had it in my mind that
>>there could be multiple RI LSAs active at the same time that apply to a
>>given node, such as if the admin just added a new RI LSA containing
>>only the admin tag to augment the existing RI LSAs being sent.  Is that
>>possible?
>
>In OSPF, a more-recent version or instance of an LSA will always
>supersede all previous instances of the same LSA.
>
>>
>>If there can only be one RI LSA that is "current" for a given node (at
>>a given scope?), then it seems like it would be useful to change the
>>text to explicitly say "all current instances" -- that would have
>>helped me as I read it.
>
>sense and multiple instances of the OSPF RI LSA. Refer to RFC 2328
>section 13.1.  
>
>
>>
>>This is definitely improved, but it does not do much to address the
>>issue I had in mind when I was writing my review.  However, it seems
>>like that issue is not actually an issue, so no further changes to this
>>text would be needed.
>>
>>
>>> >
>>> >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
>>> >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"
>>> these specifications is extremely small and has been reduced as much
>>> as practical. If you are still concerned, I suggest you discuss with
>>> Sam Hartman (also once affiliated with MIT).
>>
>>I am not especially concerned about this attack, I just noticed that
>>there was an RFC about it.  Since RFC 7474 was so recent, it made me
>>wonder how widely deployed the security fixes are today.
>
>>> <Shraddha> Security consideration section updated with the reference
>>> to RFC 7474 and 7176.
>>
>>Thanks.
>>
>>> >
>>> >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 description and mitigation of such a generic threat doesn’t
>>>belong in a minor (though important) OSPF specification. The effect of
>>>blocking control traffic is never positive ;^). At least OSPF uses
>>>reliable flooding so it will be retransmitted.
>>> >dangerous, since it sounds like the routers in question are lying
>>> >about their capabilities.  Would the document suffer harm if the
>>> <Shraddha> It's perfectly valid for a node originate a tag when the
>>>node  itself does not Process any tags. I think the sentence needs to
>>>be  rephrased. Changing it as below.
>>>
>>> <t>Meaning of the Node administrative tags is generally opaque to
>>> OSPF. Router advertising the per-node administrative tag (or tags)
>>> may be configured to do so without knowing (or even without
>>> supporting processing of) functionality implied by the tag.</t>
>>
>>means that the router doesn't need to implement the feature indicated
>>by that tag value.  I read this text as being in the second case, but I
>>am interpreting your discussion about this text to mean that you think
>>it is covering the first case.  (Yes, there can be tag values that just
>>indicate an administrative grouping and there is no corresponding
>>functionality needed on the router, but there can also be tag values
>>that indicate "the router originating this RI LSA supports accepting
>>targeted LDP sessions"
>>Based on this discussion, I think that what the parenthetical is trying
>>to say is that "the router originating the tag may not use that tag in
>>any of its processing decisions" -- is that correct?
>>
>>Changing the word "functionality" to "attributes" would cause me to
>>read the text as being in the first case I described above.
>>
>>(By the way, this paragraph had a lot of changes in my patch for
>>grammar; it might have been easier to apply that patch before making
>>further edits, to reduce the number of merge conflicts.  The grammar in
>>the quoted new text has several errors.)
>>
>>> >border router might erroneously use tag values from one domain on
>>> >the other side of the border.
>>> >fashion would dwarf the additional damage from the misinterpreted
>>> >tags and so my concern is invalid; I really can't say.
>>>
>>A misconfigured router is by definition broken.  Such misconfiguration
>>can happen either by accident due to operator error, or maliciously, if
>>an attacker has compromised the system.  While it may not be necessary
>>to say that a broken router will not pass traffic the way it's supposed
>>to, if a misconfigured router can emit routing protocol messages that
>>affect the state of the network as a whole, not just its local
>>surroundings, that seems like an analysis that is appropriate for the
>>security considerations of a routing protocol document.  Now, I don't
>>have a good picture of specific examples of network-wide issues due to
>>the admin tag, but I think there's a large enough probability that it's
>>possible for such a thing to happen that I wanted to mention it in my
>>review comments.  Maybe there is not anything worth mentioning about it
>>in the security considerations section, but I don't think that
>>"misconfiguration doesn't need to be covered" addresses the concern I
>>was attempting to raise.
>>
>>>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."
>>
>>Thank you, that helps.
>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 14 Oct 2015 12:11:00 +0000

Hi Ben, 

On 10/13/15, 7:02 PM, "Acee Lindem (acee)" <[email-masked]> wrote:

>>>LSA
>>>word

The key point here is that an OSPF router only maintains the most-recent
instance of an LSA in its Link-State Database. So, there shouldn’t be any
ambiguity. Perhaps, the text could be changed to “all RI LSA instances in
the Link-State Database (LSDB) advertised by the corresponding OSPF
router.” 

Thanks,
Acee

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Oct 2015 20:55:54 -0400 (EDT)

On Wed, 14 Oct 2015, Shraddha Hegde wrote:

>
> I completely missed looking at editorial comments and the diff in
> previous mail. Sorry about that.
>
> Have taken your changes in the latest version and diff (-06 to -08)
> attached. Pls take a look.

The new version seems improved; I'll skip line-by-line discussion of the
grammar changes since the IESG teleconference call is fast approaching.

The diagram for the TLV format in Figure 1 still has a 15-bit type and
17-bit length; both should be 16 bits.

> Editorial comments:
> <Shraddha.>Updated. Pls refer diff.
> >
> <Shraddha> I could not get this comment. Could you pls elaborate?

This is related to Alvaro's DISCUSS.  Basically, there is conflict between
saying that the interpretation of tag values is entirely local, and
imposing restirctions on how the tags should be interpreted.  It is
helpful to the reader to discuss why the document does not pick one
extreme of completely-local interpretation and a fully specified protocol
that dictates the meaning of all tags.  Instead, the document picks
something in-between, with tag interpretation mostly a matter of local
policy, but some restrictions on their use.  Describing why this choice
was made early in the text gives the reader a better picture of what the
goals of the protocol are, to better understand the details of the
protocol itself.

> <shraddha>Below is the latest text. SHOULD is changed to MUST
>
> " Each tag MUST be treated as an independent
> identifier that MAY be used in policy to perform a policy
> action. Each tag carried by the administrative tag TLV SHOULD be used to
> indicate a characteristic of a node that is independent of the
> characteristics indicated by other administrative tags.
> The administrative tag list within the TLV MUST be considered
> an unordered list. Whilst policies may be implemented based on the
> presence of multiple tags (e.g., if tag A AND tag B are present),
> they MUST NOT be reliant upon the order of the tags (i.e.,
> all policies should be considered commutative operations, such that
> tag A preceding or following tag B does not change their outcome)."

This seems okay in a quick read, but again, the resolution of Alvaro's
DISCUSS will be relevant to this text.

> <Shraddha>Changed to text below.
>
> "Being part of the RI LSA, the per-node administrative tag
> but not limited to, implementations supporting per-node
> administrative tags MUST NOT be used to convey attributes of the
> routing topology or associate tags with
> the OSPF domain) or reachability of routes."

That's an improvement, thanks.  ("but not limited to" is still bad
grammar, but the best fix is not immediately obvious.)

> <Shraddha> hope this issue is resolved in other mail thread.

I think so, yes.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Oct 2015 20:58:11 -0400 (EDT)

> the Link-State Database (LSDB) advertised by the corresponding OSPF

That seems like a useful improvement; thanks.

-Ben

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 15 Oct 2015 09:14:45 +0000

It looks good too me other than there is space missing.

s/router.When/router. When/

Thanks,
Acee

On 10/15/15, 12:05 AM, "Shraddha Hegde" <[email-masked]> wrote:

>Acee/Ben,
>
>Updated the text as below.
>
>   multiple node administrative tag TLVs MAY be contained in different
>   instances of the RI LSA.  The node administrative tags associated
>   with a node that originates tags for the purpose of any computation or
>processing at a receiving node
>   SHOULD be a superset of node administrative tags from all the TLVs in
>all the
>   received RI LSA instances in the Link-State Database (LSDB) advertised
>by the 
>   corresponding OSPF router.When an RI LSA is received that changes the
>set of 
>   tags applicable to any originating node, a receiving node MUST repeat
>any computation or
>	processing that is based on those administrative tags.
></t>
>
>
>Rgds
>Shraddha
>
>From: Benjamin Kaduk [mailto:[email-masked]]
>Sent: Thursday, October 15, 2015 6:28 AM
>To: Acee Lindem (acee) <[email-masked]>
>Cc: Shraddha Hegde <[email-masked]>; [email-masked];
>[email-masked]; [email-masked]
>> >>Thanks for clarifying.  So, this is a non-issue, and the only
>> >>question is whether the text could/should be changed to improve
>>clarity.
>> >
>> >Let me think about this since it is a generic OSPF RI ambiguity and
>> >it will affect multiple documents. In a WebEx right now though…
>>
>> The key point here is that an OSPF router only maintains the
>> most-recent instance of an LSA in its Link-State Database. So, there
>> shouldn’t be any ambiguity. Perhaps, the text could be changed to “all
>> RI LSA instances in the Link-State Database (LSDB) advertised by the
>> corresponding OSPF router.”
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 15 Oct 2015 09:17:04 +0000

Sounds good. 
Thanks, 
Acee 

On 10/15/15, 1:00 AM, "Shraddha Hegde" <[email-masked]> wrote:

>Acee,
>
>Although RFC 2328/5340 do not explicitly talk about type 11  LSAs, RFC
>5250 
>Restricts type 11 into stub/NSSAs. Adding the blow text to the draft.
>
>"An ABR in a stub or NSSA area MAY originate AS scoped RI LSAs and flood
>them into non-stub/NSSA areas and MAY originate area scoped RI LSAs into
>the stub/NSSA areas as the AS scoped LSAs
>are not flooded into stub/NSSA areas."
>
>Rgds
>Shraddha
>
>Sent: Wednesday, October 14, 2015 5:33 PM
>To: Shraddha Hegde <[email-masked]>; Benjamin Kaduk <[email-masked]>
>>>> <Shraddha> Could you pls elaborate the case. I don't quite
>>>> understand why the ABR in a stub/NSSA area would generate or receive
>>>> RI LSAs with different scopes.I think it's perfectly valid to flood
>>>> the AS scoped RI LSAs into the stub / NSSA area.
>>>
>>AS-scoped LSAs are not flooded into stub or NSSA areas. So, if an ABR
>>is going to advertise tags to its attached areas and the rest of the
>>OSPF Routing domain, it will need to originate the LSA at different
>>scopes.
>>
>>                                      If a non-ABR router from other
>>area originates RI LSA with node tag and the specific application needs
>>the
>>                                      I think this discussion is
>>equally relevant to 4970bis.
>>                                       I don't see a reason why AS
>>scoped RI LSA should be restricted in stub/NSSA.
>>                                        RI LSAs do not contain any
>>route information so it's not going to be huge in number.
>
>Please read stub and NSSA area references in RFC 2328, RFC 5340, RFC
>5250, and RFC 3101. You’ll note that stub and NSSA area have no
>visibility to topology or Router IDs of OSPF routers in other areas.
>
>Hope this helps,
>Acee 
>
>
>
>
>>                 
>>                 
>>
>>
>>
>>
>>

---

From: Shraddha Hegde <[email-masked]>
Date: Sun, 11 Oct 2015 13:07:28 +0000

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Sunday, October 11, 2015 1:04 AM
To: Benjamin Kaduk <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: secdir review of draft-ietf-ospf-node-admin-tag-05

Hi Ben, 

As the document shepherd and a long-time OSPF contributor, I’m going to try and sort out some of your comments. Note that route tagging has been in use for decades and this document is merely extending the administrative policies advertisement to the node level.

>unenforcable, as a future RFC updating this one could just remove that restriction.

The intent here is that this TLV is to be solely for locally defined policies. If there were to be a TLV for well-known tags and policies, this could be accomplished with a separate OSPF RI TLV. I agree that the normative text should be softened from “MUST NOT” to “are not expected to”. 

<Shraddha> There was a long discussion on the mailing list on whether we should allow well defined values for the admin tags majority consensus was that we should not allow any standard values for node admin tags and in future if such a requirement arises it'll go as new feature in RI TLV as Acee already mentioned. I am trying to understand why the text need to be softened when any future standardization would need altogether a new document and will not require any changes to this document.
>analysis, but the examples and the protocol description itself do give some areas for consideration.

The document could reference RFC 4593/RFC 6863 and state that authentication as specified in RFC 7474 or RFC 7166 SHOULD be used in deployments where attackers have access to the physical networks included in the OSPF domain are vulnerable.
<Shraddha> ok. Updating the Security consideration section

   The conflicting tag SHOULD not be used and this situation SHOULD be logged as an error including the tag with conflicting scopes and the originator(s). 
<Shraddha> Updated the document with above statement.

There is a case that must be allowed - the same tag could be received by an ABR at both the AS scope and the area scope in a stub or NSSA area.
<Shraddha> Could you pls elaborate the case. I don't quite understand why the ABR in a stub/NSSA area would generate or receive RI LSAs with different scopes.I think it's perfectly valid to flood the AS scoped RI LSAs into the stub / NSSA area.

>(easily) be unset.  Would force-expiring an LSA be enough to reset the 

Yes - this is standard for any OSPF LSA. However, since the OSPF RI LSA may include other TLVs or even other tags, a tag could also be withdrawn by reoriginating the RI LSA without the TLV or with a TLV that doesn’t include the withdrawn tag.

>discussion of how a tag would be removed.

I may of worked on OSPF for too long but this should be obvious to anyone implementing the draft from the specification.
<Shraddha> The below paragraph (from -07 version) is clear on this I hope.

>seems particularly disingenous given the presence of the null 

I think both RFC 7474 and RFC 7176 should be referenced. The OSPF vulnerability to replay attacks to OSPFv2/OSPFv3 routers implementing these specifications is extremely small and has been reduced as much as practical. If you are still concerned, I suggest you discuss with Sam Hartman (also once affiliated with MIT).
<Shraddha> Security consideration section updated with the reference to RFC 7474 and 7176.

In my opinion, no harm to remove - misconfiguration is almost always an issue. 
<Shraddha> It's perfectly valid for a node originate a tag when the node itself does not
Process any tags. I think the sentence needs to be rephrased. Changing it as below.

Thanks,
Acee 

>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
>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".
>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.)
>
>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.
>
>applications; please use some XML markup to preserve the list structure 
>in the rendered document.
>
>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.
>
>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 
>I am also attaching a diff to the xml sources with some grammar fixes 
>not worth enumerating explicitly.
>
>-Ben Kaduk

---

From: <[email-masked]>
Date: Tue, 13 Oct 2015 14:12:36 +0000

Hi Ben,

I see 2 options:

Option "b" makes the asci art easier to read, but remove some of the complexity of the network hence some part of the use case.

Option "a" would make something like that:

     +----------------------+   +----------------+

     |                       \ /                 |

     |   +-----------------+  x   +---------+    |

     |   |                  \/  \/          |    |

     |   |                +-T-10-T          |    |

     |   |               /  |   /|          |    |

     |   |              /  100 / |          |    |

     |   |             /    | | 100         |    |

     |   |            /   +-+-+  |          |    |

     |   |           /   /  |    |          |    |

     |   |          /   /   R-18-R          |    |

     |   |        10   10  /\   /\          |    |

     |   |        /   /   /  \ /  \         |    |

     |   |       /   /   /    x    \        |    |

     |   |      /   /   10  10 \    \       |    |

     |   |     /   /   /    /   10   10     |    |

     |   |    /   /   /    /     \    \     |    |

     |   |   A-25-A  A-25-A       A-25-A    |    |

     |   |   |    |   \    \     /    /     |    |

     |   |   |    |   201  201  201 201     |    |

     |   |   |    |     \    \ /    /       |    |

     |   |  201  201     \    x    /        |    |

     |   |   |    |       \  / \  /         |    |

     |   |   |    |        \/   \/          |    |

    |   |   I-24-I        I-24-I          100  100

     |   |  /    /         |    |           |    |

     |   +-+    /          |    +-----------+    |

     +---------+           +---------------------+

Ben, Shraddha, what would be your preference?

(Personally I'm biased as I know the network topology so any asci art seems readable to me)

Thanks,

-- Bruno

> From: Benjamin Kaduk [mailto:[email-masked]] > Sent: Friday, October 09, 2015 10:52 PM

> -Ben Kaduk

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 14 Oct 2015 04:35:15 +0000

Acee,

--------------------------------------------------------------------------------------------------------------------------------------------------

Shraddha, 

AS-scoped LSAs are not flooded into stub or NSSA areas. So, if an ABR is going to advertise tags to its attached areas and the rest of the OSPF Routing domain, it will need to originate the LSA at different scopes.

<Shraddha> Acee,  I think restricting  AS scoped RI LSA into NSSA /stub areas will have many issues.
                                      If a non-ABR router from other area originates RI LSA with node tag and the specific application needs the 
                                      Tag to be available in the entire OPF domain, how will the stub/NSSA area routers receive it?
                                      I think this discussion is equally relevant to 4970bis.
                                       I don't see a reason why AS scoped RI LSA should be restricted in stub/NSSA.
                                        RI LSAs do not contain any route information so it's not going to be huge in number.

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Wednesday, October 14, 2015 4:17 AM
To: Benjamin Kaduk <[email-masked]>; Shraddha Hegde <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: secdir review of draft-ietf-ospf-node-admin-tag-05

See inline. 

On 10/13/15, 6:27 PM, "Benjamin Kaduk" <[email-masked]> wrote:

>> standardization would need altogether a new document and will not require any changes to this document.
>
>> >whether due to network glitch or malicious action -- what should they do?
>>
>> by an ABR at both the AS scope and the area scope in a stub or NSSA area.

Shraddha, 

AS-scoped LSAs are not flooded into stub or NSSA areas. So, if an ABR is going to advertise tags to its attached areas and the rest of the OSPF Routing domain, it will need to originate the LSA at different scopes.

>only the admin tag to augment the existing RI LSAs being sent.  Is that 

In OSPF, a more-recent version or instance of an LSA will always supersede all previous instances of the same LSA.

>text to explicitly say "all current instances" -- that would have 

I see the confusion is between instances of the same LSA in the general sense and multiple instances of the OSPF RI LSA. Refer to RFC 2328 section 13.1.  

>> >considerations for OSPF authentication", but maybe it is worth mentioning some things:
>> >the

Thanks,
Acee

>> >scenarios where this would cause drastic damage to the routing topology.
>>
>that indicate "the router originating this RI LSA supports accepting targeted LDP sessions"
>"misconfiguration doesn't need to be covered" addresses the concern I was attempting to raise.
>

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 14 Oct 2015 07:23:35 +0000

Ben,

Thanks again for the follow-up.
Pls see below.

<... snipped to open comments...>

> feature in RI TLV as Acee already mentioned. I am trying to understand 
> why the text need to be softened when any future standardization would 
> need altogether a new document and will not require any changes to this document.

I suggested that the text be softened because the current statement does not have any practical effect.  It's trying to place restrictions on what {the set of future RFCs that update this document} can do, but any document in that set could remove such a restriction and override it at the same time.

I think it would be good to have a note in section 2 to the effect that "these administrative tags are solely for use within an administrative domain and are their interpretation is a matter of local policy.  It is expected that values will not be portable across administrative domains".
I know that this topic is covered later in the document, but having it early would help set the stage for the rest of the document.

<Shraddha> OK. Get your point. Updated and diff attached.

-------------------------------------------------------------------------------------------------------------------------------

I completely missed looking at editorial comments and the diff in previous mail. Sorry about that.

Have taken your changes in the latest version and diff (-06 to -08) attached. Pls take a look.

> abbreviated version in parentheses afterwards.
<Shraddha> Done.

> applications; please use some XML markup to preserve the list structure in
<Shraddha> Done
> selection at its first appearance.

<Shraddha> Done
> and is not really needed.

<Shraddha> done

> leftmost pair of A nodes.

<Shraddha> Lets close this point in the mail thread with Bruno.
> worth enumerating explicitly.
<Shraddha> Thank you. Have applied diff in latest -08 version

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]] 
Sent: Wednesday, October 14, 2015 3:57 AM
To: Shraddha Hegde <[email-masked]>
Cc: Acee Lindem (acee) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: secdir review of draft-ietf-ospf-node-admin-tag-05

Thanks, Shraddha and Acee, for helping me find some of the context I was missing.

On Sun, 11 Oct 2015, Shraddha Hegde wrote:

> to try and sort out some of your comments. Note that route tagging has 
> been in use for decades and this document is merely extending the 

Good to know; I didn't get to look at many updates past the core OSPFv2 spec.

> >then gives four pages of example usage, all the while claiming that 
> >the actual tag values are only meaningful within a single 
> >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.
> >few things that are missing before this document should be published, 
> >and that it might be worth considering a more drastic restructuring as well.
> >
> feature in RI TLV as Acee already mentioned. I am trying to understand 
> why the text need to be softened when any future standardization would 
> need altogether a new document and will not require any changes to this document.

I suggested that the text be softened because the current statement does not have any practical effect.  It's trying to place restrictions on what {the set of future RFCs that update this document} can do, but any document in that set could remove such a restriction and override it at the same time.

I think it would be good to have a note in section 2 to the effect that "these administrative tags are solely for use within an administrative domain and are their interpretation is a matter of local policy.  It is expected that values will not be portable across administrative domains".
I know that this topic is covered later in the document, but having it early would help set the stage for the rest of the document.

Thanks.

> >but a receiver would need to take some action if it happened, whether 
> >due to network glitch or malicious action -- what should they do?
>
> different scopes.I think it's perfectly valid to flood the AS scoped 
> RI LSAs into the stub / NSSA area.

I may still be confused, but I did not interpret the text in that way.
That is, the text about "all instances of the RI LSA originated by that node".  (Which I changed to "instances of RI LSAs" in my grammar edits, possibly incorrectly if I'm still confused.)  I was interpreting the word "instances" to include historical ones over time, so that even if an RI LSA carrying a particular admin tag was replaced by a different RI LSA for the same advertising router, the old one would still be an instance of that RI LSA.  Going back to RFC 2328, I'm not sure what exactly I had in mind in terms of ages and scopes and sequence numbers that would cause this situation, but I somehow had it in my mind that there could be multiple RI LSAs active at the same time that apply to a given node, such as if the admin just added a new RI LSA containing only the admin tag to augment the existing RI LSAs being sent.  Is that possible?

If there can only be one RI LSA that is "current" for a given node (at a given scope?), then it seems like it would be useful to change the text to explicitly say "all current instances" -- that would have helped me as I read it.

> anyone implementing the draft from the specification.

If it's simply a matter of re-issuing the RI LSA (I was not sure when I was writing my review), then I agree it should be obvious.

>    administrative tags and is outside of scope of this specification."

This is definitely improved, but it does not do much to address the issue I had in mind when I was writing my review.  However, it seems like that issue is not actually an issue, so no further changes to this text would be needed.

> >pointer to such considerations.  (The stance of RFC 2328 that "all OSPF protocol exchanges are authenticated"

I am not especially concerned about this attack, I just noticed that there was an RFC about it.  Since RFC 7474 was so recent, it made me wonder how widely deployed the security fixes are today.

Thanks.

> <Shraddha> Agree with Acee on this.

I had forgotten that OSPF flooding was reliable; I agree this does not need to be explicitly called out in this document, since it's a general routing concern.

> OSPF. Router advertising the per-node administrative tag (or tags) may 
> be configured to do so without knowing (or even without supporting 
> processing of) functionality implied by the tag.</t>

I think there is a question about whether this means that the router doesn't need to know what feature the tag number means, or whether it means that the router doesn't need to implement the feature indicated by that tag value.  I read this text as being in the second case, but I am interpreting your discussion about this text to mean that you think it is covering the first case.  (Yes, there can be tag values that just indicate an administrative grouping and there is no corresponding functionality needed on the router, but there can also be tag values that indicate "the router originating this RI LSA supports accepting targeted LDP sessions"
-- a router will cause breakage if it sends such a tag but does not actually support accepting targeted LDP sessions.)

Based on this discussion, I think that what the parenthetical is trying to say is that "the router originating the tag may not use that tag in any of its processing decisions" -- is that correct?

Changing the word "functionality" to "attributes" would cause me to read the text as being in the first case I described above.

(By the way, this paragraph had a lot of changes in my patch for grammar; it might have been easier to apply that patch before making further edits, to reduce the number of merge conflicts.  The grammar in the quoted new text has several errors.)

> Again, I don’t think misconfiguration needs to be covered - "emptor cavete”.

A misconfigured router is by definition broken.  Such misconfiguration can happen either by accident due to operator error, or maliciously, if an attacker has compromised the system.  While it may not be necessary to say that a broken router will not pass traffic the way it's supposed to, if a misconfigured router can emit routing protocol messages that affect the state of the network as a whole, not just its local surroundings, that seems like an analysis that is appropriate for the security considerations of a routing protocol document.  Now, I don't have a good picture of specific examples of network-wide issues due to the admin tag, but I think there's a large enough probability that it's possible for such a thing to happen that I wanted to mention it in my review comments.  Maybe there is not anything worth mentioning about it in the security considerations section, but I don't think that "misconfiguration doesn't need to be covered" addresses the concern I was attempting to raise.

Thank you, that helps.

You're welcome!

-Ben

---

From: <[email-masked]>
Date: Wed, 14 Oct 2015 07:34:11 +0000

Ben, Shraddha,

> From: Benjamin Kaduk [mailto:[email-masked]] > Sent: Wednesday, October 14, 2015 4:31 AM
> 

ok.

Shraddha, please find enclosed the updated "artwork".
My xml file is out of sync. You should only copy the figure   <figure anchor="Explicit_routing_topology" title="Explicit Routing topology">
 
-- Bruno

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 14 Oct 2015 09:25:52 +0000

Thanks Bruno.
Attaching the latest diff.

Rgds
Shraddha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, October 14, 2015 1:04 PM
To: Benjamin Kaduk <[email-masked]>; Shraddha Hegde <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: secdir review of draft-ietf-ospf-node-admin-tag-05

Ben, Shraddha,

ok.

-- Bruno

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 15 Oct 2015 04:05:46 +0000

Acee/Ben,

<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 that originates tags for the purpose of any computation or processing at a receiving node
   SHOULD be a superset of node administrative tags from all the TLVs in all the
   received RI LSA instances in the Link-State Database (LSDB) advertised by the 
   corresponding OSPF router.When an RI LSA is received that changes the set of 
   tags applicable to any originating node, a receiving node MUST repeat any computation or
	processing that is based on those administrative tags.
</t>

Rgds
Shraddha

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]] 
Sent: Thursday, October 15, 2015 6:28 AM
To: Acee Lindem (acee) <[email-masked]>
Cc: Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: secdir review of draft-ietf-ospf-node-admin-tag-05

On Wed, 14 Oct 2015, Acee Lindem (acee) wrote:

> >>question is whether the text could/should be changed to improve clarity.
> >

-Ben

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 15 Oct 2015 04:35:26 +0000

Ben,

<... snip to open comments....>
The diagram for the TLV format in Figure 1 still has a 15-bit type and 17-bit length; both should be 16 bits.

<Shraddha> done

> <Shraddha> I could not get this comment. Could you pls elaborate?

This is related to Alvaro's DISCUSS.  Basically, there is conflict between saying that the interpretation of tag values is entirely local, and imposing restirctions on how the tags should be interpreted.  It is helpful to the reader to discuss why the document does not pick one extreme of completely-local interpretation and a fully specified protocol that dictates the meaning of all tags.  Instead, the document picks something in-between, with tag interpretation mostly a matter of local policy, but some restrictions on their use.  Describing why this choice was made early in the text gives the reader a better picture of what the goals of the protocol are, to better understand the details of the protocol itself.

<Shraddha> Although , the actual values of node admin tags do not need to be standardized and is left to the operator's discretion to allocate values and assign meanings to it, It's necessary to layout certain rules/regulations and guidelines on how the tags can be used and how
they cannot be used. That will help in getting interoperable implementations from vendors and avoid surprises in the field.
For ex:  We have a statement administrative tag order has no meaning. If this document does not specify such a statement, there is every possibility some implementation will have policies that will look at the order in which the tags are encoded. Some other implementation which does not care about the order of the tag might keep changing it at every LSA refresh so it's hard to get them to interoperate.

Added below text in section 3.2.1
" This section describes general rules/ regulations 
and guidelines for using and interpreting an administrative tag which will
 facilitate interoperable implementations by vendors."

Rgds
Shraddha

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]] 
Sent: Thursday, October 15, 2015 6:26 AM
To: Shraddha Hegde <[email-masked]>
Cc: Acee Lindem (acee) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: secdir review of draft-ietf-ospf-node-admin-tag-05

> attached. Pls take a look.

The new version seems improved; I'll skip line-by-line discussion of the grammar changes since the IESG teleconference call is fast approaching.

The diagram for the TLV format in Figure 1 still has a 15-bit type and 17-bit length; both should be 16 bits.

<Shraddha> done

> <Shraddha> I could not get this comment. Could you pls elaborate?

This is related to Alvaro's DISCUSS.  Basically, there is conflict between saying that the interpretation of tag values is entirely local, and imposing restirctions on how the tags should be interpreted.  It is helpful to the reader to discuss why the document does not pick one extreme of completely-local interpretation and a fully specified protocol that dictates the meaning of all tags.  Instead, the document picks something in-between, with tag interpretation mostly a matter of local policy, but some restrictions on their use.  Describing why this choice was made early in the text gives the reader a better picture of what the goals of the protocol are, to better understand the details of the protocol itself.

<Shraddha> Although , the actual values of node admin tags do not need to be standardized and is left to the operator's discretion to allocate values and assign meanings to it, It's necessary to layout certain rules/regulations and guidelines on how the tags can be used and how
they cannot be used. That will help in getting interoperable implementations from vendors and avoid surprises in the field.

Added below text in section 3.2.1
" This section describes general rules/ regulations 
and guidelines for using and interpreting an administrative tag which will
 facilitate interoperable implementations by vendors."

> > 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".
> " Each tag MUST be treated as an independent identifier that MAY be 
> used in policy to perform a policy action. Each tag carried by the 
> administrative tag TLV SHOULD be used to indicate a characteristic of 
> a node that is independent of the characteristics indicated by other 
> administrative tags.
> The administrative tag list within the TLV MUST be considered an 
> unordered list. Whilst policies may be implemented based on the 
> presence of multiple tags (e.g., if tag A AND tag B are present), they 
> MUST NOT be reliant upon the order of the tags (i.e., all policies 
> should be considered commutative operations, such that tag A preceding 
> or following tag B does not change their outcome)."

This seems okay in a quick read, but again, the resolution of Alvaro's DISCUSS will be relevant to this text.

> "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 per-node administrative tags MUST NOT be 
> used to convey attributes of the routing topology or associate tags 
> with changes in the network topology (both within and outside the OSPF 
> domain) or reachability of routes."

That's an improvement, thanks.  ("but not limited to" is still bad grammar, but the best fix is not immediately obvious.)

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

I think so, yes.

-Ben

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 15 Oct 2015 05:00:08 +0000

Acee,

Although RFC 2328/5340 do not explicitly talk about type 11  LSAs, RFC 5250 
Restricts type 11 into stub/NSSAs. Adding the blow text to the draft.

"An ABR in a stub or NSSA area MAY originate AS scoped RI LSAs and flood 
them into non-stub/NSSA areas and MAY originate area scoped RI LSAs into the stub/NSSA areas as the AS scoped LSAs
are not flooded into stub/NSSA areas."

Rgds
Shraddha

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Wednesday, October 14, 2015 5:33 PM
To: Shraddha Hegde <[email-masked]>; Benjamin Kaduk <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: secdir review of draft-ietf-ospf-node-admin-tag-05

Hi Shraddha, 

On 10/14/15, 12:35 AM, "Shraddha Hegde" <[email-masked]> wrote:

>OSPF Routing domain, it will need to originate the LSA at different scopes.
>
>area originates RI LSA with node tag and the specific application needs the

By definition, AS-scoped LSAs are NOT flooded into a stub or NSSA area.
Please read stub and NSSA area references in RFC 2328, RFC 5340, RFC 5250, and RFC 3101. You’ll note that stub and NSSA area have no visibility to topology or Router IDs of OSPF routers in other areas.

Hope this helps,
Acee