INTERNET DRAFT C. Neumann Expires: April 30, 2004 INRIA A. Foglar INFINEON Trusted Networks/Security as QoS Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Distribution of this memo is unlimited. This document is an Internet-Draft. 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 April 30, 2004. Abstract Based on the QoS architecture and the DS codepoints defined in RFC2474 and RFC2475 we define an application that creates a trusted environment. We introduce the notion of Trusted Networks (TN) a network that has to satisfy a set of rules that can be specified by each network owner. Packets originating from this or another TN can be treated with higher confidence and higher QoS than packets from untrusted networks. The basic tool of our proposal is ingress filtering RFC2827. This approach may apply to both IPv4 and IPv6. Neumann, Foglar Expires April 30, 2004 [Page 1] Internet-Draft Trusted Networks October 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Background. . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Overview. . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . 3 2. Marking Trusted-Network Traffic. . . . . . . . . . . . . . 6 3. Trusted Networks . . . . . . . . . . . . . . . . . . . . . 7 3.1 Definition of TN . . . . . . . . . . . . . . . . . . . . 7 3.2 Entity Specific Rules (ESR). . . . . . . . . . . . . . . 7 3.3 Interconnecting Trusted Networks . . . . . . . . . . . . 8 4. Ingress Filtering. . . . . . . . . . . . . . . . . . . . . 9 5. Using trusted traffic. . . . . . . . . . . . . . . . . . . 10 6. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations. . . . . . . . . . . . . . . . . . 11 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 12 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction 1.1 Background It is a common trend to build more and more closed and secured networks. It is quite improbable that a malicious host is located in such a network or that a malicious user has access to nodes of this network. Public authorities push more and more ISPs and network operators to build these kind of networks that have to satisfy a high set of requirements. Starting from that observation we propose a mechanism that benefits from these type of networks. Differentiated treatment of the traffic according to the trust that one has in the network is now possible. We believe that our proposal will enable operators to secure their networks even more and the notion of trust into a network will become common. This document is presented with a ''telecom'' view on the problem, that means our work will mainly apply to networks of telecom operators, but may also be used otherwise. 1.2 Overview The idea of this proposal is to mark packets that fulfill a given set of rules. These rules are security and trust considerations mainly (other rules may apply). Because of the marking it is possible to differentiate marked packets from non marked packets and behavior of routers and host may vary depending of the type of packet. This is very close to Differentiated Services (DS) QoS and many terms and parts of the architecture will come from DiffServ or simply use Neumann, Foglar Expires April 30, 2004 [Page 2] Internet-Draft Trusted Networks October 2003 DiffServ terms and architecture. It is possible to consider our approach as an application of DiffServ. Our proposal is however more concerned about security and trust issues than delay and bandwidth concerns that may come from an multimedia application for example. Moreover the use of the differentiation is not restricted to routers and their respective Per-Hop-Behavior (PHB) but is extended to firewalls and hosts (and possibly more) that may apply additional rules to packets like blocking or logging non marked packets. 1.3 Terminology This section gives a general conceptual overview of the terms used in this document. Many of them are taken from [3] or very similar. Some of these terms are more precisely defined in later sections of this document. Behavior Aggregate (BA) a TN behavior aggregate. BA classifier a classifier that selects packets based only on the contents of the TN field. Boundary link a link connecting the edge nodes of two domains. Classifier an entity which selects packets based on the content of packet headers according to defined rules. DS Differentiated Services ESR Entity specific Rules. TN-marked TN-bit is set to 1. TN-unmarked TN-bit is set to 0. TN behavior aggregate a collection of packets with the same TN codepoint crossing a link in a particular direction. TN boundary node a TN node that connects one TN domain to a node either in another TN domain or in a domain that is not a TN. Neumann, Foglar Expires April 30, 2004 [Page 3] Internet-Draft Trusted Networks October 2003 TN domain a TN; a contiguous set of nodes which operate with a common set of ESR. TN and TN domain is used indifferently in this document. TN egress node a TN boundary node in its role in handling traffic as it leaves a TN domain. TN ingress node a TN boundary node in its role in handling traffic as it enters a TN domain. TN interior node a TN node that is not a TN boundary node. TN-bit the codepoint that marks the packet as TN-marked/unmarked TN node a TN-compliant (to ESR) node. TN region a set of contiguous TN domains using same or compliant ESR. Downstream TN domain the TN domain downstream of traffic flow on a boundary link. Dropper a device that performs dropping. Dropping the process of discarding packets based on specified rules; policing. Marker a device that performs marking. Marking the process of setting the TN-bit in a packet based on defined rules; pre- marking, re-marking. Mechanism a specific algorithm or operation (e.g., queuing discipline) that is implemented in a node to realize a set of one or more per- hop behaviors. Per-Hop-Behavior (PHB) the externally observable forwarding behavior applied at a TN-compliant node to a TN behavior aggregate. PHB group a set of one or more PHBs that can only be meaningfully specified and implemented simultaneously, due to a common constraint applying to all PHBs in the set such as a queue servicing or queue management policy. Neumann, Foglar Expires April 30, 2004 [Page 4] Internet-Draft Trusted Networks October 2003 A PHB group provides a service building block that allows a set of related forwarding behaviors to be specified together (e.g., four dropping priorities). A single PHB is a special case of a PHB group. Policing the process of discarding packets (by a dropper) within a traffic stream in accordance with the state of a corresponding meter enforcing a traffic profile. Pre-mark to set the TN codepoint of a packet prior to entry into a downstream DS domain. Re-mark to change the TN codepoint of a packet, usually performed by a marker in accordance with a TCA. Service the overall treatment of a defined subset of a customer's traffic within a DS domain or end-to-end. Source domain a domain which contains the node(s) originating the traffic receiving a particular service. Service Level Agreement a service contract between a customer and a (SLA) service provider that specifies the forwarding service a customer should receive. A customer may be a user organization (source domain) or another TN domain (upstream domain). A SLA may include traffic conditioning rules which constitute a TCA in whole or in part. Traffic conditioner an entity which performs traffic conditioning functions and which may contain meters, markers, droppers, and shapers. Traffic conditioners are typically deployed in TN boundary nodes only. A traffic conditioner may re-mark a traffic stream or may discard or shape packets to alter the temporal characteristics of the stream and bring it into compliance with a traffic profile. Neumann, Foglar Expires April 30, 2004 [Page 5] Internet-Draft Trusted Networks October 2003 Traffic conditioning control functions performed to enforce rules specified in a TCA, including metering, marking, shaping, and policing. Traffic Conditioning an agreement specifying classifier rules Agreement (TCA) and any corresponding traffic profiles and metering, marking, discarding and/or shaping rules which are to apply to the traffic streams selected by the classifier. A TCA encompasses all of the traffic conditioning rules explicitly specified within a SLA along with all of the rules implicit from the relevant service requirements and/or from a DS domain's service provisioning policy. Upstream TN domain the DS domain upstream of traffic flow on a boundary link. 2. Marking Trusted-Network Traffic For our proposal a bit within the IP header is needed. This bit, that we call TN-bit, is set to 1 or 0 corresponding to the rules described later in this document. A packet is considered as TN-marked if the TN-bit is set to 1. Otherwise the packet is considered as TN-unmarked. We propose to use one of the two currently unused bits (CU bits) of the Traffic Class Field in IPv6 (TOS in IPv4). This is the preferred solution. The mapping of the TN-bit for the preferred solution is: 0 1 2 3 4 5 6 7 +----+----+----+----+----+----+----+----+ | DSCP | CU | TN | +----+----+----+----+----+----+----+----+ DSCP: differentiated services codepoint CU: currently unused TN: trusted network bit Alternatively we can use a bit out of the existing DiffServ fields defined in [2]. (In other words starting from a given traffic class (TN-class) or codepoint the traffic is TN traffic). We do not specify Neumann, Foglar Expires April 30, 2004 [Page 6] Internet-Draft Trusted Networks October 2003 out of which Pool [2] the codepoint should be. This option has the disadvantage that trusted networks are not independent on QoS. In this document we call the corresponding bit TN-bit, indifferently if DiffServ fields or other fields are used. 3. Trusted Networks 3.1 Definition of TN This document introduces the notion of Trusted Networks (TN). Such a network satisfies a set of requirements which will be specified in this document. A typical Trusted Network normally consists of one or more networks under the same administration; for example, an organization's intranet or an ISP. In the example of an ISP, the ISP has control over all nodes and links within his access network. It is left to the ISP if it considers the equipments of its customers (e.g. CPE) as being part of the Trusted Network or not. A trusted network is composed of a set of nodes (TN node) which are either TN boundary or interior nodes. TN boundary nodes interconnect the TN to other trusted or untrusted networks. TN interior nodes only connect to other TN interior or boundary nodes within the same TN. One entity (e.g. one ISP) is responsible in administrating the whole network. This entity must know all the TN nodes (boundary or interior) part of that network and be able to administrate all these TN nodes. It is possible to delegate this task to a another entity (e.g. in case of two ore more connected trusted networks). All packets traffic originating from within the Trusted Network should have the TN-Bit set to 1 and set to 0 otherwise, if not specified otherwise in the ESR. 3.2 Entity Specific Rules (ESR) The notion trusted network is defined in a variable manner. An ISP could for example consider his own network as a trusted network, but another ISP could consider this same network as untrusted, since the second ISP may apply different rules and requirements to a trusted network (we call these rules Entity Specific Rules (ESR)). A set of rules and requirements have to be defined by the administrating entity for the whole network. These rules concern Neumann, Foglar Expires April 30, 2004 [Page 7] Internet-Draft Trusted Networks October 2003 links and nodes of the TN. They define the security model adapted (e.g. only IPSec traffic allowed, no wireless links etc.). We call these rules Entity Specific Rules (ESR), since they are defined by each entity independently. ESR set the required security/trust that is required by the traffic or network. Here are some examples of possible ESR (many other ESR are possible): - All nodes of the TN must have one common prefix (e.g /32). Their might exist nodes having the same prefix but not being part of the Trusted Network. - The TN-Bit can be left unchanged, if ingress filtering with prefix length /48 (or more up to /64) is performed successfully on a TN boundary node (This may be a typical rule for an ISP that consider its clients with their DSL connection for instance being part of the TN. The access server is then the TN boundary node). - Wireless links are not part of the TN, if they are used without any encryption mechanism (e.g. WEP). 3.3 Interconnecting Trusted Networks One Trusted Networks (TN 1) may be connected to another Trusted Network (TN 2) and consider all traffic receiving from TN 2 as fulfilling his own ESR. In that case the border routers of TN1 can forward the incoming traffic as is into its own network (the TN-bit is left unchanged). If one Trusted Network does not consider a connected network as Trusted, then the border router must Re-mark traffic as TN-unmarked (setting the corresponding bit to 0), if not specified otherwise in the ESR. Two connected Trusted Networks that fulfill both the same ESR can be considered as one Trusted Network. It is possible to have the case where one TN 1 trust TN 2 but TN 2 does not trust TN 1. In that case TN1 1 will consider TN 1 plus TN 2 as one Trusted Network. TN 2 will only consider its own network (TN 2) as trusted. The Service Level Agreement (SLA) between the TNs should specify whether the two networks trust each other or not, and which ESR each network has to fulfill. Neumann, Foglar Expires April 30, 2004 [Page 7] Internet-Draft Trusted Networks October 2003 TNs can be cascaded when the relationship between adjacent networks Is symmetric. If for example TN 1 trusts TN 2 and vice-versa and TN 2 trusts TN 3 and vice-versa then TN 1 can trust traffic from TN 3 and vice-versa without having to negotiate directly with TN 3. 4. Ingress Filtering Ingress Filtering [1] is an important tool for TNs. It allows to verify the source of packets up to a given prefix length, verifying for example if packet source is part of the TN. We use the term ingress filtering in the sense that we only verify the source address prefix of the packet. The action taken after verifying (dropping, TN-unmark, none...) depends on the ESR, the node and the result of ingress filtering but is not part of ingress filtering. Ingress filtering is done at TN boundary nodes. Normally TN boundary nodes should drop packets coming from outside the TN with false source packet prefix. With correct source prefix the TN-bit should be set to 0 if coming from an untrusted network, or left unchanged if coming from another trusted TN. Default recommended actions depending on origin and prefix check result: Check result\Origin Trusted network Untrusted Network Correct prefix none TN-unmark Incorrect prefix drop drop This behavior may change for some networks. For example a common rule can be to leave the TN-bit unchanged if the checked prefix length is long enough (i.e. 64 bit long). This must be specified in the ESR, and may be a common rule for an ISP when checking address prefixes of packets received from its customers. This behavior is showed in the next example: The customer might set TN-bit to 1 for all packets. If a packet passes ingress filtering at a (remote) access server (it is a TN boundary node of the ISP) with correct source address prefix of a prefix length of 64 bit the TN-bit of the packet is not changed. If the source address prefix does not match, the packet is dropped. A customer may intentionally set the TN-bit to 0. In this case Ingress filtering will not change the TN-bit, even if the source address prefix is correct. The customer might do so if he wants to enforce a different policy at the destination point of the traffic. Neumann, Foglar Expires April 30, 2004 [Page 9] Internet-Draft Trusted Networks October 2003 The concept of TN is used to verify the source of packets (up to a certain prefix). This ensures to all users of this TN that attacks described in [1] can be eliminated. 5. Using trusted traffic The traffic that has been TN-marked, can be treated differently than TN-unmarked traffic. We call this differentiated treatment "Service" as defined in [2]. In this document we do not define how trusted traffic should be used or what the final gain for the user would be. However we enumerate a set of services to motivate the use of our proposal. The notion of service has to be introduced first. Service: a description of the overall treatment of (a subset of) a customer's traffic across a particular domain, across a set of interconnected TN domains, or end-to-end. Service descriptions are covered by administrative policy and services are constructed by applying traffic conditioning to create behavior aggregates which experience a known PHB at each node within the DS (here TN) domain. Multiple services can be supported by a single per-hop behavior used in concert with a range of traffic conditioners. A "Service" defines some significant characteristics of packet transmission in one direction across a set of one or more paths within a network. These characteristics may be specified in quantitative or statistical terms of throughput, delay, jitter, and/or loss, or may otherwise be specified in terms of some relative priority of access to network resources. Service differentiation is desired to accommodate heterogeneous application requirements and user expectations, and to permit differentiated pricing of Internet service. Service provisioning and traffic conditioning policies are sufficiently decoupled from the forwarding behaviors within the network interior to permit implementation of a wide variety of service behaviors, with room for future expansion. We do not define any PHB or Service in this document. This is dependent on each implementation of our proposal. But to give an example a node could give lower priority or even deny packets with TN-Bit equal to 0. Typically this will be performed by a firewall that can simply verify the TN-bit. Moreover a node could give specified QoS to trusted packets only as these can be assigned to a particular customer. Packets with TN-bit equal to 0 could be given best effort QoS only. Neumann, Foglar Expires April 30, 2004 [Page 10] Internet-Draft Trusted Networks October 2003 At the destination point of a traffic flow the ingress firewall might apply different policies for packets with TN-bit=1 and TN-bit=0. Packets with TN-bit=0 may be treated as in current, untrusted networks. Packets with TN-bit=1 may receive a prioritized treatment. Any definition of firewall policy is beyond the scope of this text. An application (i.e. video-conferencing) may require that the traffic is trusted. It then only treats TN-marked packets and ignores all other packets. 6. Summary The concept of Trusted Networks (TN) is introduced. A TN filters packets entering the network at all ports, customer connecting points and gateways to other networks. Filtering means basically the verification of the source address prefix of the packets. Given the ingress filtering result, the trust given to the upstream network and the ESR the packet is TN-marked, -unmarked, dropped or left unchanged. The TN-bit is introduced in the IP packet header to distinguish hbetween TN-marked (TN-bit=1) and TN-unmarked (TN-bit=0) packets. The TN-bit can only be set to 1 by the source originating a packet. Routers along the path of a flow can only reset the TN-bit to 0. A router can only set a cleared TN-bit to 1 if the ESR specifies this. Based on this behavior a TN can distinguish two types of packets, TN-marked and TN-unmarked packets. For TN-marked packets the TN guarantees correctness of the source address prefix and accordance to a specified ESR. The customer of a TN can use the TN-bit of received packets as a valuable security information. 7. Security Considerations A malicious host sending traffic to an TN from the outside of the TN with the TN-bit set to 1: The defense against this class of theft- and denial-of-service attacks consists of the combination of traffic conditioning at TN boundaries with security and integrity of the network infrastructure within a TN. TN boundary nodes MUST ensure that all traffic entering the TN is marked with TN-bit values appropriate to the traffic and the TN, remarking the traffic with TN-bit values if necessary. These TN boundary nodes are the primary line of defense against theft- and denial-of-service attacks based on modified codepoints, as success of any such attack indicates that the codepoints used by the attacking traffic were inappropriate. An important instance of a boundary node is that any traffic-originating node within a TN is the initial boundary node for that traffic. Neumann, Foglar Expires April 30, 2004 [Page 11] Internet-Draft Trusted Networks October 2003 A malicious person that was able to break into one of the nodes of the Trusted Network, could send packets with forged source addresses setting the TN-Bit to one. This packet would be forwarded and considered as trusted. However nodes of a trusted Network should be secure enough so that an unauthorized person should not be able to break into one of them. 8. Acknowledgments The authors would like to acknowledge the helpful contributions of Pascal Moniot from STM and Michel Sarlotte from Thales References [1] P.Ferguson and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2827, May 2000. [2] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [3] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. Authors' Addresses Christoph Neumann INRIA Rhone-Alpes 655 avenue de l'Europe 38330 Montbonnot Saint-Martin FRANCE email: christoph.neumann@inria.fr phone: +33 4 76 61 52 69 fax: +33 4 76 61 52 52 Andreas Foglar Infineon Technologies St.-Martin-Str. 76 81541 Munich GERMANY email: andreas.foglar@infineon.com phone: +49-89-234-24616 Neumann, Foglar Expires April 30, 2004 [Page 12]