INTERNET-DRAFT Nobuo Okabe Internet Engineering Task Force Yokogawa Electric Corporation Issued: February 28, 2002 Atsushi Inoue Expires: August 28, 2002 Toshiba Corporation Masayuki Osajima ACCESS CO., LTD. Kay Noguchi IP Infusion Inc. Hiroshi Esaki The Univ. of Tokyo Hideki Kamimaki Hitachi, Ltd. Atsushi Nakamura Panasonic Takumi Segawa Matsushita Graphic Communication Systems,Inc. Clayton Ware Maxim/Dallas Semiconductor Tadamichi Matsuyama SOUM Corporation Minimum Requirements of IPv6 for Low Cost Network Appliances Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Abstract Resource limitations and cost constraints associated with small-embedded devices make it difficult to implement the entire IPv6 specification. We call such non-PC embedded devices (e.g. game-machines, AV devices, sensors, digital cameras, LCD projectors, and home appliances) "Low Cost Network Appliances", and define the minimum IPv6 requirements for them. In this draft, we will also point out several items to be discussed in future studies. okabe [Page 1] Internet Draft Min.Req. of IPv6 for LCNA February 2002 Table of Contents Abstract ............................................................1 1 Introduction.......................................................3 1.1 Requirement Language ...........................................4 2 Assumption for a minimum host .....................................4 2.1 Hardware configuration .........................................4 2.2 Transition technology from IPv4 ................................5 2.3 Multicast ......................................................5 2.4 Anycast ........................................................5 2.5 API ............................................................5 2.6 Management functions ...........................................5 2.7 Security .......................................................5 2.8 Mobility support ...............................................5 3 IPv6 minimum specification ........................................5 3.1 Internet Protocol, Version 6 (IPv6) Specification ..............6 3.1.1 Hop-by-Hop Options Header ..................................6 3.1.2 Routing Header .............................................6 3.1.3 Fragment Header ............................................7 3.1.4 Destination Options Header .................................8 3.1.5 No Next Header .............................................8 3.2 Path MTU Discovery for IP version 6 ............................8 3.3 Neighbor Discovery for IP Version 6 ............................9 3.4 IPv6 Stateless Address Autoconfiguration .......................9 3.5 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification ........................9 3.6 IP Version 6 Addressing Architecture ...........................9 3.7 DNS Extensions to support IP version 6 and IPv6 Stateless DNS Discovery .....................................................10 3.8 Default Address Selection for IPv6 ............................11 4 Security for LCNA ................................................11 4.1 Threats and Attacks that an LCNA faces ........................11 4.2 Security mechanism for LCNA....................................12 4.3 Minimum security specification for LCNA .......................12 5 Mobility support for LCNA ........................................13 6 Open Issues ......................................................13 6.1 Network-boot devices ..........................................13 6.2 Management facilities for LCNAs ...............................13 6.3 Further study for LCNA security ...............................13 7 Security Considerations ..........................................14 8 Contact information ..............................................14 9. Update from Version-00 ..........................................14 10 Appendix: Example of IPSEC minimum requirement specification ....14 10.1 IPsec specification ..........................................15 10.2 How to setup secure communication path .......................16 10.3 Key exchange specification ...................................16 10.4 IPsec API ....................................................17 11 References ......................................................17 12 Acknowledgements ................................................18 13 Authors' Addresses ..............................................18 okabe [Page 2] Internet Draft Min.Req. of IPv6 for LCNA February 2002 1. Introduction Currently, several IPv6-capable commercial end equipments and protocol stacks, which target non-PC embedded systems, have already been announced [1][2]. Also, the deployment of IPv6 for various non-PC platforms is being evaluated [3]. There might be other configurations for IPv6 embedded devices, which have different design policies, physical shapes, and restriction conditions for the implementation. Though current PCs usually support more than 64MB of memory area, typical embedded devices have only limited memory area and CPU performance as shown in Table 1. This causes severe technical problems for implementing the entire IPv6/Security functionality. In case of consumer equipment such as home appliances, the network functions have to be realized with the lowest cost. Therefore, in order to provide compact implementations, we must limit the mandatory IPv6 specification. In this draft, our target is non-PC embedded appliances called Low Cost Network Appliances (LCNA) which meet the following requirements. * Devices that have no generic functionality, but are targeted at specific tasks. * A device that has network functionality, but has limited resources for networking. * A device that is a host, not a router. There was a comment that cellular phones are also a kind of LCNA. However, special cellular networks and richer functionality set the cellular phones apart from our target (consumer) devices. Therefore, we omit them from our target (see [4] for IPv6 specification of cellular hosts). Examples of LCNAs that might be available in the near future are consumer appliances such as game-machines, AV devices, sensors, digital cameras, LCD projectors, and home appliances including refrigerators and microwave ovens. Considering the above, we will propose an IPv6/Security minimum requirement specification in this draft based upon the following policy. - This specification regulates the baseline for guaranteeing that IPv6 compliant LCNAs can communicate with minimum safety. That is, if it complies with this spec, it is guaranteed that it can communicate with another device securely if connected by IPv6. - We do not assume equipment that has any specific usage models. We will summarize a minimum requirement that is used on various LCNAs in common. - There are functions that are necessary depending upon specific network topology, communication content, and usage model such as mobility. For these functions, we will evaluate how generic the function is, and if it is necessary it will be included into the minimum specification, and if not, we will indicate that it is an optional function for a specific usage model. okabe [Page 3] Internet Draft Min.Req. of IPv6 for LCNA February 2002 Therefore, in order to adopt this specification to various implementations, it is necessary to classify the usage style, communication mode, communication contents, network mobility, and actual usage model. Then, select the optimal combination of items for each implementation. Table 1. Resource restrictions of LCNA ===============+===============+==================+======= Memory CPU Performance OS ===============+===============+==================+======= PC >64MB Pentium/64bits Windows ---------------+---------------+------------------+------- PDA 2-8MB RISC/32bits(50MHz) WinCE VxWorks PalmOS ---------------+---------------+------------------+------- AV equipment 512KB ROM RISC/32bits(20MHz) uTron | 20-64KB RAM 8-16bit MPU Monitor | LCNA ---------------+---------------+------------------+------- | Sensor 512KB ROM 8-16bits MPU Monitor | 512KB RAM | ---------------+---------------+------------------+------- | Home appliance 512KB ROM 8-16bits MPU Monitor | 16-32KB RAM | ===============+===============+==================+======= 1.1 Requirement Language The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [35]. 2. Assumption for a minimum host A minimum host MAY omit the functionality that is described as "out of scope" in this draft. 2.1 Hardware configuration In this draft, the hardware configuration of a minimum host is as follows: - A minimum host can provide enough functionality with only one network interface. If the minimum host has multiple network interfaces, it must support more resources, see 3.3 for detail. - For Layer 2, we will assume Ethernet as typical shared media and PPP as typical point-to-point media. These are considered as minimum interfaces (RFC2467 [5], RFC2470 [6], RFC2497 [7]). The media that is abstracted as Ethernet/PPP from IP layer is also targeted. - A minimum host can be invoked in stand-alone mode, which means booting via network is not necessary (See 6.1). okabe [Page 4] Internet Draft Min.Req. of IPv6 for LCNA February 2002 2.2 Transition technology from IPv4 Transition from IPv4 is an important topic when deploying a minimum host, but we will omit it in this draft. Therefore, we will only consider communications over pure IPv6 networks. For the long-term perspective, the goal is to realize the interconnection with IPv4 networks, but it does not mean that the operation of a minimum host relies on the existence of translators and/or NATs. 2.3 Multicast Multicast is not addressed in this draft, and it is a candidate for further study (RFC 2375[8], RFC 2710[9]). However, multicast related to neighbor discovery is considered, where LCNA sends/receives ND-related Link Local multicast without MLD(Multicast Listener Discovery). It does not perform explicit operation to belong to a specific multicast-group. This method works on most current networks, but in the future the designer of switches that filter IPv6 multicast must take care of this. 2.4 Anycast A minimum host does not assign anycast addresses to its own interface (RFC 2526[10]). A minimum host might use the anycast service in some cases, e.g. DNS server discovery, but providing anycast services MAY be omitted. 2.5 API Socket API and IPSec API are implementation dependent. For example, the Socket API will be expanded in a vendor specific manner, or a Java API layer can hide them. Therefore, these APIs are out of the scope of this draft. 2.6 Management functions In this draft, the functions for managing LCNAs via the network are out of scope. This is very important and must be listed as a future study item (See 6.2). 2.7 Security In Section 4 "Security for LCNA", we will regulate a baseline for guaranteeing that a minimum host can communicate securely. However, Denial of Service (DoS) and intrusion are out of scope. So, we have to consider defending from DoS and/or intrusion in another place. Also, the authentication of users is out of scope, because some minimum hosts can omit a mechanism of user accounts. 2.8 Mobility support In this draft, we do not assume that LCNA itself moves on the network, but the processing from other nodes that operate as Mobile Nodes of Mobile IPv6 is mandatory. However, the concrete regulation for LCNA is pending because the Mobile IPv6 is not yet fixed. See chapter 5 for the consideration of the case that LCNA itself needs the mobility. 3. IPv6 minimum specification In the following sections, we will explain minimum requirements okabe [Page 5] Internet Draft Min.Req. of IPv6 for LCNA February 2002 according to each related RFC and Internet Draft. 3.1 Internet Protocol, Version 6 (IPv6) Specification (RFC 2460[18]) As for extension headers, a minimum host only supports the minimum necessary functions. There are no functions that a host needs to use current IPv6 extension headers, except for Mobile IPv6 functions (abbreviated as MIP6) and IPsec. Therefore it is OPTIONAL for a minimum host to send packets with IPv6 extension headers except ESP [19] (See 10.1 for detail of AH/ESP). It is regulated that a minimum host does not send packets with extension headers. On the other hand, when a minimum host receives packets with extension headers, it MUST perform minimum processing specified in RFC2460 [18]. This is based on the principle "Be liberal in what you accept, and conservative in what you send" as specified in RFC2360 [20]. The detail of the extension header receiving process is as follows, - When the node receives unsupported extension headers, it MUST return an ICMP Parameter Problem Message (Type=4, Code=1) to the sender and discard them. - When it can recognize the extension header but does not support the options in it, it MUST perform error processing according to the option number. Since it is assumed that the minimum host does not need extension header functions, it MAY omit order check of extension headers. This is also based on RFC2360 [20] principles. Detailed processing for each extension header is as follows: 3.1.1 Hop-by-Hop Options Header [Sending] Following 3.1, minimum hosts do not send packets with this extension header. [Receiving] A minimum host SHOULD recognize it as a Hop-by-Hop Options Header, and perform the processing according to the option and option number in it. Because this option is used for signaling and router alert, in order to control routers on the path, all nodes on the transmission path have to interpret this header but do not need to interpret all options in it. 3.1.2 Routing Header [Sending] Following 3.1, minimum hosts do not send packets with this extension header. [Receiving] RFC regulates that if the Segment Left field has non-zero value in this header, the node has to forward the packet to the next intermediate node, even when the node is a host. But in the case of a minimum host, this forwarding MAY be omitted and be treated as an unsupported extension header, because only intermediate nodes (such okabe [Page 6] Internet Draft Min.Req. of IPv6 for LCNA February 2002 as routers) and the destination node have to interpret this header. One exception is when the minimum host supports the mobile node function of Mobile IPv6. As Mobile IPv6 uses a Routing header for receiving packets destined to Mobile Node, this header MUST be processed correctly. Another exception for sending this header is when using route optimization for communicating with Mobile IPv6 mobility agents. If route optimization is performed using binding update, the node MUST send packets with these extension headers. 3.1.3 Fragment Header If a minimum host satisfies the following conditions, the host MAY not send this extension header, and MAY treat one as an unsupported header when receiving it. - For TCP, * By limiting the max segment size (MSS) advertised by itself to less than the value of the total IP packet length, it becomes less than IPv6 minimum MTU. Fragmentation of the TCP packet from the correspondent is prevented. * By replacing the MSS advertised by the correspondent to the value of the total IP packet length, it becomes less than IPv6 minimum MTU. The minimum host limits the size of transmitting TCP packets. - For UDP, * The application that might receive IP packets with a size bigger than IPv6 minimum MTU from the correspondent is not supported. A typical example of this application is NFS. * The application that transmits UDP packets from its side has to do the tuning in order to limit the IP packet length to less than IPv6 minimum MTU. A minimum host SHOULD implement fragmenting/re-assembling functions if the above conditions are not satisfied. [Receiving] When reassembling the fragmented packets, the host has to store the packets in memory then perform the reassembly processing. This consumes large amounts of memory. A designer may want to omit the reassembly processing of fragmented packets if the host system is memory constrained. However, this might cause serious performance degradation in some cases. In IPv6, minimum MTU is specified as 1280 bytes, and any packet smaller than that is not fragmented. When communicating with TCP, if the advertised MSS is set smaller, the receiver side can control the maximum size which can be used for the sender's payload. By using this mechanism, we can reduce the frequency of the fragmentation. For example, if the MSS is advertised as 1000 bytes, no fragmentation happens as long as the total size of the IP header and extension headers does not exceed 280 bytes. okabe [Page 7] Internet Draft Min.Req. of IPv6 for LCNA February 2002 On the other hand, because UDP does not have a packet size control mechanism like TCP, the receiver side has no way to force the sender to limit the packet size to less than the IPv6 minimum MTU. Therefore, returning ICMPs and discarding packets might happen. There are several services that might send UDP packets with a large payload size, such as DNS and NFS. In general, DNS payload is less than 512 bytes. In the case of EDNS0, the certificate information is appended and the packet size might exceed IPv6 minimum MTU (1280 bytes). However, in this case, TCP can be used as a transport protocol and the issue is avoided. Typical UDP payload size for NFS is on the order of kilobytes. Therefore, if a minimum host implements NFS service using UDP as transport protocol (not TCP), the reassembly of IP packets is necessary. [Sending] For sending packets, if a minimum host limits the sending packet size to less than IPv6 minimum MTU (1280 bytes), it will be delivered to the final destination without any fragmentation. In this case, the processing of the fragmented header is not necessary on the sender side. Also, the management of path MTU for each destination can be omitted, which can reduce memory consumption. For TCP, by replacing the received MSS with the IPv6 minimum MTU, the minimum host can control the size of sending packets to less than 1280 bytes. But in the case of UDP, the packet size is determined in the application layer. So it is necessary to have appropriate application tuning. 3.1.4 Destination Options Header [Sending] Following 3.1, minimum hosts do not send packets with this extension header. [Receiving] A minimum host SHOULD recognize this header as Destination Options Header and perform processing according to the options and option numbers in it. One exception is the handling of Home address destination option for Mobile IPv6. As mentioned in section 2.8, even if LCNA itself does not move, it has to process the packets sent from other mobile nodes. Therefore, the processing of Home address option becomes mandatory. However, since final specification of Mobile IPv6 is not regulated yet, we omit the concrete regulation for LCNA now. 3.1.5 No Next Header This header is only interpreted but requires no action. 3.2 Path MTU Discovery for IP version 6 (RFC1981) [21] An implementation that conforms to the conditions specified in "3.1.3 Fragment Header" can omit the implementation of Path MTU Discovery, because it can guarantee that the TCP/UDP packets are sent with a length less than the minimum MTU and packet fragmentation must not happen. Therefore, even if it receives ICMP Too Big Message, it can handle that as an error. okabe [Page 8] Internet Draft Min.Req. of IPv6 for LCNA February 2002 3.3 Neighbor Discovery for IP Version 6 (IPv6) (RFC2461) [22] Because of IPv6 minimum host definition, the following functions for routers can be omitted. - Sending router advertise messages - Receiving router solicitation messages - Sending redirect messages Receiving Redirect messages is a host function but the implementation MAY omit it. If a host has the functionality, the host also SHOULD have an implementation of the destination cache. As specified in RFC2461 [22], it is the same when Layer 2 is PPP. In this draft, we assume that an LCNA has only one network Interface, but it does not inhibit multiple interfaces. When an LCNA is assumed to have multiple interfaces, the following considerations are necessary, which requires more resources. - Source address selection - Kinds of routing information (such as destination cache and routing table) - Number of cache entries will increase * ND cache * Default router list * Prefix list 3.4 IPv6 Stateless Address Autoconfiguration (RFC2462) [23] Duplicated address detection (DAD) uses the neighbor discovery function. Neighbor discovery is mandatory in IPv6. Therefore, DAD has almost no impact on resource usage, so all functions of DAD SHOULD be implemented. RFC2462 [23] does not mention anything about PPP, but everything SHOULD be implemented. Because DAD is heavily dependent on neighbor discovery and neighbor discovery is mandatory for the PPP case. 3.5 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (RFC2463) [24] On minimum hosts, ICMP used only by a router MAY be omitted (Table 2). ICMPs for Echo Request/Reply and minimum error reporting MUST be supported. 3.6 IP Version 6 Addressing Architecture (RFC 2373) [25] By default, minimum hosts MUST have the following three addresses. - Loopback (::1) - Node-local all nodes multicast (ff01::1) - Link-local all nodes multicast (ff02::1) If address autoconfiguration is performed, the following addresses MUST be supported. okabe [Page 9] Internet Draft Min.Req. of IPv6 for LCNA February 2002 - Link-local unicast (fe80/64 host ID) - Solicited-node multicast corresponding to the above - Unicast (prefix/64 host ID) corresponding to the prefix option of router advertise messages - Solicited-node multicast corresponding to the above If manual configuration is performed, the following addresses MUST be supported. - Arbitrary unicast - Solicited-node multicast corresponding to the above Table 2. Mandatory ICMP messages for LCNA ===============+===============================+========== Type Code Necessary? ===============+===============================+========== 1: 0: No route to destination No Destination 1: Administratively Prohibited No Unreachable 3: Address unreachable No Message 4: port unreachable Yes ---------------+-------------------------------+---------- 2: 0: Packet too big No Packet Too Big Message ---------------+-------------------------------+---------- 3: 0: Hop limit exceeded No Time 1: Fragment reassembly No Exceeded time exceeded Message ---------------+-------------------------------+---------- 4: 0: Erroneous header field Yes Parameter 1: Unrecognized next header Yes Problem 2: Unrecognized IPv6 option Yes Message ---------------+-------------------------------+---------- 128: 0: Echo request Yes Echo Request Message ---------------+-------------------------------+---------- 129: 0: Echo reply Yes Echo Reply Message ===============+===============================+========== 3.7 DNS Extensions to support IP version 6 (RFC1886) [26] and IPv6 Stateless DNS Discovery (draft-ietf-ipngwg-dns-discovery-02.txt) [27] The only function that is not supported in the current IPv6 autoconfiguration is automatic discovery of DNS server. On this okabe [Page 10] Internet Draft Min.Req. of IPv6 for LCNA February 2002 topic discussions are ongoing in IETF IPNG WG. If a standard is fixed, it might become a mandatory item for minimum hosts. AAAA record is defined for transform from IPv6 name to IPv6 address. So, AAAA is currently mandatory for minimum host name resolution. Also, A6 record is currently proposed and discussed in IETF for an alternative of AAAA record. We need to check the progress. If a minimum host is a passive node, it will not become an initiator of the communication. This means that automatic discovery of the DNS server and name resolution MAY be omitted (the implementation of resolver can be omitted on a passive node). On the other hand, if a minimum host is an active node, DNS name resolution is necessary. In such cases, automatic DNS server discovery SHOULD be implemented. 3.8 Default Address Selection for IPv6 (draft-ietf-ipngwg-default-addr-select-06.txt)[26] An LCNA SHOULD support Default Address Selection for IPv6 [26]. But considering the assumption of LCNA itself, it can be simplified as follows: - In section 2.5 of [26], the implementation of the policy table is not mandatory, so we can omit the policy table on LCNAs. - Section 3 of [26] mentions the check for receiving ICMP REDIRECT messages. As mentioned in section 3.3 of this draft, when ICMP REDIRECT message receive processing is omitted, the checking process can also be omitted. - The LCNA SHOULD satisfy RULE 1 to 3 concerning the source address selection rules described in section 4 of [26]. RULE 4 is not necessary when the LCNA itself does not have mobility. RULE 5 is not necessary when the LCNA has only one interface. RULE 6 is not necessary when the LCNA does not implement policy tables. RULE 7 is not mandatory because the LCNA does not mandate [34]. RULE 8 is not mandatory because it is not mandatory even in [26]. - The LCNA SHOULD satisfy RULE 1, 2, 3 and 8 concerning the destination address selection rules described in section 5 of [26]. RULE 4 is not necessary when the LCNA itself does not have mobility. RULE 5 and 6 are not necessary because the LCNA does not implement policy tables. RULE 7 is not necessary when the LCNA implements IPv6 native transport only. RULE 9 and 10 are not mandatory because it is not mandatory even in [26]. - Concerning source/destination address selection, the LCNA can implement more lightweight algorithms suitable for the implementation. 4 Security for LCNA We regulate that "Considering the limited resource on the LCNA, we SHOULD select an appropriate security mechanism depending upon the application which operates on the LCNA or the degree of threat when using it". 4.1 Threats and Attacks that an LCNA faces Various security threat must be considered for the application area of LCNAs. okabe [Page 11] Internet Draft Min.Req. of IPv6 for LCNA February 2002 - Threats related to human life, property, social infrastructure. If these items face the threat, it "directly" affects human lives, property and social lifelines. - Threats related to the privacy of users If these items face the threat, it "directly" affects human privacy. * Electronic commerce historical data * WEB access history The possible attacks are as follows: - Scanning (identifying the target of the attacks) - Tapping of the communication - Impersonation - Intrusion - DoS, DDoS It deeply depends on the functionality, application areas and data handling of LCNAs to determine how serious each attack is. 4.2 Security mechanism for LCNA In order to defend against the above threats and attacks, there are various security mechanisms on each communication layer, such as IPsec, SSL, SSH, etc. But one mechanism cannot fulfill the whole security requirements of LCNAs. For example, IPsec realizes security on the IP layer, which is transparent from the transport and/or application layer, so it can be a generic solution. On the other hand, IPsec does not work well with IP layer translation technology (such as NAT and IPv4/IPv6 translator), which might be a restriction for the promotion of LCNAs. SSL might be more important than IPsec, when LCNAs assume general Web applications. However, SSL is difficult to implement on LCNAs with limited computation power because it requires asymmetric cryptography computation on each session. Also, when the LCNA assumes applications which work using UDP, SSL cannot be a security solution. It is determined by the tradeoff of the objective, target usage, cost, and security threats of the LCNA which security mechanism (or multiple security mechanisms) the LCNA SHOULD implement. In other cases, the LCNA only supports poor performance CPU and it cannot implement IPsec, SSL nor SSH. But even in such cases, unless the security issues as mentioned above on the handled data and the LCNA operations, the LCNAs without any security mechanisms SHOULD be permitted. 4.3 Minimum security specification for LCNA It has to be carefully considered whether existing security mechanisms (IPsec, SSL, SSH, etc.) can be implemented for given resources of the LCNA. For example, the performance of various encryption algorithms on a limited performance CPU must be evaluated. Also in other cases, the effect of hardware acceleration must be evaluated, which determines whether it realizes a security solution which conforms to the cost requirements of the LCNA. okabe [Page 12] Internet Draft Min.Req. of IPv6 for LCNA February 2002 It is necessary to define a minimum specification in which the necessary items are extracted from each security mechanism based on these evaluations. In order for a better industrial popularization of LCNAs, the promotion of the minimum specification is also very important. For instance, the example of making a minimum specification of IPsec applied for typical LCNAs is shown in the Appendix. There might be a minimum specification for the security mechanism on other layers such as SSL. We hope these specifications will be proposed in other drafts. 5 Mobility support for LCNA As shown in section 2.8, in this draft, we do not mandate the mobility support when the LCNA itself moves on the network, but the communication with other mobile nodes is only specified as minimum requirement. When portable devices and wearable devices will appear as LCNAs in future, there will be more cases that needs any kind of mobility support. Even for the LCNA which is implemented based on this draft, nomadicity is supported. But when the mobility is necessary, the LCNA has to support Mobile IPv6. But because currently Mobile IPv6 standardization is not on the final stage, we will not refer to Mobile IPv6 for LCNA and it will be future work. Typical current issue for Mobile IPv6 is security mechanism for binding update. As mentioned in section 4, we need lightweight solution for this security mechanism because of limited resource of LCNAs. 6 Open Issues In this section, we will summarize items to be considered during future study. 6.1 Network-boot devices The function for booting from the network with tftp is out of scope of this draft. This boot code works in a very limited ROM area, and might need a specially limited specification. Generally such devices are designed for a special purpose and might need another implementation guideline. 6.2 Management facilities for LCNAs When LCNAs are commonly used, there may be many LCNAs on the home network. In such cases, the following management facilities will be usable. - SNMP(RFC2452[11],RFC2454[12],RFC2465[13],RFC2466[14], draft-ietf-ipsec-doi-tc-mib-04.txt[15], draft-ietf-ipsec-monitor-mib-04.txt[16]) - ICMP name lookup [17] - Vendor-specific management functions (such as Web-based tools) In order to define the management functions suitable for LCNAs, we have to define and analyze the requirements for LCNA management first. For example, traffic measurement, which is useful for router management, may not be necessary on LCNAs. 6.3 Further study for LCNA security As mentioned in 4, we have to make further study for okabe [Page 13] Internet Draft Min.Req. of IPv6 for LCNA February 2002 security which can be applicable to LCNA. Here are some viewpoints: - Surveying performance and footprint of LCNA systems: CPU performance and memory footprint have impact against LCNA security feature because LCNAs have limited resources. However, those factors may be changed by silicon technology and popularization. Regularly surveying these factors should be done. You can see our current survey at the following URL. http://www.tahi.org/minspec/ - Estimating various encryption methods and security mechanisms: As mentioned in 4.3, it must be carefully considered whether existing security mechanisms and/or encryption can be implemented on the given resources of LCNAs. Hardware suitability is also important for LCNA security. - Network models of LCNA: Due to IPv6's nature, LCNAs easily have multiple addresses. At the same time, LCNAs can be put into multi-home networks. How will these factors influence the networks where LCNAs exist? What should the networks be for LCNAs, especially in a home? - Configuring Security parameters: It is very important to configure security parameters. However, current automatic key exchange algorithms seem to be too heavy for LCNA. Manual key exchange is not the correct solution because of its inconvenience. [37] and [38] might give us hints. 7. Security Consideration As mentioned in 2.7, DOS and intrusion are out of the scope of this draft. For other security considerations about IPsec key exchange, see section 10.3 and 10.4. 8. Contact information Please contact tiny@tahi.org for questions/comments pertaining to this document. 9. Updates from Version-00 * Appended the description of MLD related matters in 2.3 Multicast. * Appended 2.8 Mobility support * Modified parts of the contents in 3.1.2 Routing Header and 3.1.4 Destination Options Header. * Appended 3.8 Default Address Selection for IPv6. * The contents of chapter 4 has been completely updated. Part of the description in version 00 has been moved to the Appendix. * Appended chapter 5. * The contents of chapter 6 has been completely updated. Part of the description in version 00 has been moved to the Appendix. * Corrected Type number of ICMP Parameter Problem Message in 3.1 10 Appendix: Example of IPSEC minimum requirements specification okabe [Page 14] Internet Draft Min.Req. of IPv6 for LCNA February 2002 Considering the restriction of resources on minimum hosts, we have regulated an example of a subset of IPsec specified in RFC2401 [28] as follows. We believe that IPsec is an effective technology in order to guarantee security of communication. That is the reason why we regulate the minimum IPsec specification in this draft. However, we have to consider whether this regulation works well in actual implementations of various appliances as mentioned in chapter 4. There are two different approaches for treating the IPsec minimum specification of LCNAs and mandating it. * Because IPsec minimum specification is very important for expanding the application of the future Internet, we have to regulate minimum IPsec as mandatory and should make effort to realize even if it is hard to deploy. Therefore, it is CORRECT to regulate IPsec minimum specification as mandatory. * Even though we regulate minimum IPsec as mandatory, no one uses it because there are no prospects to deploy it in the real world. Therefore, it is WRONG to regulate the IPsec minimum specification as mandatory. When IPv6 is widely used on the Internet, LCNAs will become numerous. Therefore, if we do not regulate the framework of LCNA's security, there might be much adhoc security implementations for LCNAs. This would cause an obstacle for the end-to-end communication principle of IPv6. However, we will not consider this problem in detail in this draft. Therefore, it is very important for the future of the Internet to come to a consensus on this discussion. 10.1 IPsec specification RFC2401 [28] assumes many communication modes. However, in this draft, we will focus on only the communication between minimum hosts using IPv6 transport mode. Communication using a security gateway is out of scope. IPSec for multicast is also out of scope because the discussion of multicast key exchange has just begun in IETF. Anycast is out of scope because detail is not fixed yet. There are several proposals for IPSec MIB and IPSec specific ICMP but they are not standardized yet, so they too are out of scope. For the security protocol, ESP [19] MUST be implemented. If the encryption of payload is NOT needed (but the authentication is necessary), the NULL algorithm can be used. Authentication data MUST be implemented and padding MUST be sequential. Because the usage of IPv6 extension headers is limited in section 3, authentication header (AH[29]) MAY be omitted from the minimum-security specification. For the encryption algorithm, AES with 128 bit key length MUST be implemented. CBC [30] MUST be supported for IV mode. For the authentication algorithm, HMAC-SHA2-256 MUST be implemented. Other algorithms MAY be implementation-dependent. RFC2401[28] specifies mandatory security association (SA) parameters that must be implemented. However, the items that are dependent on the specifications which are regulated as unnessesary in this draft MAY be omitted. For example, because only the transport mode is supported in this draft, the management of IPsec mode MAY be omitted. If automatic key exchange is not implemented, the okabe [Page 15] Internet Draft Min.Req. of IPv6 for LCNA February 2002 parameters for key lifetime MAY also be omitted. When automatic key exchange is implemented, key lifetime has to be included as an SA parameter. The specification of key lifetime with transmitted byte count is ambiguous and SHOULD NOT be implemented. In the current IPsec, it is mandated that users can setup SA parameters by some process. However, in the case of a very low-cost (one-time used) minimum host, SA parameters might be hard-coded and users do not need to perform setup. We need to consider whether this SA parameter setup capability is mandatory in LCNAs as a future work. 10.2 How to setup a secure communication path In order to setup a secure communication path by IPsec, the following procedure is necessary: 1. Two nodes that communicate through IPsec authenticate to each other. 2. Security association is setup by exchanging SA parameters in a secure manner negotiated by the two nodes. 3. Communication is performed using the setup SA. We call step 1 and 2 "Key exchange". In the current IPsec specification, two types of key exchange are defined as follows: (a) Automatic Key Exchange Key exchange modules exchange SA parameters automatically without any manual operations. The renewal of the old SA is also done automatically by the same sequence. (b) Manual Key Exchange The administrators of hosts exchange SA parameters by some method, and SAs are setup by some means (such as commands). The renewal of old SAs is done by the administrator using the same methods. 10.3 Key exchange specification The minimum security specification regulates that manual key exchange MUST be implemented. PKI[31] might be a technique used for automatic mutual authentication, but it will heavily affect the LCNAs' performance. Also, there are no standards for using PKI[31] from IPsec. Therefore, we will not regulate automatic key exchange as mandatory (SHOULD be implemented). IKE[32] is specified as a key exchange algorithm for automatic key exchange. However IKE is designed for generic purposes and is not suitable for low-power minimum hosts. Also, the description of exception handling is ambiguous, which makes interoperability of IKE implementations a serious problem. It has been pointed out that IKE is vulnerable to DOS attacks [33]. Considering these situations, there are more lightweight algorithms are being discussed in IETF. These algorithms are expected to be suitable for minimum hosts. In some cases, a key distribution center (KDC) model might be applicable for them. RFC3041 [34] proposes the enhancement of privacy by randomizing the interface-ID part of the IPv6 addresses. If this facility is necessary, the manual key exchange mandated in this draft cannot be used as is, and we need to consider alternatives (such as automatic okabe [Page 16] Internet Draft Min.Req. of IPv6 for LCNA February 2002 key exchange). Only manual key exchange is mandated for LCNAs in this draft. However, in some classes of appliances, the IPsec parameters setup at shipping time might be used until the appliance is disposed. In such cases, if the lifetime of the appliance is long, we have to evaluate whether the SA algorithm and key-length setup initially are strong enough considering all the packet counts sent/received. This evaluation is not done in detail. There is a method where the IPsec parameters are refreshed at a fixed interval, but this is also dependent on the node API, and it is not covered in this draft. 10.4 IPsec API In this example, the IPsec API is implementation dependent and must not have any security holes. For issues with this type of implementation, please refer to RFC2401[28] "2.2 Caveats and Assumptions". 11 References [1] InternetNode Inc. http://www.i-node.co.jp/ [2] ACCESS CO., LTD. http://www.access.co.jp/ [3] IPv6 Promotion Council, Application Working Group, http://www.v6pc.jp/apwg.html [4] Minimum IPv6 Functionality for a Cellular Host (draft-manyfolks-ipv6-cellular-host-01.txt) [5] Transmission of IPv6 Packets over FDDI Networks (RFC2467) [6] Transmission of IPv6 Packets over Token Ring Networks (RFC2470) [7] Transmission of IPv6 Packets over ARCnet Networks (RFC2497) [8] IPv6 Multicast Address Assignments (RFC2375) [9] Multicast Listener Discovery (MLD) for IPv6 (RFC2710) [10] Reserved IPv6 Subnet Anycast Addresses (RFC2526) [11] IP Version 6 Management Information Base for the Transmission Control Protocol (RFC2452) [12] IP Version 6 Management Information Base for the User Datagram Protocol (RFC2454) [13] Management Information Base for IP Version 6: Textual Conventions and General Group (RFC2465) [14] Management Information Base for IP Version 6: ICMPv6 Group (RFC2466) [15] IPsec DOI Textual Conventions MIB (draft-ietf-ipsec-doi-tc-mib-04.txt) [16] IPsec Monitoring MIB (draft-ietf-ipsec-monitor-mib-04.txt) [17] IPv6 Node Information Queries (draft-ietf-ipngwg-icmp-name-lookups-08) [18] Internet Protocol, Version 6 (IPv6) Specification (RFC 2460) [19] IP Encapsulating Security Payload (RFC2406) [20] Guide for Internet Standards Writers (RFC2360) [21] Path MTU Discovery for IP version 6 (RFC 1981) [22] Neighbor Discovery for IP Version 6 (IPv6) (RFC 2461) [23] IPv6 Stateless Address Autoconfiguration (RFC 2462) [24] Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (RFC 2463) [25] IP Version 6 Addressing Architecture (RFC 2373) okabe [Page 17] Internet Draft Min.Req. of IPv6 for LCNA February 2002 [26] DNS Extensions to support IP version 6 (RFC 1886) [27] IPv6 Stateless DNS Discovery (draft-ietf-ipngwg-dns-discovery-02.txt) [28] Security Architecture for the Internet Protocol (RFC2401) [29] IP Authentication Header (RFC2402) [30] The AES Cipher Algorithm and Its Use With IPsec (draft-ietf-ipsec-ciph-aes-cbc-01.txt) [31] Internet X.509 Public Key Infrastructure Certificate and CRL Profile (RFC2459) [32] The Internet Key Exchange (RFC2409) [33] Code-preserving Simplifications and Improvements to IKE (draft-ietf-ipsec-improveike-00.txt) [34] Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (RFC3041) [35] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [36] Default Address Selection for IPv6 (draft-ietf-ipngwg-default-addr-select-06.txt) [37] Configuring Security Parameters in Small Devices (draft-hanna-zeroconf-seccfg-00.txt) [38] Frank Stajano, Ross Anderson "The Resurrecting Duckling: Security Issues for Ad-hoc Wireless Networks" http://www-lce.eng.cam.ac.uk/~fms27/duckling/ 12 Acknowledgements The authors would like to thank Shoichi Sakane(Yokogawa Electric Corporation) Hiroshi Miyata(Yokogawa Electric Corporation), Jirou Sajiki(Yokogawa Electric Corporation), Nobumichi Ozoe(Yokogawa Electric Corporation) Yukiyo Akisada(Yokogawa Electric Corporation) Masahito Endo(Yokogawa Electric Corporation) Masahiro Ishiyama(Toshiba Corporation) Kiyoshi Inoue(SOUM Corporaton) for there comments and input. The authors also would like to thank all the members of non-PC Network Appliance Committee, organized in Interoperability Technology Association for Information Processing, Japan (INTAP) for there useful comments. The support of Information-Technology Promotion Agency, Japan is gratefully acknowledged. 13 Authors' Addresses Nobuo Okabe Yokogawa Electric Corporation IT Business Development Division 2-9-32 Nakacho, Musashino-shi, Tokyo, 180-8750 Japan Phone: 81-422-52-5298 Fax: 81-422-52-6426 E-Mail: nov@tahi.org okabe [Page 18] Internet Draft Min.Req. of IPv6 for LCNA February 2002 Atsushi Inoue Toshiba Corp. R&D Center 1 Komukai-Toshiba-cho, Saiwai-ku, Kawasaki 212-8582 JAPAN Phone: 81-44-549-2065 Fax: 81-44-520-1806 E-mail: inoue@isl.rdc.toshiba.co.jp Masayuki Osajima ACCESS CO., LTD, Basic Development Dept. Hirata-bld, 2-8-16 Sarugaku-cho Chiyoda-ku, Tokyo, 101-0064, Japan Phone: 81-3-5239-3807 Fax: 81-3-5259-3598 E-mail: osajima@access.co.jp Kay Noguchi IP Infusion Inc. 111 W.St. John Street, Suite 910 San Jose CA 95113 Phone:1-408-794-1500 Fax:1-408-278-0521 E-mail: kay@ipinfusion.com Hiroshi Esaki The University of Tokyo 7-3-1, Hongo, Bunkyo-ku, Tokyo, 113-8656, Japan Phone: 81-3-5841-7465 Fax: 81-3-5841-6702 E-mail: hiroshi@wide.ad.jp Hideki Kamimaki Hitachi, Ltd. Systems Development Laboratory 292 Yoshida-cho, Totsuka-ku, Yokohama, 244-0817 Japan Phone:81-45-860-3085 Fax: 81-45-860-1674 E-mail:kamimaki@sdl.hitachi.co.jp Atsushi Nakamura Panasonic Matsushita Electric Industrial Co., Ltd. Advanced Technology Research Laboratory 3-10-1 Higashimita, Tama-ku, Kawasaki 214-8501 Japan Phone:81-44-935-6979 Fax: 81-44-934-3363 E-mail: ann@mrit.mei.co.jp Takumi Segawa Matsushita Graphic Communication Systems,Inc. okabe [Page 19] Internet Draft Min.Req. of IPv6 for LCNA February 2002 2-3-8 Shimomeguro,Meguro-ku,Tokyo 153-8687,Japan tel:+81-3-5434-7678 e-mail:segawa@rdmg.mgcs.mei.co.jp Clayton Ware Maxim/Dallas Semiconductor 4401 S. Beltwood Parkway Dallas, TX 75244-3292 Phone: 972-371-6031 e-mail:clayton.ware@dalsemi.com Tadamichi Matsuyama SOUM Corporation Nissei Building, 1-29-9 Hatagaya, Shibuya-ku Tokyo 151-0072, Japan Phone: 81-3-5453-1251 Fax: 81-3-5453-1252 E-Mail: ko@soum.co.jp okabe [Page 20]