INTERNET-DRAFT Erik Nordmark, Sun Microsystems March 9, 2000 IPv6 hooks for AAA registration and "host routing" Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet Draft expires September 9, 2000. Abstract This document specifies extensions to IPv6 Neighbor Discovery that allow routers to ask hosts to periodically register. Two types of registrations are defined: to register with an AAA server using an AAA protocol, and to register with the routers using unsolicited Neighbor Advertisement messages to allow hosts to move between some links while keeping the same IPv6 address. In the latter case the routers would use the registrations to inject host routes in a "local area". The purpose of this document is to stimulate discussion on how to make IPv6 a good choice for wireless networks that have requirements on "local" mobility and/or AAA functionality. draft-nordmark-ipv6-aaa-hooks-00.txt [Page 1] INTERNET-DRAFT IPv6 hooks for AAA and "host routing" March 2000 Contents Status of this Memo.......................................... 1 1. Introduction and Motivation.............................. 3 1.1. "Host Routing"...................................... 3 1.2. AAA hooks........................................... 3 2. Terminology.............................................. 4 2.1. Requirements........................................ 4 3. Protocol Overview........................................ 4 4. Registration Request Option Format....................... 5 5. Router Configuration Variables........................... 7 6. Host Conceptual Variables................................ 8 7. Receiving Router Advertisement messages.................. 8 8. Unsolicited Neighbor Advertisement Registrations......... 9 9. Radius Registrations..................................... 10 10. AAA Registrations....................................... 10 11. Security Considerations................................. 10 12. Open Issues............................................. 11 References................................................... 11 Author's Address............................................. 12 draft-nordmark-ipv6-aaa-hooks-00.txt [Page 2] INTERNET-DRAFT IPv6 hooks for AAA and "host routing" March 2000 1. Introduction and Motivation 1.1. "Host Routing" The neighbor discovery specification [DISCOVERY] specifies mechanism by which the routers can associate a single prefix (e.g., a /64 prefix) with more than one link. This is accomplished by the routers advertising "addrconf" prefixes but no "on link" prefixes i.e. the prefix options would have the Autonomous flag set and the on-link flag clear. Such advertisements allow the hosts to autoconfigure using stateless address autoconfiguration [ADDRCONF] but the hosts do not treat any destination addresses as on-link; instead the hosts will initially send all packets to a default router. If the destination is on-link at any given time the router has the option to send a Redirect message informing a host to send packets directly to the destination. This mechanism was intended to allow a configuration option where a subnet prefix is used across multiple links. However at least two pieces are missing: o How do the routers know which hosts reside on which links at any given time? The routers need to know this so that they can efficiently route datagrams destined to hosts in the subnet prefix. o How does Duplicate Address Detection work in such a configuration? A duplicate address might exist on a different link but in the same subnet prefix. This document addresses the former issue but not the latter. 1.2. AAA hooks In some environments there is a need to have Authentication, Access control, and/or Accounting but there is currently no protocol mechanism by which a host (e.g. a roaming or mobile host) knows o Whether or not AAA is required on a given link. o Which protocol to use for AAA. There is active work to extend the Mobile IPv4 protocol [MIPv4] to piggyback AAA on the Mobile IP registration messages and have the draft-nordmark-ipv6-aaa-hooks-00.txt [Page 3] INTERNET-DRAFT IPv6 hooks for AAA and "host routing" March 2000 Foreign Agents use this information to interact with AAA servers. Such an approach is not possible in Mobile IPv6 [MIPv6] since there is no concept of a foreign agent. Furthermore, there might be need for AAA interaction even in cases where the hosts are not using Mobile IP; AAA might be needed e.g. to authenticate users to get access to the ability to send and receive IP packets. Thus there are some advantages to separating out the AAA component from Mobile IP (and there might be some disadvantages as well). Note that for certain types of links the AAA functionality might be best deployed at the link layer instead of at the IP layer. Independent of this IPv6 is currently viewed as deficient in the Mobile IP context due to a lack of AAA hooks. This specification introduces a common mechanism that can be used by routers to request that hosts on a link register using some form of "registration protocol". This is done by introducing a new Neighbor Discovery option. Unsolicited Neighbor Advertisement message serve as the registration protocol for the "host routing" functionality. The AAA protocol serves as the registration protocol for AAA functionality. Multiple registration protocols can be active at any time i.e. it is possible to combine the "host routing" functionality with the AAA functionality on the same link. 2. Terminology This documents uses the terminology defined in [IPv6], [DISCOVERY] and [MIPv6]. 2.1. Requirements 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 [KEYWORDS]. 3. Protocol Overview The protocol is based on each host maintaining a list of all the currently active registration requests. The routers advertise registration requests in Router Advertisement messages both periodically and when receiving a Router Solicitation. Each registration request has an associated lifetime so that the hosts can remove expired registration requests. The registration requests also contain a registration period indicating how often the hosts should perform a registration. For instance, the unsolicited Neighbor draft-nordmark-ipv6-aaa-hooks-00.txt [Page 4] INTERNET-DRAFT IPv6 hooks for AAA and "host routing" March 2000 Advertisement form of registrations are sent periodically. There can be multiple registration requests active at any given time. A registration request is uniquely identified by an identifying IPv6 address (typically a global IPv6 address) and the registration type. 4. Registration Request Option Format This specification defines a new Registration Request option for Neighbor Discovery. This option is used in Router Advertisement messages to make the hosts periodically register using the specified registration type. 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 | Registration Request Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Regist. Type | Registration Period | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Registrar Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Identifying Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type 8-bit identifier of the type of option. Value TBD. Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. Always 5 for this option. Registration Request Lifetime 16-bit unsigned integer. The length in time in draft-nordmark-ipv6-aaa-hooks-00.txt [Page 5] INTERNET-DRAFT IPv6 hooks for AAA and "host routing" March 2000 seconds that the registration request should be retained by the hosts. Registration Type 8-bit field specifying which protocol the hosts should use to register. The following types are defined in this document: Unsolicited Neighbor Advertisement 1 Radius 2 AAA 3 Registration Period 24-bit unsigned integer. The maximum time measured in milliseconds that should elapse between the periodic registrations by the client. The maximum value (0xFFFFFF) corresponds to approximately 4.7 minutes. [TBD: 4.7 minutes is very short. Need to grow option to carry 32 bit numbers or make the unit be in seconds instead of milliseconds.] The first registration for a new Registration Request is randomized over a short time period - 3 seconds. Subsequent periodic registrations are heavily randomized to avoid synchronization. The start time for each registration event is determined by drawing a uniformly distributed random number between .3 and 1.0 times the Registration Period and adding that to the time when the previous registration event was started. Registrar Address 128-bit IPv6 address. The address with which the hosts should register. Identifying Address 128-bit IPv6 address. An IPv6 address which together with the registration type uniquely identifies the registration request. draft-nordmark-ipv6-aaa-hooks-00.txt [Page 6] INTERNET-DRAFT IPv6 hooks for AAA and "host routing" March 2000 5. Router Configuration Variables A router MUST allow for the following conceptual variables to be configured by system management. The specific variable names are used for demonstration purposes only, and an implementation is not required to have them, so long as its external behavior is consistent with that described in this document. Default values are specified to simplify configuration in common cases. The default values for some of the variables listed below may be overridden by specific documents that describe how IPv6 operates over different link layers. This rule simplifies the configuration of Neighbor Discovery over link types with widely differing performance characteristics. For each multicast interface there is a (possibly empty) list of Registration Requests. Each Registration Request is associated with: AdvRegistrationType The type of registration which is placed in the Registration Type field in the option. Default: not set AdvRegistrationRequestLifetime The value to be placed in the Registration Request Lifetime field of the option. Default: TBD [Perhaps different for different registration types.] AdvRegistrationPeriod The value to be placed in the Registration Period field of the option. Default: TBD [Perhaps different for different registration types.] AdvRegistrarAddress The value to be placed in the Registrar Address field of the option. AdvIdentifyingAddress The value to be placed in the Identifying Address field of the option. draft-nordmark-ipv6-aaa-hooks-00.txt [Page 7] INTERNET-DRAFT IPv6 hooks for AAA and "host routing" March 2000 6. Host Conceptual Variables This document makes use of internal conceptual variables to describe protocol behavior and external variables that an implementation must allow system administrators to change. The specific variable names, how their values change, and how their settings influence protocol behavior are provided to demonstrate protocol behavior. An implementation is not required to have them in the exact form described here, so long as its external behavior is consistent with that described in this document. Hosts will need to maintain the following pieces of information. Like the prefix related information specified in [DISCOVERY] this information maintained per interface. Registration Request List A list of the registration requests that have been received in Router Advertisement messages that have not yet timed out. Each entry has an associated expiration timer value (set based on the Registration Request Lifetime) used to expire old entries, and a randomly selected registration period timer. An entry on the list is uniquely identified by the Identifying Address and the Registration Type in the received option. 7. Receiving Router Advertisement messages When a host receives a router advertisement message that contains one or more Registration Request options it performs the following operations for each instance of the options: o Look for a matching (same Identifying Address and same Registration type) entry in the conceptual RR List for the interface. o If none is found and the Registration Request Lifetime is non-zero create an entry and initialize it based on the content of the option. Initiate a registration event after a short random delay as specified in Section 4. o If an entry exists and the received Registration Request Lifetime is zero immediately expire the entry. draft-nordmark-ipv6-aaa-hooks-00.txt [Page 8] INTERNET-DRAFT IPv6 hooks for AAA and "host routing" March 2000 o Otherwise update the entry based on the content of the option setting the expiration timer to the received Registration Request Lifetime. When the expiration timer fires the entry is removed from the List. If the particular registration protocol supports de-registration it SHOULD be invoked when an entry is expired. When the randomized registration period timer fires a new registration event is initiated and a new randomized period timer value is calculated as specified in Section 4. 8. Unsolicited Neighbor Advertisement Registrations The following recommendations apply when using this mechanism with registration type 1. The routers should all be configured with the AdvRegistrarAddress being the all-routers multicast address with link scope. (ff02::2) The routers should set the AdvIdentifyingAddress to be a global address (or site-local address if no global addresses are in use) for a router on the link. This address is selected by picking the numerically largest IPv6 address (comparing in network byte order) assigned to the routers on the link. This process can be automated using information already present in the routing protocol. All routers on the link MAY send Registration Request options in their Router Advertisement messages (all using the same designated AdvIdentifyingAddress) but the sending of these options MAY also be limited to the router with the above numerically largest IPv6 address. The above recommendations ensure that all routers on the link receive the unsolicited neighbor advertisement messages. They also ensure that when a host moves to a different link it will detect that fact by receiving options with a different identifying address causing it to immediately (subject to small random delay) send unsolicited neighbor advertisements. The hosts send unsolicited neighbor advertisements using the rules in Section 7.2.6 in [DISCOVERY]. The first registration event SHOULD send MAX_NEIGHBOR_ADVERTISEMENT unsolicited neighbor advertisements, but subsequent period events SHOULD send only one advertisement. draft-nordmark-ipv6-aaa-hooks-00.txt [Page 9] INTERNET-DRAFT IPv6 hooks for AAA and "host routing" March 2000 9. Radius Registrations The following recommendations apply when using this mechanism with registration type 2. The routers should all be configured with the AdvRegistrarAddress being an address on a Radius server in the administrative domain. The routers should set the AdvIdentifyingAddress to be a designated global address (or site-local address if no global addresses are in use) of the Radius server in the administrative domain. This ensures that when a host moves between administrative domains it will immediately (subject to small random delay) perform a registration when receiving the first router advertisement in the new domain. Remainder is TBD. [Radius] 10. AAA Registrations The following recommendations apply when using this mechanism with registration type 3. The routers should all be configured with the AdvRegistrarAddress being an address on an AAA server in the administrative domain. The routers should set the AdvIdentifyingAddress to be a designated global address (or site-local address if no global addresses are in use) of the AAA server in the administrative domain. This ensures that when a host moves between administrative domains it will immediately (subject to small random delay) perform a registration when receiving the first router advertisement in the new domain. Remainder is TBD. 11. Security Considerations Router Advertisements are not required to be authenticated and even if they are authenticated it is unclear whether or not there would be a mechanisms to verify the authority of a particular node to send Router Advertisements. Neighbor Discovery uses the rule of HopCount 255 (set to 255 on transmit and verified to be 255 on reception) to drop any Neighbor Discovery packets that are sent non-neighboring nodes. This limits draft-nordmark-ipv6-aaa-hooks-00.txt [Page 10] INTERNET-DRAFT IPv6 hooks for AAA and "host routing" March 2000 any attack using ND to the neighbors. The packets carrying Registration Request options, just like all other Neighbor Discovery protocol packet exchanges, can be authenticated using the IP Authentication Header [IPv6-AUTH]. A node SHOULD include an Authentication Header when sending Neighbor Discovery packets if a security association for use with the IP Authentication Header exists for the destination address. The security associations may have been created through manual configuration or through the operation of some key management protocol. Received Authentication Headers in these packets, just like all Neighbor Discovery packets, MUST be verified for correctness and packets with incorrect authentication MUST be ignored. Confidentiality issues are addressed by the IP Security Architecture and the IP Encapsulating Security Payload documents [IPv6-SA, IPv6- ESP]. 12. Open Issues This document does not specify how Duplicate Address Detection works when a subnet prefix is used across multiple links. References [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [DISCOVERY] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [ADDRCONF] S. Thomson, T. Narten, "IPv6 Address Autoconfiguration", draft-nordmark-ipv6-aaa-hooks-00.txt [Page 11] INTERNET-DRAFT IPv6 hooks for AAA and "host routing" March 2000 RFC 2462, December 1998. [IPv6-SA] R. Atkinson. "Security Architecture for the Internet Protocol". RFC 2401, November 1998. [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 2402, November 1998. [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [MIPv6] D.B. Johnson, C. Perkins, "Mobility Support in IPv6", Internet Draft, draft-ietf-mobileip-ipv6-10.txt, March 2000. [MIPv4] C. Perkins, "IP Mobility Support", in IPv6", RFC 2002, October 1996. [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997. Author's Address Erik Nordmark Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303 USA phone: +1 650 786 5166 fax: +1 650 786 5896 email: nordmark@sun.com draft-nordmark-ipv6-aaa-hooks-00.txt [Page 12]