[RPSEC] IESG comments on draft-ietf-rpsec-routing-threats (fwd)
Tony Tauber <tony.tauber@level3.com> Tue, 25 November 2003 20:27 UTC
Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07901 for <rpsec-archive@odin.ietf.org>; Tue, 25 Nov 2003 15:27:41 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjmM-0006MN-Sg for rpsec-archive@odin.ietf.org; Tue, 25 Nov 2003 15:27:25 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPKRMH2024442 for rpsec-archive@odin.ietf.org; Tue, 25 Nov 2003 15:27:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjmM-0006M8-LI for rpsec-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 15:27:22 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07786 for <rpsec-web-archive@ietf.org>; Tue, 25 Nov 2003 15:27:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjmL-0004zm-00 for rpsec-web-archive@ietf.org; Tue, 25 Nov 2003 15:27:21 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOjmK-0004zj-00 for rpsec-web-archive@ietf.org; Tue, 25 Nov 2003 15:27:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjlt-00069U-1C; Tue, 25 Nov 2003 15:26:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjkV-0005tt-Ue for rpsec@optimus.ietf.org; Tue, 25 Nov 2003 15:25:30 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07520 for <rpsec@ietf.org>; Tue, 25 Nov 2003 15:25:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjkR-0004wM-00 for rpsec@ietf.org; Tue, 25 Nov 2003 15:25:23 -0500
Received: from mesa.bbnplanet.com ([171.78.172.21]) by ietf-mx with esmtp (Exim 4.12) id 1AOjkQ-0004vT-00 for rpsec@ietf.org; Tue, 25 Nov 2003 15:25:23 -0500
Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id hAPK9oX12051; Tue, 25 Nov 2003 15:09:51 -0500 (EST)
X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs
Date: Tue, 25 Nov 2003 15:09:50 -0500
From: Tony Tauber <tony.tauber@level3.com>
X-X-Sender: ttauber@mesa.bbnplanet.com
To: Abbie Barbir <abbieb@nortelnetworks.com>, Yi Yang <yiya@cisco.com>
cc: Sandy Murphy <sandy@tislabs.com>, Russ White <riw@cisco.com>, rpsec@ietf.org
Message-ID: <Pine.GSO.4.58.0311111843280.4325@mesa.bbnplanet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: [RPSEC] IESG comments on draft-ietf-rpsec-routing-threats (fwd)
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=subscribe>
Hi folks, These are the comments received by IESG review. They all need to be fixed or somehow addressed if the critique is non-sensical. Sorry for having sat on them for so long; it's been a busy month. Please post a revised doc and send the revisions to the list or post proposed revisions to the list for comment or recommendation if desired. Thanks, Tony ---------- Forwarded message ---------- Date: Fri, 31 Oct 2003 12:52:40 -0800 From: Alex Zinin <zinin@psg.com> To: Russ White <ruwhite@cisco.com>, Tony Tauber <ttauber@genuity.com> Subject: IESG comments on draft-ietf-rpsec-routing-threats Russ, Tony- Below are the comments from the IESG on the draft. They are also checked into the data tracker (Russ'es are under IESG discussion, and others are in comments) Alex Russ Housley (Comments): Comments: draft-ietf-rpsec-routing-threats-03 draft-ietf-rpsec-routing-threats-03.txt Generic Threats to Routing Protocols (Informational) Very nice document! I did notice a few typos. In section 3.1.1: s/form outsiders/from outsiders/ s/A link become subverted/A link is said to be subverted/ s/when an attacker gain access/when an attacker gains access/ Ted Hardie: Comment: The definition of threat wavers between "an adversary" and the "opportunity for an adversary to hurt you"; this is especially true in Section 3.1 Consistency here seems pretty important. In 3.1.2, this definition is given: "Blackhole: large amounts of traffic are directed to be forwarded through one router that cannot handle the increased level of traffic and drops many/most/all packets". I thought the aim here was to describe consequences,not how they are achieved. The consequence here seems to be "packets go in, but go nowhere". Nits: Both abstract and introduction have this statement: "The document provides a summary of generic threats that affects routing protocols." -->that affect (otherwise it reads as if the summary is doing the affecting). Section 2. "routing protocols may need to maintain the state of their" -->maintain knowledge about the state? "Routing protocol data plane uses messages to exchange information" -->The (or A) Routing protocol? Section 3. "Routing protocols are subject to treats at the control and data" --->threats. Section 3.1.2 "Disruption: This consequence occurs when a legitimate router's operation is being interrupted or prevented. Subvert links can" " interfering routing exchanges, or system integrity."--> interfering with? <I gave up on the Nits here, and I'd recommend an editing pass by a native speaker familiar with the topic> --->subverted From ops-dir: From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: donderdag 30 oktober 2003 0:10 To: Randy Bush Cc: ops directorate Subject: draft-ietf-rpsec-routing-threats-03.txt Hi, Comments below. First time I read it. Feel free to expose, as always. High-order bit: so-and-so. Looks like an OK document, but I'm not sure how much usefulness there is to it. The classification of threats etc. is made in such a way that a real analysis whether some important pieces could be missing from the consideration is difficult. That is, it's nice to read through the document, but I'm not sure if the characterizations, document organization, threat models etc. are really the useful ones, enabling easier analysis of the content. But as I don't have any bright ideas at the moment myself, I think it should be OK. Just don't expect to build any other documents on top of that (e.g., protocol-specific documents looking at how they've addressed the generic threats) and you should be ok. If you intend to build new work on top of this document, it might make sense to think whether the structure needs beefing up a bit more. On Fri, 24 Oct 2003, Randy Bush wrote: > 3. Document Actions > 3.1 WG Submissions > 3.1.1 New Item > **** o draft-ietf-rpsec-routing-threats-03.txt > Generic Threats to Routing Protocols (Informational) - 3 of 3 > Token: Alex Zinin more or less substantial comments --------------------------------- This documents investigates general threats to routing functions. In this work, the "owner" of an address prefix or an AS [17] number is an organization that has been granted the right to use that prefix or number. Each Regional Internet Registry (RIR) acquires prefixes and AS numbers from IANA, and further distributes (delegates use of) them to organizations such as ISPs and multi-homed subscribers. For address prefixes, delegation typically involves assigning a subset of a prefix to an organization, which may, in turn, further delegate subsets to other organizations, e.g., subscribers or downstream providers. ==> overly verbose on IP addressing, which is not leveraged later in the document, may be outside of the scope? Definitely needs rewording if it's staying.. A router's functions can be divided into control and data plane (protocol traffic vs. data traffic). In a similar fashion, a routing protocol has a control and a data plane. A routing protocol has a control plane that exchanges messages that are intended only for control of the protocol state. Routing protocol data plane uses messages to exchange information that is intended to be used in the forwarding function. For example, the information can be used to establish a forwarding table in each router or to return a description of the route to be used. Routing functions may affect the control and the data planes. However, there may be an emphasis on one of the planes as opposed to the other. For example, neighbor maintenance is likely to focus on the routing protocol control plane, while database maintenance may focus on the data plane. ==> IMHO, the separation of data and control planes in a router is a simple concept. However, the separation of data/control planes in a routing protocol is not (actually, I've very rarely even heard anyone mention something like that). And this description (IMHO) does not flesh it out properly. If it's staying, I'd recommend trying to reword to be clearer what which of them entails. Threats can originate form outsiders or insiders. An insider is an authorized participant in the routing protocol. An outsider is any other host or network. A particular router determines if a host is an outsider or an insider. An authorized protocol speaker can be an outsider to a particular router if the router does not consider it to be a legitimate peer (as could conceivably happen on a multi-access link). ==> by the first definition of "insider", the third definition is already "insider" because it's authorized.. or maybe I don't understand what you're talking about with the authorized speaker which is an outsider.. o Threats that result from subverted links: A link become subverted when an attacker gain access (or control) to it through a physical medium. The attacker can then take control over the link. This threat can result from the lack (or the use of weak) access control mechanisms as applied to physical mediums or channels. The attacker may eavesdrop, replay, delay, or drop routing messages, or break routing sessions between authorized routers, without participating in the routing exchange. ==> this is one-sided view of the subject. This seems clearly look at the threat from the perspective of getting physical access to the link between two routers. However, there is another case like this: router providing connectivity to a stub network, e.g., running an OSPF protocol without passive mode towards a LAN. These threats are different, at least to a degree, because typically in these stub network cases, the routing protocol packets do destined to the third parties do not traverse through the stub network. That is, e.g. replay and drop are not really relevant threats.. Not sure to which degree these should be fleshed out separately.. ... For example, an OSPF router will form a peering relationship with any attached device which appears to be running OSPF, unless MD5 authentication (or some other means) is used to prevent the neighboring relationship from forming. ==> this may need to be considered with the above in mind. This concentrates on IP-level protection, which may not be relevant if someone is able to come in as a middleman in the communication (depends on whether plain-text is used for authentication -- that is, if I see the communication, does it help me at all unless I know the key, requring a router compromise instead of a link -- I guess in most cases some hashes or others are used instead). .... 4.1 Deliberate Exposure Deliberate Exposure occurs when an attacker takes control of a router and intentionally releases routing information directly to other routers. In some cases, the receiving routers may not be authorized to access the leaked routing information. Deliberate exposure is always a threat action, however, the exposure of routing information may not be. ==> this is written as if this threat was limited to exposing information to other _routers_. In fact, the attackers goal might be to expose it to _himself_, a web page, mail posting, etc. (ie., not necessarily to other routers) as well. This would be a subset of the original threat. 4.2 Sniffing Sniffing is an action whereby attackers monitor and/or record the routing exchanges between authorized routers. Attackers can use subverted links to sniff for routing information. ==> this is a limited case of this threat. In addition to sniffing the routing information, being in a position like this, it is typically also possible to sniff the data plane as well? 4.3 Traffic Analysis Traffic analysis is action whereby attackers gain routing information by analyzing the characteristics of the data traffic on a subverted link. Traffic analysis threats can affect any data that is sent in the clear over a communication link. This threat is not peculiar to routing protocols and is included here for completeness. ==> this is not limited to clear-text communication. You can typically analyze many interesting things out of encrypted traffic as well (e.g. even if all traffic is protected by IPsec ESP). For example, looking at the destination addresses on the link should yield which prefixes are (at least) used in the routing protocol, or looking at which IP addresses communicate might help you guess about multihop iBGP sessions, etc. For example, if an attacker succeeds in spoofing the identity of a router, the subverted router can act as a masquerading router. ==> which router does "subverted" refer to? This seems to assume that spoofing would imply hijacking someone else's identity, which need not be the case (e.g., if a router has configured that everyone in a specific prefix is allowed to form adjacencies, but you spoof an address in that prefix but not one that was already used, you don't hijack an identity) -- similar later The consequences of spoofing are: o The deception of peer relationship: The authorized routers, which exchange routing messages with the spoofed router, do not realize they are neighboring with a router that is faking another router's identity. ==> this actually includes a lot of other consequences, need to spell it out -- be able to do everything authorized, e.g. blackhole, loop, forge routing information to eavesdrop, etc.etc. o Where disruption is concerned, the consequence zone includes the routers that are on the path of misdirected data traffic (Router B in Figure 2 and Figure 3). ==> plus those routers in the path in the internet which got this traffic they would not otherwise get.. 4.5.1.2 Misclaiming A misclaiming threat is defined as an attacker action advertising its authorized control of some network resources in a way that is not intended by the authoritative network administrator. ==> this is exactly what seems to happen with overclaiming as well. Apparently these two issues haven't been sufficiently well spelled out as I'm missing something.. (note: the next section on forwarder attacks lists only misstatement, not e.g. overstatement :-) editorial: ---------- in BGP, if a router receives a CEASE message, it can lead to breaking of its neighboring relationship to other routers. ==> s/breaking of/breaking off/ ? (or remove "of" ?) A PIM router might transmit a JOIN message to receive multicast data it would otherwise not receive ==> s/receive/receive./ when an attacker gain access (or control) to it through a physical ==> s/gain/gains/ Subverted links and/or subverted device (routers)can cause this ==> s/device (routers)/devices (routers) / (2 typos) routing message integrity, routing message origin, authentication or peer router authentication. ==> different variations of authentication twice, intentional or a typo? operation is being interrupted or prevented. Subvert links can ==> s/Subvert/Subverted/ devices (router) can cause this consequence by sending false ==> s/router/routers/ Subverted routers can cause this consequence by sending false routing information, interfering routing exchanges, or system integrity. ==> "or system integrity" is abrupt -- something missing? However, Router B is compromised and advertises a lower metric. ==> s/lower/better/ (lower is not always better :-) subverted links to sniff for routing information. ==> s/links /links/ attacker's location and what data traffic has passed through. A ==> s/and /and/ Falsification is an intentional action whereby false routing information is sent by a subverted router. To falsify the routing information, an attacker has to be either the originator or a forwarder of the routing information. False routing information describes the network in an unrealistic fashion, whether or not intended by the authoritative network administrator. To falsify the routing information, an attacker has to be either the originator or a forwarder of the routing information. It cannot be a receiver-only. ==> Remove "To falsify ..." sentence from the first paragraph, roughly duplicates.. the attacker(Router C in Figure 2 and Figure 3). ==> s/attacker(/attacker (/ A misclaiming threat is defined as an attacker action advertising its authorized control of some network resources in a way that is not ==> s/attacker action/action where an attacker is/ ? might increase the path cost by two hops instead of one. In BGP, the attacker might delete some AS numbers from the AS PATH. ==> s/AS/AS_/ ? The threat consequence area and period are also similar. ==> s/area/zone/ ? or by replaying out-dated packets, or by delaying responses, or by denial of receipts, and breaking synchronization. ==> s/and/or by/ for consistency ? Subverted, unauthorized and masquerading routers can slowdown their ==> s/slow/slow / [8] Cheung, S. et. al., "Protecting Routing Infrastructures from Denial of Service using co-operative intrusion detection", In Proceedings of the 1995 IEEE Symposium on Security and Privacy , May 1995. [9] Bradley, K. et. al., "A distributed Network Monitoring approach", Published , November 2001. ==> some references are not used, and these could be removed. There are probably more of them than just these two.. Appendix B. Acronyms AODV - Ad-hoc On-demand Distance Vector routing protocol ==> similarly, the acronyms should be cleaned of those that are not used in the text or aren't otherwise relevant. administration. Each AS normally uses a single interior gateway ==> kill the extra spaces :-) 5. Security Considerations This entire document is security related. Specifically the document addresses security of routing protocols as associated with threats to those protocols. [...] This document discusses inter- and intra-domain routing protocol threats that are currently known [...] ==> the section should probably be more explicit that this document is supposed to be protocol-independent. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec