Internet DRAFT - draft-bichot-network-discovery-protocol
draft-bichot-network-discovery-protocol
Internet-Draft Guillaume Bichot
Category: Experimental THOMSON
Document: draft-bichot-network- April 2003
discovery-protocol-02.txt
Network Discovery Protocol (NETDIS)
draft-bichot-network-discovery-protocol-01.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 (2003). All Rights Reserved.
Abstract
This document describes the Network Discovery Protocol (NETDIS), 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 NETDIS announcements discovers the list of Service
providers (Virtual WLAN operator) supported by the WLAN it is
currently attached.
G. Bichot Expires September 2003 [Page 1]
Internet-Draft Core Network Discovery Protocol (NETDIS) April 2003
Table of Contents
1. Introduction...................................................2
2. Model..........................................................3
3. Network announcement...........................................3
3.1 SAP potential usage........................................4
3.2 NETDIS announcement protocol...............................4
3.3 Transport protocol.........................................4
3.4 Announcement interval......................................4
4. Packet format..................................................5
5. Implementation.................................................9
6. Security Considerations.......................................10
7. References....................................................10
8. Acknowledgments...............................................10
9. Author's Addresses............................................10
10. Intellectual Property Statement..............................10
11. Full Copyright Statement.....................................11
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 service providers provide an
aggregation of these WLAN hot spots. They are also called virtual
operators. A subscriber of such virtual operator can access to the
core network (Internet for instance) through several independent
WLANs.
The core network may be Internet or a mobile (3G) network or other
private network. The WLAN virtual network operator may be the core
network operator.
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 core network operators may access
to their respective service (e.g. Internet) through the airport WLAN.
There is a need to announce (broadcast) in the access network such
information about, basically, the availability of the [virtual]
G. Bichot Expires - September 2003 [Page 2]
Internet-Draft Core Network Discovery Protocol (NETDIS) April 2003
network operator and the information for accessing the core network
(e.g. Internet).
2. Model
The figure 1 illustrates the NETDIS model. A NETDIS controller has in
charge to collect NETDIS announcement packets and multicast them
within the public access network. The NETDIS announcement packet
contains information relative to a [virtual] network operator and the
type of core network that can be accessed. The way the NETDIS
Announcer delivers the packets to the NETDIS Controller is out of
scope of this document. The NETDIS controller may be located within
the access network, within a third party operator/aggregator network
or anywhere else. The NETDIS Announcer may be located within the
access network, the core network, within a third party operator
aggregator or anywhere else.
+---------------+ +---------------+
+--+ | | | |
| | NETDIS | | I1 | |
|MT|<------>| |--------| |
| | | NETDIS | | NETDIS |
+--+ | Controller | | Announcer |
+---------------+ +---------------+
|
| I2
|
+---------------+
| |
| |
| NETDIS |
| Announcer |
+---------------+
Figure 1: The NDIS model
3. Network announcement
//The SAP protocol (RFC 2974) could be used to carry the
announcements. However RFC 2974 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.
G. Bichot Expires - September 2003 [Page 3]
Internet-Draft Core Network Discovery Protocol (NETDIS) April 2003
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/NETDIS'
3.2 NETDIS announcement protocol
This is the protocol to be used instead of SAP.
NETDIS 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 NETDIS announcements being
sent to <TBD>
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 NETDIS address FF02:0:0:0:0:0:2:7FFE.
NETDIS announcements MUST be sent on port <TBD> 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
NETDIS (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 NETDIS
group remains below a preconfigured limit. Each announcement should
have an equal announcement interval that will be fixed by the NETDIS
controller.
G. Bichot Expires - September 2003 [Page 4]
Internet-Draft Core Network Discovery Protocol (NETDIS) April 2003
4. Packet format
The figure 2 represents an NETDIS 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/NETDIS' :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Org ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| |
: Network Operator Name :
: (up to 256 bytes) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Realm name :
: (Up to 64bytes) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network type |
: (Up to 30 characters) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Payment | Accounting |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Optional authentication data |
: .... :
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| |
: Optional payload :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SAP carries NETDIS packet
The figure 3 represents a NETDIS announcement packet carried by the
NETDIS announcement protocol.
G. Bichot Expires - September 2003 [Page 5]
Internet-Draft Core Network Discovery Protocol (NETDIS) April 2003
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Org ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| |
: Network Operator Name |
: (up to 256 bytes) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Realm name :
| (Up to 64 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network service |
: (Up to 30 characters) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Payment | Accounting |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Optional authentication data |
: .... :
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| |
: Optional payload :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 NETDIS announcement protocol carries NETDIS 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. NETDIS announcers MUST set this to 0, NETDIS 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.
G. Bichot Expires - September 2003 [Page 6]
Internet-Draft Core Network Discovery Protocol (NETDIS) April 2003
Auth len: An 8 bit unsigned quantity giving the number of 32 bit
words following the main NETDIS 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.
See [1] for details. Alternatively, an organization (see Organization
ID) may specify its own authentication mechanism. If it is the case
the Authorization Length MUST be set to zero.
Msg id hash: A 16 bits quantity that used in combination with the
real name and the network service 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 NETDIS
announcer and it MUST be changed if the announcement description is
modified.
Org ID: an organization identifier. Identify the organization (e.g.
standardization body) that has characterized this announcement. Extra
value is defined and registered through IANA.
Ox00000000: default value meaning no organization specified.
0x10xxxxxx: IETF: the remaining 24 bits point out the RFC that this
announcement relies on.
Network operator name: this is the name of the [virtual] operator of
the 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. The format of this field may however depend on the
Organization ID (see above). The value may for instance correspond to
the so-called PLMN-ID as defined in [4].
Realm name: This gives the domain name the announcement relies on.
This is a character string formatted according to [3]. The NETDIS
listener may use the realm name to form the Network Access Identifier
(NAI) as specified in [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 names and thus will generate
several announcements: one per network access.
Network service: this identifies the type of service the operator
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. This
document defines a few services. New network services may be defined
G. Bichot Expires - September 2003 [Page 7]
Internet-Draft Core Network Discovery Protocol (NETDIS) April 2003
according to the organization ID. One announcement relies on one
network service. This means that an operator that wants to propose
several network services generates several announcements: one per
network service.
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. There is no
recommended format for the Network Operator Name. There is no extra
information linked with this network type.
The following values are examples. It is up to each organization body
to defines new network service values.
"3GPP" - 3GPP access: the [virtual] network operator offers the
access to a 3GPP network services. Authentication and all 3GPP
services are managed through the 3GPP network according to a well-
known method (e.g. 3GPP).
"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).
Payment: this 16 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 payment method is not identified
0x0001 - pre-paid card: a pre-paid card from the provider may be used
0x0002 - subscription: The services from that service provider are
available only on subscription.
0x0004 - credit card: the service may be paid online with a credit
card.
0x0008 - Free: the service(s) from that service provider is (are)
free
Accounting: defines the way the [virtual] network operator debits
your account. Each bit indicates whether the corresponding method is
available (1) or not (0). For each valid method an associated string
located in the payload field indicates the price. The price 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 format of this price string may
however depend on the Organization ID (see above).
G. Bichot Expires - September 2003 [Page 8]
Internet-Draft Core Network Discovery Protocol (NETDIS) April 2003
The following values are defined.
All 00: not identified: the accounting method is not identified
0x0001 - Divers: The method and the fees are explicitly mentioned in
the associated string located in the payload part.
0x02 - day: the fee is for a 24 hours period
0x03 - minute: each minute of the session is counted.
0x04 - Size: the fee depends on the total amount of data exchanged
during the session
0x05 - Connection: each successful connection implies a well-defined
fee.
The header is followed by the optional payload data. If the C bit is
set in the header the payload is compressed. The payload gathers
optional accounting information and extra information according to a
specification identified by the organization ID.
5. Implementation
One context this protocol makes sense is the public WLAN.
A mobile terminal (the NETDIS listener) discovers a set of access
points and associates with one according to the WLAN specification
(best signal strength for instance). No particular ESSID (or
equivalent WLAN ID) is targeted. Once the terminal is associated it
listens the NETDIS 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 ESSID or
equivalent WLAN ID). If there is no other WLAN (ESSID) or no
announcement are present then NETDIS fails.
The mobile terminal can even listens the NETDIS announcement before
being associated with whatever access point. 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.
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.
G. Bichot Expires - September 2003 [Page 9]
Internet-Draft Core Network Discovery Protocol (NETDIS) April 2003
6. Security Considerations
NETDIS (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 NETDIS controller can floods the medium with wrong
announcements.
- A rogue NETDIS 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 NETDIS 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
4 Digital cellular telecommunications system (Phase 2+) (GSM);
Universal Mobile Telecommunications System (UMTS); Numbering,
addressing and identification
8. Acknowledgments
9. Author's Addresses
Guillaume Bichot
THOMSON
2 independence way
Princeton, NJ 08540 - USA
Email: guillaume.bichot@thomson.net
10. Intellectual Property Statement
G. Bichot Expires - September 2003 [Page 10]
Internet-Draft Core Network Discovery Protocol (NETDIS) April 2003
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 (2003). 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 - September 2003 [Page 11]
