Network Working Group JJ. Puig Internet-Draft January 2005 Expires: July 2, 2005 Generic Security Requirements for Routing Protocols - Opened Questions draft-puig-rpsec-rqts-opened-questions-01 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 July 2, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document introduces and presents problematics of the 'Generic Security Requirements for Routing Protocols' document. Puig Expires July 2, 2005 [Page 1] Internet-Draft rpsec: Requirements Opened Questions January 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope of the requirements document . . . . . . . . . . . . . . 3 3. General issues . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Terms and concepts . . . . . . . . . . . . . . . . . . . . . . 4 6. Identities . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Establishing the neighboring relationship . . . . . . . . . . 5 8. Routing operations which have a strong incidence on security . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 9. Routing and time . . . . . . . . . . . . . . . . . . . . . . . 6 10. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1 Bootstrapping trust . . . . . . . . . . . . . . . . . . . 6 10.2 Levels of trust . . . . . . . . . . . . . . . . . . . . . 7 10.3 What do we do with dubious information ? . . . . . . . . . 7 10.4 In-transit injections . . . . . . . . . . . . . . . . . . 7 11. Edges coherence . . . . . . . . . . . . . . . . . . . . . . . 7 12. DOS prevention with token-based schemes . . . . . . . . . . . 7 13. Reacting . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 14. Inter-domain specificities . . . . . . . . . . . . . . . . . . 8 15. Getting in . . . . . . . . . . . . . . . . . . . . . . . . . . 8 16. Security Considerations . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 9 Puig Expires July 2, 2005 [Page 2] Internet-Draft rpsec: Requirements Opened Questions January 2005 1. Introduction This document introduces and presents problematics of the 'Generic Security Requirements for Routing Protocols' document. This document's goal is to provide a quick start to -and a progress report of- the requirements document. It also presents issues opened to discussion. 2. Scope of the requirements document Several topics are related to routing security, among which: o The routing protocol: this is what the requirements document is about. This encompasses protocol's control and data planes protection (PDU protection, state machine, functions, data protection...). o The routing system: where protection of the routing system is considered, routers which propagate the routing information may participate to the global security. Routing protocol's security mechanisms may or may not participate to this security. o The routing scheme: the way networks are described (prefixes) and the possible evolutions (supernetting) the descriptions may experience during operations of the routing protocol have a serious impact on security. But which security ? Those of the protocol or those of the routing system ? o The routing device: it's design may affect the routing protocol security. The relations between these topics should be considered with respect to the requirements document. As an instance, the routing scheme is an important cause of the overclaiming threat; is security of the routing protocol those of a local instance or those of it's global operation within the routing system ? Etc. Currently, the requirements document may drift too much toward the routing device security; reviews are needed for feedback regarding this question. There should be a noticeable reduction of local considerations in future versions. 3. General issues Discussing generic requirements is difficult given current specialization of routing protocols. Review is needed in order to appreciate whether current requirements are a correct trade-off with Puig Expires July 2, 2005 [Page 3] Internet-Draft rpsec: Requirements Opened Questions January 2005 respect to protocol scalability, to the transport subsystem (multicast...), etc. Of course, strength of requirements (MUSTs, SHOULDs, etc.) must also be discussed. 4. Threats The requirements document presents a sorted list of threats, which set priorities on them for the development of the requirements. Is this approach correct ? Should this section be kept in the requirements doc ? Regarding the development of requirements, two paths may be followed: o presenting requirements as opposed to threats o presenting requirements as associated with the protection of functional parts of the routing protocol (transport subsystem, neighbor state maintenance, database maintenance). Currently, the requirements doc presents requirements as opposed to threats; another section presents protection of functional parts and refers to adequate ad-hoc requirements. This approach is opened for discussion. Note the 'protection of the functional parts' path may be better adapted for non-generic, protocol-specific work. A future revision of this companion document should incorporate specific notes about specificities of some threats or functions. 5. Terms and concepts Newcomers are invited to have a look at the terminology section of the requirements document. Parts of this section requires discussion, though. Specifically, it should be decided if the definition of route correctness is appropriate. Previous versions of the requirements document divided routers into two categories: those which were actually participating to the routing protocol considered (named 'relayers') and those which were intervening as part of the transport subsystem processing (named 'forwarders'). The terms were unclear, and the underlying concept appeared to be not quite necessary. Puig Expires July 2, 2005 [Page 4] Internet-Draft rpsec: Requirements Opened Questions January 2005 Previous versions of the requirements document had several paragraphs whose purpose was to deal with trust we may derive for paths. As this is a difficult topic to address for routing protocols, this was discarded. Discussion is needed in order to figure out if trust paradigms for paths should be addressed within the draft or not. Terminology section divides local routing operations into: routing function, routing decision, forwarding function. Is this appropriate ? 6. Identities A general assumption within the requirements document is that routers are associated with identities. Furthermore, public cryptographic material is also associated with identities, which may be those of organizations or networks. Is there a need to develop on this topic ? Should the requirements document make statements regarding the identities allocation scheme ? 7. Establishing the neighboring relationship The requirements document makes the general hypothesis that an out-of-the-routing-protocol mechanism allows for neighbors to recognize each-others during neighbors relationship establishment. Should the requirements document develop on this ? Should it state it very explicitly ? 8. Routing operations which have a strong incidence on security Some routing protocol operations have a strong incidence on security. Precisely, the following operations threaten information traceability, and prevent routing protocols from building any form of transitive authority: Routes generalization / specialization (ex: through the prefix length) Aggregation (ex: BGP path aggregation) Filtering Current requirements do not prevent against any of these operations. Should we set requirements regarding these operations ? Regarding route generalization / specialization, another issue may be raised: which should take precedence ? As an instance, if prefix P1 Puig Expires July 2, 2005 [Page 5] Internet-Draft rpsec: Requirements Opened Questions January 2005 is shorter than prefix P2, which should be re-advertised ? which should be installed ? should we consider that these pieces of information are not comparable and use both ? Should the address allocation scheme give a kind of legitimacy for some prefixes against some others ? 9. Routing and time The requirements document introduces many limitations with regard to time validity of cryptographic material, cryptographic evidences and routing information. Cryptographic material and evidences are related and both have a limited lifetime. The way this limitation is implemented is outside the scope of the requirements document. Routing information is not time-limited when flooded through the routing protocol messages. However, it is recommended that routing information from which the local process can only derive a low level of trust will be inserted with an adequate lifetime in the routing database. This way, a routing device may decide to discard a routing database entry with knowledge of the trust level, of other routes to similar or related destinations, of the age of the information. We need to discuss on whether these statements are appropriate or not. Furthermore, do we need to address time granularity and elaborate on mechanisms ? 10. Trust 10.1 Bootstrapping trust The requirements document assumes that trust starts with the verifiable knowledge of 'who owns what', 'who controls what', 'who is authorized to advertised what'. By advertisers here are actually meant originators, even though one may imagine authorizations schemes for re-advertisements. There are several points to discuss: o Is the 'chain' approach relevant ? Note that the approach may map to offline or online schemes, in-band or out-band, hierarchic (as in PKIs) or non-hierarchic (as in web of trusts), on-demand or diffusion. o Should it be worded differently, possibly in a section of it's own ? Puig Expires July 2, 2005 [Page 6] Internet-Draft rpsec: Requirements Opened Questions January 2005 10.2 Levels of trust Given that routing information may not be entirely trusted when it is not learnt first-hand, that all participants may not be involved in a fully-trusting relationship, and that, on the other-hand, we may need to route to more destinations than the subset we can actually trust, use of heuristics to derive trust levels may be a requirement. This should be discussed; may be this should also be presented in a stand-alone section. 10.3 What do we do with dubious information ? What should be done with routes whose trust level is unknown or low ? Currently, requirements state that installing these data is a local policy decision, and they should be installed with a limited lifetime. One may also suggest that this data should only be used for the routing protocol operations, not for user traffic. 10.4 In-transit injections What's the value of an attribute injected by a propagator ? In other words, should we study how injection should affect the confidence associated with routing information ? 11. Edges coherence Do routing incoherences at the boundary of a routing domain affect the security of routing protocols ? Should the requirements document discuss this ? 12. DOS prevention with token-based schemes This topic was mentioned on the list some times ago. As this is solution space, it should not be mentioned in the requirements. However, should they mention the need for a fast rejection mechanism ? Is there a need to elaborate ? 13. Reacting Security mechanisms can not prevent all security issues. As a consequence, should the requirements document express requirements regarding incidents detection and reactive / failback procedures ? Note that these affect the routing protocol in that, on one hand, design of the routing protocol may help for preventing further progression of damages and for recovering and, on the other hand, local procedures should be able to control the routing protocol accordingly. Puig Expires July 2, 2005 [Page 7] Internet-Draft rpsec: Requirements Opened Questions January 2005 14. Inter-domain specificities Inter-domain routing involves organizations which may have different interests in the network. Political aspects of routing are greatly exacerbated in this context. It is therefore much more difficult to determine who can be trusted. The requirements document make no statement about the architectural scheme which should support inter-domain routing security, even though the topic is discussed in a section of its own. 15. Getting in People interested in participating are encouraged to read this document and at least the requirements document terminology. Further readings include other sections of the requirements document and the threats document. Requirements doc sources, versions and tagged versions can be found at: http://www-lor.int-evry.fr/~puig/rpsec-rqts/ . 16. Security Considerations This draft is security related. Specifically it summarizes opened questions with current work on the establishment of generic security requirements for routing protocols. Author's Address Jean-Jacques Puig CNRS / UMR 5157 (Samovar) / 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/ Puig Expires July 2, 2005 [Page 8] Internet-Draft rpsec: Requirements Opened Questions January 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Puig Expires July 2, 2005 [Page 9]