From exim@www1.ietf.org Tue Sep 2 09:34:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23199 for ; Tue, 2 Sep 2003 09:34:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u9oL-0004KJ-7O for rpsec-archive@odin.ietf.org; Tue, 02 Sep 2003 07:59:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82Bx1D5016627 for rpsec-archive@odin.ietf.org; Tue, 2 Sep 2003 07:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u6RH-0002Fa-1a for rpsec-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 04:22:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29098 for ; Tue, 2 Sep 2003 04:22:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u6RD-0000vS-00 for rpsec-web-archive@ietf.org; Tue, 02 Sep 2003 04:22:55 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19u6RC-0000vO-00 for rpsec-web-archive@ietf.org; Tue, 02 Sep 2003 04:22:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u4tc-0003kj-Ht; Tue, 02 Sep 2003 02:44:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u1Es-0002MD-EV for rpsec@optimus.ietf.org; Mon, 01 Sep 2003 22:49:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01535 for ; Mon, 1 Sep 2003 22:49:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u1En-0002Jm-00 for rpsec@ietf.org; Mon, 01 Sep 2003 22:49:45 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19tpy6-000310-00 for rpsec@ietf.org; Mon, 01 Sep 2003 10:47:46 -0400 Received: from tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id DB77B20298 for ; Mon, 1 Sep 2003 08:47:08 -0600 (MDT) Date: Mon, 1 Sep 2003 08:47:07 -0600 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: multipart/mixed; boundary=Apple-Mail-15-368565149 From: Danny McPherson To: rpsec@ietf.org Message-Id: <28CCC990-DC8B-11D7-930E-000393D54EA6@tcb.net> X-Mailer: Apple Mail (2.552) Subject: [RPSEC] Requirements Draft 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , --Apple-Mail-15-368565149 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Folks, Here's the initial version of the requirements draft. Comments and feedback on additional content, corrections, "document direction" and topics, etc.. are most welcome! Feel free to reply to rpsec or directly to Jean-Jacques and/or myself. After collecting a week or two of initial feedback, we'll likely post the next version to internet-drafts, this has not been posted there yet. Thanks! -danny --Apple-Mail-15-368565149 Content-Disposition: attachment; filename=draft-ietf-rpsec-routing-security-requirements-00.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-rpsec-routing-security-requirements-00.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. McPherson Internet-Draft JJ. Puig Expires: February 20, 2004 August 22, 2003 Security Requirements for Routing Protocols draft-ietf-rpsec-routing-security-requirements-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 20, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Routing protocols are subject to attacks that can harm individual users or the network operations as a whole. This document provides a=20= description of basic security requirements for routing protocols and routing systems. McPherson & Puig Expires February 20, 2004 [Page 1] =0C Internet-Draft Routing Protocols Security Requirements August 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. General considerations . . . . . . . . . . . . . . . . . . . 4 2.1 What MUST / SHOULD be protected ? . . . . . . . . . . . . . 4 2.2 Transport Layer considerations . . . . . . . . . . . . . . . 4 3. Cryptographic requirements . . . . . . . . . . . . . . . . . 6 3.1 Basic cryptographic requirements . . . . . . . . . . . . . . 6 3.2 Crypto keys requirements . . . . . . . . . . . . . . . . . . 6 3.2.1 Public key cryptography . . . . . . . . . . . . . . . . . . 6 3.2.2 Crypto-hygiene . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.3 Key strength . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Performances . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 Use of cryptography . . . . . . . . . . . . . . . . . . . . 8 3.5 Specific considerations for link-state protocols . . . . . . 9 3.6 Specific considerations for distance vectors protocols . . . 9 4. Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1 The TTL Hack . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 Link layer . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. The Byzantine problem . . . . . . . . . . . . . . . . . . . 11 5.1 General requirements . . . . . . . . . . . . . . . . . . . . 11 5.2 Byzantine detection . . . . . . . . . . . . . . . . . . . . 11 5.3 Byzantine robustness . . . . . . . . . . . . . . . . . . . . 11 6. Local considerations . . . . . . . . . . . . . . . . . . . . 12 6.1 Extra checks . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2 Fail-back procedures . . . . . . . . . . . . . . . . . . . . 12 6.3 Auditable Events . . . . . . . . . . . . . . . . . . . . . . 12 7. Agreements requirements . . . . . . . . . . . . . . . . . . 13 7.1 Authenticating public keys . . . . . . . . . . . . . . . . . 13 7.2 Announcing routes . . . . . . . . . . . . . . . . . . . . . 13 7.3 Advertizing a prefix . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . 14 Normative References . . . . . . . . . . . . . . . . . . . . 15 References . . . . . . . . . . . . . . . . . . . . . . . . . 16 Informative References . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 A. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . 19 McPherson & Puig Expires February 20, 2004 [Page 2] =0C Internet-Draft Routing Protocols Security Requirements August 2003 1. Introduction Routing protocols are subject to threats and attacks that can harm individual users or the network as a whole. This document provides a description of basic security requirements for routing protocols and routing systems. This work is designed to serve as reference material for current routing protocols analysis and extensions design, and as a guidance for designing new, more secure, routing protocols and routing systems. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document is organized as follows: o Section 2 presents general considerations relative to the security of routing protocols and routing systems. o Section 3 defines cryptographic requirements for routing operations. o Section 4 presents the neighboring issue and concerns related to forwarding of the routing protocol messages. o Section 5 provides guidance for tackling the Byzantine problem. o Considerations on local decisions (verifying database coherence, fail-back procedures) are given Section 6. o Agreements requirements and operations involving network=20 operators responsibility are presented Section 7. McPherson & Puig Expires February 20, 2004 [Page 3] =0C Internet-Draft Routing Protocols Security Requirements August 2003 2. General considerations This section provides general considerations on the design of secure routing protocols. 2.1 What MUST / SHOULD be protected ? Distribution of destination reachability information with the = required=20 policy considerations (QoS, trusted route, etc.) is what is expected=20= from a routing protocol. Reachability MUST be protected against unauthorized route deletions and route additions. Note that these are high level operations; aggregation, for instance, may result in the same consequences as announcing new routes. Route attributes (path information, metrics, trusted entity for the=20= forwarding of specific traffics) SHOULD also be protected. [TBD] We have to decide if route attributes require as much protection as route existence, probably yes. Note that manipulation=20= of a routes associated attributes may achieve the same effects=20 as those resulting from addition / deletion. This all depends on the adversary motivations. Yet, modifying=20 attributes in order to achieve a precise goal may be more difficult than injecting an additional route. Routing protocols may benefit=20 from protection of routes and lack of protection of route=20 attributes. Traffic overload may provoke DOS of routing negotiations, while these would help in balancing the high traffic. Forwarding is usually the principal purpose of devices running routing protocols. In order to achieve correctness of forwarding tables, means to enforce availability of the medium to the routing protocol SHOULD be provided. 2.2 Transport Layer Considerations The choice of the Transport Layer for the routing protocol may ease the requirements presented in the following sections. Any routing protocol designed to run on a specific Transport Layer SHOULD document or provide appropriate references to the security=20 properties provided by the Transport Layer. A routing protocol designed to be, within certain extent, Transport Layer independent, may provide options to activate inner security features on-demand. Though such a flexibility would help avoiding potential redundancy of functions with the Transport Layer and adjusting performance requirements, such an approach is usually not McPherson & Puig Expires February 20, 2004 [Page 4] =0C Internet-Draft Routing Protocols Security Requirements August 2003 desirable because of it's added complexity. The Tranport Layer may already grant the following properties: o Neighboring: a technology may provide a way to address adjacent=20 neighbors. The neighboring range in this kind of technology is typically of one system away and relies on direct mapping over the Link Layer. o Integrity: the Transport Layer may provide data integrity. This is insufficient to achieve security without proper means of authenticating the system which provided the integrity proof in the first place. o Authenticity: if the underlying layer both provides authenticity and integrity, many routing threats may be thwarted. Further considerations are required though, among which are resistance to replay, performance, Byzantine detection and robustness, etc. o Separate control channel: if the underlying technology provides separated channels for control traffic and user data traffic, this may help against DOS of the routing protocol. These control=20 channels may be provided via the same Link Layer infrastructure, = or perhaps via an out-of-band (OOB) network. McPherson & Puig Expires February 20, 2004 [Page 5] =0C Internet-Draft Routing Protocols Security Requirements August 2003 3. Cryptographic requirements 3.1 Basic cryptographic requirements The following requirements are understood on a producer / consumer of the routing information basis. Forwarders of the information may not need to provide the following, if they do not modify the content of messages. Integrity: data integrity is an obvious requirement. Anti-replay: this comes here mainly for protection against active attacks from subverted links, though this feature will also provide added protection against natural duplication of packets. Note that underlying layers may provide an unauthenticated anti-replay feature, which would be of no use from a security point of view. Authentication: the two above features are of no use without authentication of the peer. Authenticating correctly the messages sent from neighbors is the most important security requirement for a routing protocol. Authentication techniques that should be considered currently are: digital signature, keyed hash. There have been considerations of confidentiality as a mean to counter disclosure of network topology. The gains from such a feature are not obvious, especially because traffic analysis of forwarded data may provide the topology disclosure, and also because public information may be required in order to prove the legitimacy of routers for announcing routes or prefixes. Besides, this involves additional performance issues which are particularly undesirable. Providing confidentiality is not required (although perhaps it=20 should be. Comments?). 3.2 Crypto keys requirements Key management involves several considerations. Besides, routing protocols involve several interconnected devices and a routing protocol design should analyze scaling issues. Public key cryptography should be the most appropriate paradigm at the current time. 3.2.1 Public key cryptography [TBD] I'm not sure this section is really useful. Public key cryptography is traditionaly associated with drawbacks such as administration, deployment, reachability, caching. Administration is needed as a side effect. Because routing devices McPherson & Puig Expires February 20, 2004 [Page 6] =0C Internet-Draft Routing Protocols Security Requirements August 2003 may not belong to the same organizations, a kind of trusted third party must exist to tie identities, public keys and possibly other contents like addresses or rights to advertise certain prefix or routes. Deployment is mainly a scaling issue. Temptation is great to rely upon a mechanism that (almost) succeeded in scaling (DNS). On the other hand, care should be taken not to misuse or overload these mechanisms. Reachability of the public key information is required. This may be done in-band within the routing protocol, or through a stand-alone protocol. In the later case, specific consideration occurs regarding availability of the service under high traffic. Reachability is required in order to retrieve keys, but also for revocation checking or roll-overs. Caching is both a useful help for deployment, reachability and performance. On the other hand, it jeopardizes revocation of keys or roll-over. 3.2.2 Crypto-hygiene Limiting key lifetime and refreshing them is good cryptographic hygiene. Therefore, a mechanism to roll-over keys is required both for public keys and for session keys; Public keys roll-over may not require a soft transition, while refreshing session keys may require to move from the old key to the new one with no session interruption. Lifetime MUST be evaluated both in terms of time and of amount of data. 3.2.3 Key strength [TBD] Give correct lifetime for keys, in years against mips ? Strength of public keys should be high. Changing these keys may be administratively heavy if they are used in EGPs. Besides, a third party may not emerge if keys have a short lifetime. In IGPs, strength of these keys should not be that high, though this mainly depends on internal administration tasks scheduling. Strength of symmetric keys does not require to be high: refresh may happen during low traffic periods -if they exist-, and verification must be fast. These keys should be used only as a fast authentication schemes. McPherson & Puig Expires February 20, 2004 [Page 7] =0C Internet-Draft Routing Protocols Security Requirements August 2003 3.3 Performances System resources (CPU, memory) might be overloaded by cryptographic operations, especially by public key computations. These performance issues should be taken into account when designing a routing protocol, otherwise they would open the device to other forms of attacks that will result in the same consequences as attacks against routing operations. Performance evaluation often requires hypothesis on the underlying hardware, which is somewhat restricting. When possible, methods to derive a symmetric key from public exponents should be used, given that the symmetric cryptography operations considered are less computationaly expensive. Caution should be taken if the number of devices sharing the same symmetric key is greater than two. There had been several discussions on the use of a token based fast rejection scheme, which would be embedded on interfaces of the devices, because routing protocol's traffic, user data traffic , and of course maligne traffic often share the same channel, possibly at a high rate. The management of such a scheme may require a stand-alone protocol and raises issues when neighbors communicate through several interfaces. [TBD] Considerations of which data should be store in non-volatile storage ? 3.4 Use of cryptography [TBD] This section should explain how the above cryptography considerations will help countering common threats. It may be wise to wait for the next version of the threat draft before going further. This section may be rejected in appendix. Correct use of anti-replay, integrity and authentication should suffice to protect against deception or usurpation damages resulting from subverted links or spoofed messages. This will be insufficient to prevent disclosure or disruption. Subverted routers, being authorized as participants to the routing protocol, will still be able to process with attacks resulting in all of these damages. Further protection requires a registry stating authorizations for the routing devices to be available. This information must be authenticated by an adequate entity. [TBD] Where do we put stuff about bandwidth allocation to protect against DOS ? McPherson & Puig Expires February 20, 2004 [Page 8] =0C Internet-Draft Routing Protocols Security Requirements August 2003 3.5 Specific considerations for link-state protocols 3.6 Specific considerations for distance vectors protocols Validation of incremental costs adjustments, route caracteristics updates, etc. McPherson & Puig Expires February 20, 2004 [Page 9] =0C Internet-Draft Routing Protocols Security Requirements August 2003 4. Neighbors Neighbors are the peers involved in routing operations which can be reached within a maximum number of hops. Often, neighbors definition is limited to the systems that are directly reachable through with the link layer, regardless of the technology actually used for the transport layer of the routing protocol. There are several ways to ensure that the routing information actually comes from a system within a max range. Note that this does not prove that the message itself has been sent by the legitimate system (it may be a replay). It is also possible to provide such a feature within the routing protocol. 4.1 The TTL Hack The TTL hack is a clever way to limit the range effect of routing messages and to prevent intrusion in the neighboring in IP networks. By setting TTL to max value (255), neighbors can check that the message comes from direct neighbors. Spoofed routing messages coming from outside the neighboring range will get their TTL decreased and be rejected. This does not protect against insiders nor against outsiders using tunnels to carry engineered packets. 4.2 Link layer Direct use of the link layer instead of Network (IP) layer for communications of the routing protocol limits neighboring implicitly. In some cases (VLAN frame hopping), and outsider may break in the neighbors zone. McPherson & Puig Expires February 20, 2004 [Page 10] =0C Internet-Draft Routing Protocols Security Requirements August 2003 5. The Byzantine problem Note that detection and robustness properties are not necessarily correlated. 5.1 General requirements TBD: explain here how hypothesis needed for tackling correctly the pb (synchronization, topology considerations...) may be mapped on the specific context of routing protocols. 5.2 Byzantine detection 5.3 Byzantine robustness TBD: Define severed solutions: couldn't enforce policy requirements (cost, trusted path), yet forwarding is insured. McPherson & Puig Expires February 20, 2004 [Page 11] =0C Internet-Draft Routing Protocols Security Requirements August 2003 6. Local considerations 6.1 Extra checks A routing device may be configured to run extra checks on the routing state, like checking databases against previous information. Some active tests may also be triggered: sending source routed ICMP packets, etc. Such tests may also involve the neighbors. High caution should be taken regarding implementation of such features. 6.2 Fail-back procedures When detecting obvious routing misbehavior which result from misuse of the routing protocol, and when sources responsibles for this misbehavior cannot be identified (Byzantine detection), fail-back procedures may be attempted, based on previous recorded states, fail-safe states or heuristics on the routing information and on trust. Degradation of the service should often be better than no service at all, thus the device may adjust local route costs information when such events occur. 6.3 Auditable Events The following events should be audited: 1. Authentication failure 2. Errors reported by forwarders 3. Detection of a Byzantine event McPherson & Puig Expires February 20, 2004 [Page 12] =0C Internet-Draft Routing Protocols Security Requirements August 2003 7. Agreements requirements Secure EGPs operations will require a kind of agreement between the involved parties. Though providers may achieve this agreement on a case by case basis, this is unlikely to be effective in the field. Emergence of trusted third parties upon which would rely the diffusion of public key material and relations to prefix ownership would fit better. Another question is whether these informations must be tied with public information related to the system ownership, such as the organization name. This may lead to specific routing policies or abuses that would introduce more complexity. 7.1 Authenticating public keys Note: It should be clear that a light paradigm would better fit in most cases, so we should avoid the acronym PKI as much as possible, though we have to deal with the problem of the trusted party at one point. 7.2 Announcing routes Legitimacy for announcing routes / updating infos. 7.3 Advertizing a prefix Using authorization paradigms should be sufficient. Ways to prove the right to advertise a prefix. Where will we find the appropriate victim for the administration of these infos ? McPherson & Puig Expires February 20, 2004 [Page 13] =0C Internet-Draft Routing Protocols Security Requirements August 2003 8. Security Considerations This entire informational draft RFC is security related. Specifically it addresses security of routing protocols as associated with requirements to those protocols. In a larger context, this work builds upon the recognition of the IETF community that signaling and control/management planes of networked devices need strengthening. Routing protocols can be considered part of that signaling and control plane. However, to date, routing protocols have largely remained unprotected and opened to malicious attacks. This document discusses inter and intra domain routing protocol security requirements as we know them today and lays the foundation for the design of new, more secure, routing protocols. McPherson & Puig Expires February 20, 2004 [Page 14] =0C Internet-Draft Routing Protocols Security Requirements August 2003 Normative References [SEC-GLOSS] Shirey, R, "Internet Security Glossary", RFC 2828 , May 2000. McPherson & Puig Expires February 20, 2004 [Page 15] =0C Internet-Draft Routing Protocols Security Requirements August 2003 References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. McPherson & Puig Expires February 20, 2004 [Page 16] =0C Internet-Draft Routing Protocols Security Requirements August 2003 Informative References [BYZANTINE] Perlman, R, "Network Layer Protocols with Byzantine Robustness", , August 1988 . Authors' Addresses Danny McPherson Arbor Networks EMail: danny@arbor.net Jean-Jacques Puig INT / LoR / Piece A-108 9, Rue Charles Fourier Evry 91011 France Phone: +33 1 60.76.44.65 Fax: +33 1 60.76.47.11 EMail: jean-jacques.puig@int-evry.fr URI: http://www-lor.int-evry.fr/~puig/ McPherson & Puig Expires February 20, 2004 [Page 17] =0C Internet-Draft Routing Protocols Security Requirements August 2003 Appendix A. Acronyms EGP - External Gateway Protocols. Routing protocols used between different ASs. IGP - Internal Gateway Protocols. Routing protocols used within a single AS. McPherson & Puig Expires February 20, 2004 [Page 18] =0C Internet-Draft Routing Protocols Security Requirements August 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION McPherson & Puig Expires February 20, 2004 [Page 19] =0C Internet-Draft Routing Protocols Security Requirements August 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. McPherson & Puig Expires February 20, 2004 [Page 20] =0C --Apple-Mail-15-368565149-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Sep 4 10:47:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28046 for ; Thu, 4 Sep 2003 10:47:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uvOB-0006eb-TK for rpsec-archive@odin.ietf.org; Thu, 04 Sep 2003 10:47:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84ElBxO025573 for rpsec-archive@odin.ietf.org; Thu, 4 Sep 2003 10:47:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uvOB-0006eO-QR for rpsec-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 10:47:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27981 for ; Thu, 4 Sep 2003 10:47:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uvO9-0004cm-00 for rpsec-web-archive@ietf.org; Thu, 04 Sep 2003 10:47:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uvO8-0004ci-00 for rpsec-web-archive@ietf.org; Thu, 04 Sep 2003 10:47:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uvO1-0006d1-9Y; Thu, 04 Sep 2003 10:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uvNr-0006cZ-Aa for rpsec@optimus.ietf.org; Thu, 04 Sep 2003 10:46:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27962 for ; Thu, 4 Sep 2003 10:46:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uvNo-0004cH-00 for rpsec@ietf.org; Thu, 04 Sep 2003 10:46:48 -0400 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 19uvNn-0004a4-00 for rpsec@ietf.org; Thu, 04 Sep 2003 10:46:48 -0400 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id BA63134745 for ; Thu, 4 Sep 2003 16:42:17 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 83C8D3F43A for ; Thu, 4 Sep 2003 16:50:18 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003090416372627894 for ; Thu, 04 Sep 2003 16:37:26 +0200 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id 433403F43A for ; Thu, 4 Sep 2003 16:50:18 +0200 (CEST) Received: from jjp by localhost with local id 19uvGc-0004Xn-00 for ; Thu, 04 Sep 2003 16:39:22 +0200 Date: Thu, 4 Sep 2003 16:39:22 +0200 From: Jean-Jacques Puig To: rpsec@ietf.org Message-ID: <20030904143922.GB15450@ivan.int-evry.fr> Mail-Followup-To: rpsec@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [RPSEC] -02 Threats Draft review 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Hello, Some parts we may need to work on: A] >2. Routing Functions Overview > > This section provides an overview of common functions that are shared > among various routing protocols. In general, routing protocols share > the following common functions: Wouldn't 'Routing protocols share the following functions:' be sufficient ? B] Are the words authorized/unauthorized used consistently ? >3. Generic Routing Protocol Threat Model > > The model developed in this section can be used to identify threats > to any routing protocol. It examines attacks which can be launched > against routing from subverted entities within the routing system, > and from entities outside the routing system. Both of these types of > entities are called >>unauthorized<< entities. I agree on this one, but: >3.1.1 Threat Sources >... > o Threats that result from subverted devices (e.g. routers): A > subverted device (router) is an >>authorized<< router that may have > routing software bugs, hardware defects, incorrect or unintended > configurations. Devices can be susceptible to such threats due to > the lack mechanisms to verify system integrity (For example, the > router is working correctly as been intended by the authoritative > network administrator), or such mechanisms can be circumvented. > Such threats may enable attackers to inappropriately claim > authority for some network resources, or violate routing > protocols, such as advertising invalid routing information. That is: Section 3 intro states that subverted devices are unauthorized, while threat sources states the opposite. Is a clarification needed ? C] >3.1.2 Threat Consequences The list is big. Yet, I would also propose: o Performance: data traffic destined for the network is forwarded on a path which has performance caracteristics that would not have been elected for this traffic. (Performance, or incorrect allocation of ressources) Let's take an instance: +-----------R1----------R2-----------+ Left_Nets -<------------R3----------R4------------>- Right_Nets +-----------R5----------R6-----------+ An attacker has interest in a certain application somewhere in Right_Nets. Links within Left_Nets and Right_Nets satisfy the attacker requirements, in terms of bandwidth, rtt, etc. Normal path between Left_Nets and Right_Nets is through R3 - R4, in both ways. The attacker may confuse routers to change to a faster path (e.g. R1-R2). He can also behave differently if his application has asymetric requirements, and confuse routers to set up a path in one way with great bandwidth and in the other way with, say, low latency. This is interesting if link medias provide different bandwidth or latency, or if some path offer more bandwidth merely because they host less traffic, or also because of the scheduling policy on the routers if they provide QoS. On the other hand, the attacker can also damage applications using the same means: long latency paths will cause timeouts in many apps. Note that this is different from congestion: congestion may be obvious if it lasts long, but here tcp congestion control will react to congestion, and the pb is less detectable. Of course, we are concerned about the network, and not applications. Damage to the network is other consumption of resources, corruption of forwarding policies, reduction of the forwarding quality. Does it make sense ? Is it redundant with a fore-mentionned consequence ? D] (overclaiming) > o Where deception is concerned, the consequence zone covers the > routers that >>do not believe<< the attacker's advertisement and use > the attacker to reach the claimed subnets (Router B and other > deceived routers on the Internet in Figure 2 and Figure 3). How can they be deceived by the attacker if they do not believe it ? -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Sep 10 03:42:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21253 for ; Wed, 10 Sep 2003 03:42:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wzc9-0002ym-Vg for rpsec-archive@odin.ietf.org; Wed, 10 Sep 2003 03:42:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8A7g9rR011453 for rpsec-archive@odin.ietf.org; Wed, 10 Sep 2003 03:42:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wzc9-0002ye-KH for rpsec-web-archive@optimus.ietf.org; Wed, 10 Sep 2003 03:42:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21245 for ; Wed, 10 Sep 2003 03:42:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wzc7-0001Rc-00 for rpsec-web-archive@ietf.org; Wed, 10 Sep 2003 03:42:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wzc6-0001RY-00 for rpsec-web-archive@ietf.org; Wed, 10 Sep 2003 03:42:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wzc1-0002xS-RR; Wed, 10 Sep 2003 03:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wzbD-0002wm-OK for rpsec@optimus.ietf.org; Wed, 10 Sep 2003 03:41:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21224 for ; Wed, 10 Sep 2003 03:41:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wzbB-0001RD-00 for rpsec@ietf.org; Wed, 10 Sep 2003 03:41:09 -0400 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 19wzbA-0001R1-00 for rpsec@ietf.org; Wed, 10 Sep 2003 03:41:08 -0400 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 1A30833F7B for ; Wed, 10 Sep 2003 09:39:07 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 96D343F414 for ; Wed, 10 Sep 2003 09:49:11 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003091009390602747 for ; Wed, 10 Sep 2003 09:39:06 +0200 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id 4904E3F414 for ; Wed, 10 Sep 2003 09:49:11 +0200 (CEST) Received: from jjp by localhost with local id 19wzZ4-0002PM-00 for ; Wed, 10 Sep 2003 09:38:58 +0200 Date: Wed, 10 Sep 2003 09:38:58 +0200 From: Jean-Jacques Puig To: rpsec@ietf.org Subject: Re: [RPSEC] -02 Threats Draft review Message-ID: <20030910073858.GB8341@ivan.int-evry.fr> Mail-Followup-To: rpsec@ietf.org References: <200309091340.h89DexlO005329@filbert.tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200309091340.h89DexlO005329@filbert.tislabs.com> 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , On Tue, Sep 09, 2003 at 09:40:59AM -0400, Sandy Murphy wrote: > >Are the words authorized/unauthorized used consistently ? > >... > >That is: Section 3 intro states that subverted devices are unauthorized, > >while threat sources states the opposite. Is a clarification needed ? > > I would say that a legitimate router that was subverted (which, by the > way, is defined in the draft as meaning a router with software bugs, hardware > defects or misconfigurations, not one that was broken into) was still an > authorized router - it might be using its authorization improperly but > it still holds the authorization. To say otherwise is to make > authorization a property that changes magically if a hardware defect > occurs. Which would hardly be within the capability of a peer router > to detect. Agree. But should threat sources mention only legitimate routers that was subverted, or should it rather mention all subverted routers, among which a sub-category are also authorized participants ? I had the feeling from the intro to the threat model that by default all subverted devices were under consideration. > > >The list is big. Yet, I would also propose: > > > >o Performance: data traffic destined for the network is forwarded on a > > path which has performance caracteristics that would not have been > > elected for this traffic. > >... > >Does it make sense ? Is it redundant with a fore-mentionned consequence > > The draft includes: > > o Delay: data traffic destined for the network or host is forwarded > along a route that is in some way inferior to the route it would > otherwise take, > > as a damage that might accrue to a host or network address. The "in > some way inferior" covers almost any measure of quality, but the use > of the term "delay" hints that the motivation was to cover routes that > were longer (in hops, in source-destination round-trip time, etc.) > than the protocol would otherwise find. This is very important in > some applications as you note. And it is important in some networking > environments, like wireless, where excess resource consumption is an > issue. I partly agree. The fact is the goal of the attack may also be the opposite: to get a data traffic forwarded along a route that is in some way superior (that is: promote a traffic). The attacker may be clever enough to limit side effects significantly so that no delay variation appears for normal traffic. In a nutshell, he steals resources that are currently unused. e.g. on some links (satellite & wdm ?) more bandwidth than required may be available. Bandwidth consumption on these links will have almost no influence on delay. > >> routers that >>do not believe<< the attacker's advertisement and use > > > >How can they be deceived by the attacker if they do not believe it ? > > Surely a typo. (But rather a critical one.) That's both the good and the bad part of not having a good level of English: I'm quickly unseated by such things :) -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Fri Sep 12 17:46:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18126 for ; Fri, 12 Sep 2003 17:46:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xvk4-0002s2-6B for rpsec-archive@odin.ietf.org; Fri, 12 Sep 2003 17:46:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CLkCeN011029 for rpsec-archive@odin.ietf.org; Fri, 12 Sep 2003 17:46:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xvk4-0002ro-2U for rpsec-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 17:46:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18119 for ; Fri, 12 Sep 2003 17:46:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xvk1-0006FT-00 for rpsec-web-archive@ietf.org; Fri, 12 Sep 2003 17:46:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xvk1-0006FP-00 for rpsec-web-archive@ietf.org; Fri, 12 Sep 2003 17:46:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xvju-0002qa-Mg; Fri, 12 Sep 2003 17:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xvj4-0002ps-GT for rpsec@optimus.ietf.org; Fri, 12 Sep 2003 17:45:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18092 for ; Fri, 12 Sep 2003 17:45:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xvj1-0006FI-00 for rpsec@ietf.org; Fri, 12 Sep 2003 17:45:07 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19xvj1-0006FF-00 for rpsec@ietf.org; Fri, 12 Sep 2003 17:45:07 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.22) id 19xvj1-0002Ez-HJ for rpsec@ietf.org; Fri, 12 Sep 2003 21:45:07 +0000 Date: Fri, 12 Sep 2003 14:44:42 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <162165234174.20030912144442@psg.com> To: rpsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [RPSEC] AD-review: draft-ietf-rpsec-routing-threats 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The draft is a big step forward, I believe. However, I have several concerns and comments: Meta-comments 1. Use of the models defined in sections 2 and 2.1 Seems that section 3 is the only place where the RP functional model is used. The rest of the document does not benefit from it, i.e. the threat descriptions do not identify the levels at which the threat actions and threat consequences occur. Having this type of analysis should help formulate the requirements for security mechanisms that should cover certain threats. The control and data plane within routing protocols does not seem to be used in the document at all and I wonder if we really need it there. 2. Byzantine failures as a threat. Section 4.8 talks about Byzantine failures and is positioned within the structure of the document as part of the "Generally Identifiable Routing Threats". It was not clear to me what threats different from those described in sections 4.1--4.7 are implied in this section. 3. Terminology. The document uses the term "forward" and "forwarder" to mean the routing message or PDU relaying process. This collides with the generally accepted use of these terms to mean data packet forwarding. My suggestion would be to not confuse these. More specific comments on the document: Section 1. Introduction 2nd para: > This documents takes a 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 Rggistry (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. --stands out from the 1st and 3rd. Since it defines a term, it might be a good idea to move to the very end of the section. ... > The security requirements derived from this analysis are intended to > be used as guidance to those who are designing and modifying routing > protocols. They may also be used by routing protocol implementers to > increase the robustness of their implementations. I would remove this one--seems that an explanation like this belongs in the reqs document itself. > 2. Routing Functions Overview ... > o Transport Subsystem: The routing protocol transmits messages to > its neighbors using some underlying protocol. For example, OSPF > uses IP, while AODV uses a broadcast link. Other protocols may run ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ what does this really mean? AODV uses UDP as the transport proto. > 3. Generic Routing Protocol Threat Model ... > At the routing function level threats can affect the transport > subsystem, where the routing protocol can be subject to attacks on > its underlying protocol. At the neighbor state maintenance level, > there are threats that can lead to attacks that can disrupt the > neighboring relationship with widespread consequences. For example, > if the DR election is disrupted in an OSPF network, what is meant by "DR election is disrupted"? > an unauthorized > router could be chosen as designated router. This might allow > unauthorized access to routing information. In fact, it is not necessary to be a DR to get access to OSPF LSAs, as they are flooded to all routers. > In BGP, if a router > receives a CEASE message, it can break the neighboring relationship > and cause any related topology information to be flushed. Strictly speaking, BGP does not carry topology information. > There are threats against the database maintenance functionality. For > example, the information in the database must be authentic and > authorized. Threats that jeopardize this information can affect the > routing functionality in the overall network. For example, if an > OSPF router sends LSA's with the wrong Advertising Router, the > receivers will compute a SPF tree that is incorrect and might not > forward the traffic. or will loop it, which is worse ... > 3.1.1 Threat Sources ... > 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 host is determined to be an outsider or an > insider from the point of view of a particular router. Even an > authorized protocol speaker can be an outsider to a particular router > if the router does not consider the speaker to be a legitimate peer > (as could conceivably happen on a multi-access link). This one is really hard to parse. Essentially what the text seems to say is that an insider is foo, but then that even the insider can be an outsider. Is it meant to say that router A authorized to talk to B, but not to C is an outsider to C? > 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. Furthermore, MANET protocols > frequently speak over the broadcast link. ^ and what does this mean? > 3.1.2 Threat Consequences ... > o Disclosure: Disclosure of routing information happens when a > router successfully accesses the information without being does it have to be a router? "an attacker" instead? > 4.6 Interference > ... > o When a subverted link is used to launch the action, the threat > consequence zone covers routers that are using the link to > exchange the routing information. not only. attack on a link causes consequences at the neighbor maintenance level, which causes changes in the database. i.e., the consequences are network-wide. > 4.7 Overload The section does not talk about state overloading in the control plane. I.e., since we trust all authorized routers, it is possible for e.g. a compromised router to trigger creation of an excessive amount of state that routers within the network are not able to handle. > 5. Security Considerations > > This entire informational draft RFC is security related. Specifically ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ change to "document"? > it addresses security of routing protocols as associated with threats > to those protocols. In a larger context, this work builds upon the > recognition of the IETF community that signaling and control/ > management planes of networked devices need strengthening. Routing > protocols can be considered part of that signaling and control plane. > However, to date, routing protocols have largely remained unprotected > and open to malicious attacks. This document discusses inter and > intra domain routing protocol threats as we know them today and lays > the foundation for a future draft which fully discusses security ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "other documents that will discuss"? > requirements for routing protocols. > Appendix B. Acronyms Some acronyms (e.g., LSRP, iBGP, eBGP) are not used in the document Regards -- Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Sep 16 19:48:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20199 for ; Tue, 16 Sep 2003 19:48:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zPYT-0007P2-Sw for rpsec-archive@odin.ietf.org; Tue, 16 Sep 2003 19:48:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GNmLgE028452 for rpsec-archive@odin.ietf.org; Tue, 16 Sep 2003 19:48:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zPYT-0007Op-Ne for rpsec-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 19:48:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20185 for ; Tue, 16 Sep 2003 19:48:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zPYR-00055O-00 for rpsec-web-archive@ietf.org; Tue, 16 Sep 2003 19:48:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zPYQ-00055K-00 for rpsec-web-archive@ietf.org; Tue, 16 Sep 2003 19:48:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zPY9-0007NV-I9; Tue, 16 Sep 2003 19:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zPXH-0007N6-JQ for rpsec@optimus.ietf.org; Tue, 16 Sep 2003 19:47:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20159; Tue, 16 Sep 2003 19:47:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zPXF-00055A-00; Tue, 16 Sep 2003 19:47:05 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19zPXE-000551-00; Tue, 16 Sep 2003 19:47:04 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8GNkXF05398; Tue, 16 Sep 2003 19:46:33 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Sep 2003 19:46:33 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75406EA46F3@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: internet-drafts@ietf.org Cc: Russ White , "Abbie Barbir" , Tony Tauber , rpsec@ietf.org Date: Tue, 16 Sep 2003 19:46:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C37CAC.C05584B8" Subject: [RPSEC] Request To Publish: draft-ietf-rpsec-routing-threats-03 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C37CAC.C05584B8 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37CAC.C05584B8" ------_=_NextPart_001_01C37CAC.C05584B8 Content-Type: text/plain Please publish the following draft-ietf-rpsec-routing-threats-03 as a WG Draft. Thanks Abbie ------_=_NextPart_001_01C37CAC.C05584B8 Content-Type: text/html Request To Publish: draft-ietf-rpsec-routing-threats-03

Please publish the following

draft-ietf-rpsec-routing-threats-03

as a WG Draft.

Thanks
Abbie

  ------_=_NextPart_001_01C37CAC.C05584B8-- ------_=_NextPart_000_01C37CAC.C05584B8 Content-Type: text/plain; name="draft-ietf-rpsec-routing-threats-03.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-rpsec-routing-threats-03.txt" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Network Working Group A. = Barbir Internet-Draft Nortel = Networks Expires: March 16, 2004 S. = Murphy Network Associates, = Inc Y. = Yang Cisco = Systems September 16, = 2003 Generic Threats to Routing Protocols draft-ietf-rpsec-routing-threats-03 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 16, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Routing protocols are subject to attacks that can harm individual users or network operations as a whole. This document provides a description and a summary of generic threats that affects routing protocols in general. This work describes threats, including threat sources and capabilities, threat actions, and threat consequences as well as a breakdown of routing functions that might be separately attacked. Barbir, et al. Expires March 16, 2004 [Page = 1] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. Routing Functions Overview . . . . . . . . . . . . . . . . . = 4 3. Generic Routing Protocol Threat Model . . . . . . . . . . . = 5 3.1 Threat Definitions . . . . . . . . . . . . . . . . . . . . . = 5 3.1.1 Threat Sources . . . . . . . . . . . . . . . . . . . . . . . = 6 3.1.2 Threat Consequences . . . . . . . . . . . . . . . . . . . . = 7 4. Generally Identifiable Routing Threats . . . . . . . . . . . = 11 4.1 Deliberate Exposure . . . . . . . . . . . . . . . . . . . . = 11 4.2 Sniffing . . . . . . . . . . . . . . . . . . . . . . . . . . = 11 4.3 Traffic Analysis . . . . . . . . . . . . . . . . . . . . . . = 12 4.4 Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . = 12 4.5 Falsification . . . . . . . . . . . . . . . . . . . . . . . = 13 4.5.1 Falsifications by Originators . . . . . . . . . . . . . . . = 13 4.5.2 Falsifications by Forwarders . . . . . . . . . . . . . . . . = 16 4.6 Interference . . . . . . . . . . . . . . . . . . . . . . . . = 17 4.7 Overload . . . . . . . . . . . . . . . . . . . . . . . . . . = 18 4.8 Byzantine Failures . . . . . . . . . . . . . . . . . . . . . = 18 5. Security Considerations . . . . . . . . . . . . . . . . . . = 19 Normative References . . . . . . . . . . . . . . . . . . . . = 20 Informative References . . . . . . . . . . . . . . . . . . . = 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . = 21 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . = 23 B. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . = 24 Intellectual Property and Copyright Statements . . . . . . . = 25 Barbir, et al. Expires March 16, 2004 [Page = 2] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 1. Introduction Routing protocols are subject to threats and attacks that can harm individual users or the network operations as a whole. The document provides a summary of generic threats that affects routing = protocols. In particular, this work identifies generic threats to routing protocols that include threat sources, threat actions, and threat consequences. A breakdown of routing functions that might be separately attacked is provided. This work should be considered as a precursor to developing a common set of security requirements for routing protocols. While it is well known that bad, incomplete, or poor implementations of routing protocols may, in themselves, lead to routing problems or failures, or may increase the risk of a network being attacked successfully, these issues are not considered here. This document only considers attacks against robust, well considered implementations of routing protocols, as outlined in OSPF [6], IS-IS [10] , RIP [11] and BGP [17]. 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. The document is organized as follows: Section 2 provides a review of routing functions. Section 3 defines threats. In section 4 a discussion on generally identifiable routing threat actions is provided. Section 5 addresses security considerations. Barbir, et al. Expires March 16, 2004 [Page = 3] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 2. Routing Functions Overview This section provides an overview of common functions that are = shared among various routing protocols. In general, routing protocols share the following functions: o Transport Subsystem: The routing protocol transmits messages to its neighbors using some underlying protocol. For example, OSPF uses IP, while other protocols may run over TCP. o Neighbor State Maintenance: neighboring relationship formation is the first step for topology determination. For this reason, routing protocols may need to maintain the state of their neighbors. Each routing protocol may use a different mechanism for determining its neighbors in the routing topology. Some protocols have distinct exchange through which they establish neighboring relationships, e.g., Hello exchanges in OSPF. o Database Maintenance: Routing protocols exchange network topology and reachability information. The routers collect this information in routing databases with varying detail. The maintenance of these databases is a significant portion of the function of a routing protocol. 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. Barbir, et al. Expires March 16, 2004 [Page = 4] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 3. Generic Routing Protocol Threat Model The model developed in this section can be used to identify threats to any routing protocol. It examines attacks which can be launched against routing from subverted entities within the routing system, and from entities outside the routing system. Both of these types of entities are called unauthorized entities. Routing protocols are subject to treats at the control and data planes and at the functional level. At the control plane level, control and data plane are subject to attack. An attacker may be = able to break a neighbor (e.g., peering, adjacency) relationship. This type of attack can impact the network routing behavior in the affected routers and likely the surrounding neighborhood. An attacker who is able to break a database exchange between two = routers can also affect routing behavior. In the routing protocol data plane, an attacker who is able to introduce bogus data can have a strong effect on the behavior of routing in the neighborhood. At the routing function level threats can affect the transport subsystem, where the routing protocol can be subject to attacks on its underlying protocol. At the neighbor state maintenance level, there are threats that can lead to attacks that can disrupt the neighboring relationship with widespread consequences. For example, in BGP, if a router receives a CEASE message, it can lead to = breaking of its neighboring relationship to other routers. There are threats against the database maintenance functionality. = For example, the information in the database must be authentic and authorized. Threats that jeopardize this information can affect the routing functionality in the overall network. For example, if an OSPF router sends LSAs with the wrong Advertising Router, the receivers will compute a SPF tree that is incorrect and might not forward the traffic. If a BGP router advertises a NLRI that it is not authorized to advertise, then receivers might forward that = NLRI's traffic toward that router and the traffic would not be deliverable. A PIM router might transmit a JOIN message to receive multicast data it would otherwise not receive 3.1 Threat Definitions In this work, a threat is defined as a motivated, capable adversary. This characterization of threats clearly distinguishes threats from attacks. By modeling the motivations (attack goals) and capabilities of the adversaries who are threats, one can better understand what classes of attacks these threats may mount and thus what types of countermeasures will be required to deal with these attacks. In [1] = a threat is defined as a potential for violation of security, which Barbir, et al. Expires March 16, 2004 [Page = 5] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 exists when there is a circumstance, capability, action, or event that could breach security and cause harm. A threat presents itself when an adversary has the ability to take advantage of an existing security weakness. Threats can be categorized based on various rules, such as threat sources, threat actions, threat consequences, threat consequence zones, and threat consequence periods. 3.1.1 Threat Sources There are many sources for threats that may affect routing = protocols. In some cases, unauthorized entities such as attackers may illegally participate in the routing operations. In other circumstances, there are threats to routing protocols from entities that are running incorrect code, or using invalid configurations. 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). In general, threats can be classified into the following categories based on their sources [2]: 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. o Threats that result from subverted devices (e.g. routers): A subverted device (router) is an authorized router that may have been broken into by an attacker. The attacker can use the subverted device to inappropriately claim authority for some network resources, or violate routing protocols, such as advertising invalid routing information. 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. Barbir, et al. Expires March 16, 2004 [Page = 6] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 3.1.2 Threat Consequences A threat consequence is a security violation that results from a threat action [1]. The compromise to the behavior of the routing system can damage a particular network or host or can damage the operation of the network as a whole. There are four types of threat consequences: disclosure, deception, disruption, and usurpation [1]. o Disclosure: Disclosure of routing information happens when a router successfully accesses the information without being authorized. Subverted links can cause disclosure, if routing exchanges lack confidentiality. Subverted devices (routers), can cause disclosure, as long as they are successfully involved in = the routing exchanges. Although inappropriate disclosure of routing information can pose a security threat or be part of a later, larger, or higher layer attack, confidentiality is not generally = a design goal of routing protocols. o Deception: This consequence happens when a legitimate router receives a false routing message and believes it to be true. Subverted links and/or subverted device (routers)can cause this consequence if the receiving router lacks ability to check routing message integrity, routing message origin, authentication or peer router authentication. o Disruption: This consequence occurs when a legitimate router's operation is being interrupted or prevented. Subvert links can cause this by replaying, delaying, or dropping routing messages, or breaking routing sessions between legitimate routers. = Subverted devices (router) can cause this consequence by sending false routing messages, interfering normal routing exchanges, or flooding unnecessary messages. (DoS is a common threat action causing disruption.) o Usurpation: This consequence happens when an attacker gains control over a legitimate router's services/functions. Subverted links can cause this by delaying or dropping routing exchanges, = or replaying out-dated routing information. Subverted routers can cause this consequence by sending false routing information, interfering routing exchanges, or system integrity. Note: an attacker does not have to directly control a router to control its services. For example, in Figure 1, Network 1 is dual-homed through Router A and Router B, and Router A is preferred. However, Router B is compromised and advertises a lower metric. Consequently, devices on the Internet choose the path through Router Barbir, et al. Expires March 16, 2004 [Page = 7] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 B to reach Network 1. In this way, Router B steals the data traffic and Router A surrenders its control of the services to Router B. = This depicted in Figure 1. +-------------+ +-------+ | Internet |---| Rtr A | +------+------+ +---+---+ | | | | | | | *-+-* +-------+ / \ | Rtr B |----------* N 1 * +-------+ \ / *---* Figure 1: Dual-homed Network Several threat consequences might be caused by a single threat action. In Figure 1, there exist at least two consequences: routers using Router B to reach Network 1 are deceived, while Router A is usurped. Within the context of the threat consequences described above, = damage that might result from attacks against the network as a whole may include: o Network congestion: more data traffic is forwarded through some portion of the network than would otherwise need to carry the traffic, o 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, o Looping: data traffic is forwarded along a route that loops, so that the data is never delivered (resulting in network congestion), o Partition: some portion of the network believes that it is partitioned from the rest of the network when it is not, o Churn: the forwarding in the network changes (unnecessarily) at a rapid pace, resulting in large variations in the data delivery patterns (and adversely affecting congestion control techniques), Barbir, et al. Expires March 16, 2004 [Page = 8] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 o Instability: the protocol becomes unstable so that convergence on a global forwarding state is not achieved, and o Overload: the protocol messages themselves become a significant portion of the traffic the network carries. The damage that might result from attacks against a particular host or network address may include: o Starvation: data traffic destined for the network or host is forwarded to a part of the network that cannot deliver it, o Eavesdrop: data traffic is forwarded through some router or network that would otherwise not see the traffic, affording an opportunity to see the data or at least the data delivery = pattern, o Cut: some portion of the network believes that it has no route to the host or network when it is in fact connected, o Delay: data traffic destined for the network or host is forwarded along a route that is in some way inferior to the route it would otherwise take, o Looping: data traffic for the network or host is forwarded along = a route that loops, so that the data is never delivered It is important to consider all compromises, because some security solutions can protect against one attack but not against others. It might be possible to design a security solution that protects against an attack that eavesdropped on one destination's traffic without protecting against an attack that overwhelmed a router. Similarly, it is possible to design a security solution that = prevents a starvation attack against one host, but not against a network = wide resources. The security requirements must be clear as to which compromises are being avoided and which compromises must be = addressed by other means (e.g., by administrative means outside the = protocol). 3.1.2.1 Threat Consequence Zone A threat consequence zone covers the area within which the network operations have been affected by threat actions. Possible threat consequence zones can be classified as: a single link or router, multiple routers (within a single routing domain), a single routing domain, multiple routing domains, or the global Internet. The threat consequence zone varies based on the threat action and origin. Similar threat actions that happened at different locations may = cause totally different threat consequence zones. For example, when a compromised link breaks the routing session between a distribution Barbir, et al. Expires March 16, 2004 [Page = 9] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 router and a stub router, only reachability to and from the network devices attached on the stub router will be impaired. In other = words, the threat consequence zone is a single router. Nonetheless, if the compromised router is located between a customer edge router and its corresponding provider edge router, such an action might cause the whole customer site to lose its connection. In this case, the threat consequence zone might be a single routing domain. 3.1.2.2 Threat Consequence Periods Threat consequence period is defined as a portion of time during which the network operations have been impacted by the threat consequences. The threat consequence period is influenced by, but = not totally dependent on the duration of the threat action. In some cases, the network operations will get back to normal as soon as the threat action has been stopped. In other cases, however, threat consequences may appear longer than threat action. For example, in the original ARPANET link-state algorithm, some errors in a router might introduce three instances of an LSA, and all of them would be flooded throughout the network forever, until the entire network was power cycled [3]. Barbir, et al. Expires March 16, 2004 [Page = 10] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 4. Generally Identifiable Routing Threats This section addresses generally identifiable and recognized threat action against routing protocols. The threats are not necessarily specific to individual protocols but may be present in one or more = of the common routing protocols in use today. 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. The consequence of deliberate exposure is the disclosure of routing information. The threat consequence zone of deliberate exposure depends on the routing information that the attackers have exposed. The more knowledge they have exposed, the bigger the threat consequence zone. The threat consequence period of deliberate exposure might be longer than the duration of the action itself. The routing information exposed will not be out-dated until there is a topology change of = the exposed network. 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. The consequence of sniffing is disclosure of routing information. The threat consequence zone of sniffing depends on the attacker's location, the routing protocol type, and the routing information = that has been recorded. For example, if the subverted link is in an OSPF totally stubby area, the threat consequence zone should be limited = to the whole area. An attacker that is sniffing a subverted link in an EBGP session can gain knowledge of multiple routing domains. The threat consequence period might be longer than the duration of the action. If an attacker stops sniffing a subverted link their acquired knowledge will not be out-dated until there is a topology change of the affected network. Barbir, et al. Expires March 16, 2004 [Page = 11] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 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. The consequence of data traffic analysis is the disclosure of = routing information. For example, the source and destination IP address of the data traffic, the type, magnitude, and volume of traffic is disclosed. The threat consequence zone of the traffic analysis depends on the attacker's location and what data traffic has passed through. A subverted link at the network core should be able to disclose more information than its counterpart at the edge. The threat consequence period might be longer than the duration of the traffic analysis. After the attacker stops traffic analysis, its knowledge will not be out-dated until there is a topology change of the disclosed network. 4.4 Spoofing Spoofing occurs when an illegitimate device assumes the identity of = a legitimate one. Spoofing in and of itself is often not the true attack. Spoofing is special in that it can be used to carry out = other threat actions causing other threat consequences. An attacker can = use spoofing as a means for launching other types of attacks. For example, if an attacker succeeds in spoofing the identity of a router, the subverted router can act as a masquerading router. In other situations, the spoofed router can be used to send out unrealistic routing information that might cause the disruption of network services. There are a few cases where spoofing can be an attack in and of itself. For example, messages from an attacker which spoof the identity of a legitimate router may cause a neighbor relationship to form and deny the formation of the relationship with the legitimate router. The consequences of spoofing are: o The disclosure of routing information: The spoofed router will be able to gain access to the routing information. o The deception of peer relationship: The authorized routers, = which Barbir, et al. Expires March 16, 2004 [Page = 12] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 exchange routing messages with the spoofed router, do not realize they are neighboring with a router that is faking another = router's identity. The threat consequence zone includes: The consequence zone of the disclosed routing information depends on what routing information has been exchanged between the = spoofed router and its neighbors. The threat consequence zone covers: o The consequence zone of the fake peer relationship will be = limited to those routers mistrusting the attacker's identity. o The consequence zone of the disclosed routing information depends on the attacker's location, the routing protocol type, and the routing information that has been exchanged between the attacker and its deceived neighbors. 4.5 Falsification 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. 4.5.1 Falsifications by Originators An originator of routing information can launch the falsifications that are described in the next sections. 4.5.1.1 Overclaiming Overclaiming occurs when a subverted router advertises its control = of some network resources, while in reality it does not, or the advertisement is not authorized. This is given in Figure 2 and Figure 3. Barbir, et al. Expires March 16, 2004 [Page = 13] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 +-------------+ +-------+ +-------+ | Internet |---| Rtr B |---| Rtr A | +------+------+ +-------+ +---+---+ | . | | | . | *-+-* +-------+ / \ | Rtr C |------------------* N 1 * +-------+ \ / *---* Figure 2: Overclaiming-1 +-------------+ +-------+ +-------+ | Internet |---| Rtr B |---| Rtr A | +------+------+ +-------+ +-------+ | | | | *---* +-------+ / \ | Rtr C |------------------* N 1 * +-------+ \ / *---* Figure 3: Overclaiming-2 The above figures provide examples of overclaiming. Router A, the attacker, is connected with the Internet through Router B. Router C is authorized to advertise its link to Network 1. In Figure 2, = Router A controls a link to Network 1, but is not authorized to advertise it. In Figure 3, Router A does not control such a link. But in = either case, Router A advertises the link to the Internet, through Router = B. Compromised routers, unauthorized routers, and masquerading routers can overclaim network resources. The consequence of overclaiming includes: o Usurpation of the overclaimed network resources. In Figure 2 and Figure 3, it will cause a usurpation of Network 1 when Router B = or other routers on the Internet (not shown in the figures) believe that Router A provides the best path to reach the Network 1. = They, the routers, thereby forward the data traffic, destined to = Network Barbir, et al. Expires March 16, 2004 [Page = 14] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 1, to Router A. The best result is the data traffic uses an unauthorized path Figure 2, and the worst case is the data never reach the destination Network 1 Figure 3. The ultimate consequence is Router A gaining control over Network 1's = services, by controlling the data traffic. o Usurpation of the legitimate advertising routers. In Figure 2 = and Figure 3, Router C is the legitimate advertiser of Network 1. By overclaiming, Router A also controls (partially or totally) the services/functions provided by the Router C. (This is NOT a disruption, because Router C is operating in a way intended by = the authoritative network administrator.) o Deception of other routers. In Figure 2 and Figure 3, Router B, = or other routers on the Internet, might be deceived to believe the path through Router A is the best. o Disruption of data planes on some routers. This might happen on routers that are on the path, which is used by other routers to reach the overclaimed network resources through the attacker. In Figure 2 and Figure 3, when other routers on the Internet are deceived, they will forward the data traffic to Router B, which might be overloaded. The threat consequence zone varies based on the consequence: o Where usurpation is concerned, the consequence zone covers the network resources that are overclaimed by the attacker (Network 1 in Figure 2 and 3), and the routers that are authorized to advertise the network resources but lose the competition against the attacker(Router C in Figure 2 and Figure 3). o Where deception is concerned, the consequence zone covers the routers that do believe the attacker's advertisement and use the attacker to reach the claimed subnets (Router B and other = deceived routers on the Internet in Figure 2 and Figure 3). 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). The threat consequence will cease when the attacker stops overclaiming, and will totally disappear when the routing tables are converged. As a result the consequence period is longer than the duration of the overclaiming. 4.5.1.2 Misclaiming Barbir, et al. Expires March 16, 2004 [Page = 15] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 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. An attacker can eulogize or disparage when advertising these network resources. Subverted routers, unauthorized routers, and masquerading routers = can misclaim network resources. The threat consequences of misclaiming are similar to the consequences of overclaimin. The consequence zone and period are also similar to those of overclaiming. 4.5.2 Falsifications by Forwarders When a legitimate router forwards routing information, it must or must not modify the routing information, depending on the routing information and the routing protocol type. For example, in RIP, the forwarder must modify the routing information by increasing the hop count by 1. On the other hand, the forwarder must not modify the = type 1 LSA in OSPF. In general, forwarders in distance vector routing protocols are authorized to and must modify the routing information, while most forwarders in link state routing protocols are not authorized to and must not modify most routing information. As a forwarder authorized to modify routing message, an attacker might not forward necessary routing information to other authorized routers. Unauthorized aggregation (summarization) is special type of understatement. 4.5.2.1 Misstatement This is defined as an action whereby the attacker describes route attributes in an incorrect manner. For example, in RIP, the attacker might increase the path cost by two hops instead of one. In BGP, the attacker might delete some AS numbers from the AS PATH. Where forwarding routing information should not be modified, an attacker can launch the following falsifications: o Deletion: Attacker deletes valid data in the routing message. o Insertion: Attacker inserts false data in the routing message. o Substitution: Attacker replaces valid data in the routing message with false data. Barbir, et al. Expires March 16, 2004 [Page = 16] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 o Replaying: Attacker replays out-dated data in the routing = message. All types of attackers (Compromised links, compromised routers, unauthorized routers, and masquerading routers) can falsify the routing information when they forward the routing messages. The threat consequences of these falsifications by forwarders are similar to those caused by originators: Usurpation of some network resources and related routers; deception of routers using false paths; and disruption of data planes of routers on the false paths. The threat consequence area and period are also similar. 4.6 Interference Interference is a threat action where an attacker uses a subverted link or router to inhibit the exchanges by legitimate routers. The attacker can do this by adding noise, or by not forwarding packets, or by replaying out-dated packets, or by delaying responses, or by denial of receipts, and breaking synchronization. Subverted, unauthorized and masquerading routers can slowdown their routing exchanges or create flapping routing sessions of legitimate neighboring routers. The consequence of interference is the disruption of routing operations. The consequence zone of interference varies based on the source of the threats: o When a subverted link is used to launch the action, the threat consequence zone covers routers that are using the link to exchange the routing information. An attack on a link can cause consequences at the neighbor maintenance level, that may lead to changes in the database. In this case, the consequences can be felt network-wide. o When subverted routers, unauthorized routers, or masquerading routers are the attackers, the threat consequence zone covers routers with which the attackers are exchanging routing information. o The threat consequences might disappear as soon as the interference is stopped, or might not totally disappear until the networks have converged. Therefore, the consequence period is equal or longer than the duration of the interference. Barbir, et al. Expires March 16, 2004 [Page = 17] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 4.7 Overload Overload is defined as a threat action whereby attackers place = excess burden on legitimate routers. For example, it is possible for an attacker to overload the control plane. In this regard, it is possible for a compromised router to trigger creation of an = excessive amount of state that routers within the network are not able to handle. In a similar fashion, it is possible for an attacker to overload the data plane. Since data plane is involved in routing exchanges, overload of the data plane can also influence the routing operations. This section combines overload of the control plane and the data plane (i.e., the routing protocol messages and the data traffic, not the control and data plane of the routing protocol itself as discussed in section 2.1). The routing protocol design might have a chance to limit control plane traffic. However, the routing protocol cannot limit the data traffic. Thus, an attacker can affect the behavior of the entire routing system. 4.8 Byzantine Failures As described in [4], "A node with a Byzantine failure may corrupt messages, forge messages, delay messages, or send conflicting messages to different nodes." These faults may arise from routers which have been subverted by an attacker or which have faulty hardware or software. In any case, they represent a threat to correct operation of routing and routing protocols. The ability of the network to function in the face of such defects = is described as Byzantine robustness and would fall into the scope of a requirements document for routing protocol security which may build from the base established in this document. Barbir, et al. Expires March 16, 2004 [Page = 18] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 5. Security Considerations This entire document is security related. Specifically the document addresses security of routing protocols as associated with threats = to those protocols. In a larger context, this work builds upon the recognition of the IETF community that signaling and control/ management planes of networked devices need strengthening. Routing protocols can be considered part of that signaling and control = plane. However, to date, routing protocols have largely remained = unprotected and open to malicious attacks. This document discusses inter- and intra-domain routing protocol threats that are currently known and lays the foundation for other documents that will discuss security requirements for routing protocols. Barbir, et al. Expires March 16, 2004 [Page = 19] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 Normative References [1] Shirey, R, "Internet Security Glossary", RFC 2828 , May 2000. [2] Smith, R et al., "Securing Distance-Vector Routing Protocols", Symposium on Network and Distributed System Security , February 1997. [3] Rosen, E., "Vulnerabilities of Network Control Protocols: An Example, Computer Communication Review", , July 1981. [4] Perlman, R, "Network Layer Protocols with Byzantine Robustness", , August 1988 . [5] Murphy, S et al., "OSPF with Digital Signatures", RFC 2154 , June 1997. [6] Moy, J, "OSPF Version 2", RFC 2328 , April 1998. [7] Mittal, V et al., "Sensor-Based Intrusion Detection for Intra-Domain istance-Vector Routing", Proceedings of the ACM Conference on Computer and Communication Security (CCS'02), Washington, DC , November 2002. [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. [10] Shen, N. et. al., "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 2763 , February 2000. [11] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1721 , November 1994. Barbir, et al. Expires March 16, 2004 [Page = 20] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 Informative References [12] Vetter, W. et al., "Experimental Study of Insider Attacks in = a Link State Routing Protocol", 5th IEEE International Conference on Network Protocols, Atlanta, GA , 1997. [13] "Internet Group Management Protocol", RFC 3376 , October = 2002. [14] Estrin, D. et al., "Independent Multicast-Sparse Mode = (PIM-SM): Protocol pecification", RFC 2362 , June 1998 . [15] Ballardie, A. et al., "Multicast-Specific Security Threats and Counter-Measures", "Symposium on network and Distributed System Security" , February 1995. [16] Smith, A. et al., "Securing the Border Gateway Routing Protocol", Proc. Global Internet'96 , November 1996. [17] Kent, S. et al., "Secure Border Gateway Protocol (Secure-BGP)", IEEE Journal on Selected Areas in = Communications , April 2000. Authors' Addresses Abbie Barbir (Editor) Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: EMail: abbieb@nortelnetworks.com Sandy Murphy Network Associates, Inc 3060 Washington Rd. Glenwood, MD 21738 USA Phone: 443-259-2303 EMail: sandy@tislabs.com Barbir, et al. Expires March 16, 2004 [Page = 21] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 Yi Yang Cisco Systems 7025 Kit Creek Road RTP, NC 27709 Canada Phone: EMail: yiya@cisco.com Barbir, et al. Expires March 16, 2004 [Page = 22] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 Appendix A. Acknowledgements This draft would not have been possible save for the excellent efforts and team work characteristics of those listed here. o Dennis Beard- Nortel Networks o Ayman Musharbash - Nortel Networks o Jean-Jacques Puig, int-evry, France o Paul Knight - Nortel Networks o Elwyn Davies - Nortel Networks o Ameya Dilip Pandit - Graduate student - University of Missouri o Senthilkumar Ayyasamy - Graduate student - University of Missouri o Stephen Kent- BBN Barbir, et al. Expires March 16, 2004 [Page = 23] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 Appendix B. Acronyms AODV - Ad-hoc On-demand Distance Vector routing protocol AS - Autonomous system. Set of routers under a single technical administration. Each AS normally uses a single interior gateway protocol (IGP) and metrics to propagate routing information within the set of routers. Also called routing domain. AS-Path - In BGP, the route to a destination. The path consists of the AS numbers of all routers a packet must go through to reach a destination. BGP - Border Gateway Protocol. Exterior gateway protocol used to exchange routing information among routers in different autonomous systems. LSA - Link-State Announcement M-OSPF - Multicast Open Shortest Path First NLRI - Network layer reachability information. Information that is carried in BGP packets and is used by MBGP. OSPF - Open Shortest Path First. A link-state IGP that makes routing decisions based on the shortest-path-first (SPF) algorithm (also referred to as the Dijkstra algorithm). Barbir, et al. Expires March 16, 2004 [Page = 24] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances = of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification = can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Barbir, et al. Expires March 16, 2004 [Page = 25] =0C Internet-Draft Generic Threats to Routing Protocols September = 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barbir, et al. Expires March 16, 2004 [Page = 26] =0C ------_=_NextPart_000_01C37CAC.C05584B8-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Sep 17 09:52:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11484 for ; Wed, 17 Sep 2003 09:52:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zcjC-0007Hm-4M for rpsec-archive@odin.ietf.org; Wed, 17 Sep 2003 09:52:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HDqInO028000 for rpsec-archive@odin.ietf.org; Wed, 17 Sep 2003 09:52:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zcjC-0007HX-0K for rpsec-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 09:52:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11419 for ; Wed, 17 Sep 2003 09:52:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zcjA-0006A0-00 for rpsec-web-archive@ietf.org; Wed, 17 Sep 2003 09:52:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zcj9-00069x-00 for rpsec-web-archive@ietf.org; Wed, 17 Sep 2003 09:52:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zciv-0007Cf-R4; Wed, 17 Sep 2003 09:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zciD-00077t-SZ for rpsec@optimus.ietf.org; Wed, 17 Sep 2003 09:51:17 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11321; Wed, 17 Sep 2003 09:51:08 -0400 (EDT) Message-Id: <200309171351.JAA11321@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rpsec@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 17 Sep 2003 09:51:07 -0400 Subject: [RPSEC] I-D ACTION:draft-ietf-rpsec-routing-threats-03.txt 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Protocol Security Requirements Working Group of the IETF. Title : Generic Threats to Routing Protocols Author(s) : A. Barbir, S. Murphy, Y. Yang Filename : draft-ietf-rpsec-routing-threats-03.txt Pages : 26 Date : 2003-9-17 Routing protocols are subject to attacks that can harm individual users or the network operations as a whole. This document provides a description and a summary of generic threats that affects routing protocols in general. The work describes threats, including threat sources and capabilities, threat actions, and threat consequences as well as a breakdown of routing functions that might be separately attacked. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-routing-threats-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rpsec-routing-threats-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rpsec-routing-threats-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-17093239.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rpsec-routing-threats-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rpsec-routing-threats-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-17093239.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Sep 17 17:15:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00153 for ; Wed, 17 Sep 2003 17:15:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjdt-00080w-R5 for rpsec-archive@odin.ietf.org; Wed, 17 Sep 2003 17:15:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HLFHZE030800 for rpsec-archive@odin.ietf.org; Wed, 17 Sep 2003 17:15:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjdt-00080h-MZ for rpsec-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 17:15:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00144 for ; Wed, 17 Sep 2003 17:15:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zjdr-0003mv-00 for rpsec-web-archive@ietf.org; Wed, 17 Sep 2003 17:15:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zjdr-0003mr-00 for rpsec-web-archive@ietf.org; Wed, 17 Sep 2003 17:15:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjdf-0007yV-Jw; Wed, 17 Sep 2003 17:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjdK-0007yD-5j for rpsec@optimus.ietf.org; Wed, 17 Sep 2003 17:14:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00119 for ; Wed, 17 Sep 2003 17:14:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zjdH-0003mS-00 for rpsec@ietf.org; Wed, 17 Sep 2003 17:14:40 -0400 Received: from mesa.bbnplanet.com ([171.78.172.21]) by ietf-mx with esmtp (Exim 4.12) id 19zjdH-0003m9-00 for rpsec@ietf.org; Wed, 17 Sep 2003 17:14:39 -0400 Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h8HLDx927452 for ; Wed, 17 Sep 2003 17:13:59 -0400 (EDT) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Wed, 17 Sep 2003 17:13:58 -0400 (EDT) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] Agenda items for IETF 58 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Hi folks, Please let us know what you'd like to present (or see presented?) at the next meeting in Minneapolis. Thanks, Tony and Russ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Sep 17 17:33:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01108 for ; Wed, 17 Sep 2003 17:33:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjv6-0008OK-Sy for rpsec-archive@odin.ietf.org; Wed, 17 Sep 2003 17:33:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HLX41i032250 for rpsec-archive@odin.ietf.org; Wed, 17 Sep 2003 17:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjv6-0008O5-PP for rpsec-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 17:33:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01100 for ; Wed, 17 Sep 2003 17:32:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zjv4-00046p-00 for rpsec-web-archive@ietf.org; Wed, 17 Sep 2003 17:33:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zjv3-00046m-00 for rpsec-web-archive@ietf.org; Wed, 17 Sep 2003 17:33:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjv3-0008Mu-Pt; Wed, 17 Sep 2003 17:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjuF-0008MZ-KN for rpsec@optimus.ietf.org; Wed, 17 Sep 2003 17:32:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01076 for ; Wed, 17 Sep 2003 17:32:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zjuD-00046H-00 for rpsec@ietf.org; Wed, 17 Sep 2003 17:32:09 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19zjuC-000450-00 for rpsec@ietf.org; Wed, 17 Sep 2003 17:32:08 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 17 Sep 2003 14:31:54 -0700 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8HLVb5g003372 for ; Wed, 17 Sep 2003 17:31:37 -0400 (EDT) Received: from russpc.whitehouse.intra (rtp-vpn1-477.cisco.com [10.82.225.221]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA29096 for ; Wed, 17 Sep 2003 17:31:36 -0400 (EDT) Date: Wed, 17 Sep 2003 17:31:39 -0400 (Eastern Daylight Time) From: Russ White Reply-To: Russ White To: Routing Protocols Security Working Group Message-ID: X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] RP Requirements Doc Comments... 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , 2. General considerations .... 2.1 What MUST / SHOULD be protected ? Distribution of destination reachability information with the required policy considerations (QoS, trusted route, etc.) is what is expected from a routing protocol. Possibly replace with: Routing protocols act as distributed databases with very quick synchornzation times. They are responsible for distributing information about reachability to destinations attached to the network, and the distribution of policies about the available paths. Note that policy propogation within a routing protocol which operates between administrative routing domains, exterior gateway protocols, is very difficult. This particular area of security is fraught with difficulties making it next to impossible to actually secure policy across multiple administrative domains. Reachability MUST be protected against unauthorized route deletions and route additions. Note that these are high level operations; aggregation, for instance, may result in the same consequences as announcing new routes. ....or the removal of some routing information, and the policies attending that routing information. Route attributes (path information, metrics, trusted entity for the forwarding of specific traffics) SHOULD also be protected. [TBD] We have to decide if route attributes require as much protection as route existence, probably yes. Note that manipulation of a routes associated attributes may achieve the same effects as those resulting from addition / deletion. I think you can mention this, but it's actually going to be difficult to impossible to find any way of securing policies within an EGP. Since each administrative domain can add policies to a given route, anyone can essentially insert any policy. The question: "Who's policy are we honoring" has to be answered before we can begin to think about this. The originator's policy? Or the AS we received the route from? Or the AS that currently has the route? Or some other AS? Traffic overload may provoke DOS of routing negotiations, while these would help in balancing the high traffic. Forwarding is usually the principal purpose of devices running routing protocols. In order to achieve correctness of forwarding tables, means to enforce availability of the medium to the routing protocol SHOULD be provided. You mean protection against traffic overload may provide opportunities for DOS attacks? The wording is just backwards, I think, in the first sentence. 2.2 Transport Layer Considerations .... A routing protocol designed to be, within certain extent, Transport Layer independent, may provide options to activate inner security features on-demand. Though such a flexibility would help avoiding potential redundancy of functions with the Transport Layer and adjusting performance requirements, such an approach is usually not Do you mean "lower layer" when you say "inner?" desirable because of it's added complexity. I don't understand what this sentence is saying, actually. The Tranport Layer may already grant the following properties: "Grant" vs "provide?" o Neighboring: a technology may provide a way to address adjacent neighbors. The neighboring range in this kind of technology is typically of one system away and relies on direct mapping over the Link Layer. o Neighbor discovery and maintenance: A given transport layer technology may provide a way to discover and communicate with adjacenct devices participating in the routing domain (neighbors). I don't know if you want to say anything about direct mapping to the link layer--what would you mean by this? Something like what IS-IS does? It doesn't seem to apply to OSPF, EIGRP, or BGP? o Integrity: the Transport Layer may provide data integrity. This is insufficient to achieve security without proper means of authenticating the system which provided the integrity proof in the first place. Replace with: o Integrity: While the transport layer chosen by the routing protocol designer may provide data integrity, most data integrity techaniwues do not provide security. To provide secure data integrity, the transport must use some form of cryptographic hashing or signatures to validate data integrity. Or something along these lines (?). o Authenticity: if the underlying layer both provides authenticity and integrity, many routing threats may be thwarted. Further considerations are required though, among which are resistance to replay, performance, Byzantine detection and robustness, etc. I assume further requirements for integrity will be discussed someplace else, later on? Otherwise, this is a bit skimpy. 3. Cryptographic requirements 3.1 Basic cryptographic requirements The following requirements are understood on a producer / consumer of the routing information basis. Forwarders of the information may not need to provide the following, if they do not modify the content of messages. Integrity: data integrity is an obvious requirement. Wht do you mean by integrity, though? Should you attempt to define integrity in some way, or refer to a definition provided in the security definitions draft? Anti-replay: this comes here mainly for protection against active attacks from subverted links, though this feature will also provide added protection against natural duplication of packets. Note that underlying layers may provide an unauthenticated anti-replay feature, which would be of no use from a security point of view. Unless the actual data used for preventing replay is also authenticated--I'd probably mention this. So, something like: Anit-Replay: In order to routing protocol peering sessions on subverted, or publicly accessible, links, the transport used by a routing protocol SHOULD provide some form of anti-replay protection. Note that if this anti-replay mechanism is not part of a cryptographic system, or is not cryptographically protected through integrity validation procedures, More later, as I get the chance to look over other parts. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Sat Sep 20 09:54:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04986 for ; Sat, 20 Sep 2003 09:54:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nml-0001aL-Oh for rpsec-archive@odin.ietf.org; Fri, 19 Sep 2003 12:07:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JG77Ym006082 for rpsec-archive@odin.ietf.org; Fri, 19 Sep 2003 12:07:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nmj-0001ZR-KR for rpsec-web-archive@optimus.ietf.org; Fri, 19 Sep 2003 12:07:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04845 for ; Fri, 19 Sep 2003 12:03:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0NjP-0003Dp-00 for rpsec-web-archive@ietf.org; Fri, 19 Sep 2003 12:03:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0Nj0-00039w-00 for rpsec-web-archive@ietf.org; Fri, 19 Sep 2003 12:03:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nip-0008Tw-R3; Fri, 19 Sep 2003 12:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Ni1-0008Br-Tx for rpsec@optimus.ietf.org; Fri, 19 Sep 2003 12:02:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04141 for ; Fri, 19 Sep 2003 12:02:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0JE5-0000bB-00 for rpsec@ietf.org; Fri, 19 Sep 2003 07:15:01 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A0J47-00066S-00 for rpsec@ietf.org; Fri, 19 Sep 2003 07:04:43 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8JB46J15336; Fri, 19 Sep 2003 07:04:06 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Sep 2003 07:04:06 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75406F1730B@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Russ White , Routing Protocols Security Working Group Subject: RE: [RPSEC] RP Requirements Doc Comments... Date: Fri, 19 Sep 2003 07:04:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37E9D.BDD988C2" 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37E9D.BDD988C2 Content-Type: text/plain Russ, Thanks for the feedback. Overall the doc is a good start. However, I have some concerns with the overall structure of the document. First, the doc does not take advantage of the work/knowledge that was acquired from the genral threat doc. It seems to me that the approach must be slightly different. The proper way to go (in my opinion) is to identify a list of threats that we are trying to medigate. Map this list to the class of protocols that we would like to address Then put put a check list on the known methods to medigate the threats. Prioritize threats that we will address (as applicabale to the protocols) determine what in scope and what is not. Then generate the list of requirements. For example, talking about crypto sterngth without taking into consideration what you are trying to protect or threats that you are trying to medigate is immature. Otherwise, it seems to me that we will be trying to pull rabits out of a magician hat. These are my two cents (Canadian) Abbie > -----Original Message----- > From: Russ White [mailto:ruwhite@cisco.com] > Sent: Wednesday, September 17, 2003 5:32 PM > To: Routing Protocols Security Working Group > Subject: [RPSEC] RP Requirements Doc Comments... > > > > 2. General considerations > > .... > > 2.1 What MUST / SHOULD be protected ? > > Distribution of destination reachability information with > the required > policy considerations (QoS, trusted route, etc.) is what > is expected > from a routing protocol. > > Possibly replace with: > > Routing protocols act as distributed databases with very > quick synchornzation times. They are responsible for > distributing information about reachability to destinations > attached to the network, and the distribution of policies > about the available paths. Note that policy propogation > within a routing protocol which operates between > administrative routing domains, exterior gateway protocols, > is very difficult. This particular area of security is > fraught with difficulties making it next to impossible to > actually secure policy across multiple administrative domains. > > Reachability MUST be protected against unauthorized route deletions > and route additions. Note that these are high level operations; > aggregation, for instance, may result in the same consequences as > announcing new routes. > > ....or the removal of some routing information, and the > policies attending that routing information. > > Route attributes (path information, metrics, trusted entity for the > forwarding of specific traffics) SHOULD also be protected. > > [TBD] We have to decide if route attributes require as much > protection as route existence, probably yes. Note that > manipulation > of a routes associated attributes may achieve the same effects > as those resulting from addition / deletion. > > I think you can mention this, but it's actually going to be > difficult to impossible to find any way of securing policies > within an EGP. Since each administrative domain can add > policies to a given route, anyone can essentially insert any > policy. The question: "Who's policy are we honoring" has to > be answered before we can begin to think about this. The > originator's policy? Or the AS we received the route from? Or > the AS that currently has the route? Or some other AS? > > Traffic overload may provoke DOS of routing negotiations, > while these > would help in balancing the high traffic. Forwarding is usually the > principal purpose of devices running routing protocols. In order to > achieve correctness of forwarding tables, means to enforce > availability of the medium to the routing protocol SHOULD be > provided. > > You mean protection against traffic overload may provide > opportunities for DOS attacks? The wording is just backwards, > I think, in the first sentence. > > 2.2 Transport Layer Considerations > > .... > > A routing protocol designed to be, within certain extent, Transport > Layer independent, may provide options to activate inner security > features on-demand. Though such a flexibility would help avoiding > potential redundancy of functions with the Transport Layer and > adjusting performance requirements, such an approach is usually not > > Do you mean "lower layer" when you say "inner?" > > desirable because of it's added complexity. > > I don't understand what this sentence is saying, actually. > > The Tranport Layer may already grant the following properties: > > "Grant" vs "provide?" > > o Neighboring: a technology may provide a way to address adjacent > neighbors. The neighboring range in this kind of technology is > typically of one system away and relies on direct > mapping over the > Link Layer. > > o Neighbor discovery and maintenance: A given transport layer > technology may provide a way to discover and communicate with > adjacenct devices participating in the routing domain (neighbors). > > I don't know if you want to say anything about direct mapping > to the link layer--what would you mean by this? Something > like what IS-IS does? It doesn't seem to apply to OSPF, EIGRP, or BGP? > > o Integrity: the Transport Layer may provide data > integrity. This is > insufficient to achieve security without proper means of > authenticating the system which provided the integrity proof in > the first place. > > Replace with: > > o Integrity: While the transport layer chosen by the routing > protocol designer may provide data integrity, most data > integrity techaniwues do not provide security. To provide > secure data integrity, the transport must use some form of > cryptographic hashing or signatures to validate data integrity. > > Or something along these lines (?). > > o Authenticity: if the underlying layer both provides authenticity > and integrity, many routing threats may be thwarted. Further > considerations are required though, among which are > resistance to > replay, performance, Byzantine detection and robustness, etc. > > I assume further requirements for integrity will be discussed > someplace else, later on? Otherwise, this is a bit skimpy. > > 3. Cryptographic requirements > > 3.1 Basic cryptographic requirements > > The following requirements are understood on a producer / > consumer of > the routing information basis. Forwarders of the > information may not > need to provide the following, if they do not modify the content of > messages. > > Integrity: data integrity is an obvious requirement. > > Wht do you mean by integrity, though? Should you attempt to > define integrity in some way, or refer to a definition > provided in the security definitions draft? > > Anti-replay: this comes here mainly for protection > against active > attacks from subverted links, though this feature will also > provide added protection against natural duplication of packets. > Note that underlying layers may provide an unauthenticated > anti-replay feature, which would be of no use from a security > point of view. > > Unless the actual data used for preventing replay is also > authenticated--I'd probably mention this. So, something like: > > Anit-Replay: In order to routing protocol peering sessions on > subverted, or publicly accessible, links, the transport used > by a routing protocol SHOULD provide some form of anti-replay > protection. Note that if this anti-replay mechanism is not > part of a cryptographic system, or is not cryptographically > protected through integrity validation procedures, > > > More later, as I get the chance to look over other parts. > > :-) > > Russ > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > ------_=_NextPart_001_01C37E9D.BDD988C2 Content-Type: text/html RE: [RPSEC] RP Requirements Doc Comments...

Russ,

Thanks for the feedback.
Overall the doc is a good start.

However, I have some concerns with the overall structure of the document.

First, the doc does not take advantage of the work/knowledge that was acquired from the genral threat doc.

It seems to me that the approach must be slightly different.
The proper way to go (in my opinion) is to identify a list of threats that we are trying to medigate.
Map this list to the class of protocols that we would like to address
Then put put a check list on the known methods to medigate the threats.
Prioritize threats that we will address (as applicabale to the protocols)
determine what in scope and what is not.

Then generate the list of requirements.

For example, talking about crypto sterngth without taking into consideration what you are
trying to protect or threats that you are trying to medigate is immature.

Otherwise, it seems to me that we will be trying to pull rabits out of a magician hat.

These are my two cents (Canadian)

Abbie


> -----Original Message-----
> From: Russ White [mailto:ruwhite@cisco.com]
> Sent: Wednesday, September 17, 2003 5:32 PM
> To: Routing Protocols Security Working Group
> Subject: [RPSEC] RP Requirements Doc Comments...
>
>
>
> 2. General considerations
>
> ....
>
> 2.1 What MUST / SHOULD be protected ?
>
>    Distribution of destination reachability information with
> the required
>    policy considerations (QoS, trusted route, etc.) is what
> is expected
>    from a routing protocol.
>
> Possibly replace with:
>
> Routing protocols act as distributed databases with very
> quick synchornzation times. They are responsible for
> distributing information about reachability to destinations
> attached to the network, and the distribution of policies
> about the available paths. Note that policy propogation
> within a routing protocol which operates between
> administrative routing domains, exterior gateway protocols,
> is very difficult. This particular area of security is
> fraught with difficulties making it next to impossible to
> actually secure policy across multiple administrative domains.
>
>    Reachability MUST be protected against unauthorized route deletions
>    and route additions. Note that these are high level operations;
>    aggregation, for instance, may result in the same consequences as
>    announcing new routes.
>
> ....or the removal of some routing information, and the
> policies attending that routing information.
>
>    Route attributes (path information, metrics, trusted entity for the
>    forwarding of specific traffics) SHOULD also be protected.
>
>    [TBD] We have to decide if route attributes require as much
>    protection as route existence, probably yes.  Note that
> manipulation
>    of a routes associated attributes may achieve the same effects
>    as those resulting from addition / deletion.
>
> I think you can mention this, but it's actually going to be
> difficult to impossible to find any way of securing policies
> within an EGP. Since each administrative domain can add
> policies to a given route, anyone can essentially insert any
> policy. The question: "Who's policy are we honoring" has to
> be answered before we can begin to think about this. The
> originator's policy? Or the AS we received the route from? Or
> the AS that currently has the route? Or some other AS?
>
>    Traffic overload may provoke DOS of routing negotiations,
> while these
>    would help in balancing the high traffic. Forwarding is usually the
>    principal purpose of devices running routing protocols. In order to
>    achieve correctness of forwarding tables, means to enforce
>    availability of the medium to the routing protocol SHOULD be
>    provided.
>
> You mean protection against traffic overload may provide
> opportunities for DOS attacks? The wording is just backwards,
> I think, in the first sentence.
>
> 2.2 Transport Layer Considerations
>
> ....
>
>    A routing protocol designed to be, within certain extent, Transport
>    Layer independent, may provide options to activate inner security
>    features on-demand. Though such a flexibility would help avoiding
>    potential redundancy of functions with the Transport Layer and
>    adjusting performance requirements, such an approach is usually not
>
> Do you mean "lower layer" when you say "inner?"
>
>    desirable because of it's added complexity.
>
> I don't understand what this sentence is saying, actually.
>
>    The Tranport Layer may already grant the following properties:
>
> "Grant" vs "provide?"
>
>    o  Neighboring: a technology may provide a way to address adjacent
>       neighbors. The neighboring range in this kind of technology is
>       typically of one system away and relies on direct
> mapping over the
>       Link Layer.
>
> o Neighbor discovery and maintenance: A given transport layer
> technology may provide a way to discover and communicate with
> adjacenct devices participating in the routing domain (neighbors).
>
> I don't know if you want to say anything about direct mapping
> to the link layer--what would you mean by this? Something
> like what IS-IS does? It doesn't seem to apply to OSPF, EIGRP, or BGP?
>
>    o  Integrity: the Transport Layer may provide data
> integrity. This is
>       insufficient to achieve security without proper means of
>       authenticating the system which provided the integrity proof in
>       the first place.
>
> Replace with:
>
> o Integrity: While the transport layer chosen by the routing
> protocol designer may provide data integrity, most data
> integrity techaniwues do not provide security. To provide
> secure data integrity, the transport must use some form of
> cryptographic hashing or signatures to validate data integrity.
>
> Or something along these lines (?).
>
>    o  Authenticity: if the underlying layer both provides authenticity
>       and integrity, many routing threats may be thwarted.  Further
>       considerations are required though, among which are
> resistance to
>       replay, performance, Byzantine detection and robustness, etc.
>
> I assume further requirements for integrity will be discussed
> someplace else, later on? Otherwise, this is a bit skimpy.
>
> 3. Cryptographic requirements
>
> 3.1 Basic cryptographic requirements
>
>    The following requirements are understood on a producer /
> consumer of
>    the routing information basis. Forwarders of the
> information may not
>    need to provide the following, if they do not modify the content of
>    messages.
>
>       Integrity: data integrity is an obvious requirement.
>
> Wht do you mean by integrity, though? Should you attempt to
> define integrity in some way, or refer to a definition
> provided in the security definitions draft?
>
>       Anti-replay: this comes here mainly for protection
> against active
>       attacks from subverted links, though this feature will also
>       provide added protection against natural duplication of packets.
>       Note that underlying layers may provide an unauthenticated
>       anti-replay feature, which would be of no use from a security
>       point of view.
>
> Unless the actual data used for preventing replay is also
> authenticated--I'd probably mention this. So, something like:
>
> Anit-Replay: In order to routing protocol peering sessions on
> subverted, or publicly accessible, links, the transport used
> by a routing protocol SHOULD provide some form of anti-replay
> protection. Note that if this anti-replay mechanism is not
> part of a cryptographic system, or is not cryptographically
> protected through integrity validation procedures,
>
>
> More later, as I get the chance to look over other parts.
>
> :-)
>
> Russ
>
> __________________________________
> riw@cisco.com CCIE <>< Grace Alone
>
>
> _______________________________________________
> RPSEC mailing list
> RPSEC@ietf.org
> https://www1.ietf.org/mailman/listinfo/rpsec
>

------_=_NextPart_001_01C37E9D.BDD988C2-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Sat Sep 20 09:54:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05054 for ; Sat, 20 Sep 2003 09:54:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nid-0008Pn-Nj for rpsec-archive@odin.ietf.org; Fri, 19 Sep 2003 12:02:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JG2pFq032341 for rpsec-archive@odin.ietf.org; Fri, 19 Sep 2003 12:02:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nic-0008PK-Qp for rpsec-web-archive@optimus.ietf.org; Fri, 19 Sep 2003 12:02:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02303 for ; Fri, 19 Sep 2003 11:59:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0NfO-0002BF-00 for rpsec-web-archive@ietf.org; Fri, 19 Sep 2003 11:59:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0NfJ-00029J-00 for rpsec-web-archive@ietf.org; Fri, 19 Sep 2003 11:59:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0New-0007CE-OE; Fri, 19 Sep 2003 11:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Ne7-00075V-HD for rpsec@optimus.ietf.org; Fri, 19 Sep 2003 11:58:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01740 for ; Fri, 19 Sep 2003 11:57:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0NVF-0007Lk-00 for rpsec@ietf.org; Fri, 19 Sep 2003 11:49:01 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A0NV5-0007AG-00 for rpsec@ietf.org; Fri, 19 Sep 2003 11:48:51 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8JFm9J29819 for ; Fri, 19 Sep 2003 11:48:09 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Sep 2003 11:48:10 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75406F176CD@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: rpsec@ietf.org Subject: FW: [RPSEC] RP Requirements Doc Comments... Date: Fri, 19 Sep 2003 11:48:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37EC5.6BB384D0" 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37EC5.6BB384D0 Content-Type: text/plain > -----Original Message----- > From: Barbir, Abbie [CAR:1A11:EXCH] > Sent: Friday, September 19, 2003 6:38 AM > To: 'Russ White'; Routing Protocols Security Working Group > Subject: RE: [RPSEC] RP Requirements Doc Comments... > > > Russ, > > Thanks for the feedback. > Overall the doc is a good start. > > However, I have some concerns with the overall structure of > the document. > > First, the doc does not take advantage of the work/knowledge > that was acquired from the genral threat doc. > > It seems to me that the approach must be slightly different. > The proper way to go (in my opinion) is to identify a list of > threats that we are trying to medigate. Map this list to the > class of protocols that we would like to address Then put put > a check list on the known methods to medigate the threats. > Prioritize threats that we will address (as applicabale to > the protocols) determine what in scope and what is not. > > Then generate the list of requirements. > > For example, talking about crypto sterngth without taking > into consideration what you are > trying to protect or threats that you are trying to medigate > is immature. > > Otherwise, it seems to me that we will be trying to pull > rabits out of a magician hat. > > These are my two cents (Canadian) > > Abbie > > > > -----Original Message----- > > From: Russ White [mailto:ruwhite@cisco.com] > > Sent: Wednesday, September 17, 2003 5:32 PM > > To: Routing Protocols Security Working Group > > Subject: [RPSEC] RP Requirements Doc Comments... > > > > > > > > 2. General considerations > > > > .... > > > > 2.1 What MUST / SHOULD be protected ? > > > > Distribution of destination reachability information with > > the required > > policy considerations (QoS, trusted route, etc.) is what > > is expected > > from a routing protocol. > > > > Possibly replace with: > > > > Routing protocols act as distributed databases with very > > quick synchornzation times. They are responsible for > > distributing information about reachability to destinations > > attached to the network, and the distribution of policies > > about the available paths. Note that policy propogation > > within a routing protocol which operates between > > administrative routing domains, exterior gateway protocols, > > is very difficult. This particular area of security is > > fraught with difficulties making it next to impossible to > > actually secure policy across multiple administrative domains. > > > > Reachability MUST be protected against unauthorized > route deletions > > and route additions. Note that these are high level operations; > > aggregation, for instance, may result in the same consequences as > > announcing new routes. > > > > ....or the removal of some routing information, and the > > policies attending that routing information. > > > > Route attributes (path information, metrics, trusted > entity for the > > forwarding of specific traffics) SHOULD also be protected. > > > > [TBD] We have to decide if route attributes require as much > > protection as route existence, probably yes. Note that > > manipulation > > of a routes associated attributes may achieve the same effects > > as those resulting from addition / deletion. > > > > I think you can mention this, but it's actually going to be > > difficult to impossible to find any way of securing policies > > within an EGP. Since each administrative domain can add > > policies to a given route, anyone can essentially insert any > > policy. The question: "Who's policy are we honoring" has to > > be answered before we can begin to think about this. The > > originator's policy? Or the AS we received the route from? Or > > the AS that currently has the route? Or some other AS? > > > > Traffic overload may provoke DOS of routing negotiations, > > while these > > would help in balancing the high traffic. Forwarding is > usually the > > principal purpose of devices running routing protocols. > In order to > > achieve correctness of forwarding tables, means to enforce > > availability of the medium to the routing protocol SHOULD be > > provided. > > > > You mean protection against traffic overload may provide > > opportunities for DOS attacks? The wording is just backwards, > > I think, in the first sentence. > > > > 2.2 Transport Layer Considerations > > > > .... > > > > A routing protocol designed to be, within certain > extent, Transport > > Layer independent, may provide options to activate inner security > > features on-demand. Though such a flexibility would help avoiding > > potential redundancy of functions with the Transport Layer and > > adjusting performance requirements, such an approach is > usually not > > > > Do you mean "lower layer" when you say "inner?" > > > > desirable because of it's added complexity. > > > > I don't understand what this sentence is saying, actually. > > > > The Tranport Layer may already grant the following properties: > > > > "Grant" vs "provide?" > > > > o Neighboring: a technology may provide a way to > address adjacent > > neighbors. The neighboring range in this kind of technology is > > typically of one system away and relies on direct > > mapping over the > > Link Layer. > > > > o Neighbor discovery and maintenance: A given transport layer > > technology may provide a way to discover and communicate with > > adjacenct devices participating in the routing domain (neighbors). > > > > I don't know if you want to say anything about direct mapping > > to the link layer--what would you mean by this? Something > > like what IS-IS does? It doesn't seem to apply to OSPF, > EIGRP, or BGP? > > > > o Integrity: the Transport Layer may provide data > > integrity. This is > > insufficient to achieve security without proper means of > > authenticating the system which provided the > integrity proof in > > the first place. > > > > Replace with: > > > > o Integrity: While the transport layer chosen by the routing > > protocol designer may provide data integrity, most data > > integrity techaniwues do not provide security. To provide > > secure data integrity, the transport must use some form of > > cryptographic hashing or signatures to validate data integrity. > > > > Or something along these lines (?). > > > > o Authenticity: if the underlying layer both provides > authenticity > > and integrity, many routing threats may be thwarted. Further > > considerations are required though, among which are > > resistance to > > replay, performance, Byzantine detection and robustness, etc. > > > > I assume further requirements for integrity will be discussed > > someplace else, later on? Otherwise, this is a bit skimpy. > > > > 3. Cryptographic requirements > > > > 3.1 Basic cryptographic requirements > > > > The following requirements are understood on a producer / > > consumer of > > the routing information basis. Forwarders of the > > information may not > > need to provide the following, if they do not modify the > content of > > messages. > > > > Integrity: data integrity is an obvious requirement. > > > > Wht do you mean by integrity, though? Should you attempt to > > define integrity in some way, or refer to a definition > > provided in the security definitions draft? > > > > Anti-replay: this comes here mainly for protection > > against active > > attacks from subverted links, though this feature will also > > provide added protection against natural duplication > of packets. > > Note that underlying layers may provide an unauthenticated > > anti-replay feature, which would be of no use from a security > > point of view. > > > > Unless the actual data used for preventing replay is also > > authenticated--I'd probably mention this. So, something like: > > > > Anit-Replay: In order to routing protocol peering sessions on > > subverted, or publicly accessible, links, the transport used > > by a routing protocol SHOULD provide some form of anti-replay > > protection. Note that if this anti-replay mechanism is not > > part of a cryptographic system, or is not cryptographically > > protected through integrity validation procedures, > > > > > > More later, as I get the chance to look over other parts. > > > > :-) > > > > Russ > > > > __________________________________ > > riw@cisco.com CCIE <>< Grace Alone > > > > > > _______________________________________________ > > RPSEC mailing list > > RPSEC@ietf.org > > https://www1.ietf.org/mailman/listinfo/rpsec > > > ------_=_NextPart_001_01C37EC5.6BB384D0 Content-Type: text/html FW: [RPSEC] RP Requirements Doc Comments...

> -----Original Message-----
> From: Barbir, Abbie [CAR:1A11:EXCH]
> Sent: Friday, September 19, 2003 6:38 AM
> To: 'Russ White'; Routing Protocols Security Working Group
> Subject: RE: [RPSEC] RP Requirements Doc Comments...
>
>
> Russ,
>
> Thanks for the feedback.
> Overall the doc is a good start.
>
> However, I have some concerns with the overall structure of
> the document.
>
> First, the doc does not take advantage of the work/knowledge
> that was acquired from the genral threat doc.
>
> It seems to me that the approach must be slightly different.
> The proper way to go (in my opinion) is to identify a list of
> threats that we are trying to medigate. Map this list to the
> class of protocols that we would like to address Then put put
> a check list on the known methods to medigate the threats.
> Prioritize threats that we will address (as applicabale to
> the protocols) determine what in scope and what is not.
>
> Then generate the list of requirements.
>
> For example, talking about crypto sterngth without taking
> into consideration what you are
> trying to protect or threats that you are trying to medigate
> is immature.
>
> Otherwise, it seems to me that we will be trying to pull
> rabits out of a magician hat.
>
> These are my two cents (Canadian)
>
> Abbie
>
>
> > -----Original Message-----
> > From: Russ White [mailto:ruwhite@cisco.com]
> > Sent: Wednesday, September 17, 2003 5:32 PM
> > To: Routing Protocols Security Working Group
> > Subject: [RPSEC] RP Requirements Doc Comments...
> >
> >
> >
> > 2. General considerations
> >
> > ....
> >
> > 2.1 What MUST / SHOULD be protected ?
> >
> >    Distribution of destination reachability information with
> > the required
> >    policy considerations (QoS, trusted route, etc.) is what
> > is expected
> >    from a routing protocol.
> >
> > Possibly replace with:
> >
> > Routing protocols act as distributed databases with very
> > quick synchornzation times. They are responsible for
> > distributing information about reachability to destinations
> > attached to the network, and the distribution of policies
> > about the available paths. Note that policy propogation
> > within a routing protocol which operates between
> > administrative routing domains, exterior gateway protocols,
> > is very difficult. This particular area of security is
> > fraught with difficulties making it next to impossible to
> > actually secure policy across multiple administrative domains.
> >
> >    Reachability MUST be protected against unauthorized
> route deletions
> >    and route additions. Note that these are high level operations;
> >    aggregation, for instance, may result in the same consequences as
> >    announcing new routes.
> >
> > ....or the removal of some routing information, and the
> > policies attending that routing information.
> >
> >    Route attributes (path information, metrics, trusted
> entity for the
> >    forwarding of specific traffics) SHOULD also be protected.
> >
> >    [TBD] We have to decide if route attributes require as much
> >    protection as route existence, probably yes.  Note that
> > manipulation
> >    of a routes associated attributes may achieve the same effects
> >    as those resulting from addition / deletion.
> >
> > I think you can mention this, but it's actually going to be
> > difficult to impossible to find any way of securing policies
> > within an EGP. Since each administrative domain can add
> > policies to a given route, anyone can essentially insert any
> > policy. The question: "Who's policy are we honoring" has to
> > be answered before we can begin to think about this. The
> > originator's policy? Or the AS we received the route from? Or
> > the AS that currently has the route? Or some other AS?
> >
> >    Traffic overload may provoke DOS of routing negotiations,
> > while these
> >    would help in balancing the high traffic. Forwarding is
> usually the
> >    principal purpose of devices running routing protocols.
> In order to
> >    achieve correctness of forwarding tables, means to enforce
> >    availability of the medium to the routing protocol SHOULD be
> >    provided.
> >
> > You mean protection against traffic overload may provide
> > opportunities for DOS attacks? The wording is just backwards,
> > I think, in the first sentence.
> >
> > 2.2 Transport Layer Considerations
> >
> > ....
> >
> >    A routing protocol designed to be, within certain
> extent, Transport
> >    Layer independent, may provide options to activate inner security
> >    features on-demand. Though such a flexibility would help avoiding
> >    potential redundancy of functions with the Transport Layer and
> >    adjusting performance requirements, such an approach is
> usually not
> >
> > Do you mean "lower layer" when you say "inner?"
> >
> >    desirable because of it's added complexity.
> >
> > I don't understand what this sentence is saying, actually.
> >
> >    The Tranport Layer may already grant the following properties:
> >
> > "Grant" vs "provide?"
> >
> >    o  Neighboring: a technology may provide a way to
> address adjacent
> >       neighbors. The neighboring range in this kind of technology is
> >       typically of one system away and relies on direct
> > mapping over the
> >       Link Layer.
> >
> > o Neighbor discovery and maintenance: A given transport layer
> > technology may provide a way to discover and communicate with
> > adjacenct devices participating in the routing domain (neighbors).
> >
> > I don't know if you want to say anything about direct mapping
> > to the link layer--what would you mean by this? Something
> > like what IS-IS does? It doesn't seem to apply to OSPF,
> EIGRP, or BGP?
> >
> >    o  Integrity: the Transport Layer may provide data
> > integrity. This is
> >       insufficient to achieve security without proper means of
> >       authenticating the system which provided the
> integrity proof in
> >       the first place.
> >
> > Replace with:
> >
> > o Integrity: While the transport layer chosen by the routing
> > protocol designer may provide data integrity, most data
> > integrity techaniwues do not provide security. To provide
> > secure data integrity, the transport must use some form of
> > cryptographic hashing or signatures to validate data integrity.
> >
> > Or something along these lines (?).
> >
> >    o  Authenticity: if the underlying layer both provides
> authenticity
> >       and integrity, many routing threats may be thwarted.  Further
> >       considerations are required though, among which are
> > resistance to
> >       replay, performance, Byzantine detection and robustness, etc.
> >
> > I assume further requirements for integrity will be discussed
> > someplace else, later on? Otherwise, this is a bit skimpy.
> >
> > 3. Cryptographic requirements
> >
> > 3.1 Basic cryptographic requirements
> >
> >    The following requirements are understood on a producer /
> > consumer of
> >    the routing information basis. Forwarders of the
> > information may not
> >    need to provide the following, if they do not modify the
> content of
> >    messages.
> >
> >       Integrity: data integrity is an obvious requirement.
> >
> > Wht do you mean by integrity, though? Should you attempt to
> > define integrity in some way, or refer to a definition
> > provided in the security definitions draft?
> >
> >       Anti-replay: this comes here mainly for protection
> > against active
> >       attacks from subverted links, though this feature will also
> >       provide added protection against natural duplication
> of packets.
> >       Note that underlying layers may provide an unauthenticated
> >       anti-replay feature, which would be of no use from a security
> >       point of view.
> >
> > Unless the actual data used for preventing replay is also
> > authenticated--I'd probably mention this. So, something like:
> >
> > Anit-Replay: In order to routing protocol peering sessions on
> > subverted, or publicly accessible, links, the transport used
> > by a routing protocol SHOULD provide some form of anti-replay
> > protection. Note that if this anti-replay mechanism is not
> > part of a cryptographic system, or is not cryptographically
> > protected through integrity validation procedures,
> >
> >
> > More later, as I get the chance to look over other parts.
> >
> > :-)
> >
> > Russ
> >
> > __________________________________
> > riw@cisco.com CCIE <>< Grace Alone
> >
> >
> > _______________________________________________
> > RPSEC mailing list
> > RPSEC@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rpsec
> >
>

------_=_NextPart_001_01C37EC5.6BB384D0-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Mon Sep 22 10:59:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19012 for ; Mon, 22 Sep 2003 10:59:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1S9s-0008BX-Gb for rpsec-archive@odin.ietf.org; Mon, 22 Sep 2003 10:59:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MExOEK031459 for rpsec-archive@odin.ietf.org; Mon, 22 Sep 2003 10:59:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1S9s-0008BK-Ca for rpsec-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 10:59:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18977 for ; Mon, 22 Sep 2003 10:59:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1S9p-000085-00 for rpsec-web-archive@ietf.org; Mon, 22 Sep 2003 10:59:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1S9k-000080-00 for rpsec-web-archive@ietf.org; Mon, 22 Sep 2003 10:59:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1S9U-00088T-UC; Mon, 22 Sep 2003 10:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1S9F-00088A-Dc for rpsec@optimus.ietf.org; Mon, 22 Sep 2003 10:58:45 -0400 Received: from mesa.bbnplanet.com (mesa.bbnplanet.com [171.78.172.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18943 for ; Mon, 22 Sep 2003 10:58:35 -0400 (EDT) Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h8MEohS02180; Mon, 22 Sep 2003 10:50:44 -0400 (EDT) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Mon, 22 Sep 2003 10:50:43 -0400 (EDT) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Russ White cc: Routing Protocols Security Working Group Subject: Re: [RPSEC] RP Requirements Doc Comments... In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , I'm working on my own list of comments, but also want to respond to what others have written. See below: On Wed, 17 Sep 2003, Russ White wrote: > 2. General considerations > > .... > > 2.1 What MUST / SHOULD be protected ? > > Distribution of destination reachability information with the > required policy considerations (QoS, trusted route, etc.) is what > is expected from a routing protocol. > > Possibly replace with: > > Routing protocols act as distributed databases with very quick > synchornzation times. Is that always true? Is RIP a distributed database? I don't get that RIP routers' view must be synchronized to work. Which is not to say they can just disagree w/o care and still have things work right. > They are responsible for distributing information about reachability > to destinations attached to the network, and the distribution of > policies about the available paths. Note that policy propogation > within a routing protocol which operates between administrative > routing domains, exterior gateway protocols, is very difficult. This > particular area of security is fraught with difficulties making it > next to impossible to actually secure policy across multiple > administrative domains. Certainly a worthwhile point. Could be a SHOULD or MAY? > Reachability MUST be protected against unauthorized route > deletions and route additions. Note that these are high level > operations; aggregation, for instance, may result in the same > consequences as announcing new routes. > > ....or the removal of some routing information, and the policies > attending that routing information. > > Route attributes (path information, metrics, trusted entity for > the forwarding of specific traffics) SHOULD also be protected. > > [TBD] We have to decide if route attributes require as much > protection as route existence, probably yes. Note that > manipulation of a routes associated attributes may achieve the > same effects as those resulting from addition / deletion. > > I think you can mention this, but it's actually going to be > difficult to impossible to find any way of securing policies within > an EGP. Since each administrative domain can add policies to a given > route, anyone can essentially insert any policy. The question: > "Who's policy are we honoring" has to be answered before we can > begin to think about this. The originator's policy? Or the AS we > received the route from? Or the AS that currently has the route? Or > some other AS? Again, perhaps MAY to at least acknowledge some desirability. > 2.2 Transport Layer Considerations > > .... > > A routing protocol designed to be, within certain extent, > Transport Layer independent, may provide options to activate > inner security features on-demand. Though such a flexibility > would help avoiding potential redundancy of functions with the > Transport Layer and adjusting performance requirements, such an > approach is usually not > > Do you mean "lower layer" when you say "inner?" It seems that what is meant is "internal to the protocol; transport-layer agnostic". Do you want "may" to be "MAY"? > o Integrity: the Transport Layer may provide data integrity. > This is insufficient to achieve security without proper means of > authenticating the system which provided the integrity proof in > the first place. > > Replace with: > > o Integrity: While the transport layer chosen by the routing protocol > designer may provide data integrity, most data integrity techaniwues > do not provide security. To provide secure data integrity, the > transport must use some form of cryptographic hashing or signatures to > validate data integrity. > > Or something along these lines (?). Perhaps all of that is over-specified? Should the requirement be described as the need to provide for data integrity, authenticity, etc. as mitigation to threats outlined in the Threats document? Could go on to describe how such services may be imparted by the transport layer but include details as to how that is to be done with the given transport features. > 3. Cryptographic requirements > > Anti-replay: this comes here mainly for protection against > active attacks from subverted links, though this feature will > also provide added protection against natural duplication of > packets. Note that underlying layers may provide an > unauthenticated anti-replay feature, which would be of no use > from a security point of view. What do you have in mind in that last sentence? Any examples? > Unless the actual data used for preventing replay is also > authenticated--I'd probably mention this. Similarly, I'm not enough of a security geek to know if there are non-cryptographic or non-authenticated ways of providing anti-replay protection. > So, something like: > > Anit-Replay: In order to routing protocol peering sessions on > subverted, or publicly accessible, links, Remember, all links should be considered vulnerable to subversion so the "publically accessible" serves only as an additional caveat. People shouldn't think "well, it's not "publically accessible" (whatever that means) so foo isn't needed". > the transport used by a routing protocol SHOULD provide some form of > anti-replay protection. Could we say that the protocol MUST be resistant to replay attacks and perhaps go on to say that such protection could be provided w/in the protocol (eg. some kind of global sequence number hash? just an idle thought) or within the transport layer. Come to think of it, if the transport layer is not an end-to-end thing (like TCP) but a hop-by-hop method (like IP), the problem may get stickier, especially if the forwarders are also expected to act on the update (eg. increase metric). > Note that if this anti-replay mechanism is > not part of a cryptographic system, or is not cryptographically > protected through integrity validation procedures, Sentence fragment? Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Mon Sep 22 11:14:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19826 for ; Mon, 22 Sep 2003 11:14:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1SNi-0000oD-9U for rpsec-archive@odin.ietf.org; Mon, 22 Sep 2003 11:13:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MFDgVa003103 for rpsec-archive@odin.ietf.org; Mon, 22 Sep 2003 11:13:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1SNi-0000ny-1u for rpsec-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 11:13:42 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19803 for ; Mon, 22 Sep 2003 11:13:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1SN2-0000js-6m; Mon, 22 Sep 2003 11:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1SMt-0000eJ-BG for rpsec@optimus.ietf.org; Mon, 22 Sep 2003 11:12:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19741 for ; Mon, 22 Sep 2003 11:12:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1SMn-0000Gi-00 for rpsec@ietf.org; Mon, 22 Sep 2003 11:12:45 -0400 Received: from mesa.bbnplanet.com ([171.78.172.21]) by ietf-mx with esmtp (Exim 4.12) id 1A1SMc-0000GS-00 for rpsec@ietf.org; Mon, 22 Sep 2003 11:12:34 -0400 Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h8MFBfC02190; Mon, 22 Sep 2003 11:11:46 -0400 (EDT) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Mon, 22 Sep 2003 11:11:40 -0400 (EDT) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Abbie Barbir cc: Russ White , Routing Protocols Security Working Group Subject: RE: [RPSEC] RP Requirements Doc Comments... In-Reply-To: <87609AFB433BD5118D5E0002A52CD75406F1730B@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75406F1730B@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , On Fri, 19 Sep 2003, Abbie Barbir wrote: > Russ, > > Thanks for the feedback. > Overall the doc is a good start. I agree also. > However, I have some concerns with the overall structure of the document. That's fine. I pushed the authors to get something out for discussion so that the structure/approach could be hashed out before too much work was put into the meat. > First, the doc does not take advantage of the work/knowledge that was > acquired from the genral threat doc. > > It seems to me that the approach must be slightly different. > The proper way to go (in my opinion) is to identify a list of > threats that we are trying to medigate. Agreed, again. Please take the lead from Sec. 3 (and 4?) of the Threats doc if possible. > Map this list to the class of protocols that we would like to > address Then put put a check list on the known methods to medigate > the threats. Prioritize threats that we will address (as > applicabale to the protocols) determine what in scope and what is > not. I like that idea also. However, we probably want to _mitigate_ the threats (or medicate them? .... 8-) Tony > Then generate the list of requirements. > > For example, talking about crypto sterngth without taking into > consideration what you are trying to protect or threats that you are > trying to medigate is immature. > > Otherwise, it seems to me that we will be trying to pull rabits out > of a magician hat. > > These are my two cents (Canadian) > > Abbie _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Mon Sep 22 15:15:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02538 for ; Mon, 22 Sep 2003 15:15:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1W9H-0001LP-7B for rpsec-archive@odin.ietf.org; Mon, 22 Sep 2003 15:15:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MJF38T005163 for rpsec-archive@odin.ietf.org; Mon, 22 Sep 2003 15:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1W9H-0001LC-1J for rpsec-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 15:15:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02466 for ; Mon, 22 Sep 2003 15:14:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1W9F-00003A-00 for rpsec-web-archive@ietf.org; Mon, 22 Sep 2003 15:15:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1W99-000022-00 for rpsec-web-archive@ietf.org; Mon, 22 Sep 2003 15:14:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1W7H-0001Ef-4n; Mon, 22 Sep 2003 15:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1W6k-0001DQ-56 for rpsec@optimus.ietf.org; Mon, 22 Sep 2003 15:12:36 -0400 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02148 for ; Mon, 22 Sep 2003 15:12:16 -0400 (EDT) Received: from cisco.com (64.102.124.12) by sj-iport-2.cisco.com with ESMTP; 22 Sep 2003 12:09:33 -0700 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8MJBo01029625; Mon, 22 Sep 2003 15:11:51 -0400 (EDT) Received: from russpc.whitehouse.intra (rtp-vpn1-230.cisco.com [10.82.224.230]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA02294; Mon, 22 Sep 2003 15:11:50 -0400 (EDT) Date: Mon, 22 Sep 2003 15:11:43 -0400 (Eastern Daylight Time) From: Russ White Reply-To: Russ White To: Tony Tauber cc: Routing Protocols Security Working Group Subject: Re: [RPSEC] RP Requirements Doc Comments... In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > > 2.1 What MUST / SHOULD be protected ? > > > > Distribution of destination reachability information with the > > required policy considerations (QoS, trusted route, etc.) is what > > is expected from a routing protocol. > > > > Possibly replace with: > > > > Routing protocols act as distributed databases with very quick > > synchornzation times. > > Is that always true? Is RIP a distributed database? I don't get that > RIP routers' view must be synchronized to work. Which is not to say they > can just disagree w/o care and still have things work right. Yes, even though the databases might not synch, a routing protocol is still a distributed database, essentially. > > They are responsible for distributing information about reachability > > to destinations attached to the network, and the distribution of > > policies about the available paths. Note that policy propogation > > within a routing protocol which operates between administrative > > routing domains, exterior gateway protocols, is very difficult. This > > particular area of security is fraught with difficulties making it > > next to impossible to actually secure policy across multiple > > administrative domains. > > Certainly a worthwhile point. Could be a SHOULD or MAY? I think so.... MAY might be reasonable. There are conditions under which a routing system could actually validate these sorts of things, but I think another draft is shortly forthcoming which will explain this in greater detail (figure wednesday of this week). > > I think you can mention this, but it's actually going to be > > difficult to impossible to find any way of securing policies within > > an EGP. Since each administrative domain can add policies to a given > > route, anyone can essentially insert any policy. The question: > > "Who's policy are we honoring" has to be answered before we can > > begin to think about this. The originator's policy? Or the AS we > > received the route from? Or the AS that currently has the route? Or > > some other AS? > > Again, perhaps MAY to at least acknowledge some desirability. Yep, that would work.... > > 2.2 Transport Layer Considerations > > > > .... > > > > A routing protocol designed to be, within certain extent, > > Transport Layer independent, may provide options to activate > > inner security features on-demand. Though such a flexibility > > would help avoiding potential redundancy of functions with the > > Transport Layer and adjusting performance requirements, such an > > approach is usually not > > > > Do you mean "lower layer" when you say "inner?" > > It seems that what is meant is "internal to the protocol; transport-layer > agnostic". Do you want "may" to be "MAY"? I'm not certain--I just wanted to make certain we define what we mean when we say "inner" here. > > o Integrity: the Transport Layer may provide data integrity. > > This is insufficient to achieve security without proper means of > > authenticating the system which provided the integrity proof in > > the first place. > > > > Replace with: > > > > o Integrity: While the transport layer chosen by the routing protocol > > designer may provide data integrity, most data integrity techaniwues > > do not provide security. To provide secure data integrity, the > > transport must use some form of cryptographic hashing or signatures to > > validate data integrity. > > > > Or something along these lines (?). > > Perhaps all of that is over-specified? Should the requirement be > described as the need to provide for data integrity, authenticity, etc. > as mitigation to threats outlined in the Threats document? Could go on to > describe how such services may be imparted by the transport layer but > include details as to how that is to be done with the given transport > features. It should probably follow the threats doc better.... :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Mon Sep 22 15:29:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04132 for ; Mon, 22 Sep 2003 15:29:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1WNJ-000343-TE for rpsec-archive@odin.ietf.org; Mon, 22 Sep 2003 15:29:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MJTXPu011773 for rpsec-archive@odin.ietf.org; Mon, 22 Sep 2003 15:29:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1WNJ-00033o-Ow for rpsec-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 15:29:33 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04093 for ; Mon, 22 Sep 2003 15:29:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1WMn-0002wz-DC; Mon, 22 Sep 2003 15:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1WM6-0002te-A5 for rpsec@optimus.ietf.org; Mon, 22 Sep 2003 15:28:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03945 for ; Mon, 22 Sep 2003 15:28:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1WLz-00014c-00 for rpsec@ietf.org; Mon, 22 Sep 2003 15:28:11 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1A1WLo-0000sx-00 for rpsec@ietf.org; Mon, 22 Sep 2003 15:28:01 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h8MJPUjK055132; Mon, 22 Sep 2003 15:25:30 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h8MJPK62055075; Mon, 22 Sep 2003 15:25:20 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h8MJPFr01532; Mon, 22 Sep 2003 15:25:15 -0400 (EDT) Date: Mon, 22 Sep 2003 15:25:15 -0400 From: Jeffrey Haas To: Russ White Cc: Tony Tauber , Routing Protocols Security Working Group Subject: Re: [RPSEC] RP Requirements Doc Comments... Message-ID: <20030922152515.G13894@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ruwhite@cisco.com on Mon, Sep 22, 2003 at 03:11:43PM -0400 X-Virus-Scanned: by AMaViS perl-11 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , My apologies for coming in mid-conversation, but: On Mon, Sep 22, 2003 at 03:11:43PM -0400, Russ White wrote: > > Is that always true? Is RIP a distributed database? I don't get that > > RIP routers' view must be synchronized to work. Which is not to say they > > can just disagree w/o care and still have things work right. > > Yes, even though the databases might not synch, a routing protocol is still > a distributed database, essentially. Sort of. A routing protocol is a way of distributing information that is used to determine reachability. A distributed database is one way to do that, like the LSDB based protocols. RIP and BGP are "routing by rumor" to borrow someone elses words. At best, in RIP and BGP, you have the portion of your neighbors database that they use, but you don't have a picture of the entire network. This changes the attack spaces. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Mon Sep 22 15:31:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04357 for ; Mon, 22 Sep 2003 15:31:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1WPG-0003Il-G0 for rpsec-archive@odin.ietf.org; Mon, 22 Sep 2003 15:31:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MJVYUi012685 for rpsec-archive@odin.ietf.org; Mon, 22 Sep 2003 15:31:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1WPE-0003IP-Vs for rpsec-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 15:31:33 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04304 for ; Mon, 22 Sep 2003 15:31:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1WOj-0003Bs-BM; Mon, 22 Sep 2003 15:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1WNl-00036W-Oe for rpsec@optimus.ietf.org; Mon, 22 Sep 2003 15:30:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04129 for ; Mon, 22 Sep 2003 15:29:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1WNk-0001D6-00 for rpsec@ietf.org; Mon, 22 Sep 2003 15:30:00 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A1WNR-00019i-00 for rpsec@ietf.org; Mon, 22 Sep 2003 15:29:50 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 22 Sep 2003 12:26:45 -0700 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8MJT35g027307; Mon, 22 Sep 2003 15:29:03 -0400 (EDT) Received: from russpc.whitehouse.intra (rtp-vpn1-230.cisco.com [10.82.224.230]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA03291; Mon, 22 Sep 2003 15:29:02 -0400 (EDT) Date: Mon, 22 Sep 2003 15:28:55 -0400 (Eastern Daylight Time) From: Russ White Reply-To: Russ White To: Jeffrey Haas cc: Tony Tauber , Routing Protocols Security Working Group Subject: Re: [RPSEC] RP Requirements Doc Comments... In-Reply-To: <20030922152515.G13894@nexthop.com> Message-ID: References: <20030922152515.G13894@nexthop.com> X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > > > Is that always true? Is RIP a distributed database? I don't get that > > > RIP routers' view must be synchronized to work. Which is not to say they > > > can just disagree w/o care and still have things work right. > > > > Yes, even though the databases might not synch, a routing protocol is still > > a distributed database, essentially. > > Sort of. A routing protocol is a way of distributing information that is > used to determine reachability. A distributed database is one way to do > that, like the LSDB based protocols. RIP and BGP are "routing by rumor" > to borrow someone elses words. > > At best, in RIP and BGP, you have the portion of your neighbors database > that they use, but you don't have a picture of the entire network. This > changes the attack spaces. Well, it's a loosely syncrhonized database. What else would you characterize it as? It's providing reachability information (data in the form of a table) to a group of peers (distributed). Again, loosely, but there's no other characterization for it, unless you want to classify it as some completely new type of application. And, btw, link state protocols aren't so pure as you might think. When you hit an area or routing domain border, the databases stop synch'ing even in link state protocols. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Mon Sep 22 17:20:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11485 for ; Mon, 22 Sep 2003 17:20:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Y6K-0007mI-0u for rpsec-archive@odin.ietf.org; Mon, 22 Sep 2003 17:20:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MLK7ZR029893 for rpsec-archive@odin.ietf.org; Mon, 22 Sep 2003 17:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Y6J-0007m0-P8 for rpsec-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 17:20:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11441 for ; Mon, 22 Sep 2003 17:19:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1Y6H-0002P9-00 for rpsec-web-archive@ietf.org; Mon, 22 Sep 2003 17:20:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1Y6G-0002P6-00 for rpsec-web-archive@ietf.org; Mon, 22 Sep 2003 17:20:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Y6E-0007jl-Qn; Mon, 22 Sep 2003 17:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Y5n-0007ed-In for rpsec@optimus.ietf.org; Mon, 22 Sep 2003 17:19:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11424 for ; Mon, 22 Sep 2003 17:19:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1Y5l-0002MY-00 for rpsec@ietf.org; Mon, 22 Sep 2003 17:19:33 -0400 Received: from king.mcs.drexel.edu ([129.25.6.170]) by ietf-mx with esmtp (Exim 4.12) id 1A1Y5k-0002M7-00 for rpsec@ietf.org; Mon, 22 Sep 2003 17:19:32 -0400 Received: from king.mcs.drexel.edu (localhost [127.0.0.1]) by king.mcs.drexel.edu (8.12.9/8.12.8) with ESMTP id h8MLJG6T009011; Mon, 22 Sep 2003 17:19:17 -0400 (EDT) Received: (from vp@localhost) by king.mcs.drexel.edu (8.12.9/8.12.8/Submit) id h8MLJAnA009010; Mon, 22 Sep 2003 17:19:10 -0400 (EDT) Date: Mon, 22 Sep 2003 17:19:10 -0400 (EDT) From: Vassilis Prevelakis Message-Id: <200309222119.h8MLJAnA009010@king.mcs.drexel.edu> To: rpsec@ietf.org Subject: Re: [RPSEC] RP Requirements Doc Comments... Cc: riw@cisco.com, tony.tauber@level3.com 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > > > 2.1 What MUST / SHOULD be protected ? > > > > > > Distribution of destination reachability information with the > > > required policy considerations (QoS, trusted route, etc.) is what > > > is expected from a routing protocol. > > > > > > Possibly replace with: > > > > > > Routing protocols act as distributed databases with very quick > > > synchornzation times. > > > > Is that always true? Is RIP a distributed database? I don't get that > > RIP routers' view must be synchronized to work. Which is not to say they > > can just disagree w/o care and still have things work right. > > Yes, even though the databases might not synch, a routing protocol is still > a distributed database, essentially. This discussion is getting more and more surealistic. The question "Is RIP a distributed database?" is like asking whether English is a human being. I also think that everybody should first agree what a "distributed database" is before we start arguing whether RIP is or isn't one. (for that reason alone the statement about routing protocols and distributed databases is unsuitable for inclusion in an RFC). Finally the fundamental differences between link-state and vector distance protocols make it very difficult to generalize. So I think that the original phrasing is OK and should be left alone. **vp _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Mon Sep 22 22:29:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28908 for ; Mon, 22 Sep 2003 22:29:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1cux-0000CE-1s for rpsec-archive@odin.ietf.org; Mon, 22 Sep 2003 22:28:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N2ShFL000750 for rpsec-archive@odin.ietf.org; Mon, 22 Sep 2003 22:28:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1cuw-0000C1-Tw for rpsec-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 22:28:42 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28604 for ; Mon, 22 Sep 2003 22:28:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1cuI-00004s-9H; Mon, 22 Sep 2003 22:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ctm-0008S2-7K for rpsec@optimus.ietf.org; Mon, 22 Sep 2003 22:27:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28066 for ; Mon, 22 Sep 2003 22:27:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1cti-0001Mg-00 for rpsec@ietf.org; Mon, 22 Sep 2003 22:27:26 -0400 Received: from mesa.bbnplanet.com ([171.78.172.21]) by ietf-mx with esmtp (Exim 4.12) id 1A1cmS-0000aw-00 for rpsec@ietf.org; Mon, 22 Sep 2003 22:19:56 -0400 Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h8N2JE802506; Mon, 22 Sep 2003 22:19:14 -0400 (EDT) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Mon, 22 Sep 2003 22:19:13 -0400 (EDT) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Vassilis Prevelakis cc: rpsec@ietf.org Subject: Re: [RPSEC] RP Requirements Doc Comments... In-Reply-To: <200309222119.h8MLJAnA009010@king.mcs.drexel.edu> Message-ID: References: <200309222119.h8MLJAnA009010@king.mcs.drexel.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Vassilis, Thanks for draining the surrealism. I hadn't meant to remove sense from the discussion. Instead, I wanted to consider whether modeling RPs as databases, distributed, synchronized or otherwise was accurate or useful. I'm quite agnostic on the topic but wanted to plumb the depths somewhat. I'm happy to leave the original wording. Tony On Mon, 22 Sep 2003, Vassilis Prevelakis wrote: > > > > 2.1 What MUST / SHOULD be protected ? > > > > > > > > Distribution of destination reachability information with > > > > the required policy considerations (QoS, trusted route, > > > > etc.) is what is expected from a routing protocol. > > > > > > > > Possibly replace with: > > > > > > > > Routing protocols act as distributed databases with very quick > > > > synchornzation times. > > > > > > Is that always true? Is RIP a distributed database? I don't > > > get that RIP routers' view must be synchronized to work. Which > > > is not to say they can just disagree w/o care and still have > > > things work right. > > > > Yes, even though the databases might not synch, a routing protocol > > is still a distributed database, essentially. > > This discussion is getting more and more surealistic. > > The question "Is RIP a distributed database?" is like asking whether > English is a human being. > > I also think that everybody should first agree what a "distributed > database" is before we start arguing whether RIP is or isn't one. > (for that reason alone the statement about routing protocols and > distributed databases is unsuitable for inclusion in an RFC). > > Finally the fundamental differences between link-state and vector distance > protocols make it very difficult to generalize. > > So I think that the original phrasing is OK and should be left alone. > > **vp > > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Sep 23 07:00:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06575 for ; Tue, 23 Sep 2003 07:00:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ktw-0002I3-Gw for rpsec-archive@odin.ietf.org; Tue, 23 Sep 2003 07:00:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NB0BJ7008788 for rpsec-archive@odin.ietf.org; Tue, 23 Sep 2003 07:00:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ktt-0002HU-Sk for rpsec-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 07:00:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06537 for ; Tue, 23 Sep 2003 06:59:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1ktp-0002CA-00 for rpsec-web-archive@ietf.org; Tue, 23 Sep 2003 07:00:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1ktp-0002C7-00 for rpsec-web-archive@ietf.org; Tue, 23 Sep 2003 07:00:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ktm-0002Fw-Pc; Tue, 23 Sep 2003 07:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ktb-0002Ea-Mh for rpsec@optimus.ietf.org; Tue, 23 Sep 2003 06:59:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06528 for ; Tue, 23 Sep 2003 06:59:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1ktX-0002AT-00 for rpsec@ietf.org; Tue, 23 Sep 2003 06:59:47 -0400 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1A1ktW-00022z-00 for rpsec@ietf.org; Tue, 23 Sep 2003 06:59:47 -0400 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 48D4B345AA for ; Tue, 23 Sep 2003 12:54:42 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 6016B3F423 for ; Tue, 23 Sep 2003 13:09:31 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003092312544128621 for ; Tue, 23 Sep 2003 12:54:41 +0200 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id 3FCE33F426 for ; Tue, 23 Sep 2003 13:09:31 +0200 (CEST) Received: from jjp by localhost with local id 1A1knF-0000ro-00 for ; Tue, 23 Sep 2003 12:53:17 +0200 Date: Tue, 23 Sep 2003 12:53:17 +0200 From: Jean-Jacques Puig To: Routing Protocols Security Working Group Subject: Re: [RPSEC] RP Requirements Doc Comments... Message-ID: <20030923105317.GB31066@ivan.int-evry.fr> Mail-Followup-To: Routing Protocols Security Working Group References: <87609AFB433BD5118D5E0002A52CD75406F1730B@zcard0k6.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , On Mon, Sep 22, 2003 at 11:11:40AM -0400, Tony Tauber wrote: > > First, the doc does not take advantage of the work/knowledge that was > > acquired from the genral threat doc. > > > > It seems to me that the approach must be slightly different. > > The proper way to go (in my opinion) is to identify a list of > > threats that we are trying to medigate. > > Agreed, again. Please take the lead from Sec. 3 (and 4?) of the > Threats doc if possible. I also agree. However I think a routing protocol is designed for a specific use, and this use is what determines the threats we need to address. In fact, instead of mapping the selected threats list to the class of protocols, I would do it the other way; That is: 1 - Identify classes of protocols which map to different use (obvious classes are EGP / IGP) 2 - By class, select threats that should/must/may be mitigated. 3 - By class, mention threats that are significant but cannot be mitigated. 4 - Present requirements which address threats common to all classes. 5 - Present requirements which address threats in specific classes. 6 - Eventually explain the how the requirements mitigates the threats (appendix) For point 1 and 2, considerations may be largely independent from the design of the protocol. However, this is no longer true from point 3 (Addressing security when using distance vectors is not the same pb than for link state, true ?). This makes the approach a bit difficult. Advices / comments on this proposed structure ? -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Sep 23 09:12:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10950 for ; Tue, 23 Sep 2003 09:12:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1mx7-0001Ur-JS for rpsec-archive@odin.ietf.org; Tue, 23 Sep 2003 09:11:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NDBbj9005747 for rpsec-archive@odin.ietf.org; Tue, 23 Sep 2003 09:11:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1mx7-0001Uc-FC for rpsec-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 09:11:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10928 for ; Tue, 23 Sep 2003 09:11:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1mx5-0006Ug-00 for rpsec-web-archive@ietf.org; Tue, 23 Sep 2003 09:11:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1mx5-0006Ud-00 for rpsec-web-archive@ietf.org; Tue, 23 Sep 2003 09:11:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1mwX-0001Oe-Sb; Tue, 23 Sep 2003 09:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1mvd-0001Hv-Pm for rpsec@optimus.ietf.org; Tue, 23 Sep 2003 09:10:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10867 for ; Tue, 23 Sep 2003 09:09:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1mvc-0006MC-00 for rpsec@ietf.org; Tue, 23 Sep 2003 09:10:04 -0400 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1A1mvb-0006JE-00 for rpsec@ietf.org; Tue, 23 Sep 2003 09:10:03 -0400 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 680E134383 for ; Tue, 23 Sep 2003 15:08:17 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 88A023F42A for ; Tue, 23 Sep 2003 15:23:08 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003092315081630280 for ; Tue, 23 Sep 2003 15:08:16 +0200 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id 66CD03F42A for ; Tue, 23 Sep 2003 15:23:08 +0200 (CEST) Received: from jjp by localhost with local id 1A1msV-0001FK-00 for ; Tue, 23 Sep 2003 15:06:51 +0200 Date: Tue, 23 Sep 2003 15:06:51 +0200 From: Jean-Jacques Puig To: Routing Protocols Security Working Group Subject: Re: [RPSEC] RP Requirements Doc Comments... Message-ID: <20030923130651.GC31066@ivan.int-evry.fr> Mail-Followup-To: Routing Protocols Security Working Group References: <20030922152515.G13894@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , On Mon, Sep 22, 2003 at 03:28:55PM -0400, Russ White wrote: > > Sort of. A routing protocol is a way of distributing information that is > > used to determine reachability. A distributed database is one way to do > > that, like the LSDB based protocols. RIP and BGP are "routing by rumor" > > to borrow someone elses words. > > > > At best, in RIP and BGP, you have the portion of your neighbors database > > that they use, but you don't have a picture of the entire network. This > > changes the attack spaces. > > Well, it's a loosely syncrhonized database. What else would you > characterize it as? It's providing reachability information (data in the > form of a table) to a group of peers (distributed). > > Again, loosely, but there's no other characterization for it, unless you > want to classify it as some completely new type of application. It may be difficult to speak of a distributed database, even with taking into considerations a loose synchronization; A distributed database must achieve consistency conditions and the knowledge of all local parts should help rebuilding the distributed information with few incoherences. Local routing databases have no requirements to be consistent with the other parts of the system, and may effectively not be. At best, they are correlated databases; these databases are built with knowledge of direct neighbors and of local networks (local part), remote views of the other networks (remote part) and local configuration directives (config part). Attacks may affect directly or indirectly any of these parts. Yet I agree the concept of a distributed routing database is very convenient to get a quick understanding of most issues (like, hum, underclaiming ;). Finally, local databases are merely 'views' of the topology and routers observers with deforming glasses and deforming megaphones: It is hard to tell what the original object is only with these views. So I would avoid speaking of a routing protocol as a distributed database, moreover the final running code should not be confused with a data storage. -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Sep 23 09:51:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13299 for ; Tue, 23 Sep 2003 09:51:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nZH-00050z-8S for rpsec-archive@odin.ietf.org; Tue, 23 Sep 2003 09:51:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NDp33r019276 for rpsec-archive@odin.ietf.org; Tue, 23 Sep 2003 09:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nZH-00050p-5A for rpsec-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 09:51:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13280 for ; Tue, 23 Sep 2003 09:50:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1nZF-00004d-00 for rpsec-web-archive@ietf.org; Tue, 23 Sep 2003 09:51:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1nZE-00004a-00 for rpsec-web-archive@ietf.org; Tue, 23 Sep 2003 09:51:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nZE-0004zb-Re; Tue, 23 Sep 2003 09:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nYg-0004yY-1e for rpsec@optimus.ietf.org; Tue, 23 Sep 2003 09:50:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13246 for ; Tue, 23 Sep 2003 09:50:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1nYe-00003J-00 for rpsec@ietf.org; Tue, 23 Sep 2003 09:50:24 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1A1nYd-00002l-00 for rpsec@ietf.org; Tue, 23 Sep 2003 09:50:23 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h8NDnlIO088028 for rpsec@ietf.org; Tue, 23 Sep 2003 09:49:47 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h8MJcQJN055765; Mon, 22 Sep 2003 15:38:26 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h8MJcO62055753; Mon, 22 Sep 2003 15:38:24 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h8MJcJa02234; Mon, 22 Sep 2003 15:38:19 -0400 (EDT) Date: Mon, 22 Sep 2003 15:38:19 -0400 From: Jeffrey Haas To: Russ White Cc: Tony Tauber , Routing Protocols Security Working Group Subject: Re: [RPSEC] RP Requirements Doc Comments... Message-ID: <20030922153819.H13894@nexthop.com> References: <20030922152515.G13894@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ruwhite@cisco.com on Mon, Sep 22, 2003 at 03:28:55PM -0400 X-Virus-Scanned: by AMaViS perl-11 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , On Mon, Sep 22, 2003 at 03:28:55PM -0400, Russ White wrote: > Well, it's a loosely syncrhonized database. What else would you > characterize it as? It's providing reachability information (data in the > form of a table) to a group of peers (distributed). > > Again, loosely, but there's no other characterization for it, unless you > want to classify it as some completely new type of application. > > And, btw, link state protocols aren't so pure as you might think. When you > hit an area or routing domain border, the databases stop synch'ing even in > link state protocols. I think my quibble is with the word "distributed". RIP et al are only "distributed" in the sense that I tell you, you tell someone else. However, you tell me what you have and use not what someone else told you. Your example of the link-state protocols serves as a good example. To carry the example further, I tell you, you just pass along what I tell you and so on until it reaches a boundary. Everyone then uses the information. What this alludes to is a scope of trust. In RIP and BGP, we are expected to trust that the person directly adjacent to us has trustworthy information. In OSPF and ISIS, we have to trust that the information is flooded through the domain correctly. None of this changes our security issues, but it does mean we should take some care to make sure that we're talking about the scope of the issue within the proper context. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Sep 23 10:19:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15696 for ; Tue, 23 Sep 2003 10:19:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1o0Q-0006hd-Ra for rpsec-archive@odin.ietf.org; Tue, 23 Sep 2003 10:19:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NEJ6II025759 for rpsec-archive@odin.ietf.org; Tue, 23 Sep 2003 10:19:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1o0Q-0006hO-NU for rpsec-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 10:19:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15667 for ; Tue, 23 Sep 2003 10:18:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1o0O-0000Rc-00 for rpsec-web-archive@ietf.org; Tue, 23 Sep 2003 10:19:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1o0O-0000RZ-00 for rpsec-web-archive@ietf.org; Tue, 23 Sep 2003 10:19:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1o0L-0006g7-JF; Tue, 23 Sep 2003 10:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nzv-0006fF-01 for rpsec@optimus.ietf.org; Tue, 23 Sep 2003 10:18:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15661 for ; Tue, 23 Sep 2003 10:18:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1nzs-0000RE-00 for rpsec@ietf.org; Tue, 23 Sep 2003 10:18:32 -0400 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1A1nzs-0000R4-00 for rpsec@ietf.org; Tue, 23 Sep 2003 10:18:32 -0400 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id D896B3435B for ; Tue, 23 Sep 2003 16:15:00 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id EF7E83F42A for ; Tue, 23 Sep 2003 16:29:52 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003092316150014530 for ; Tue, 23 Sep 2003 16:15:00 +0200 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id C22BE3F42A for ; Tue, 23 Sep 2003 16:29:52 +0200 (CEST) Received: from jjp by localhost with local id 1A1nv4-0001Qw-00 for ; Tue, 23 Sep 2003 16:13:34 +0200 Date: Tue, 23 Sep 2003 16:13:34 +0200 From: Jean-Jacques Puig To: Routing Protocols Security Working Group Subject: Re: [RPSEC] RP Requirements Doc Comments... Message-ID: <20030923141334.GA3345@ivan.int-evry.fr> Mail-Followup-To: Routing Protocols Security Working Group References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , On Mon, Sep 22, 2003 at 03:11:43PM -0400, Russ White wrote: > > > I think you can mention this, but it's actually going to be > > > difficult to impossible to find any way of securing policies within > > > an EGP. Since each administrative domain can add policies to a given > > > route, anyone can essentially insert any policy. The question: > > > "Who's policy are we honoring" has to be answered before we can > > > begin to think about this. The originator's policy? Or the AS we > > > received the route from? Or the AS that currently has the route? Or > > > some other AS? I agree EGP security is an interesting challenge and this will need long discussion. But we should take care that the whole document does not fall exclusively on this topic. This is why I need more feedback about the doc structure. Hot-Topics are expected to be EGPs, distance vector protocols and possibly the confidentiality requirement. The main difficulty is that there are several ways to classify RPs, and that each classification underlines different security issues. > > > 2.2 Transport Layer Considerations > > > > > > .... > > > > > > A routing protocol designed to be, within certain extent, > > > Transport Layer independent, may provide options to activate > > > inner security features on-demand. Though such a flexibility > > > would help avoiding potential redundancy of functions with the > > > Transport Layer and adjusting performance requirements, such an > > > approach is usually not > > > > > > Do you mean "lower layer" when you say "inner?" > > > > It seems that what is meant is "internal to the protocol; transport-layer > > agnostic". Do you want "may" to be "MAY"? > > I'm not certain--I just wanted to make certain we define what we mean when > we say "inner" here. Sorry; "built-in" is meant here. > > Perhaps all of that is over-specified? Should the requirement be > > described as the need to provide for data integrity, authenticity, etc. > > as mitigation to threats outlined in the Threats document? Could go on to > > describe how such services may be imparted by the transport layer but > > include details as to how that is to be done with the given transport > > features. > > It should probably follow the threats doc better.... Agree. This will change. -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Sep 23 10:54:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18035 for ; Tue, 23 Sep 2003 10:54:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1oYG-00011O-DZ for rpsec-archive@odin.ietf.org; Tue, 23 Sep 2003 10:54:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NEs4FJ003920 for rpsec-archive@odin.ietf.org; Tue, 23 Sep 2003 10:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1oYG-000119-9g for rpsec-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 10:54:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17926 for ; Tue, 23 Sep 2003 10:53:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1oYD-00016J-00 for rpsec-web-archive@ietf.org; Tue, 23 Sep 2003 10:54:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1oYD-00016G-00 for rpsec-web-archive@ietf.org; Tue, 23 Sep 2003 10:54:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1oYC-0000z2-TG; Tue, 23 Sep 2003 10:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1oY9-0000yp-Cs for rpsec@optimus.ietf.org; Tue, 23 Sep 2003 10:53:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17921 for ; Tue, 23 Sep 2003 10:53:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1oY6-00015o-00 for rpsec@ietf.org; Tue, 23 Sep 2003 10:53:54 -0400 Received: from mesa.bbnplanet.com ([171.78.172.21]) by ietf-mx with esmtp (Exim 4.12) id 1A1oY6-00015F-00 for rpsec@ietf.org; Tue, 23 Sep 2003 10:53:54 -0400 Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h8NErL102994; Tue, 23 Sep 2003 10:53:21 -0400 (EDT) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Tue, 23 Sep 2003 10:53:20 -0400 (EDT) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Jean-Jacques Puig cc: Routing Protocols Security Working Group Subject: Re: [RPSEC] RP Requirements Doc Comments... In-Reply-To: <20030923141334.GA3345@ivan.int-evry.fr> Message-ID: References: <20030923141334.GA3345@ivan.int-evry.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mesa.bbnplanet.com id h8NErL102994 Content-Transfer-Encoding: quoted-printable 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On the topic of "EGP issues, including policy", I'd like to see if we might set it (really BGP) off to the side a bit for the time being as I think that inter-domain BGP as it's used today is kind of a special, degenerate (not in the pejorative sense) case of a routing protocol. If we think of a routing protocol fundamentally as a way to build a functional network through distribution of reachability information, would that allow us to make some general requirements and put inter-domain policy in a different section? Just tossing it out there. Tony On Tue, 23 Sep 2003, Jean-Jacques Puig wrote: > I think a routing protocol is designed for a specific use, and this > use is what determines the threats we need to address. In fact, > instead of mapping the selected threats list to the class of > protocols, I would do it the other way; That is: >=B7 > =BB=B7=B7=B7=B7=B71 - Identify classes of protocols which map to differ= ent use > =BB=B7=B7=B7=B7=B7(obvious classes are EGP / IGP) >=B7 > =BB=B7=B7=B7=B7=B72 - By class, select threats that should/must/may be = mitigated. >=B7 > =BB=B7=B7=B7=B7=B73 - By class, mention threats that are significant bu= t cannot > =BB=B7=B7=B7=B7=B7be mitigated. >=B7 > =BB=B7=B7=B7=B7=B74 - Present requirements which address threats common= to all > =BB=B7=B7=B7=B7=B7classes. >=B7 > =BB=B7=B7=B7=B7=B75 - Present requirements which address threats in spe= cific > =BB=B7=B7=B7=B7=B7classes. >=B7 > =BB=B7=B7=B7=B7=B76 - Eventually explain the how the requirements mitig= ates the > =BB=B7=B7=B7=B7=B7threats (appendix) >=B7 > =BB=B7=B7=B7=B7=B7For point 1 and 2, considerations may be largely inde= pendent from > =BB=B7=B7=B7=B7=B7the design of the protocol. However, this is no longe= r true from > =BB=B7=B7=B7=B7=B7point 3 (Addressing security when using distance vect= ors is not the > =BB=B7=B7=B7=B7=B7same pb than for link state, true ?). This makes the = approach a bit > =BB=B7=B7=B7=B7=B7difficult. >=B7 > =BB=B7=B7=B7=B7=B7Advices / comments on this proposed structure ? >=B7 >=B7 On Tue, 23 Sep 2003, Jean-Jacques Puig wrote: > On Mon, Sep 22, 2003 at 03:11:43PM -0400, Russ White wrote: > > > > I think you can mention this, but it's actually going to be > > > > difficult to impossible to find any way of securing policies > > > > within an EGP. Since each administrative domain can add > > > > policies to a given route, anyone can essentially insert any > > > > policy. The question: "Who's policy are we honoring" has to be > > > > answered before we can begin to think about this. The > > > > originator's policy? Or the AS we received the route from? Or > > > > the AS that currently has the route? Or some other AS? > > I agree EGP security is an interesting challenge and this will > need long discussion. But we should take care that the whole > document does not fall exclusively on this topic. This is why > I need more feedback about the doc structure. Hot-Topics are > expected to be EGPs, distance vector protocols and possibly > the confidentiality requirement. The main difficulty is that > there are several ways to classify RPs, and that each > classification underlines different security issues. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Sep 23 11:24:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20030 for ; Tue, 23 Sep 2003 11:24:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1p1T-0002L4-B0 for rpsec-archive@odin.ietf.org; Tue, 23 Sep 2003 11:24:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NFOF3E008989 for rpsec-archive@odin.ietf.org; Tue, 23 Sep 2003 11:24:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1p1T-0002Ku-5r for rpsec-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 11:24:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19997 for ; Tue, 23 Sep 2003 11:24:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1p1S-0001hp-00 for rpsec-web-archive@ietf.org; Tue, 23 Sep 2003 11:24:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1p1R-0001hk-00 for rpsec-web-archive@ietf.org; Tue, 23 Sep 2003 11:24:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1p1E-0002JA-Mz; Tue, 23 Sep 2003 11:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1p0Q-0002IM-MQ for rpsec@optimus.ietf.org; Tue, 23 Sep 2003 11:23:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19969 for ; Tue, 23 Sep 2003 11:23:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1p0P-0001gs-00 for rpsec@ietf.org; Tue, 23 Sep 2003 11:23:09 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A1p0P-0001gg-00 for rpsec@ietf.org; Tue, 23 Sep 2003 11:23:09 -0400 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8NFMa5g011747; Tue, 23 Sep 2003 11:22:36 -0400 (EDT) Received: from dhcp-64-102-60-51.cisco.com (dhcp-64-102-60-51.cisco.com [64.102.60.51]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA07849; Tue, 23 Sep 2003 11:22:36 -0400 (EDT) Date: Tue, 23 Sep 2003 11:22:36 -0400 (EDT) From: Russ White Reply-To: Russ White To: Tony Tauber cc: Jean-Jacques Puig , Routing Protocols Security Working Group Subject: Re: [RPSEC] RP Requirements Doc Comments... In-Reply-To: Message-ID: References: <20030923141334.GA3345@ivan.int-evry.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > On the topic of "EGP issues, including policy", I'd like to see if we > might set it (really BGP) off to the side a bit for the time being as I > think that inter-domain BGP as it's used today is kind of a special, > degenerate (not in the pejorative sense) case of a routing protocol. > > If we think of a routing protocol fundamentally as a way to build a > functional network through distribution of reachability information, > would that allow us to make some general requirements and put > inter-domain policy in a different section? Just tossing it out there. Inter-domain could be put in a different document--which is probably the right long term solution. My original point was not to bring BGP specifically into the picture, but to illustrate that making "securing the path" a requirement is problematic. EGPs are the easiest place to illustrate this, but I also believe it to be true in all distance vector protocols, and link state protocols once they pass over an area or l1/l2 edge. So, let's not worry about the EGP specific part, but rather on this not being a requirement we can actually specify, perhaps (?). :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Sep 25 12:49:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05340 for ; Thu, 25 Sep 2003 12:49:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZIt-0005Vp-BA for rpsec-archive@odin.ietf.org; Thu, 25 Sep 2003 12:49:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PGnJkn021183 for rpsec-archive@odin.ietf.org; Thu, 25 Sep 2003 12:49:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZIt-0005Va-6t for rpsec-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 12:49:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05264 for ; Thu, 25 Sep 2003 12:49:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2ZIr-0001SE-00 for rpsec-web-archive@ietf.org; Thu, 25 Sep 2003 12:49:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2ZIr-0001SA-00 for rpsec-web-archive@ietf.org; Thu, 25 Sep 2003 12:49:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZIb-0005QB-8W; Thu, 25 Sep 2003 12:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZHl-0005NO-FI for rpsec@optimus.ietf.org; Thu, 25 Sep 2003 12:48:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05163 for ; Thu, 25 Sep 2003 12:48:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2ZHj-0001Pp-00 for rpsec@ietf.org; Thu, 25 Sep 2003 12:48:07 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A2ZHj-0001Ot-00 for rpsec@ietf.org; Thu, 25 Sep 2003 12:48:07 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 25 Sep 2003 09:45:50 -0700 Received: from sconvery-lnx1.cisco.com (sconvery-lnx1.cisco.com [171.71.118.67]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8PGlZ0E011207 for ; Thu, 25 Sep 2003 09:47:36 -0700 (PDT) Received: (from sconvery@localhost) by sconvery-lnx1.cisco.com (8.11.6/8.11.6) id h8PGlZf26151 for rpsec@ietf.org; Thu, 25 Sep 2003 09:47:35 -0700 Date: Thu, 25 Sep 2003 09:47:35 -0700 From: Sean Convery To: rpsec@ietf.org Message-ID: <20030925094735.A26117@sconvery-lnx1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: [RPSEC] 01 Version of BGP Attack Tree 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: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Just an FYI, we've published the 01 version of the BGP attack tree: http://www.ietf.org/internet-drafts/draft-convery-bgpattack-01.txt Change log follows: minor spelling, wording fixes merged tree element 2.1.1.3.1 with 2.1.1.3.1.1 fixed tree mistake in 2.1.3.2.2 clarified definition of permissive router in section 2.1.2 fixed ORs in 2.1.5.3 and 2.1.5.4 reworked 2.1.5.4.1 (Update flooding) per list comments Clarified 2.1.3 based on list comments Added reference to NANOG BGP testing prezo and integrated portions of results into draft Switched to mnemonic references instead of numbers Comments welcome as always. Thanks, Sean _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec