Internet-Draft Guillaume Bichot Category: Experimental THOMSON Document: draft-bichot-network- October 2002 discovery-protocol-00.txt Network Discovery Protocol (NDP) draft-bichot-network-discovery-protocol-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 [1]. 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. Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes the Network Discovery Protocol (NDP), a protocol that provides a way to broadcast information about the network service accessible through the access network where the information is broadcasted. This allows several service providers to share the same access network. The public WLAN access network is particularly targeted by this protocol. As a result a mobile terminal listening NDP announcements discovers whether its Service provider (Virtual WLAN operator) is supported by the WLAN it is currently attached. G. Bichot Expires April 2003 [Page 1] Internet-Draft Network Discovery Protocol (NDP) October 2002 Table of Contents 1. Introduction...................................................2 2. Model..........................................................3 3. Network announcement...........................................4 3.1 SAP potential usage........................................4 3.2 NDP announcement protocol..................................4 3.3 Transport protocol.........................................4 3.4 Announcement interval......................................5 4. Packet format..................................................5 5. Implementation.................................................8 6. Security Considerations........................................9 7. References.....................................................9 8. Acknowledgments................................................9 9. Author's Addresses.............................................9 10. Intellectual Property Statement..............................10 11. Full Copyright Statement.....................................10 1. Introduction The development of public data access network is growing. These networks mainly wireless (WLAN) offer the access to Internet, local services and potentially other core network (3G) services. Since it is impossible, for a customer to subscribe to all possible independent WLAN operators, some companies provide an aggregation of these WLAN hot spots. It Means that the subscriber of such service provider can access to the core network (Internet for instance) through several independent WLANs. Basically what a virtual network operator needs in the WLAN are: - A way to authenticate its subscribers - A way to connect the WLAN with the core network it offers the access to. The core network may be Internet. The service provider is then called a virtual network operator (indeed the service provider does not own neither the Internet nor the WLAN). Any organization can become a virtual network operator including public network operator (e.g. 3GPP). The core network may be any other network like a cellular (3GPP for instance) network. The network operator is then obviously the one who owns the core network. G. Bichot Expires - April 2003 [Page 2] Internet-Draft Network Discovery Protocol (NDP) October 2002 It is likely that several [virtual] network operators share a public WLAN access network. For instance, in a hot spot like an airport, the WLAN operator has an agreement with two virtual network operators in such a way the customers from both virtual network operators may access to their respective service (Internet access) through the airport WLAN. There is a need to announce (broadcast) in the access network such information about, basically, the availability of the [virtual] network operator and the information for accessing the core network (e.g. Internet). 2. Model The figure 1 illustrates the NDP model. A NDP controller has in charge to collect NDP announcement packets and multicast them within the public access network. The NDP announcement packet contains information relative to a [virtual] network operator and the type of network that can be accessed. The way the NDP packets are delivered to the NDP controller is out of scope of this document. The NDP controller may be located within the access network, within a third party operator/aggregator network or anywhere else. +-----------------+ +-----------------+ | | | | +--+ | | | | | | NDP | | I1 | | |MT|<------>| |--------| | | | | | | | | | | | | | +--+ | NDP | | Service | | Controller | | Provider | +-----------------+ +-----------------+ | | I2 | +-----------------+ | | | | | | | | | | | | | Service | | Provider | +-----------------+ G. Bichot Expires - April 2003 [Page 3] Internet-Draft Network Discovery Protocol (NDP) October 2002 Figure 1: The NDP model 3. Network announcement //The SAP protocol (RFC 2974) could be used to carry the announcements. However it is stipulates that a SAP listener shall support SDP (RFC 2327). Due to this constraint we have also defined a new announcement protocol based on SAP. Both options are possible. 3.1 SAP potential usage In case of the usage of SAP, the following constraints apply. - Session deletion is not supported - Encryption is not supported - The SAP announcer is located in the NDP controller. - The originating source field shall be empty - A new payload type is defined: 'application/NDP' 3.2 NDP announcement protocol This is the protocol to be used instead of SAP. NDP uses UDP/IP multicast in order to broadcast the information relative to the different network services. For each network service provider, announcements [packets] are sent regularly and continuously within the well-known multicast channel. IPv4 global scope network announcements use multicast addresses in the range 224.2.128.0 - 224.2.255.255 with NDP announcements being sent to IPv6 are announced on the address FF0X:0:0:0:0:0:2:7FFE where X is the 4-bit scope value. For example, an announcement for a link-local session assigned the address FF02:0:0:0:0:0:1234:5678, should be advertised on NDP address FF02:0:0:0:0:0:2:7FFE. NDP announcements MUST be sent on port and SHOULD be sent with an IP time-to-live of 255. The announcement contains the identity of the [virtual] network operator as well as some information regarding the network. The header MAY be signed. 3.3 Transport protocol G. Bichot Expires - April 2003 [Page 4] Internet-Draft Network Discovery Protocol (NDP) October 2002 NDP (or SAP) packets are carried over UDP / IP. 3.4 Announcement interval The time period between repetitions of an announcement is chosen such that the total bandwidth used by all announcements on a single NDP group remains below a preconfigured limit. Each announcement should have an equal announcement interval that will be fixed by the NDP controller. 4. Packet format The figure 2 represents an NDP announcement packet carried by the SAP packet. The SAP header as well as the payload type field is described in [1]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : SAP Header : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : payload type = : : 'application/NDP' : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Network Operator Name : : (Up to 256 bytes) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : realm name : : (Up to 64bytes) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network type | : (Up to 30 characters) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Payment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | : optional payload : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: SAP carries NDP packet The figure 3, represents an NDP announcement packet carried by the NDP announcement protocol. G. Bichot Expires - April 2003 [Page 5] Internet-Draft Network Discovery Protocol (NDP) October 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V=1 |L|R|R|R|C| Auth len | msg id hash | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Network Operator Name : : (Up to 256 characters) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Realm name : : (Up to 64 bytes) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network type | : (Up to 30 characters) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Payment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Optional authentication data | : .... : *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | | : Optional payload : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 NDP announcement protocol carries NDP packet V: Version Number. The version number field MUST be set to 1. L: Indicates whether the announcement relies to the access (local) network. If yes L is set to 1. Otherwise L is set to 0 R: Reserved. NDP announcers MUST set this to 0, NDP listeners MUST ignore the contents of this field. C: Compressed bit. If the compressed bit is set to 1, the payload is compressed using the zlib compression algorithm [3]. If the payload is to be compressed and encrypted, the compression MUST be performed first. Auth len: An 8 bit unsigned quantity giving the number of 32 bit words following the main NDP header that contain authentication data. If it is zero, no authentication header is present. Authentication data: containing a digital signature of the packet, with length as specified by the authentication length header field. G. Bichot Expires - April 2003 [Page 6] Internet-Draft Network Discovery Protocol (NDP) October 2002 Msg id hash: A 16 bits quantity that, used in combination with the real name, provides a globally unique identifier indicating the precise version of this announcement. The choice of value for this field is not specified here, except that it MUST be unique for each Network announcement by a particular NDP announcer and it MUST be changed if the announcement description is modified. Network operator name: this is the name of the operator of the [virtual] network. The network operator is a well-identified interlocutor for the customer, the client. The name is a bytes string that may contain any byte with the exceptions of 0x00 that is used to terminate the string. By default the byte string contains US-ASCII characters. Realm name: This gives the domain name the announcement relies on. This is a character string formatted according to [3]. One announcement relies on one real name. This means that an operator that wants to propose several different network accesses will use different real name and thus will generate several announcements: one per network access. The NDP listener may use the realm name to form the Network Access Identifier (NAI) as specified in [3]. Payment method: this 32 bits field identifies the method of payment that is accepted by the service provider. Each bit indicates whether the corresponding method is available (1) or not (0). The following values are defined. All 00: not identified: the accounting method is not identified 0x01 - pre-paid card: a pre-paid card from the provider may be used 0x02 - subscription: The services from that service provider are available only on subscription. 0x04 - credit card: the service may be paid online with a credit-card 0x08 - Free: the service(s) from that service provider is (are) free Network type: this identifies the type of network the provider offers the access. The field is a bytes string that may contain any byte with the exceptions of 0x00 that is used to terminate the string. By default the byte string contains US-ASCII characters. The following values are defined. 0x00: Null byte string: Not identified: the network type is unknown. "IN" - Internet access: The [virtual] network operator offers the access to the Internet. After being authenticated by the service provider, the client can access to the Internet. G. Bichot Expires - April 2003 [Page 7] Internet-Draft Network Discovery Protocol (NDP) October 2002 "3GPP" - 3GPP access: the [virtual] network operator offers the access to a 3GPP network. Authentication and all 3GPP services are managed through the 3GPP network according to a well-known method (e.g. 3GPP) or according to the specification of the 3GPP network operator as the service provider. "3GPP2" - 3GPP2 access: the [virtual] network operator offers the access to a 3GPP2 network. Authentication and all 3GPP services are managed through the 3GPP network according to a well-known method (e.g. 3GPP2) or according to the private specification of the 3GPP network operator as the service provider. "PRIVATE" - Private network: the [virtual] network operator offers the access to a private network. The name of this private network shall be present in the payload part. It will be the first byte string, terminated by the character 0x00. The byte string contains ISO-10646 characters in UTF-8 encoding. The header is followed by the optional payload data itself. If the C bit is set in the header the payload is compressed. 5. Implementation One context this protocol makes sense is the public WLAN. Two scenario are envisaged: - A mobile terminal (the NDP listener) discovers a set of access points and associates with one according to the WLAN specification (best signal strength for instance). It does not care about the SSID (or equivalent WLAN ID). Once the terminal is associated it listens the NDP announcements. The user [or the terminal if only one choice is possible) chooses the network operator he wants to deal with and triggers the authentication process. If no announcement is present, the terminal may try to associate with another access point belonging to another network (different SSID). If there is no other WLAN (SSID) or no announcement are present then NDP fails. - The mobile terminal can listens the NDP announcement before being associated with whatever access point (this is in theory possible. The terminal needs only to join/synchronize with an access point and it should be able to listen the multicast/broadcast packets). In case of several access points in range, the terminal listen the different announcement from the different access points. There may be several WLANs. The user (or the terminal if only one choice is possible) chooses the network operator he wants to deal with and triggers the association between the mobile terminal and the corresponding access point. G. Bichot Expires - April 2003 [Page 8] Internet-Draft Network Discovery Protocol (NDP) October 2002 In both cases, the mobile terminal may use the realm name (found in the announcement) as part of the NAI [3] in order to establish the AAA connection (EAP) with the host associated with the chosen [virtual] network operator. 6. Security Considerations NDP (as SAP) contains mechanisms for ensuring integrity of session announcements, for authenticating the origin of an announcement. In case of non-usage of the integrity protection mechanism some denial of service attacks are possible. - A Rogue NDP controller can floods the medium with wrong announcements. - A rogue NDP controller can spoof announcements by catching real announcements, modify them and forward them. Although in a wireless environment this type of attack is unlikely it may appear when the rogue controller (an access point in that case) has a better signal strength than the regular Controller (access point). The NDP listener would then prefer to listen the Rogue controller. A way to solve that problem is for the listener to listen several controllers (access points), one after the other, in order to compare the announcements. 7. References 1 Session Announcement Protocol, RFC 2974, October 2000. 2 Session Description Protocol, RFC 2327, April 1998. 3 Network Access Identifier, RFC 2486 8. Acknowledgments 9. Author's Addresses Guillaume Bichot THOMSON 2 independence way Princeton, NJ 08540 - USA Email: guillaume.bichot@thomson.net G. Bichot Expires - April 2003 [Page 9] Internet-Draft Network Discovery Protocol (NDP) October 2002 10. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. 11. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." G. Bichot Expires - April 2003 [Page 10]