INTERNET-DRAFT Nobuo Okabe Internet Engineering Task Force Shoichi Sakane Issued: November 14, 2001 Hiroshi Miyata Expires: April 14, 2002 Jirou Sajiki Yokogawa Electric Corporation Atsushi Inoue Masahiro Ishiyama Toshiba Corporation Masayuki Osajima Kay Noguchi ACCESS CO., LTD. Hiroshi Esaki The Univ. of Tokyo Minimum Requirement of IPv6 for Low Cost Network Appliance 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 As the always-on network is becoming popular, lots of nodes, not only ordinary PCs but also various information appliances such as sensors, home appliances, AV equipments, are to be connected to the Internet. In order to involve huge number of nodes into the Internet, we need much more IP addresses, and IPv6 becomes mandatory. Because the cost and resource dedicated for the network module is very limited on these low-cost consumer devices, it is difficult to implement whole IPv6 specification on them. We call such non-PC embedded devices "Low Cost Network Appliance", and considered minimum requirement of IPv6 for them. In this draft, we will also point out that there are lots of items to be discussed for future studies. manyfolks [Page 1] Internet Draft Min.Req. of IPv6 for LCNA November 2001 Table of Contents Abstract ............................................................1 1 Introduction.......................................................2 1.1 Requirement Language ...........................................4 2 Assumption for a minimum host .....................................4 2.1 Hardware configuration .........................................4 2.2 Transition technology from IPv4 ................................4 2.3 Multicast ......................................................4 2.4 Anycast ........................................................5 2.5 API ............................................................5 2.6 Management functions ...........................................5 2.7 Security .......................................................5 3 IPv6 minimum specification ........................................5 3.1 Internet Protocol, Version 6 (IPv6) Specification ..............5 3.1.1 Hop-by-Hop Options Header ..................................6 3.1.2 Routing Header .............................................6 3.1.3 Fragment Header ............................................6 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 ............................8 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 4 IPsec minimum requirement ........................................11 4.1 Consideration of security for LCNAs ...........................11 4.2 IPsec specification ...........................................12 4.3 How to setup secure communication path ........................12 4.4 Key exchange specification ....................................13 5 Open Issues ......................................................13 5.1 How to promote IPsec minimum specification ....................13 5.2 Network-boot devices ..........................................13 5.3 Management facilities for LCNAs ...............................14 5.4 Is SA parameter setup capability mandatory ? ..................14 6 Security Considerations ..........................................14 7 References .......................................................14 8 Acknowledgements .................................................15 9 Authors' Addresses ...............................................16 1. Introduction Currently, several IPv6-supporting commercial equipments and protocol stacks, which are targeting non-PC embedded systems, has already been announced [1][2]. Also, the deployment of IPv6 for various non-PC platforms is being experimented [3]. There might be another configurations for IPv6 embedded devices, which have different design policies, physical shapes, and restriction conditions for the implementation. Though current PC usually manyfolks [Page 2] Internet Draft Min.Req. of IPv6 for LCNA November 2001 supports 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 problem for implementing whole IPv6/IPsec functions. In case of consumer equipments such as home appliances, the network functions have to be realized with lowest cost. Therefore, in order to realize compact implementations, we have to limit the mandatory IPv6 specification. In this draft, our target is the non-PC embedded appliances with the following conditions, which are called "Low Cost Network Appliance (LCNA in short hereafter)". * A device that has no generic functionalities, but only has a specific function. * A device that has network functionality, but the cost and resource dedicated for the network function is very limited. * A device that is a host, not a router. Examples of LCNAs that might be available in near future are consumer appliances such as game-machines, AV equipments, sensors, digital cameras, LCD projectors, and home appliances such as refrigerators and microwave ovens. There was a comment that cellular phones are also a kind of LCNAs. But as we have to also consider special networks for cellular phones with richer network functions, cellular phones are a little different from our target (consumer) devices. So, we omit them from our target (see [4] for IPv6 specification of cellular hosts). Table 1. Resource restriction 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 | ===============+===============+==================+======= + Considering the above, we will propose IPv6/IPsec minimum requirement specification in this draft based upon the following policy. - This specification regulates the baseline for guaranteeing that manyfolks [Page 3] Internet Draft Min.Req. of IPv6 for LCNA November 2001 IPv6 compliant LCNAs can communicate with minimum safety. That is, if it complies this spec, it is guaranteed that it can communicate with another devices securely if connected by IPv6. - We do not assume equipment that has specific usage model. 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 only notify it as optional function for a specific usage model. Therefore, in order for adopting this specification to various implementations, it is necessary to classify the usage style, communication mode, communication contents, network mobility, actual usage model, then to select the optimal combination of items for each implementation, which is the future works. 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 On 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. Those 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 5.1). 2.2 Transition technology from IPv4 Transition from IPv4 is an important topic on deploying the minimum hosts, but we will omit it on this draft. Therefore, we will consider communications over pure IPv6 networks. For long-term perspective, the goal is to realize the interconnection with IPv4 networks, but it does not mean that the operation of minimum hosts relies on the existence of translators and/or NATs. 2.3 Multicast Multicast is not treated in this draft, and it is the candidate for manyfolks [Page 4] Internet Draft Min.Req. of IPv6 for LCNA November 2001 further study (RFC 2375[8], RFC 2710[9]). However, the multicast related to neighbor discovery is considered. 2.4 Anycast A minimum host does not assign anycast addresses to its own interface (RFC 2526[10]). A minimum host might use 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, Socket API will be expanded with vendor specific manner, or Java API layer can hide them. Therefore, these APIs are out of scope in this draft. 2.6 Management functions In this draft, the functions for managing LCNAs via network are out of scope. But this is very important and has to be listed in future study items (See 5.2). 2.7 Security In Section 4 "IPsec minimum requirement", we will regulate a baseline for guaranteeing that a minimum host can communicate securely. However, DOS and intrusion are out of scope. So, we have to consider defensing 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. 3. IPv6 minimum specification In the following sections, we will explain minimum requirements according to each related RFCs and Internet Drafts. 3.1 Internet Protocol, Version 6 (IPv6) Specification (RFC 2460[18]) As for extension headers, a minimum host only supports minimum necessary function. 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 4.2 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 extension headers receiving process is as follows, - When the node receives unsupported extension headers, it MUST returns ICMP Parameter Problem Message (Type=1, 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. manyfolks [Page 5] Internet Draft Min.Req. of IPv6 for LCNA November 2001 As it is assumed that minimum host does not need extension header function, it MAY omit order check of extension headers. This is also based on RFC2360 [20] principle. 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 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 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 have to forward the packet to the next intermediate node, even when the node is a host. But in case of minimum host, this forwarding MAY be omitted and be treated as unsupported extension header, because only intermediate nodes (such as routers) and a destination node have to interpret this header. One exception is when the minimum host support mobile node function of MIP6. As MIP6 uses Routing header, this header MUST be processed correctly. Another exception for sending this header is when using route optimization for communicating with MIP6 mobility agents. If route optimization is performed using binding update, the node MUST send packets with these extension headers. When Binding Update is implemented, it is necessary to understand destination option header also. 3.1.3 Fragment Header If a minimum host satisfies the following conditions, the host MAY not send this extension header, and MAY treat the one as unsupported header when receiving it. - For TCP, * By limiting the MSS advertised by itself less than the value that the total IP packet length becomes less than IPv6 minimum MTU, the fragmentation of TCP packet from the correspondent is prevented. * By replacing the MSS advertised by the correspondent to the value that the total IP packet length becomes less than IPv6 manyfolks [Page 6] Internet Draft Min.Req. of IPv6 for LCNA November 2001 minimum MTU, the minimum host limits the size of sending TCP packets. - For UDP, * The application that might receive IP packets with the size bigger than IPv6 minimum MTU from the correspondent is not supported. Typical example of this application is NFS. * The application that sends UDP packet from its side has to do the tuning in order to limit the IP packet length 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 on memory then performs the reassemble processing. So it consumes large memory area. As the memory area if a minimum host is so limited, that the reassemble processing for the fragmented packets is one of the items that the designer wants to omit. However, it is not proper way not to implement the functionality without a kind of mechanism that restrains fragmented packets because of serious performance degradation. In IPv6, minimum MTU is specified as 1280 bytes, and the packet smaller than that is not fragmented. So, when communicating with TCP, if the advertised MSS (Max Segment Size) is set smaller, the receiver side can control the maximum size which can be used for sender's payload. By using this mechanism, we can reduce the frequency of the fragmentation (For example, if MSS is advertised as 1000 bytes, no fragmentation happen as long as the total size of IP header and extension headers does not exceed 280 bytes). On the other hand, because UDP does not have packet size control mechanism like TCP, the receiver side has no ways to force the sender to limit the packet size less than IPv6 minimum MTU. Therefore, returning ICMPs and discarding packets might happen. There are several services that might send UDP packets with large payload size, such as DNS and NFS. In general, DNS payload is less than 512 bytes. But in 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 transport protocol, and the issue is avoided. Typical UDP payload size for NFS is kilobytes order. So if a minimum host implements NFS service using UDP as transport protocol (not TCP), the reassemble of IP packets is necessary. [Sending] For sending packets, if an minimum host limits the sending packet size less than IPv6 minimum MTU (1280 bytes), it will delivered to final destination without any fragmentation, and the processing of fragment header is not necessary on sender side. Also the management of path MTU for each destination can be omitted, which can reduce memory consumption. In case of TCP, by replacing the received MSS to IPv6 minimum MTU, the minimum host can control the size of sending packets less than 1280 bytes. But in case of UDP, the manyfolks [Page 7] Internet Draft Min.Req. of IPv6 for LCNA November 2001 packet size is determined in 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 performs processing according to the options and option numbers in it. For sending, if minimum host need to communicate with mobility agents using binding update function of MIP6, it MUST interpret this extension header of received packets. And the minimum host MUST send packets with this extension header. Also, as stated in 3.1.2, minimum host that can interpret binding update function MUST send packets with routing header. 3.1.5 No Next Header This header is only interpreted but has no actions. 3.2 Path MTU Discovery for IP version 6 (RFC1981) [21] An implementation that conforms 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 the length less than minimum MTU and packet fragmentation must not happen. Therefore, even if it received ICMP Too Big Message, it can handle that as an error. 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 the 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 to have multiple interfaces. When an LCNA is assumed to have multiple interfaces, the following consideration and implementation is necessary, which requires more resources. - Source address selection - Kinds of routing information (such as destination cache and manyfolks [Page 8] Internet Draft Min.Req. of IPv6 for LCNA November 2001 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 neighbor discovery function. As neighbor discovery is mandatory in IPv6, it is always implemented. Therefore, DAD has almost no impact for resource usage, so basically all functions of DAD SHOULD be implemented. RFC2462 [23] does not mention anything about PPP, but basically everything SHOULD be implemented, because DAD is heavily dependent with neighbor discovery and neighbor discovery is also mandatory on 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 router MAY be omitted (Table 2). Basically, ICMPs for Echo Request/Reply and minimum error reporting MUST be supported. 3.6 IP Version 6 Addressing Architecture (RFC 2373) [25] By defaults, 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. - 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 message - 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 manyfolks [Page 9] Internet Draft Min.Req. of IPv6 for LCNA November 2001 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 which is not supported in current IPv6 autocofiguration is automatic discovery of DNS server. On this topic, discussions are ongoing in IETF IPNG WG. If a standard is fixed, it might become mandatory item for minimum hosts. AAAA record is defined for transform from IPv6 name to IPv6 address. So, AAAA is currently mandatory for minimum hosts name resolution. Also, A6 record is currently proposed and discussed in IETF for an alternative of AAAA record. So we need to check how it goes. If a minimum host is a passive node, it will not become an initiator of the communication, which means that automatic discovery of DNS server and name resolution MAY be omitted (the implementation of manyfolks [Page 10] Internet Draft Min.Req. of IPv6 for LCNA November 2001 resolver can be omitted on a passive node). On the other hand, if a minimum host is an active node, DNS name resolving is necessary. In such cases, automatic DNS server discovery SHOULD be implemented. 4. IPsec minimum requirement Considering the restriction of resource on minimum hosts, we have regulated a subset of IPsec specified in RFC2401 [28] as follows, which is called "minimum security specification". 4.1 Consideration of security for LCNAs 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. But we have to consider whether this regulation works well in actual implementations of various appliances. Currently, there are several issues that prevents from realizing security even if IPsec minimum specification is implemented. The first issue is the network environment. In order to deploy minimum hosts on current network environment, we cannot neglect existing IPv4 networks. So, we have to assume NAT or IPv4/IPv6 translators between the minimum host and the correspondent host. Current IPsec cannot handle such a situation, which means the effectiveness of security mechanism relying upon IPsec is very limited. Another issue is the cost-performance of minimum hosts. Because the resource of minimum hosts is so limited that there might be a class of appliances that cannot perform IPsec processing by itself. Enhancing the performance increases the cost of the appliance, so that decision is very severe from the business perspective. If IPsec is not working as generic security solution, the cost increase caused by implementing IPsec on the appliance might not be accepted. When using 8 bit CISC CPU, for example, the encryption processing is too heavy no matter whether it is the symmetric key encryption or asymmetric key encryption. We have experienced a case that it took about 30 seconds for SSL handshake when SSL web server is operated upon 8-bit CPU. This might be a typical number for the load of asymmetric key processing and might be a reference of usability. Also the load for symmetric key encryption is not neglectable. On the same system, when we turned on UDP checksum, the throughput of packet degraded about 1 millisecond. The tick time of the OS on this system is 2 milliseconds, so UDP checksum calculation consumes about 50 % of the tick time. This result implies that the symmetric key encryption processing inside OS is very tough without any hardware supports. Considering the above two issues, there are two different approaches for treating IPsec minimum specification of LCNAs. - 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 manyfolks [Page 11] Internet Draft Min.Req. of IPv6 for LCNA November 2001 realize that even if it is hard to deploy. Therefore, it is CORRECT to regulate IPsec minimum specification as mandatory. - Even though we regulates minimum IPsec mandatory, nobody use that because there are no perspectives to deploy it in real world. Therefore, it is WRONG to regulate IPsec minimum specification as mandatory. When IPv6 is widely used in the Internet, the number of LCNAs must become very huge. So, if we do not regulate the framework of LCNA's security, there might be lots of adhoc security implementations for LCNAs, which must be an obstacle for end-to-end communication principle of IPv6. But we will not consider this problem in detail in this draft. Therefore, it is very important for the future of the Internet to make a consensus on this discussion. 4.2 IPsec specification RFC2401 [28] assumes lots of communication modes. However, in this draft, we will focus on only the communication between minimum hosts using IPv6 transport mode. Communication using security gateway is out of scope. IPSec for multicast is out of scope because the discussion of multicast key exchange has just begun in IETF. Anycast is also out of scope because detail is not fixed yet. There are several proposals for IPSec MIB and IPSec specific ICMP but not standardized yet, so they are out of scope either. For security protocol, ESP [19] MUST be implemented. If the encryption of payload is NOT needed (but the authentication is necessary), NULL algorithm can be used. Authentication data MUST be implemented. Padding MUST be sequential. Because the usage of IPv6 extension headers is limited in section 3, authentication header (AH [29]) MAY be omitted from minimum security specification. For encryption algorithm, AES with 128 bit key length MUST be implemented. CBC [30] MUST be supported for IV mode. For authentication algorithm, HMAC-SHA2-256 MUST be implemented. Other algorithms MAY be implementation-dependent. RFC2401[28] specifies mandatory SA parameters to be implemented. However, the items dependent with the specifications which are regulated as unnessesary in this draft MAY be omitted. For example, because only transport mode is supported in this draft, the management of IPsec mode MAY be omitted. If automatic key exchange is not implemented, the parameters for key lifetime MAY also be omitted. When automatic key exchange is implemented, key lifetime has to be included as SA parameter. The specification of key lifetime with transmitted byte count is ambiguous and SHOULD NOT be implemented. 4.3 How to setup 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 each other. 2. Security association (SA) is setup by exchanging SA parameters by manyfolks [Page 12] Internet Draft Min.Req. of IPv6 for LCNA November 2001 secure manner negotiated by the two nodes. 3. Communication is performed using the setup SA. We call step 1 and 2 "Key exchange". On current IPsec specification, two type 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 old SA is also done by the same sequence automatically. (b) Manual Key Exchange The administrators of hosts exchange SA parameters by some methods, and SAs are setup by some means (such as commands). The renewal of old SAs is done by the administrator using the same methods. 4.4 Key exchange specification 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 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 purpose and is not suitable for low-power minimum hosts. Also the description of exception handling is ambiguous, which makes interoperability of IKE implementations serious problem. Also, it is pointed out that IKE is vulnerable to DOS attacks [33]. Considering these situations, currently more lightweight algorithms are discussed in IETF. These algorithms are expected to be suitable for minimum hosts. Also in some cases, key distribution center (KDC) model might be applicable for them. 5. Open Issues In this section, we will summarize items to be cosidered in future study. 5.1 How to promote IPsec minimum specification First of all, as mentioned in 4.1, there is an issue whether the IPsec minimum specification will be used for all LCNAs' implementations that have severe resource restriction. In order to resolve this issue, we have to perform a promotion like interoperability events or make an reference implementation open to public. Part of these activities is currently implemented by TAHI group in WIDE project. 5.2 Network-boot devices The function for booting from network with tftp or else is out of scope in this draft. This boot code works on very limited ROM area, and might need specially limited specification. But generally such devices are designed for special purpose and might need another manyfolks [Page 13] Internet Draft Min.Req. of IPv6 for LCNA November 2001 implemetation guideline. 5.3 Management facilities for LCNAs When LCNAs are commonly used, there are lots of LCNAs upon home network. In such a case, 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 requirement for LCNA management first. For example, the traffic measurement, which is useful for router management, may not be necessary on LCNAs. 5.4 Is SA parameter setup capability mandatory ? On current IPsec, it is mandated that users can setup SA parameters by some means. However, in case of very low-cost (one-time used) minimum host, SA parameters might be hard-coded and users need not setup. We need to consider whether this SA parameter setup capability is mandatory or not in LCNAs. 6. Security Consideration RFC3401 [34] proposes the enhancement of privacy by randomizing the interface-ID part of IPv6 addresses. If this facility is necessary, the manual key exchange mandated in this draft cannot be used as it is, and we need to consider some alternatives (such as automatic key exchange). As mentioned in 2.7, DOS and intrusion are out of scope in this draft. In this draft, only manual key exchange is mandated for LCNAs. But in some class of appliances, the IPsec parameters setup at the shipping time might be used until the appliance is disposed. In such a case, if the lifetime of the appliance is very long, we have to evaluate whether the SA algorithm and key-length set up initially are strong enough considering the all packets counts sent/received. But this evaluation is not done in detail. Also there is a method that the IPsec parameters are refreshed every fixed interval, but this is also dependent to the node API, and it is not covered in this draft. In this draft, IPsec API is implementation dependent, but it must not have any security holes. About this type of implementation issues, please refer to RFC2401[28] "2.2 Caveats and Assumptions". 7 References [1] InternetNode Inc. http://www.i-node.co.jp/ [2] ACCESS CO., LTD. http://www.access.co.jp/ manyfolks [Page 14] Internet Draft Min.Req. of IPv6 for LCNA November 2001 [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) [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. 8 Acknowledgements The authors would like to thank Nobumichi Ozoe, Yukiyo Akisada, Masahito Endo of Yokogawa Electric Corporation and Tadamichi Matsuyama, Kiyoshi Inoue of SOUM Corporaton for there comments and input. manyfolks [Page 15] Internet Draft Min.Req. of IPv6 for LCNA November 2001 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. 9 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 Shoichi Sakane Yokogawa Electric Corporation IT Product Division 2-9-32 Nakacho, Musashino-shi, Tokyo, 180-8750 Japan Phone: +81-422-52-6413 Fax: +81-422-52-6426 E-mail: sakane@kame.net Hiroshi Miyata Yokogawa Electric Corporation IT Product Division 2-9-32 Nakacho, Musashino-shi, Tokyo, 180-8750 Japan Phone: +81-422-52-6413 Fax: +81-422-52-6426 E-mail: H.Miyata@jp.yokogawa.com Jirou Sajiki Yokogawa Electric Corporation IT Product Division 2-9-32 Nakacho, Musashino-shi, Tokyo, 180-8750 Japan Phone: +81-422-52-6413 Fax: +81-422-52-6426 E-mail: Jirou.Sajiki@jp.yokogawa.com 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 Masahiro Ishiyama manyfolks [Page 16] Internet Draft Min.Req. of IPv6 for LCNA November 2001 Toshiba Corp. R&D Center 1 Komukai-Toshiba-cho, Saiwai-ku, Kawasaki 212-8582 JAPAN Phone: +81-44-549-2238 Fax: +81-44-520-1806 E-mail: masahiro@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 ACCESS CO., LTD, Basic Development Dept. Hirata-bld, 2-8-16 Sarugaku-cho Chiyoda-ku, Tokyo, 101-0064, Japan Phone: +81-3-5259-3809 Fax: +81-3-5259-3598 E-mail: kay@v6.access.co.jp 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 manyfolks [Page 17]