Network Working Group S. KONDO Internet-Draft Trend Micro Inc. Expires: January 16, 2005 S. SUZUKI Hitachi, Ltd. A. INOUE Toshiba Corporation R&D Center July 18, 2004 Quarantine Model Overview for IPv6 Network Security draft-kondo-quarantine-overview-01 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 January 16, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract In the current Internet, a site is often secured by firewall, which filters bogus traffic from outside at the border of the site. This 'Border Defense Model', however, has lots of potential security issues, and also prevents a deployment of next-generation Internet applications and services. This memo surveys the security issues of the 'Border Defense Model', and proposes a network architecture 'Quarantine Model', to prevent KONDO, et al. Expires January 16, 2005 [Page 1] Internet-Draft Quarantine Model Overview July 2004 those security issues and promote various end-to-end Internet usages. In our 'Quarantine Model', network nodes are connected to separate network segments according to their security levels. And a different security policy is implemented on each network segment using the multiple security-related techniques, such as filtering, authentication, and encryption. This 'devide and conquer' framework provides more flexible and better network security to 'Quarantine Model'. This memo enumerates requirements and issues for this architecture. However, it is beyond the scope of this document to propose specific implementations or protocols. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Issues in border defense model . . . . . . . . . . . . . . . . 5 2.1 Technical issues of border defense model . . . . . . . . . 5 2.1.1 Traffic volume and full packet inspection . . . . . . 5 2.1.2 Encrypted and tunneling session . . . . . . . . . . . 5 2.2 Operational issues border defense model . . . . . . . . . 5 2.2.1 Immediate update of filtering rule against new security issues . . . . . . . . . . . . . . . . . . . 5 2.2.2 Mobility node (Note PC) control, wireless LAN . . . . 6 2.2.3 Unmanaged network . . . . . . . . . . . . . . . . . . 6 2.3 Requirements of new security model for IPv6 . . . . . . . 6 3. Architecture overview . . . . . . . . . . . . . . . . . . . . 7 3.1 Key concept . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Security segments and policy enforcement . . . . . . . . . 8 3.2.1 Quarantine segment . . . . . . . . . . . . . . . . . . 8 3.2.2 Isorated segment . . . . . . . . . . . . . . . . . . . 8 3.2.3 Normal segment . . . . . . . . . . . . . . . . . . . . 9 3.3 Advantage of quarantine model . . . . . . . . . . . . . . 9 4. Quarantine model components . . . . . . . . . . . . . . . . . 10 4.1 Quarantine inspection agent . . . . . . . . . . . . . . . 10 4.2 Quarantine server . . . . . . . . . . . . . . . . . . . . 11 4.3 Policy enforcement point . . . . . . . . . . . . . . . . . 11 4.4 Policy enforcer . . . . . . . . . . . . . . . . . . . . . 11 4.5 Quarantine monitor . . . . . . . . . . . . . . . . . . . . 12 4.5.1 Host type quarantine monitor . . . . . . . . . . . . . 12 4.5.2 Network type quarantine monitor . . . . . . . . . . . 12 4.6 Prevention information server . . . . . . . . . . . . . . 12 5. Quarantine inspection . . . . . . . . . . . . . . . . . . . . 13 5.1 Network node information . . . . . . . . . . . . . . . . . 13 5.2 Quarantine certification . . . . . . . . . . . . . . . . . 13 5.3 Quarantine inspection process . . . . . . . . . . . . . . 13 5.4 Issues in quarantine inspection process . . . . . . . . . 14 KONDO, et al. Expires January 16, 2005 [Page 2] Internet-Draft Quarantine Model Overview July 2004 5.4.1 Multiple network interfaces . . . . . . . . . . . . . 14 5.4.2 Non quarantine-model-ready node . . . . . . . . . . . 14 5.4.3 Integration with the account-based authentication framework . . . . . . . . . . . . . . . . . . . . . . 15 6. Network separation . . . . . . . . . . . . . . . . . . . . . . 16 6.1 Security segment . . . . . . . . . . . . . . . . . . . . . 16 6.2 Policy enforcement point and segment partitioning area . . 16 6.3 Policy enforcer . . . . . . . . . . . . . . . . . . . . . 17 6.4 Trigger events for EP control . . . . . . . . . . . . . . 17 6.4.1 Quarantine compliance event . . . . . . . . . . . . . 18 6.4.2 Prevention Information update . . . . . . . . . . . . 18 6.4.3 Alert notification from quarantine monitor . . . . . . 18 6.5 Deployment for IPv6 network . . . . . . . . . . . . . . . 18 6.5.1 Link local address and security segment . . . . . . . 18 6.5.2 Control RA/RS . . . . . . . . . . . . . . . . . . . . 18 7. Prevention information . . . . . . . . . . . . . . . . . . . . 19 7.1 Prevention information deployment process . . . . . . . . 19 7.2 Update prevention information . . . . . . . . . . . . . . 20 7.3 Identification of security information . . . . . . . . . . 20 7.4 Multiple prevention informaiton sources . . . . . . . . . 20 8. Requirements and working items . . . . . . . . . . . . . . . . 21 8.1 Quarantine inspection . . . . . . . . . . . . . . . . . . 21 8.1.1 Quarantine inspection protocol . . . . . . . . . . . . 21 8.1.2 Entity information data format . . . . . . . . . . . . 21 8.1.3 EAP format extention and authentication framework integration . . . . . . . . . . . . . . . . . . . . . 21 8.2 Policy enforcement point control . . . . . . . . . . . . . 21 8.2.1 Security policy definition language . . . . . . . . . 21 8.2.2 Generic EP control protocols and commands . . . . . . 21 8.3 Prevention information . . . . . . . . . . . . . . . . . . 22 8.3.1 Prevention information data format . . . . . . . . . . 22 8.3.2 Prevention information deployment and subscription protocol . . . . . . . . . . . . . . . . . . . . . . . 22 9. Security considerations . . . . . . . . . . . . . . . . . . . 23 9.1 Protection about credential information of network nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.2 False statement of entity information . . . . . . . . . . 23 9.3 Faked quarantine server . . . . . . . . . . . . . . . . . 23 9.4 DoS attack from deceit quarantine monitor . . . . . . . . 23 9.5 Interval period of quarantine inspection . . . . . . . . . 23 9.6 Switching speed of network segment change . . . . . . . . 23 9.7 Reliablity of prevention information . . . . . . . . . . . 24 9.8 Routing between different segment . . . . . . . . . . . . 24 9.9 Multi protocol stack environment of IPv4 and IPv6 . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 11. Informative References . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . 27 KONDO, et al. Expires January 16, 2005 [Page 3] Internet-Draft Quarantine Model Overview July 2004 1. Introduction A site is often secured by firewall, which prevents network attacks from outside, such as viruses, worms, or DoS attacks. To block these kind of attacks, firewall divides internal/external networks at the border security point (e.g. the edge of the network site). At this point, the firewall blocks or allows the incoming traffic based on the security policy of the site. However, this 'Border Defense Model' is insufficient. It assumes there is no security issue inside the network site. This assumption is no longer true now; viruses or worms can infect PCs through firewall (like NIMDA or MS-Blaster), or users can connect their infected PCs from outside the network site. This means that 'Border Defense Model' like firewall does not completely secure the network site. In addition to the above weakness, 'Border Defense Model' is an obstacle for the deployment of new network protocols and technologies. As a result of trade-off between security and convenience, a site security policy become very restricted and gives limited connectivity to users (e.g. only to a HTTP port). Especially for the deployment of IPv6 network, it is very hard to guarentee end-to-end connections through the security border point. The network nodes cannot easily talk to each other over the firewall even if they have global unicast IP addresses. Additionally, 'Border Defense Model' does not allow new network protocols and services such as multimedia services, QoS, multicasting, P2P application protocols, and so on. Therefore, 'Quarantine Model' is required to give more transparent and flexible security approach than border defense model for IPv6 networks. This memo propose a 'Quarantine Model', to solve the two issues mentioned above. It designs to collaborate with existing security technologies to provide more flexible and better network security architecture. It does not conflict with existing security technologies and can collaborate with the model of 'Border Defense Model'. KONDO, et al. Expires January 16, 2005 [Page 4] Internet-Draft Quarantine Model Overview July 2004 2. Issues in border defense model There are two types of issues in Border Defense Model. Technical issue comes from the nature of protocols and/or implementations, such as handling encrypted sessions or limitation of scanning speed. Operational issue is related to the administrative requirement or customer's request. 2.1 Technical issues of border defense model 2.1.1 Traffic volume and full packet inspection In border defense model, a firewall at the security border point tends to be a bottleneck of a network site. It has to scan all of the incoming connection and check all the packets because it is not enough filtering sessions by port and address. In addition, the amount of the network traffic between the Internet and a site has been increasing. 2.1.2 Encrypted and tunneling session It can not inspect the contents encapsulated in tunnels and encrypted session on border firewall. IPsec and tunneling technologies such as VPN, it breaks border defense model. Those session step into the internal network without any contents checking by firewall. Border defence model can only allow those sessions or block it. 2.2 Operational issues border defense model 2.2.1 Immediate update of filtering rule against new security issues In typical disaster cases of CodeRed, NIMDA, MS Blaster, and MyDoom worms, it took only a few hours to spread themselves all over the world. This fact means that firewalls cannot extinguish viruses from their networks without sufficient and timely assist by network administrators. Current firewalls have two major drawbacks on this matter. First, it is often quite difficult to configure the proper filtering rule to reject a new type of virus from outside. Second, virus can intrude a site even during the configuration of this filtering rule. Therefore, the assumption that "There are no attacks from inside the network", on which border defense model stand is completely collapsed by these two cases. To overcome these security threats, we need some integrated mechanism to enforce security fixes to nodes by automatic installation and checking. KONDO, et al. Expires January 16, 2005 [Page 5] Internet-Draft Quarantine Model Overview July 2004 2.2.2 Mobility node (Note PC) control, wireless LAN The biggest problem breaking down the border defense model is mobile node control. The mobile node such as note PC is easy to step into the internal network cross the border defense point. Nothing enforces to check and scan those mobile nodes which bring a virus and worms into the internal network. Border defense model cannot manage well this critical case breaking security border. We must identify there is a lot of physical back door to get into the internal network for example wireless LAN access point. Border defense point such as gateway, router is not only the route to get into their internal network to break border defense model. 2.2.3 Unmanaged network The Internet connectivity has been getting popular all over the world and the always-on connection is common. Although this is a strong driving force for the unmanaged network such as home-LAN, it also brings security threats to this environment; users in unmanaged network does not have enough knowledge for security management to protect their network, and they might become victims for crackers. This issue is not negligible for the Internet, because the number of such networks is so huge. If crackers can override these unmanaged networks, they can give significant impact or trouble to the whole Internet by attacks like DDoS. 2.3 Requirements of new security model for IPv6 One of the major advantages of IPv6 is the liberation from NAT or IP masquerade, which is lead to the use of end-to-end communication. This advantage is, however, inconsistent with the border defense model as mentioned in Section 2.1 and Section 2.2. This inconsistency is a hard obstacle for the deployment of IPv6, since administrators normally prefers border defense model to the IPv6 advantage [5]. We need to solve several issues for these situation. We need to propose the alternative solution without any additional security risk. Also, it is hard for the administrators to change their security policies. In order to promote new IPv6 services, we have to propose better security model which supports end-to-end communication without degrading the security risk. KONDO, et al. Expires January 16, 2005 [Page 6] Internet-Draft Quarantine Model Overview July 2004 3. Architecture overview 3.1 Key concept Quarantine Model is a flexible security architecture to let a security border work as virtual network segment. It admits network nodes into different network segments by security levels of them, and gives the security policy for each network segment. For construction of 'Quarantine Model', it requires the following. o Security compliance check and admition control a network node Quarantine model enforces to check security status of a network node when it connects to network. it selects a network segment for the network node by result of the quarantine inspection and applies security policy for the segment. If the node is not compliant to the security policy, it is rejected to get into the ordinary segment. o Network separation by security level Quarantine model mandates a network mechanism to separate network nodes to different networks based on their security levels. The separation is not so simple as the border defence model (inside and outside). It separates the network into several virtual segments which are based on security policy. o Appling security policy for each separated network Each segment operates on a security policy. The policy includes access control, routing, QoS, and so on. Quarantine model integrates and collaborates with existing policy enforcement point (e.g. switch, router, firewall etc.) in the internal network to create a segment for policy enforcement. When connecting to an untrusted network segment, the communication between other internal network segments and nodes would be blocked, or specific ports and services are filtered. Also outgoing session will be routed to servers which perform contents scanning and filtering. On the other hand, we can configure that any kind of communication between trusted nodes and trusted network segments are not blocked. On this policy, all the outgoing and incoming connection at security border point are allowed. Also in case of network segment with medium security level, we can configure any rules, such as accepting selected port and services, allowing specific destinations, etc. KONDO, et al. Expires January 16, 2005 [Page 7] Internet-Draft Quarantine Model Overview July 2004 3.2 Security segments and policy enforcement Quarantine model divides the internal network to several segments to apply security policy including access rules, routing path, QoS, etc. It is called as security segment and organized based on the security policy configuration. Fig.1 shows the typical segment in quarantine model. At least, it must have quarantine segment and others to separate quarantined/ isolated network nodes from security policy compliant nodes. On initial state, the node is in the quarantine segment. Based on the quarantine inspection result (compliance for security policy), it will move to another segment. At least, all segments must allow connection to quarantine server for the quarantine inspection process. Fig.1 Segment status flow for network node. isolated quarantine normal +---- segment ----+ +---- segment ----+ +---- segment ----+ | | | | | | | | | inspection | | | | | | | | | | update ----------> ----------> | | patche file | | | | | | <---------- <---------- retry | | | | | | inspection | | | | | | | +------------------+ +------------------+ +------------------+ 3.2.1 Quarantine segment This segment is used when a network node connects into network at the first time. It is for quarantine inspection process and provides limited connectivity for that. Non quarantine-model-ready node is also managed in this segment. 3.2.2 Isorated segment It is used for connecting unsecure (non-complient) network nodes. In this segment, network nodes are isolated from other segments and allow to connect only specific servers and services for downloading KONDO, et al. Expires January 16, 2005 [Page 8] Internet-Draft Quarantine Model Overview July 2004 security patches file, or updating virus signature file, etc. Other connectivity is restricted and blocked in this segment. 3.2.3 Normal segment We may classify the normal segments into several levels based on compliance level of network node. 3.3 Advantage of quarantine model This model is designed to help border defense model to solve existing issues that are described in previous section Section 2. For encrypted end-to-end connection issues, it guarantees security level of the network node in the quarantine authentication process. We can configure to block encrypted connection without quarantine inspection process. It still cannot scan session contents and packets, but it reduces possibility that virus and worms infected node connect into the internal network segment. It enforces to apply security patch or secure configuration to internal network node to protect attacking from the internal network node. In the previous network worm case like CodeRed? and NIMDA, it uses known security hole and it is already reported several month ago before those worms coming to the world. Thus, it can block most of network worm attacks if it manages security issues well for all internal network nodes in quarantine process. It is better solution to solve those security threats than border defence model. In contrast of border defence model, it gives transparent connectivity for trusted node. It is more flexible to have conductivity to outside of network and no restriction by security border point. Also, the accessibility of trusted node depends on site security policy configuration. Once it is qualified as the site security policy in quarantine process, it can have more transparent accessibilities from/to the outside of network. It is affinity for IPv6 network. KONDO, et al. Expires January 16, 2005 [Page 9] Internet-Draft Quarantine Model Overview July 2004 4. Quarantine model components Quarantine model has following components. Fig.2 Quarantine model components. +----+ +------| QS | | +----+ | +----+ +----+ +------| PE | +---| QA | (outside of network) (secure path) | +----+ | +----+ | | | | V +----+ V +----+ +----+ | +----+ =======+=======| RT |===============| RT |===| SW |---+---| QA | | +----+ +----+ +----+ +----+ | +----+ | | +---| FW |---+ | | +----+ | | +----+ | | | +----+ | PS | +---+ : +---+ +---| CL | +----+ | +----+ | +----+ +---| FW |---+ <---(quarantine path) +----+ PS: Prevention information server QS: Quarantine server PE: Policy enforcer QA: Network node with quarantine inspection agent CL: Network node without quarantine inspection agent RT: Router (policy enforcement point) SW: Switch (policy enforcement point) FW: Firewall (policy enforcement point) 4.1 Quarantine inspection agent Quarantine inspection agent (QA) is installed in any network node. It makes credencial information which includes platform versions, installed softwares and any kind of settings etc. QA sends that credencial information to quarantine server to request quarantine inspection process and controls network interfaces using the inspection result. (e.g. release dynamic IP address) It also checks the functionality of network nodes, such as having personal firewalls or not. We can (optionally) configure the notwork node itself as the policy enforcement point. KONDO, et al. Expires January 16, 2005 [Page 10] Internet-Draft Quarantine Model Overview July 2004 4.2 Quarantine server Quarantine server (QS) does quarantine inspection check and manages security policy compliance of network nodes. QS communicates with QA to get credencial information of the network node. And then, QS compares that credential with prevention information to check security policy compliance of site security policy. As a result of quarantine inspection, QS creates quarantine certification for network node and sends back to QA. It is checked validation and expiration in QS when it is received from QA. Based on the result of quarantine inspection, it controls security policy enforcer to push that network node into some network segment. 4.3 Policy enforcement point In the quarantine model, the following network devices and services are categorized as policy enforcement point. Those enforcement points separate the networks in order to enforce the site's security policy to the specific network segment. Enforcement points are classified into three types. Difference between this three types is partition size and functionality of network separation. o single partitioning type, which has one network node in partitioning border. * VLAN switch * Host firewall o group partitioning type, which has several network nodes inside of the partitioning border. * Gateway firewall * Router * Access filter o no partitioning type * DHCP Server * RA server This last type does not have partitioning function itself. It simply leases IP address to network node for segmentation control. 4.4 Policy enforcer Policy enforcer (PE) controls all of enforcement point in the network to create network segments. It provides abstract layer for each existing enforcement point to converts site security policy definition to construct network segments. Requested by quarantine KONDO, et al. Expires January 16, 2005 [Page 11] Internet-Draft Quarantine Model Overview July 2004 server, it dynamically controls enforcement point (update access rules etc.) to keep network segments. 4.5 Quarantine monitor There are two types of quarantine monitor (QM) in this model. The difference between the two types is concerning the monitoring target. Host type of QM checks the status of the network node itself and network type of QM checks the network traffic. QMs are the optional component of quarantine model. QMs are not included in minimum configuration of quarantine model, however QMs are useful for checking real time state changes in network nodes and supporting non quarantine model nodes. 4.5.1 Host type quarantine monitor This type of quarantine monitor is implemented as a part of QA. It monitors internal status/configuration changes in host node and triggers quarantine inspection action. 4.5.2 Network type quarantine monitor Network type quarantine monitor is placed in security enforcement point like firewall/IDS box or individually such as IDS appliance box. It monitors network traffic and inspects any kind of network problem. It alerts to quarantine server to request to enforce quarantine inspection process for that network node if it find any problem causes from that network node. It is important to isolate network node which does not have QA and out of quarantine inspection process. 4.6 Prevention information server Prevention information server (PS) stores known security threat and vulnerability information and provides it to quarantine server. This server is managed by security vendor, individual security incident handling organization or software/hardware provider itself. User subscribes this prevention information service for quarantine inspection process. It is optional to have local prevention information cache server in this model. KONDO, et al. Expires January 16, 2005 [Page 12] Internet-Draft Quarantine Model Overview July 2004 5. Quarantine inspection 5.1 Network node information Quarantine model uses credential information of a network node for quarantine inspection. Credential information is generated by quarantine inspection agent, and consists of the following information for security compliance checking in quarantine server. o OS, kernel or platform version o patch instration status o system configurations o network configurations o installed software and version o security software and configuration, status o product information (serial no, product type code) o etc. It may include prevention information source (server address etc.) with software information as an option to retrieve prevention information from there. 5.2 Quarantine certification It certificates security compliance of network node. It is created on quarantine server as a result of quarantine inspection and is sent back to quarantine inspection agent. Quarantine server periodically requests the update of this certification to the quarantine inspection agent, so that it reflects the up-to-date security status of network node. 5.3 Quarantine inspection process Quarantine inspection is done in the following steps: 1) discover quarantine server When network node detects link up signal as network is ready to use, it discovers quarantine server in that network. At this moment, network node is in a segment dedicated for quarantine as a default. 2) prepare credential information of network node Quarantine agent correct credential information of network node. 3) send credential information to quarantine server If a node does not have any changes in credential information and has KONDO, et al. Expires January 16, 2005 [Page 13] Internet-Draft Quarantine Model Overview July 2004 a quarantine certificate from server, quarantine inspection agent just sends the quarantine certificate, instead of the credential information, to quarantine server. 4) security compliance checking In quarantine server, it checks credential information with prevention information. Based of site security policy, it selects one of security segment for network node. If received quarantine certification is valid and not expired, it relies on latest inspection result which is stored in quarantine server. In this quarantine inspection, it checks following things and compares with site security policy to select one of security segment. o Is there any vulnerable software in use ? o Is secuirty software signature is up-to-date ? o Is its configuration secure enough ? o Unknown software installed ? 5) reply quarantine inspection result to agent After quarantine inspection checking, quarantine server generate a quarantine certification for network node and stores it as a quarantine inspection result. QS send quarantine certification back to agent. 5) security policy enforcement Based on quarantine inspection result, quarantine server send a trigger to policy enforcer about network node and its security segment to enforce its security policy on it. 5.4 Issues in quarantine inspection process 5.4.1 Multiple network interfaces Quarantine model requests quarantine inspection process for each network interface, if network node has multiple interfaces. Quarantine inspection agent can receive a different result for each quarantine inspection process. Network node belongs several security segments for each network interface. 5.4.2 Non quarantine-model-ready node However, network node doesn't have a quarantine inspection agent, it KONDO, et al. Expires January 16, 2005 [Page 14] Internet-Draft Quarantine Model Overview July 2004 is belongs to default security segment. Those network nodes are allowed only limited connectivity as default security segment. 5.4.3 Integration with the account-based authentication framework An account-based authentication framework, such as 802.1X[2] or PANA[4], can be used together as a part of quarantine inspection mechanism. First, a node is authenticated using 802.1X or PANA to be connected to a segment dedicated for quarantine inspection. If the node is authenticated, then quarantine server inspects the node in this quarantine segment. After quarantine server permits the node, it may connect the node to an appropriate network based on the account information used in the first account-based authentication. Quarantine server may use the result of account-based authentication, and gives different segment for account role based setting. KONDO, et al. Expires January 16, 2005 [Page 15] Internet-Draft Quarantine Model Overview July 2004 6. Network separation 6.1 Security segment In quarantine model, it logically divides network to several segments for site security policy enforcement. This segment is minimum unit of security policy management. Quarantine model applies site security policies to each security segment. It reconsiders ancient security policy paradigm or border defence model like 'divides to internal network and external network'. It introduces multiple layered and more dynamical security partitioning in the internal network management for security policy enforcement. Each security segment is applied different security policy. Security policy includes following things to restrict network connectivity for network nodes. o routing path to contents/packet filters o QoS o access filtering o network monitoring o access logging o etc. 6.2 Policy enforcement point and segment partitioning area Network segments are created by combination of policy enforcement point, which is called segment partitioning area and it works as minimum isolation unit of quarantine model. Security policy segment is identified as group of several piece of this segment partitioning area which is applied same security policy. In general, separation-target or separation-method depends on implementation of policy enforcement points. In this draft policy enforcement point is classified in the following three types: Partition type Personal firewall and host based firewall is host type policy enforcement point. There is itself in segment partitioning area. This policy enforcement point type dynamically plug on/off to network. o Partition type Router/VLAN switch and gateway firewall are partitioning type. It KONDO, et al. Expires January 16, 2005 [Page 16] Internet-Draft Quarantine Model Overview July 2004 includes several network nodes inside of this segment partitioning area. This type can not protect/block network traffic between network nodes which are under this segment partitioning area except VLAN. It estimates disaster range is same as segment partitioning area, if this segment is contaminated by security policy. o Addressing type IP address is used for security policy segmentation. DHCP and RA server are addressing type of policy enforcement point. In quarantine model, it would be controlled to lease IP address for network node that based on quarantine inspection result. This type only control IP address of network node. It does not have functionality about segment partitioning control itself. It can not control any session and traffic between different security policy segment. Quarantine model recommends to use this with some other policy enforcement point. 6.3 Policy enforcer Policy enforcer manages all policy enforcement point in the network to create security segment to apply site security policy. It generates control messages, commands or access rules from site security policy definition for each enforcement point. Under control of policy enforcer, enforcement point such as host firewall, router/ swich is dynamically applied rule set or configured. 6.4 Trigger events for EP control There is threee cases of trigger events for EP control. Those events are from quarantine server to policy enforcer. Fig.3 Network separatin control sequence. QA QS PE PP | | | | |----(1)--->| | | | |----(2)--->| | |<----------| |----(3)--->| | | | | QA: Quarantine agent QS: Quarantine server PE: Policy enforcer PP: Policy enforcement point KONDO, et al. Expires January 16, 2005 [Page 17] Internet-Draft Quarantine Model Overview July 2004 6.4.1 Quarantine compliance event This event is triggered when quarantine server check security policy compliance of network node during quarantine inspection process. Whatever, it is compliant or not, quarantine server triggers policy enforcer to move into that network node to admitted network segment. 6.4.2 Prevention Information update New prevention information makes quarantine inspection process for all network nodes. When it is received by quarantine server, quarantine server request all network nodes to do quarantine inspection again. In this latest quarantine inspection process, some network node would not be compliant and policy enforcer got a request to take an action to control segment for it. 6.4.3 Alert notification from quarantine monitor Quarantine server request policy enforcer to isolate traffic source node which is found by quarantine monitor. 6.5 Deployment for IPv6 network This section descrives issues in adapting quarantine model to IPv6 network. 6.5.1 Link local address and security segment Link local address can use immediately when network interface becomes linked up. Therefore, it would be better to used as a default security segment. Any network node who has IPv6 stack, it does quarantine inspection process on link local network as quarantine segment. However quarantine segment must enforce restricted security policy settings, link local network is better for quarantine segment. It only not allowed to communicate to other network segment. 6.5.2 Control RA/RS Network prefix configuration must be controlled by policy enforcer. It has two option to control network prefix configuration for specific network node. One option is enhancement RA server to check RS packet and block to send RA packet to security uncompliant network node. Second option is block RA/RS packet from security uncompliant network node on the router. KONDO, et al. Expires January 16, 2005 [Page 18] Internet-Draft Quarantine Model Overview July 2004 7. Prevention information Prevention information is used for quarantine inspection checking. Based on this prevention information, quarantine server inspects security threat and compares with site security policy. Prevention information is installed in the prevention server. In this model, user subscribes one of prevention information service from some security vendor or individual security organization. (It may use their own prevention information server or some volunteer based services) 7.1 Prevention information deployment process Quarantine server periodically requests new information to prevention information server. It is stored in quarantine server as local cache. In this request, it does not need to get all information, QS may request the information concerning specific platform and/or software version. Not only for polling, prevention information server may push updated information to subscribed quarantine servers. Fig.4 Prevention information deployment process. QA QS PS | | | | |-------(1)------>| | | | | |<------(2)-------| | | : | | | : | | |<------(3)-------| | | | |<------(4)-------| | | | | |-------(5)------>| | | | | QA: Quarantine Inspection Agent QS: Quarantine Server PS: Prevention Information Server (1) Prevention information request (2) Prevention information response (3) Prevention information update (4) Quarantine inspection result expire (5) Quarantine inspection request KONDO, et al. Expires January 16, 2005 [Page 19] Internet-Draft Quarantine Model Overview July 2004 7.2 Update prevention information Prevention information would be updated after it is published. At the first release, it includes uncertain information but so far it would be updated about security risk level, software version which has such security hole, etc. In other case, it would be identified as false alarm and canceled. This prevention information requests quarantine inspection to all related network node. It makes quarantine certification of network nodes to be invalid. 7.3 Identification of security information There is an issue for prevention information that how to identify software, application and package. Prevention information describes the security threat information about specific software, therefore it required to have some finger print to identify the software. It can not simply use software name as identification key. It will conflict in some case. Identification key should be unique value. 7.4 Multiple prevention informaiton sources Prevention information is provided from different types of service provider. o Security vendor services o Independent security incident handling organization o Volunteer or indivisual person's Major difference between those providers is quality of service and subscription costs. o indivisual software/hardware provider service This one provides individual software information. If it is specified source of prevention information server in credential information of network node, quarantine server requests prevention information to them for quarantine inspection process. It is designed for individual software/hardware developer provides their own prevention information. KONDO, et al. Expires January 16, 2005 [Page 20] Internet-Draft Quarantine Model Overview July 2004 8. Requirements and working items In order to implement quarantine model, it is required to define related protocols, data format and so on. Those must be standardized for interoperability of network devices. It is one of our motivations to discuss about this quarantine model on IETF to define related protocols and formats to define and standardized. 8.1 Quarantine inspection 8.1.1 Quarantine inspection protocol This protocol is used for communication and control between quarantine inspection agent and server. It is required to support following requirements. o Secure communication (encrypted session) o Authentication framework o Proxy mode support for quarantine server proxy o Quarantine inspection requrest from server (periodical control) 8.1.2 Entity information data format In order to describe any kind of entity platform and information, flexible data format is required. It must have data integrity and protection support for security reason. 8.1.3 EAP format extention and authentication framework integration In existing quarantine model implementation, EAP extension is used to transfer additional security information. Those security information is vendor specific, which need not have interoperability function for sending additional quarantine security information. For integration with existing authentication framework with quarantine model, it must be standardized. 8.2 Policy enforcement point control 8.2.1 Security policy definition language It is used to describe a site security policy to convert network device control command and protocols. 8.2.2 Generic EP control protocols and commands It is native commands and protocols set for quarantine model. For existing network devices and EP, it is converted to proprietary protocols and commands from it. KONDO, et al. Expires January 16, 2005 [Page 21] Internet-Draft Quarantine Model Overview July 2004 8.3 Prevention information 8.3.1 Prevention information data format It is required to have a capability to describe any kind of security threat and vulnerability information for quarantine inspection. This format must support data integrity and protection support for security reason. 8.3.2 Prevention information deployment and subscription protocol The protocol and command between quarantine server and prevention information server must encrypted and protected and support authentication framework to identify prevention information server. KONDO, et al. Expires January 16, 2005 [Page 22] Internet-Draft Quarantine Model Overview July 2004 9. Security considerations 9.1 Protection about credential information of network nodes Credential information of network nodes should be protected on communication channel between quarantine server and quarantine inspection agent and in local storage. It includes security vulnerability. Therefore, it gives useful information to crackers as the probe information to find target for attacking. 9.2 False statement of entity information It has a possibility that the quarantine server receives false statement of credential information. To solve this security risk, it is required to have an authentication of quarantine inspection agent and credential information. 9.3 Faked quarantine server In quarantine process, quarantine inspection agent discovers quarantine server when it connects into network. Quarantine server should have some authentication for quarantine server discovery against fake quarantine server. 9.4 DoS attack from deceit quarantine monitor Quarantine monitor should be authenticated and protected, otherwise it would be introduced DoS attack from fake quarantine monitor. Therefore, network type quarantine monitor should be managed by network administrator and should not rely on unknown quarantine monitor. 9.5 Interval period of quarantine inspection Quarantine inspection process should be executed in reasonable short periodical time (ex. less than 1 hour). It causes security risk if this interval period is too long, entity information and quarantine inspection result should not be relied for a long period of time. During the intervals, quarantine status of network node would be changed by using new security threat information. Configuration of network entities might be changed, or new software will be installed, and so on. 9.6 Switching speed of network segment change Responsibility of segment change speed should be faster as possible. It faces security risks during isolating dangerous entity to quarantine segment. Response speed depends on EP types. It should KONDO, et al. Expires January 16, 2005 [Page 23] Internet-Draft Quarantine Model Overview July 2004 be estimated segment pollution area and security risk when you deploy quarantine model and select EP types. 9.7 Reliablity of prevention information Quarantine inspection is based on prevention information. Quality and reliability of prevention information are important for quarantine model. If it has a lot of false information, quarantine process also is not reliable. Prevention information server should be authenticated for avoiding the fake servers. Prevention information should be protected on communication channel between quarantine server and prevention information server. It is out of scope in this document about how to rely on prevention information and provider and organization. 9.8 Routing between different segment It breaks network segmentation by security policy, if an entity has router setting between different segments, for example VPN connections, wireless LAN ad-hook mode. Quarantine inspection should check the network configuration in the target entity. 9.9 Multi protocol stack environment of IPv4 and IPv6 It should carefully configure quarantine model on mixed environment of IPv4 and IPv6. Security policy and network segment design should cover both networks. Translator and tunnel server should be carefully configured especially for the routing between IPv4 and IPv6. KONDO, et al. Expires January 16, 2005 [Page 24] Internet-Draft Quarantine Model Overview July 2004 10. Acknowledgements This memo is based on the discussion in WIDE project secure6 working group for next generation of network security. The author gratefully acknowledges the contributions of: ATARASHI Yoshifumi, WIDE Project (http://www.wide.ad.jp) Secure6 working group members. 11 Informative References [1] Bellovin, S., "Distributed Firewalls", ;login; pp.39-47, http:/ /www.research.att.com/~smb/papers/distfw.html, November 1999. [2] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001. [3] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [4] Ohba (Ed.), Y., "Protocol for Carrying Authentication for Network Access (PANA)", http://www.ietf.org/internet-drafts/ draft-ietf-pana-pana-04.txt, May 2004. [5] Vives, A. and J. Palet, "IPv6 Security Problem Statement", http://www.ietf.org/internet-drafts/ draft-vives-v6ops-ipv6-security-ps-01.txt, July 2004. [6] Savola, P., "Firewalling Considerations for IPv6", http:// www.ietf.org/internet-drafts/ draft-savola-v6ops-firewalling-02.txt, October 2003. [7] Palet, J., "IPv6 distributed security requirements", http:// www.ietf.org/internet-drafts/ draft-palet-v6ops-ipv6security-00.txt, February 2004. KONDO, et al. Expires January 16, 2005 [Page 25] Internet-Draft Quarantine Model Overview July 2004 Authors' Addresses KONDO Satoshi Trend Micro Inc. Shinjuku MAYNDS Tower, 30F 2-2-1 Yoyogi Shibuya-ku, Tokyo 151-0053 Japan Phone: +81-3-5334-3600 Fax: +81-3-5334-4049 EMail: satoshi_kondo@trendmicro.co.jp SUZUKI Shinsuke Hitachi, Ltd. 1-280 Higashi-Koigakubo Kokubunji, Tokyo 185-8601 Japan Phone: +81-42-323-1111 Fax: +81-42-327-7868 EMail: suz@crl.hitachi.co.jp INOUE Atsushi Toshiba Corporation R&D Center 1 Komukai-Toshiba-cho Saiwai-ku Kawasaki, Kanagawa 212-8582 Japan Phone: +81-44-549-2065 Fax: +81-44-520-1806 EMail: inoue@isl.rdc.toshiba.co.jp KONDO, et al. Expires January 16, 2005 [Page 26] Internet-Draft Quarantine Model Overview July 2004 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 (2004). 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 KONDO, et al. Expires January 16, 2005 [Page 27] Internet-Draft Quarantine Model Overview July 2004 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. KONDO, et al. Expires January 16, 2005 [Page 28]