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

Benjamin Kaduk <kaduk@MIT.EDU> Fri, 09 October 2015 20:52 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id BE42A1ACCE7; Fri, 9 Oct 2015 13:52:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.611
X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BkOSGEHtY83Y; Fri, 9 Oct 2015 13:52:11 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu []) by ietfa.amsl.com (Postfix) with ESMTP id 119901ACCE9; Fri, 9 Oct 2015 13:52:10 -0700 (PDT)
X-AuditID: 12074422-f79976d0000078ca-93-561828f92c7f
Received: from mailhub-auth-3.mit.edu ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 91.97.30922.9F828165; Fri, 9 Oct 2015 16:52:10 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu []) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t99Kq9eG008621; Fri, 9 Oct 2015 16:52:09 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t99Kq6We030323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Oct 2015 16:52:08 -0400
Received: (from kaduk@localhost) by multics.mit.edu ( id t99Kq5mW023676; Fri, 9 Oct 2015 16:52:05 -0400 (EDT)
Date: Fri, 9 Oct 2015 16:52:05 -0400 (EDT)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ospf-node-admin-tag.all@ietf.org
Message-ID: <alpine.GSO.1.10.1510091159450.26829@multics.mit.edu>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-449483132-1444423925=:26829"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixCmqrftLQyLMYOVtVovfr7awW8z4M5HZ 4sPChywOzB5LlvxkCmCM4rJJSc3JLEst0rdL4MrY3/SVueDAZ8aKtrPlDYxv7jN2MXJwSAiY SLS/8+9i5AQyxSQu3FvP1sXIxSEksJhJ4vqS7UwQzgZGiT/tp1khnINMEl+n72cHaRESqJdY ufcwE4jNIqAl0XTrFFicTUBFYuabjWwgtohAhMTCA+vA4sIC1hI/lhwGs3kFHCU6391kBrFF BXQkVu+fwgIRF5Q4OfMJC8h1zAIBEuunqExg5JuFJDMLIQMSZgZavHz6NqhwtMSp8xIQYUWJ zQd2s0LYjhI32juZIGxRiRU35jBClIdI7Dksv4CRYxWjbEpulW5uYmZOcWqybnFyYl5eapGu qV5uZoleakrpJkZQqLO7KO1g/HlQ6RCjAAejEg/vhBjxMCHWxLLiytxDjJIcTEqivLcVJMKE +JLyUyozEosz4otKc1KLDzGqAK16tGH1BUYplrz8vFQlEd6Y50CtvCmJlVWpRfkwZdIcLEri vJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeI2AsS4kWJSanlqRlplTgpBm4uA8xCjBwQM0nA2k hre4IDG3ODMdIn+KUVFKnPe6OlBCACSRUZoH1wtOUbuZVF8xigO9Jcx7CqSKB5je4LpfAQ1m Ahqcwy8GMrgkESEl1cA4f5Zd6GHhWjP9J0LB7VWt9dwTFI5/MPC54yZpcM9vdsUjrZ17Cq3D K8KYhL7/PHRI98rWPwenvdz6+USzt2AG75tXqmdWy9qLNXKpFS/men72ndfKTkvDcsmWNvEl q4+E1vAUuOhO2NA7e9q7b+6LuRhv/Cv8te7AxXsZSk9OVez/+nANe4yZEktxRqKhFnNRcSIA JtspGiwDAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/6ZhlpKFUSoK5877xO7Cj75mwLmI>
Subject: [secdir] secdir review of draft-ietf-ospf-node-admin-tag-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2015 20:52:16 -0000

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

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

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