One document matched: draft-puig-rpsec-rqts-opened-questions-01.txt
Differences from draft-puig-rpsec-rqts-opened-questions-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 13:07:21 |