Network Working Group S. KONDO Internet-Draft Trend Micro Inc. Expires: August 8, 2004 S. SUZUKI Hitachi, Ltd. February 8, 2004 Quarantine Model Overview for IPv6 Network Security draft-kondo-quarantine-overview-00 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 August 8, 2004. 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 that security issues and promote a deployment of the next-generation Internet. KONDO & SUZUKI Expires August 8, 2004 [Page 1] Internet-Draft Quarantine Model Overview February 2004 In our 'Quarantine Model', nodes are connected to separate networks according to their security level. And a different security policy is implemented on each network 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 consideration issues for this architecture. It is, however, beyond the scope of this document to propose a specific implementation or protocol. 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 end-to-end connection . . . . . . . . . . . . . . 5 2.1.3 Tunneling technology, VPN . . . . . . . . . . . . . . . . . 5 2.2 Operational issues border defense model . . . . . . . . . . 6 2.2.1 Immediate update of filtering rule against new security issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.2 Mobility node (Note PC) control, wireless LAN . . . . . . . 6 2.2.3 Unmanaged network . . . . . . . . . . . . . . . . . . . . . 7 2.3 Requirements of new security model for IPv6 . . . . . . . . 7 3. Architecture overview of quarantine model . . . . . . . . . 8 3.1 Security level inspection of network node . . . . . . . . . 8 3.2 Separation of network by security level . . . . . . . . . . 8 3.3 Appling security policy for each separated network . . . . . 9 4. Advantage of quarantine security model . . . . . . . . . . . 10 5. Deployment model . . . . . . . . . . . . . . . . . . . . . . 11 5.1 Basic deployment model . . . . . . . . . . . . . . . . . . . 11 5.2 Deployment model for consumer segment . . . . . . . . . . . 12 6. Components of quarantine model . . . . . . . . . . . . . . . 14 6.1 Prevention information server . . . . . . . . . . . . . . . 14 6.2 Quarantine inspection agent . . . . . . . . . . . . . . . . 14 6.3 Quarantine authentication server . . . . . . . . . . . . . . 14 6.4 Quarantine certificate profile . . . . . . . . . . . . . . . 14 6.5 Prevention information . . . . . . . . . . . . . . . . . . . 14 6.6 Site security policy configuration . . . . . . . . . . . . . 15 6.7 Network admission controller . . . . . . . . . . . . . . . . 15 7. Quarantine procedure . . . . . . . . . . . . . . . . . . . . 16 7.1 Connecting to network . . . . . . . . . . . . . . . . . . . 16 7.2 Vulnerability scanning . . . . . . . . . . . . . . . . . . . 16 7.3 Profile sending . . . . . . . . . . . . . . . . . . . . . . 16 7.4 Security inspection . . . . . . . . . . . . . . . . . . . . 16 7.5 Network admission control . . . . . . . . . . . . . . . . . 16 7.6 Profile information expiration . . . . . . . . . . . . . . . 16 KONDO & SUZUKI Expires August 8, 2004 [Page 2] Internet-Draft Quarantine Model Overview February 2004 8. Action items . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1 Prevention information description format . . . . . . . . . 18 8.2 Profile information request protocol . . . . . . . . . . . . 18 8.3 Profile information expiration control . . . . . . . . . . . 18 8.4 Network device entity identification . . . . . . . . . . . . 18 8.5 Embedded system and small devices support . . . . . . . . . 18 8.6 Delivery and operations of prevention information . . . . . 19 8.7 Confliction of prevention information . . . . . . . . . . . 19 8.8 Home network and unmanaged network . . . . . . . . . . . . . 19 8.9 NAC and integration to existing security framework . . . . . 19 9. Security issues . . . . . . . . . . . . . . . . . . . . . . 21 9.1 Certification of quarantine inspection agent . . . . . . . . 21 9.2 Security issues of quarantine profile . . . . . . . . . . . 21 9.3 Prevention information protection . . . . . . . . . . . . . 21 9.4 Authentication and certification for prevention information server . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 Informative References . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . 24 KONDO & SUZUKI Expires August 8, 2004 [Page 3] Internet-Draft Quarantine Model Overview February 2004 1. Introduction A network site is often secured by firewall, which prevents network attackings from outside, such as virus, worm, or DoS. To block these kind of attackings, firewall divides internal network and external network at the border security point (e.g. the edge of the network site). At this point, firewall blocks or allows the incoming traffic based on the security policy of the site. However, this 'Border Defense Model' is insufficient. 'Border Defense Model' assumes there is no security issue inside network site. This assumption is no longer true now; virus or worm can infect PCs through firewall (like NIMDA or MS-Blaster), or users can connect their PCs infected outside the network site. This fact means '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 customers (e.g. only to a HTTP port). Especially for IPv6 network, it is too ristrictive to make a end-to-end connection over the security border point. The network node cannot easily talk each other over firewall even it has global unicast IP addresses. Additionally, it seldomly coexists with new network protocol and services such as multimedia services, QoS, multicasting, P2P application protocols etc. Therefore, 'Quarantine Model' is required to give more transparent security approach than border defense model for IPv6 network. 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 is not conflict existing security technologies and not exclusive model of 'Border Defense Model'. This memo contains following sections. In Section 2, describes the issues of current border defense model and the requirements for the next-generation Internet. Section 3 describes the overview and the basic concept of 'Quarantine Model', and the remaining section explains a deployment model, components, procedures, ToDos, and the security issues of this model. KONDO & SUZUKI Expires August 8, 2004 [Page 4] Internet-Draft Quarantine Model Overview February 2004 2. Issues in border defense model There are two issues in Border Defense Model: technical one and operational one. The former one is brought about by the nature of protocols or implementations, such as handling of encrypted session or scanning speed. The later one is the issue owing 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, firewall has to scan all the connections and packets, since it cannot detect recent viruses and worms which spread over the Internet via some well-known open port (e.g. HTTP, SMTP). Furthermore, the amount of the network traffic between the Internet and a network site has been increasing, because of the deployment of high-speed network intrastructure and applications consuming bandwidth. Considering these two trends, firewall at the security border point will become a bottleneck of a network site in the Border Defense Model. 2.1.2 Encrypted end-to-end connection Once encrypted session is established between internal machines of border defense point and outside of border, border defense point cannot inspect its connection and contents of data (see section 5 of[2]). 2.1.3 Tunneling technology, VPN Tunneling technologies, such as VPN or RAS, are often used to provide an intranet connectivity to outside the site. Although they are conveniently provide such services, they still have some security holes, because it is difficult for firewalls to inspect the contents encapsulated in tunnels. o Users can create tunnels against the administrator's will. (e.g. XXX over HTTP) o Complicatated 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 KONDO & SUZUKI Expires August 8, 2004 [Page 5] Internet-Draft Quarantine Model Overview February 2004 Section 2.1.2). 2.2 Operational issues border defense model 2.2.1 Immediate update of filtering rule against new security issues There was some Internet disaster case by CodeRed, NIMDA, MS Blaster, MyDoom worm, and they need only a few hours to spread themselves all over the world. This fact means that firewalls do not assist network administrators to extinguish viruses from their networks. There are two reasons for this firewall weakness. First, it is often quite difficult to configure the proper filtering rule to reject a new virus from outside. Second, virus can intrude a site even during the configuration of this filtering rule. These two lead to the collapse of the assumption of border defense model : 'There is no attack from inside the network'. To overcome this kind of security threat, some integrated mechanism is necessary to enforce the security fixes to nodes by automatic installation and checking. 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 go outside of their security border and to connect to other network connectivity like home LAN, dial up connection etc. We cannot control them when it goes outside of the security border. They are facing security risk on the outside of network connectivity and possibility to infect network worms. There is security risk when those mobile node is back and plugged into the their internal network. Nothing enforces to check and scan those mobile nodes to reject virus and worms get into when it is connected back to the internal network. Current border defense model cannot manage well this critical case breaking security border. Wireless LAN and its connectivity bring security risk into border defense model. The radio wave reach to outside of building and office floor and any one can easily get into their network if it does not well securely configured. We must identify there is many physical back door to get into the internal network. Border defense point such as gateway, router is not only the route to get into their internal network to break border defense model. KONDO & SUZUKI Expires August 8, 2004 [Page 6] Internet-Draft Quarantine Model Overview February 2004 2.2.3 Unmanaged network The Internet connectivity has been getting popular all over the world and it is often provided in always-on style. Although this has been a strong driving force for the Internet deployment to unmanaged network environments such as home-LAN, it also brings about a security threat to this environment; users in unmanaged network does not have enough knowledge for security management to protect their network, and hence they are potential victims for crackers. This is not a negligible issue for the Internet, because the number of such network is great and crackers can give a heavy impact or trouble to the Internet by DDoD using all of such networks. 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 leads 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. There are two reasons for this choise: the lack of the alternative solution without any additional security risk, and the difficulty in changing their security policies. To promote IPv6 and new network services, much better security model has to be provide to support end-to-end communication without degrading the security risk. KONDO & SUZUKI Expires August 8, 2004 [Page 7] Internet-Draft Quarantine Model Overview February 2004 3. Architecture overview of quarantine model Quarantine Model is flexible security archtecture to make a security border as virtual network segment. It admits network nodes into different network segment by security level of them, and gives security policy for each network segments. For construction of 'Quarantine Model', it requires below things. o Security level inspection of network node o Separation of network by security level o Appling security policy for each separated network Those three things are described in following sections. 3.1 Security level inspection of network node The security inspection agent is required to check the security level of node to select the network segment based on site security policy. The network node need to be installed agent program to do security inspection to check it's security level. It checks security vulnerabilities conpare with security prevention information. o OS and software versions o Installed security patches o Installed security software (e.g. anti-virus software, firewalls etc.) o configuration and settings of software o etc. 3.2 Separation of network by security level Quarantine model mandates a network mechanism to separate network users to different networks based on their security levels. You MAY use state-of-the-art separation technologies like 802.1x, as long as the network administrators can manage this separation rule. Note that this 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. KONDO & SUZUKI Expires August 8, 2004 [Page 8] Internet-Draft Quarantine Model Overview February 2004 3.3 Appling security policy for each separated network Quarantine mode applies different security policies for separate network segments. That security policy includes access control rules, routing settings etc. It divides the internal network to several segments by security level and configures security policies for them. For untrusted network segment, it would be blocked the communication between other internal network segments and nodes, filtered specific ports and services. Also outgoing sessions are routed to contents scanning and filtering servers. On the other hand, it can configure it does not block any kind of communication between trusted node and trusted network segment. It permits outgoing and incoming connection at security border point for them by site security policy. It would be configured to accept selected port and services, allow to communicate specific destinations etc. for medium security leveled network segment. Applying security policy to the internal network segment and border defence point, quarantine model integrates and collaborates with other existing border defense products and tools (e.g. switch router, firewall etc.). KONDO & SUZUKI Expires August 8, 2004 [Page 9] Internet-Draft Quarantine Model Overview February 2004 4. Advantage of quarantine security model This model is designed to help border defense model to solve existing issues that is described in previous sections. The key concept is that it separates trusted node traffic and untrusted traffic and focus on untrusted connection filtering and scanning. It reduces the target traffic to scan and filter on the border defense point. It solves the issue of Section 2.1.1. 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 on quarantine path. It still cannot scan session contents and packets, but it reduces possibility that virus and worms infected node generates attacking packet and sends it on the encrypted connection path. It solves existing problems of border defence model (e.g. Section 2.1.2, Section 2.1.3). 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. It means if we can manage security issues well for all internal network nodes, we can block most of network worm attacks. It is more better solution to solve those security threats (e.g. Section 2.2.1, Section 2.2.2, Section 2.2.3) than border defence model. It gives transparent connectivity for trusted node . From the network node and application point of views, 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 authenticated by quarantine authentication server and certificate that node is qualified as the site security policy, it can have more transparent accessibilities from/to the outside of network. It is affinity for IPv6 network (e.g. Section 2.3). KONDO & SUZUKI Expires August 8, 2004 [Page 10] Internet-Draft Quarantine Model Overview February 2004 5. Deployment model This section describes two typical concept models of quarantine security model deployment. The component of quarantine model and quarantine procedure is described in following Section 6 and Section 7. 5.1 Basic deployment model First one is typical deployment model such as enterprise or organization sites. In this model, it has contents scanning and filtering servers. It routes untrusted sessions to that quarantine path for security scanning. The internal network segments by security level are separated by swich/router from other virtual network segment by site security policy settings. Fig. Network Diagram of Quarantine Model Component. | | +-----+ +-------------| PIS | | +-----+ ----->| | +-----+ | RT |-------------+ +-----+ | | +---------+--- ... ---+ | | | | | +-----+ +-----+ +-----+ ----->| |CS/FW| |CS/FW| ... |CS/FW| | +-----+ +-----+ +-----+ | | | | | +---------+--- ... ---+ +-----+ | | RT |-------------+<----- +-----+ | +---------+---------+.......... | | | : +-----+ +-----+ +-----+ +-----+ | SW | | QAS | | NAC | | QIS | +-----+ +-----+ +-----+ +-----+ | +---------+----+----+---------+ | | | | +-----+ +-----+ +-----+ +-----+ KONDO & SUZUKI Expires August 8, 2004 [Page 11] Internet-Draft Quarantine Model Overview February 2004 | QIA | | QIA | | CL | | CL |<----- +-----+ +-----+ +-----+ +-----+ PIS: prevention information server QAS: quarantine authentication server QIA: quarantine inspection agent and installed node NAC: network admission controller RT: router SW: switch FW: firewall and security border point CS: connection & packet inspection and scanner. CL: network node that not installed QIA. 5.2 Deployment model for consumer segment Second case is consumer and home user environment and ISP services. In this case, contents scanning and filtering servers are in ISP facilities and NAC controls router/switch of subscriber end point. It can isolate the customer's traffic which send out network worm and attacking packet and vulnerable node from trusted and secure customer area from attacking and DoS packet, network virus outbreak to protect and block consuming bandwidth. Fig. Network Diagram for ISP/VAR Service Model. | | +-----+ +-------------| PIS | ----->| +-----+ | +---ISP's facility | | +-----+ | | RT |-------------+ | +-----+ | | | +---------+--- ... ---+ | | | | | | | +-----+ +-----+ +-----+ | ----->| |CS/FW| |CS/FW| ... |CS/FW| | | +-----+ +-----+ +-----+ | | | | | | | +---------+--- ... ---+ | +-----+ | | | RT |-------------+<----- | +-----+ KONDO & SUZUKI Expires August 8, 2004 [Page 12] Internet-Draft Quarantine Model Overview February 2004 | | | +---------+---------+---------+ | | | | | | +-----+ +-----+ +-----+ +-----+ | |RT/SW| | QAS | | NAC | | QIS | | +-----+ +-----+ +-----+ +-----+ +--- | +..................................... | : : +-----+ +-----+ ----->| RT | user1 | RW | user2 ... userN +-----+ +-----+ | | +---------+----+----+---------+ | | | | +-----+ +-----+ +-----+ +-----+ | QIA | | QIA | | CL | | CL |<----- +-----+ +-----+ +-----+ +-----+ PIS: prevention information server QAS: quarantine authentication server QIA: quarantine inspection agent and installed node NAC: network admission controller RT: router SW: switch FW: firewall and security border point CS: connection & packet inspection and scanner. CL: network node that not installed QIA. KONDO & SUZUKI Expires August 8, 2004 [Page 13] Internet-Draft Quarantine Model Overview February 2004 6. Components of quarantine model There are basic component set of quarantine model for any kind of deployment model. 6.1 Prevention information server Prevention information server(PIS) stores prevention information about security holes and vulnerability reports. All known security threat information and prevention information about security attacks and risks are stored in the PIS network. The PIS network is configured as tree structure to get prevention information from upper layer PIS if it does not have requested prevention information in the site local PIS. The site local PIS is optional component in this model. ISP or security vender may provides PIS for end users as a service / business. 6.2 Quarantine inspection agent Quarantine inspection agent(QIA) do inspection in installed machine and create quarantine certificate profile, and then send the profile information to quarantine authentication server. It corrects information about installed software and OS versions and configurations etc. to check with prevention information on the quarantine authentication server. 6.3 Quarantine authentication server Quarantine authentication server(QAS) checks profiles which are sent from inspection agent. It queries PIS and check the profile information with prevention infromation and identifies their security level by site security policy. Based on the security level, it rejects the network node to connect into the internal network or select one of the network segment to admit. 6.4 Quarantine certificate profile This is quarantine inspection result. It is generated by QIA and sent to QAS to check security level of the node. 6.5 Prevention information This information inludes the security hole and vulnerability information about specific version of software OS or hardware. It KONDO & SUZUKI Expires August 8, 2004 [Page 14] Internet-Draft Quarantine Model Overview February 2004 will have security level, assessment of damage impact, disaster analysis etc. to use by QAS to predict how much that security threat is critical. 6.6 Site security policy configuration The site security policy describes the security policy of network. It defines network segments and connectivity of them. Additionally, it configures requirement of security level of nodes which connect into the network, actions and scripts when it does not satisfy security conditions. 6.7 Network admission controller It works with existing systems, tools and frameworks to make a network segment in the internal network by security levels. It avoid target node from secure network segment and move into other network segment (e.g. quarantined network segment) by existing technics such as changing IP address, VLAN port control, routing etc. KONDO & SUZUKI Expires August 8, 2004 [Page 15] Internet-Draft Quarantine Model Overview February 2004 7. Quarantine procedure Quarantine procedure is processed following steps. 7.1 Connecting to network When does network node connect to the internal network facility and it is up linked, QAS requests inspection and profile information to them. At this moment, network node is moved into the untrusted network segment to separate it from other network node and internal network segments. 7.2 Vulnerability scanning By a request from QAS, network node which install QIA scans itself to check the status of installed software version, OS version, configurations and generates profile information. 7.3 Profile sending Network node sends its profile information to QAS to check its security level and get authentication to connect into secure network segment. 7.4 Security inspection When QAS receives the profile information from the network node, QAS checks it with prevention information. It asks PIS to get prevention information for inspection and checks security vulnerability in the network node. Finally, QAS identifies security level of the network node. 7.5 Network admission control Based on security inspection result, QAS requests admission action to Network Admission Controller to control the network node to connect into the network segment. In the network admission controller, it controls network configuration for the router/switch or servers like DHCP, RADIUS, to control network node to separate and move into specific network segment by security level. 7.6 Profile information expiration When QAS gets new prevention information or update from PIS, it requests related network nodes to send profile information, and checks the profile information with latest prevention information. If it finds a vulnerability on profile information, it applies new security level for the network node and it requests to move the KONDO & SUZUKI Expires August 8, 2004 [Page 16] Internet-Draft Quarantine Model Overview February 2004 network node to other network segment if it dose not fit the security level of existing network segment. KONDO & SUZUKI Expires August 8, 2004 [Page 17] Internet-Draft Quarantine Model Overview February 2004 8. Action items The status of this quarantine model is discussion and feasibility inspection. Here is several technical and operational issues to realize this quarantine model from this concept memo. Currently, some vendors like Cisco [3] are designing their proprietary protocol and products to implement similar idea and model, but we need to have standard protocol, format and interoperability for this quaraine model. It is one of our motivation to discuss about this quarantine model on IETF to define related protocols and formats to be standardized. 8.1 Prevention information description format Prevention information format should be standardized. Currently, security vendor and authority publish security report and analysis report. But it is only for human readable document and it cannot simply integrate with any kind of system for self configuration and automatic corresponding. Several software vendors provide prevention information and configuration, rule set and signature to detect and block security threat for their proprietary system. It should have standard format to exchange those information by program to integrate with multi vendor system. 8.2 Profile information request protocol It is required to have a protocol for profile information request and transferring between QIA and QAS. 8.3 Profile information expiration control It should support profile information expiration control. When new security hole is found or vulnerability is reported, the system should enforce to quarantine inspection to all nodes again. It should support dynamic control of quarantine and secure node separation. 8.4 Network device entity identification The identifier of network device entity is one of concern. IP address, MAC address or any kind of information can be use to identify nodes, but these can dynamically change and create fake data. We need to have reliable and unique identification data. 8.5 Embedded system and small devices support It should consider to support embedded system and small devices. Specially for home use, it may uses those small devices and non-PC platform on home LAN. KONDO & SUZUKI Expires August 8, 2004 [Page 18] Internet-Draft Quarantine Model Overview February 2004 The protocol design and quarantine agent should be designed to support those small devices and it must be lightweight. It means it should not require much CPU resource and code size to integrate into those small platform. These small devices are implemented as single function and pre installed software into flash ROM and it does not update so often and not support to install new software and user customize it. Quarantine inspection agent and profile should handle those characteristic well. 8.6 Delivery and operations of prevention information Discussion point here is who should provides prevention information. There are several opportunity to provide prevention information. o Security vendor o Software/Hardware vendor o Independent security organization Security vendor can provides prevention information to users as services and business which is like as virus/worm scanning pattern and IDS rules, filtering signatures file. But they can not cover all software and hardware products and cannot correct security vulnerability information by themself without products vendor's help. It is better to have a hierarchical structure for PIS like DNS. 8.7 Confliction of prevention information It has a possibility to provides prevention information of security vulnerbility from multiple information source. It introduces conflict of prevention information data in PIS network. 8.8 Home network and unmanaged network The target network is not only for enterprise, but it should also care home LAN and no administrator environment. It means it should support some kinds of auto configuration. This is high priority of requirement for design and implementation of quarantine model. 8.9 NAC and integration to existing security framework It is very important things to integrate with existing system like switch, router and firewall etc. to make separation for internal network to quarantine area and secure area. Quarantine model itself does not specify how to divide two network areas into quarantine KONDO & SUZUKI Expires August 8, 2004 [Page 19] Internet-Draft Quarantine Model Overview February 2004 (untrusted node network) and secure network (trusted node network). NAC must support to communicate routers, switchs, firewalls to create virtual network segment by security level. To integrate those products and technologies, we should have flexible and customized interface on network admission controller and its configuration format and scripts to describe control commands. KONDO & SUZUKI Expires August 8, 2004 [Page 20] Internet-Draft Quarantine Model Overview February 2004 9. Security issues 9.1 Certification of quarantine inspection agent We have to define an architecture that how can we trust QIA program. QIA should be authenticate and certificate by site security policy configuration. Otherwise it is easy to create fake result and there is no way to check reliability of quarantine inspection agent, and then this model would be corrupt. 9.2 Security issues of quarantine profile Quarantine profile information and transport way are also protected and secured between agent and server. 9.3 Prevention information protection It should have authentication check for prevention information. 9.4 Authentication and certification for prevention information server We have to consider about reliability of PIS. It should have a protocols for authentication and certificate chain of PIS. KONDO & SUZUKI Expires August 8, 2004 [Page 21] Internet-Draft Quarantine Model Overview February 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, INOUE Atsushi and WIDE Project (http://www.wide.ad.jp) Secure6 working group members. KONDO & SUZUKI Expires August 8, 2004 [Page 22] Internet-Draft Quarantine Model Overview February 2004 Informative References [1] Bellovin, S., "Distributed Firewalls", ;login; pp.39-47, http:/ /www.research.att.com/~smb/papers/distfw.html, November 1999. [2] Savola, P., "Firewalling Considerations for IPv6", http:// www.ietf.org/internet-drafts/ draft-savola-v6ops-firewalling-02.txt, October 2003. [3] Cisco Systems, Inc., "CISCO SELF-DEFENDING NETWORK", http:// www.cisco.com/go/selfdefend, November 2003. 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 KONDO & SUZUKI Expires August 8, 2004 [Page 23] Internet-Draft Quarantine Model Overview February 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 & SUZUKI Expires August 8, 2004 [Page 24] Internet-Draft Quarantine Model Overview February 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 & SUZUKI Expires August 8, 2004 [Page 25]