Network Working Group S. KONDO Internet-Draft Trend Micro Inc. Expires: September 9, 2006 S. SUZUKI ALAXALA Networks Corporation A. INOUE Toshiba Corporation R&D Center March 8, 2006 Quarantine Model Overview for IPv6 Network Security draft-kondo-quarantine-overview-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 September 9, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract In the current Internet, a site is often secured by firewall, which filters harmful traffic from outside at the border of the site. This 'Border Defense Model', provides only a single line of defence and hinders the deployment of many next-generation Internet applications and services. KONDO, et al. Expires September 9, 2006 [Page 1] Internet-Draft Quarantine Model Overview March 2006 This memo surveys the security issues of the 'Border Defense Model', and proposes a network architecture 'Quarantine Model', to provide a better security model and promote various end-to-end Internet usages. In our 'Quarantine Model', nodes shareing an Enterprise network network are connected to separate logical networks according to their security privilege level and community of interest. A different security policy is implemented on each logical network segment using the multiple security-related techniques, such as filtering, authentication, and encryption. This 'Compartmentalized' framework provides a better depth of network defenes and additional flexibility to our '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. KONDO, et al. Expires September 9, 2006 [Page 2] Internet-Draft Quarantine Model Overview March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Issues in border defense model . . . . . . . . . . . . . . . . 6 2.1. Technical issues of border defense model . . . . . . . . . 6 2.1.1. Traffic volume and full packet inspection . . . . . . 6 2.1.2. Encrypted and tunneling session . . . . . . . . . . . 6 2.1.3. Tunnneling technology, VPN . . . . . . . . . . . . . . 6 2.2. Operational issues border defense model . . . . . . . . . 6 2.2.1. Immediate update of filtering rule against new security issues . . . . . . . . . . . . . . . . . . . 6 2.2.2. Mobile node control, wireless access . . . . . . . . . 7 2.2.3. Unmanaged network . . . . . . . . . . . . . . . . . . 8 2.3. Requirements of new security model for IPv6 . . . . . . . 8 3. Architecture overview of quarantine model . . . . . . . . . . 9 3.1. Key concept . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Security segments and policy enforcement . . . . . . . . . 10 3.2.1. Quarantine segment . . . . . . . . . . . . . . . . . . 11 3.2.2. Isorated segment . . . . . . . . . . . . . . . . . . . 11 3.2.3. Normal segment . . . . . . . . . . . . . . . . . . . . 11 3.3. Advantage of quarantine model . . . . . . . . . . . . . . 11 4. Quarantine model components . . . . . . . . . . . . . . . . . 13 4.1. Quarantine inspection agent . . . . . . . . . . . . . . . 13 4.2. Quarantine authentication server . . . . . . . . . . . . . 13 4.3. Policy enforcement point . . . . . . . . . . . . . . . . . 14 4.4. Policy enforcer . . . . . . . . . . . . . . . . . . . . . 15 4.5. Quarantine monitor . . . . . . . . . . . . . . . . . . . . 15 4.5.1. Host type quarantine monitor . . . . . . . . . . . . . 15 4.5.2. Network type quarantine monitor . . . . . . . . . . . 15 4.6. Vulnerability information server . . . . . . . . . . . . . 15 5. Quarantine inspection . . . . . . . . . . . . . . . . . . . . 17 5.1. Network node information . . . . . . . . . . . . . . . . . 17 5.2. Quarantine certification . . . . . . . . . . . . . . . . . 17 5.3. Quarantine inspection process . . . . . . . . . . . . . . 17 5.4. Issues in quarantine inspection process . . . . . . . . . 18 5.4.1. Multiple network interfaces . . . . . . . . . . . . . 19 5.4.2. Non quarantine-model-ready node . . . . . . . . . . . 19 5.4.3. Integration with the account-based authentication framework . . . . . . . . . . . . . . . . . . . . . . 19 6. Network separation . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Security segment . . . . . . . . . . . . . . . . . . . . . 20 6.2. Policy enforcement point and segment partitioning area . . 20 6.3. Policy enforcer . . . . . . . . . . . . . . . . . . . . . 21 6.4. Trigger events for EP control . . . . . . . . . . . . . . 21 6.4.1. Quarantine compliance event . . . . . . . . . . . . . 22 6.4.2. Prevention Information update . . . . . . . . . . . . 22 6.4.3. Alert notification from quarantine monitor . . . . . . 22 6.5. Deployment for IPv6 network . . . . . . . . . . . . . . . 22 KONDO, et al. Expires September 9, 2006 [Page 3] Internet-Draft Quarantine Model Overview March 2006 6.5.1. Link local address and security segment . . . . . . . 22 6.5.2. Control RA/RS . . . . . . . . . . . . . . . . . . . . 23 7. Vulnerability information . . . . . . . . . . . . . . . . . . 24 7.1. Vulnerability information deployment process . . . . . . . 24 7.2. Update Vulnerability information . . . . . . . . . . . . . 25 7.3. Identification of security information . . . . . . . . . . 25 7.4. Multiple vulnerability informaiton sources . . . . . . . . 26 8. Requirements and working items . . . . . . . . . . . . . . . . 27 8.1. Quarantine inspection . . . . . . . . . . . . . . . . . . 27 8.1.1. Quarantine inspection protocol . . . . . . . . . . . . 27 8.1.2. Entity information data format . . . . . . . . . . . . 27 8.1.3. EAP format extention and authentication framework integration . . . . . . . . . . . . . . . . . . . . . 27 8.2. Policy enforcement point control . . . . . . . . . . . . . 27 8.2.1. Security policy definition language . . . . . . . . . 27 8.2.2. Generic EP control protocols and commands . . . . . . 28 8.3. Vulnerability information . . . . . . . . . . . . . . . . 28 8.3.1. Vulnerability information data format . . . . . . . . 28 8.3.2. Vulnerability information deployment and subscription protocol . . . . . . . . . . . . . . . . 28 8.4. Network device entity identification . . . . . . . . . . . 28 8.5. Embedded system and small devices support . . . . . . . . 28 9. Security considerations . . . . . . . . . . . . . . . . . . . 30 9.1. Protection about credential information of network nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.2. False statement of entity information . . . . . . . . . . 30 9.3. Faked quarantine server . . . . . . . . . . . . . . . . . 30 9.4. DoS attack from deceit quarantine monitor . . . . . . . . 30 9.5. Interval period of quarantine inspection . . . . . . . . . 30 9.6. Switching speed of network segment change . . . . . . . . 30 9.7. Reliablity of vulnerability information . . . . . . . . . 31 9.8. Conflicting vulnerability information . . . . . . . . . . 31 9.9. Routing between different segment . . . . . . . . . . . . 31 9.10. Multi protocol stack environment of IPv4 and IPv6 . . . . 31 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 11. Informative References . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . . . 34 KONDO, et al. Expires September 9, 2006 [Page 4] Internet-Draft Quarantine Model Overview March 2006 1. Introduction A site is often secured by firewall, which filters network attacks such as unauthorized access, DoS, and worms from outside. To block these kind of attacks, a firewall divides the internal network and external network at the border security point (e.g. generally the service-provider edge of the site's network). At this point, the firewall blocks or allows the incoming traffic by screening based on the site's security policy. However, this 'Border Defense Model' is insufficient as a defence in depth. The 'Border Defence Model' assumes there is no security issue inside network site. This assumption is no longer true now; Viruses or worms (like NIMDA or MS-Blaster, Slammer) can infect PCs through firewalls, users can connect their PCs infected outside the network site, and malicious insider can breach the network from within. This fact means 'Border Defense Model' 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 all users (e.g. only to a HTTP port). Especially for IPv6 network, to the 'Border Defense Model' often blocks all end-to-end connections through the security border point. Network nodes cannot easily talk to each other through a firewall even if they have global unicast IP addresses and shared IPsec keys. Additionally, this model inhibits the adoption of new network protocols and services such as multimedia services, QoS, multicasting, P2P application protocols, and so on. Therefore, a new 'Quarantine Model' is needed as a more flexible security approach for next generation networks. This memo propose a 'Quarantine Model', for firewalling, to solve the two issues mentioned above. It designed to work in synergy with existing security technologies such as IDS, virus scanning and spyware filtering to provide a more flexible and better network security architecture. It does not in conflict existing security technologies and not exclusive model of 'Border Defense Model'. In combination with border defense and network defense this model provides a thorough defense in depth. KONDO, et al. Expires September 9, 2006 [Page 5] Internet-Draft Quarantine Model Overview March 2006 2. Issues in border defense model There are two types of issues in Border Defense Model: a technical one and an operational one. The technical one is brought about by the nature of protocols or implementations, such as handling of excrypted sessions or scanning speeds. The operational one is the issue of security administration requirements vs. customer's request. 2.1. Technical issues of border defense model 2.1.1. Traffic volume and full packet inspection In the 'Border Defense Model', the firewall has to scan all the connections and packets, since it need to detect all recent viruses and worms wich spread over the Internet via well-known open ports (e.g. HTTP, SMTP). Furthermore, the amount of the network trrafic between the Internet and network sites has been increasing, because of the deployment of high-speed network infrastructure, increasing numbers of IP-capable devices, and new applications consuming bandwidth. Considering these two trends, firewall at the security border point will become a bottleneck of a network site in the 'Border Defence Model'. 2.1.2. Encrypted and tunneling session One encrypted session are established between internal machines of an border defence point and machines outside of border, the border defense point cannot inspect its connectiions and packiet contents (see section 5 of [2]) 2.1.3. Tunnneling technology, VPN Tunneling technologies, such as VPN or RAS, are often used to provide intranet connectivity to machines outside of the site. Although they conveniently provide such services, they are potential security holes because it is difficult for firewalls to inspect the contents encapsulated in the encrypted tunnels set up by these technologies. o Users can create tunnels against the admninistrator's will. (e.g. XXX over HTTP) o Complicated firewall configuration can often lead to a misconfiguration. o Administrators cannot inspect the contents within the tunnel, once the tunneling session is authenticated and established (see Section 2.1.2) 2.2. Operational issues border defense model 2.2.1. Immediate update of filtering rule against new security issues There were some Internet disasters case by attacks such as CodeRed, KONDO, et al. Expires September 9, 2006 [Page 6] Internet-Draft Quarantine Model Overview March 2006 NIMDA, MS Blaster, Slammer, and MyDoom worms, which needed only a few hours to spread themselves all over the world. Often these attacks entered a site network through one machine and once inside spread uninhibited to all of the machines in the site. A single firewall often fails to prevent the spread of attacks through an entire site network. There are three reasons for this firewall weekness. 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. Third, a compromised machine may be brought into a network or be connected via a VPN. These three lead to the collapse of the assumption of 'Border Defense Model'. To overcome this kind of security threat, some integrated mechanism is necessary to enforce the security fixes to nodes by automatic installation and checking of each node's 'personal firewall' rules, virus detection, and spyware blocking status. 2.2.2. Mobile node control, wireless access The biggest problem breaking down the border defense model is mobile node (Notebook PC, PDF, etc.) control. The mobile node goes outside of their security border and connects to other public and private networks like home LAN, dial up connections, WiFi hotspots, etc. We cannot control mobile nodes when they go outside of the security border. Mobile nodes face security risks on the outside of an enterprise's managed network and may become infected with viruses, spyware and network worms. There is a security risk when mobile nodes return to their home network. Often nothing enforces a check of mobile nodes to prevent virus, worms, and spyware from getting into the home network site. The current border defense model cannot manage this critical mobile node case well, often allowing unmanaged breaches in the security border. Wireless LANs and other wireless technologies are bringing additional security risk into the border defense model. The readio waves reach to outside of building and office floor and often anyone can easily get into a network if wireless access points and host-shareing is not securely configured. We must identify that there are many physical and virtual back doors to get into a site's internal network. Border defense point such as a firewall or screening rules on a router do not protect the only route to breach the internal network and break the border defense KONDO, et al. Expires September 9, 2006 [Page 7] Internet-Draft Quarantine Model Overview March 2006 model. 2.2.3. Unmanaged network Internet connectivity is spreading world-wide and it is often provided in an always-on style with relatively permanent address. Although this has been a strong driving force for Internet deployment into unmanaged network environments such as home-LAN, it also brings a new security threats to this environment; users in unmanaged networks does not have enough knowledge for security management to protect their network, and hence they are potential victims for attackers. This is not negligible for the Internet, because the number of such networks is great and attackers can cause a heavvy operational or financial impact on the Internet by compromising such hosts for DDoS, creating spam distribution bots, and other malicious uses. 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 makes it far cheaper to deploy new peer-to-eer network applications like VOIP. 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]. There are two reasons for this choice: the lack of an alternative solution without any additional security risk, and the difficulty in changing security policies. To promote Ipv6 and new network services, a better security model has to be provided to support end- to-end communication without increasing security risk. KONDO, et al. Expires September 9, 2006 [Page 8] Internet-Draft Quarantine Model Overview March 2006 3. Architecture overview of quarantine model 3.1. Key concept Quarantine Model is a flexible security architecture to create a security border work as virtual network segments. It compartmentalizes network nodes into different network segments by security levels of them, and disributes security policy for each network segment. The following is required for construction of the 'Quarantine Model': o Security compliance inspection of nodes entering a network segment Quarantine model enforces to check security status of a network node when it connects to network. it selects the proper network segment based on site security policy. A security agent program needs to be installed on each host ot do security inspection to check it's security status. It checks security vulnerabilites, settings, and compares the node's status to the security policy such as OS and installed software versions, security patches, security software status (e.g. anti-virus software, firewalls etc.), configuration and settings of system and softwares. If the node is not compliant to the security policy, it is rejected to get into the ordinary segment. o Separation of pyhsical networks by security levels Quarantine model mandates a network mechanism to separate network nodes on the same segment to different virtual networks based on their security levels. You MAY use state-of-the-art layer-2 separation technologies like 802.1x, as long as the network administrators can manage this separation rule. Note that this also MAY be accomplished by the contents in packet headers (e.g. IP address, flow-label, port number etc), since routers/switch can dispatch packets to different networks according to these information. A thrid alternative is to assign separate IPsec keys and policies to isolate different user groups. o Appling separate security policy for each network segment Quarantine model applies different security policies for separete network segments. That security policy includes access control rules, routing settings etc. 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 from untrusted nodes are routed to deep content scanning and filtering IDS. KONDO, et al. Expires September 9, 2006 [Page 9] Internet-Draft Quarantine Model Overview March 2006 On the other hand, the system should be configurable so it does not block any kind of communication between trusted nodes and trusted network segments. It should permit approved outgoing and incoming connections at security border points for trusted nodes according to the site security policy. It should be configured to accept selected port and services, allow communications to specific destinations etc. for the medium security leveled network segments. By appliying security policy to the internal network segment, end- host, and border defence point, the quarantine model integrate with and compliments other existing border defense products and tools (e.g. router filters, site firewalls etc.). 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 | | | | | | | +------------------+ +------------------+ +------------------+ KONDO, et al. Expires September 9, 2006 [Page 10] Internet-Draft Quarantine Model Overview March 2006 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 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 add better internal defenses to help adjust the border defense model to solve existing issues described in previous sections. The key concept is that is separetes trusted nodes and their traffic from untrusted nodes and focuses on untrusted connection filtering and scanning. It reduces the target traffic that a site's defenses have to scan and filter on the border defense point and distributes much of the defense load to end-user machines. It solves the issue of section 2.1.1 For encrypted end-to-end connection issues, it guarantees security integrity of nodes entering a security segment through a quarantine authentication process. We can configure the site's perimeter firewall to block unauthorized encrypted connections on a quarantine path but the site firewall still cannot scan encrypted session contents and packets. This site firewall's limited filtering still reduces the possibility that known viruses and worms infect internal nodes. It solves existing problems of border defence model (e.g. Section 2.1.2, Section 2.1.3). It enforces the application of security patches and proper security configuration to internal network nodes to protect against insider threats. This mechanism could prevent the spread of network worm case like CodeRed and NIMDA which exploited known security holes that were already reported several month before those worms were relased. If we can better manage security issues for all internal network KONDO, et al. Expires September 9, 2006 [Page 11] Internet-Draft Quarantine Model Overview March 2006 nodes, we can block most of todaay's network worm and application vulnerability attacks. It offers serveral security threats (e.g. Section 2.2.1, Seciton 2.2.2, Section 2.2.3) than the border defense model. It gives better transparent end-to-end connectivity for properly secured and trusted nodes. From the network node and application point of views, it is more flexible to have end-to-end connectivity outside of the network perimeter and no restriction by border security points. Also, the acccessibility of a trusted node depends on site security policy configuration. Once a node is authenticated by the quarantine authentication server and update to conform with a site's security policy, it can have more transparent access from/to the outside network and to other trusted internal nodes. This model is an enabler for an IPv6 based end-to-end network solution (e.g. Section 2.3). KONDO, et al. Expires September 9, 2006 [Page 12] Internet-Draft Quarantine Model Overview March 2006 4. Quarantine model components Quarantine model has following components. Fig.2 Quarantine model components. +----+ +------| QAS| | +----+ | +----+ +----+ +------| PE | +---| QIA| (outside of network) (secure path) | +----+ | +----+ | | | | V +----+ V +----+ +----+ | +----+ =======+=======| RT |===============| RT |===| SW |---+---| QIA| | +----+ +----+ +----+ +----+ | +----+ | | +---| FW |---+ | | +----+ | | +----+ | | | +----+ | VIS| +---+ : +---+ +---| CL | +----+ | +----+ | +----+ +---| FW |---+ <---(quarantine path) +----+ VIS: Vulnerability information server QAS: Quarantine authentication 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 (QIA) is software installed on host machines to inspect the machine and create a quarantine cetificate profile, and then send the profile information to quarantine authentication server. It corrects misconfigured settings on installed software and patches, OS versions, and properly configures host IPsec policy and firewall rules. The QIA check vulnerability information provided by the quarantine authentication server or separate vulnerability information server. 4.2. Quarantine authentication server Quarantine server (QAS) does quarantine inspection check and manages KONDO, et al. Expires September 9, 2006 [Page 13] Internet-Draft Quarantine Model Overview March 2006 security policy compliance of network nodes. QAS communicates with QIA to get credencial information of the network node. And then, QSA compares that credential with prevention information to check security policy compliance of site security policy. As a result of quarantine inspection, QAS creates quarantine certification for network node and sends back to QIA. It is checked validation and expiration in QAS when it is received from QIA. Based on the security level, it rejects network nodes attempts to connect into the internal network or select one of the network segments and admits the node into that segments. 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. KONDO, et al. Expires September 9, 2006 [Page 14] Internet-Draft Quarantine Model Overview March 2006 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 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 QIA. 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 QIA and out of quarantine inspection process. 4.6. Vulnerability information server Vulnerability information server (VIS) stores vulnerability information about security holes and vulnerability reports. All known security threat information and prevention information about security attacks and risks are stored in the VIS network. The VISnetwork is configured as tree structure to get vulnerability information from upper layer VIS if it does not have requiested vulnerability informjation in the site local VIS. KONDO, et al. Expires September 9, 2006 [Page 15] Internet-Draft Quarantine Model Overview March 2006 The site local VIS is optional component in this model. ISPor security vendor may provides VISfor end users as a service /vusiness. KONDO, et al. Expires September 9, 2006 [Page 16] Internet-Draft Quarantine Model Overview March 2006 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. KONDO, et al. Expires September 9, 2006 [Page 17] Internet-Draft Quarantine Model Overview March 2006 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 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. QAS send quarantine certification back to agent. 6) 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 KONDO, et al. Expires September 9, 2006 [Page 18] Internet-Draft Quarantine Model Overview March 2006 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 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 September 9, 2006 [Page 19] Internet-Draft Quarantine Model Overview March 2006 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 KONDO, et al. Expires September 9, 2006 [Page 20] Internet-Draft Quarantine Model Overview March 2006 network. o Partition type Router/VLAN switch and gateway firewall are partitioning type. It 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. KONDO, et al. Expires September 9, 2006 [Page 21] Internet-Draft Quarantine Model Overview March 2006 Fig.3 Network separatin control sequence. QIA QAS PE PP | | | | |----(1)--->| | | | |----(2)--->| | |<----------| |----(3)--->| | | | | QIA: Quarantine inspection agent QAS: Quarantine authentication server PE: Policy enforcer PP: Policy enforcement point 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 KONDO, et al. Expires September 9, 2006 [Page 22] Internet-Draft Quarantine Model Overview March 2006 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 September 9, 2006 [Page 23] Internet-Draft Quarantine Model Overview March 2006 7. Vulnerability information Vulnerability information is used for quarantine inspection checking. Based on this vulnerability information, quarantine server inspects security threat and compares with site security policy. Vulnerability information is installed in the vulnerability information server. In this model, user subscribes one of vulnerability information service from some security vendor or individual security organization. (It may use their own vulnerability information server or some volunteer based services) 7.1. Vulnerability information deployment process Quarantine server periodically requests new information to vulnerability 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, vulnerability information server may push updated information to subscribed quarantine servers. KONDO, et al. Expires September 9, 2006 [Page 24] Internet-Draft Quarantine Model Overview March 2006 Fig.4 Vulnerability information deployment process. QA QS VIS | | | | |-------(1)------>| | | | | |<------(2)-------| | | : | | | : | | |<------(3)-------| | | | |<------(4)-------| | | | | |-------(5)------>| | | | | QA: Quarantine Inspection Agent QS: Quarantine Server VIS: Vulnerability Information Server (1) Vulnerability information request (2) Vulnerability information response (3) Vulnerability information update (4) Quarantine inspection result expire (5) Quarantine inspection request 7.2. Update Vulnerability information Vulnerability 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 vulnerability 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 vulnerability information that how to identify software, application and package. Vulnerability information describes the security threat information about specific software, therefore it required to have some finger print to identify installed software. It can not simply use software name as identification key. It will conflict in some case. Identification key should be unique KONDO, et al. Expires September 9, 2006 [Page 25] Internet-Draft Quarantine Model Overview March 2006 value. 7.4. Multiple vulnerability informaiton sources Vulnerability 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 vulnerability information server in credential information of network node, quarantine server requests vulnerability information to them for quarantine inspection process. It is designed for individual software/hardware developer provides their own vulnerability information. KONDO, et al. Expires September 9, 2006 [Page 26] Internet-Draft Quarantine Model Overview March 2006 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. KONDO, et al. Expires September 9, 2006 [Page 27] Internet-Draft Quarantine Model Overview March 2006 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. 8.3. Vulnerability information 8.3.1. Vulnerability information data format It is required to have a capability to describe any kind of security threat and vulnerability information for quarantine inspection. Currently, security vendors and authorities publish security reports and analysis in various formats. These are often only huyman readable documents and generally cannot be simply parsed into any kind of system for self cofiguration and automatic upgrade. Several software vendors provide vulnerability information and signatures to detect and block security threats for their proprietary systems. We believe a standardized format to exchange vulnerability information will allow reports to be quickly processed into security updates across multiple vendor's systems. This format must support data integrity and protection support for security reason. 8.3.2. Vulnerability 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. 8.4. Network device entity identification One important concern is the security identifier of network devices. IP address, MAC address or any kind of informatin can be use to identify nodes, but these can dynamically changed or spoofed to create fake data. The system SHOULD have reliable and unique node identification based on cryptographically generated and verified signatures. 8.5. Embedded system and small devices support The system SHOULD consider support for embedded system and small devices like personal digital assistants (PDAs) and network appliances. Specially for home use, it may uses those small devices and non-PC platform on home LAN. The system must also consider access to simple servers such as print an file servers on local networks. The protocol design and quarantine agent should be designed to KONDO, et al. Expires September 9, 2006 [Page 28] Internet-Draft Quarantine Model Overview March 2006 support those small devices and it must be lightweigth, If integrated into these devices, it should require minimal CPU resources and code sisze to ease integrate into small platforms. These small devices are often implemented as single function devices with pre-installed software into flash ROM and are often difficult or impossible to update or change configurations by end users. A Quarantine inspection agent for these devices should be customized to handle embedded devices. KONDO, et al. Expires September 9, 2006 [Page 29] Internet-Draft Quarantine Model Overview March 2006 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 nodes to quarantine segment. Response speed depends on EP types. It should KONDO, et al. Expires September 9, 2006 [Page 30] Internet-Draft Quarantine Model Overview March 2006 be estimated segment pollution area and security risk when you deploy quarantine model and select EP types. 9.7. Reliablity of vulnerability information Quarantine inspection is based on vulnerability information. Quality and reliability of vulnerability information are important for quarantine model. If it has a lot of false information, quarantine process also is not reliable. Vulnerability information server should be authenticated for avoiding the fake servers. Vulnerability information should be protected on communication channel between quarantine server and vulnerability information server. It is out of scope in this document about how to rely on vulnerability information and provider and organization. 9.8. Conflicting vulnerability information Multiple information sources could provide conflicting vulnerability information. 9.9. 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.10. 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 September 9, 2006 [Page 31] Internet-Draft Quarantine Model Overview March 2006 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 and David Green, CERDEC Site Manager SRI International(Dave.B.Green@us.army.mil). 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-11.txt, May 2004. [5] Savola, P., "Distributed Security Threat Model", http:// www.ietf.org/internet-drafts/ draft-savola-distsec-threat-model-01.txt, October 2005. [6] Kaeo, M. and P. Savola, "IPv6 distributed security requirements", http://www.ietf.org/internet-drafts/ draft-kaeo-distsec-framework-00.txt, February 2006. KONDO, et al. Expires September 9, 2006 [Page 32] Internet-Draft Quarantine Model Overview March 2006 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 ALAXALA Networks Corporation Shinkawasaki Mitsui Bldg West Tower. 13F, 890 Kashimada, Saiwai-ku Kawasaki, Kanagawa 212-0058 Japan Phone: +81-44-549-1200 Fax: +81-44-549-1272 Email: suz@alaxala.net 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 September 9, 2006 [Page 33] Internet-Draft Quarantine Model Overview March 2006 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 (2006). 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. KONDO, et al. Expires September 9, 2006 [Page 34]