Network Working Group Steven M. Bellovin Internet Draft AT&T Labs Research Expiration Date: May 2003 November 2002 Access Control Prefix Router Advertisement Option for IPv6 draft-bellovin-ipv6-accessprefix-00.txt 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. Abstract Some very low-end devices are expected to rely on address-based authentication, even though that is not a high-security mechanism. In particular, they may wish to permit access by "local" peers only, for some value of "local". This memo proposes a new Router Advertisement option to supply a list of privileged prefixes. Bellovin [Page 1] Internet Draft draft-bellovin-ipv6-accessprefix-00.txt November 2002 1. Introduction Some very low-end devices may rely on address-based authentication, even though that is not a high-security mechanism [Bell89]. In particular, they may wish to permit access by "local" peers only, for some value of "local". This desire was one of the rationales for site-local addresses [RFC2373]. But site-local addresses have a number of disadvantages. Though most are out of scope for this document, one is important: not only is "site" ill-defined, its instantiation in any given installation may not match the desired security property. For example, a university dormitory may wish to restrict access to its printers to residents, but the "site" may include the entire campus. Explicitly-configured filters could accomplish the same thing, of course. But printers can be painful to configure via a limited menu interface; lower-end devices, such as Internet-connected light switches and toasters, are even harder to administer. An easy-to- administer autoconfigure mechanism is essential. The solution is to have routers announce the proper access control prefix via an option in the Router Advertisement message [RFC2461]. Devices that care can interpret and obey this option. To allow for different access policies even for devices on the same link, multiple classes of access control prefix may be announced. 1.1. Terminology 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 [RFC2119]. 2. Prefix Option 2.1. Syntax The access control prefix option follows the format given in Section 4.6 of [RFC2461]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length | Class | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bellovin [Page 2] Internet Draft draft-bellovin-ipv6-accessprefix-00.txt November 2002 | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [To be assigned] Length 3 Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. Class Prefix class. Devices MAY be configured to use access control prefixes only in certain classes. Class 0 is the default class; all devices not otherwise configured SHOULD use prefix class 0. Prefix class 255 is reserved for the link- local prefix; see below. All devices MUST obey class 255. Lifetime 32-bit unsigned integer, giving the valid lifetime of this prefix, in seconds. At the end of the validity interval, all access rights granted by this prefix MUST be deleted. A value of 0 indicates unlimited lifetime. Prefix An IP address or a prefix of an IP address. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. 2.2. Router Behavior A suitably-configured router MAY include one or more access control prefix announcements in its Router Advertisement messages. If more than one prefix is announced for a given class, communication is permitted with all such prefixes. If possible, routers SHOULD send out the same, consistent set of prefixes in each message. If that is not possible (i.e., because of packet size limitations), additional Advertisement messages should be sent as soon as is possible consistent with congestion control Bellovin [Page 3] Internet Draft draft-bellovin-ipv6-accessprefix-00.txt November 2002 principles. Bear in mind that the typical target devices for this feature are low-end, and will have neither very much buffering nor the ability to service incoming packets quickly. It is better to send all prefixes for a given class in a single message, to ensure consistent behavior. A router may revoke access to a prefix by sending a new advertisement with a very short lifetime. This SHOULD be done to old prefixes when changing allowable prefixes. 2.3. Device Behavior A device MAY be configured to use access control based on prefix advertisements. If a device is configured in this fashion, it MUST listen for access control prefix announcements. Devices MAY be configured to use more than one prefix class. Incoming packets whose source address does not match one of the permitted prefixes MUST be discarded without further processing, even if they are acceptable via other security mechanisms. Devices MUST NOT send packets to any destination whose address does not match one of the allowed prefixes. Inbound or outbound packets dropped by these rules SHOULD be noted in the appropriate MIB or other auditing mechanism. By default, devices SHOULD be preconfigured to think that they have received an advertisement for Class 255, Prefix fe80::/10, lifetime unlimited. This is the link-local prefix; it must be allowed initially to permit devices to receive their initial access control configurations. Routers MAY override this class; note that if such an advertisement ever expires, the device will not be able to receive any further link-local messages, including further access control prefix announcements. At that point, manual intervention will probably be required. In their default configuration, devices MUST NOT accept packets from any non-link-local prefixes until they have received suitable advertisements. However, there MAY be a configuration option to permit acceptance of packets with the current link's prefix. Access control prefix announcements apply only to the interface on which they are received. Multi-homed devices generally should receive such messages on each interface, with the obvious exception of the local loopback interface. Nothing in this specification prevents devices from using access control prefix announcements as a supplementary mechanism. In such configurations, the obligations to drop or block packets do not Bellovin [Page 4] Internet Draft draft-bellovin-ipv6-accessprefix-00.txt November 2002 apply. 3. Open Issues The biggest open issue is whether or not this option should exist. It is not a substitute for real security. Beyond that, we may wish to simplify it. Should the class mechanism exist? Does it add too much complexity? What about the lifetime? Should multiple prefixes within a class be permitted? If we delete all of these feature, we are left with a mechanism by which one prefix can be specially blessed, for all dumb devices on the network. That may suffice. 4. IANA Considerations A new IPv6 Neighbor Discovery option type code must be assigned. 5. Security Considerations This mechanism should not be confused with a real security mechanism, such as IPsec [RFC2041]. If at all possible, cryptographic security mechanisms should be used instead of this option. Among the the threats are packets with forged source addresses. Routers may be able to filter packets that, based on their source address, cannot legally arrive on some interface; they SHOULD do so for any prefixes that have privileged access. But it is generally trivial for hosts on a LAN to forge the source address of some other, more trusted host on that LAN. Access control prefixes cannot defend against this sort of attack. It's even possible to impersonate the advertising router. To guard against this, nodes implementing the access control prefix option MUST take special care to validate Router Advertisement options according to Section 6.1.2 of [RFC2461]. Bellovin [Page 5] Internet Draft draft-bellovin-ipv6-accessprefix-00.txt November 2002 6. References [Bell89] "Security Problems in the TCP/IP Protocol Suite", S.M. Bellovin, Computer Communications Review 19:2, April 1989. [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", S. Bradner. RFC 2119. March 1997. [RFC2401] "Security Architecture for the Internet Protocol", S. Kent and R. Atkinson, RFC 2401, November 1998. [RFC2373] "IP Version 6 Addressing Architecture. R. Hinden and S. Deering. RFC 2373. July 1998. [RFC2461] "Neighbor Discovery for IP Version 6 (IPv6)", T. Narten, E. Nordmark, W. Simpson. RFC 2461. December 1998. 7. Author Information Steven M. Bellovin AT&T Labs Research Shannon Laboratory 180 Park Avenue Florham Park, NJ 07932 Phone: +1 973-360-8656 email: bellovin@acm.org Bellovin [Page 6]