[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [18.7.68.34]) 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 ( [18.9.21.43]) (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 [18.9.28.11]) 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 [18.187.2.37]) (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 (8.12.9.20060308) id t99Kq5mW023676; Fri, 9 Oct 2015 16:52:05 -0400 (EDT)
Date: Fri, 09 Oct 2015 16:52:05 -0400
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 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
- [secdir] secdir review of draft-ietf-ospf-node-ad… Benjamin Kaduk
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Acee Lindem (acee)
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Acee Lindem (acee)
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Benjamin Kaduk
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Benjamin Kaduk
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Acee Lindem (acee)
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Benjamin Kaduk
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Acee Lindem (acee)
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Acee Lindem (acee)
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Benjamin Kaduk
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Benjamin Kaduk
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Acee Lindem (acee)
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Acee Lindem (acee)
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Shraddha Hegde
- Re: [secdir] secdir review of draft-ietf-ospf-nod… bruno.decraene
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Shraddha Hegde
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Shraddha Hegde
- Re: [secdir] secdir review of draft-ietf-ospf-nod… bruno.decraene
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Shraddha Hegde
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Shraddha Hegde
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Shraddha Hegde
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Shraddha Hegde