One document matched: draft-faccin-mih-infoserv-01.txt
Differences from draft-faccin-mih-infoserv-00.txt
Network Working Group G. Daley
Internet-Draft Monash University CTIE
Expires: April 15, 2006 S. Faccin
Nokia
E. Hepworth
Siemens/Roke Manor Research
Q. Xie
Motorola
October 12, 2005
Some Requirements for a Handover Information Service
draft-faccin-mih-infoserv-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 will expire on April 15, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Handover Information Services may be used to assist handovers between
wireless cells, based on stored network knowledge. Information
Services can be used to provide topology and channel information
Daley, et al. Expires April 15, 2006 [Page 1]
Internet-Draft Some Requirements for an IS October 2005
which may allow a moving host to select an appropriate link-layer
connection to make, amongst available networks, whether using the
same technology or between heterogeneous technologies.
This document is an effort to describe use cases and problem
statements for information services, when they are transported and
discovered over IP networks.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Information Services . . . . . . . . . . . . . . . . . . . 4
1.2 Scope of work on information services . . . . . . . . . . 5
2. Relationship to 802.21 . . . . . . . . . . . . . . . . . . . . 5
2.1 802.21 Media Independent Information Services . . . . . . 5
3. Scenarios for IS Transported over IP . . . . . . . . . . . . . 6
3.1 Information Service Scenarios . . . . . . . . . . . . . . 6
3.2 Further Scenario Considerations . . . . . . . . . . . . . 9
3.3 Specific Use Information Services . . . . . . . . . . . . 10
4. Protocol Development Scope . . . . . . . . . . . . . . . . . . 11
4.1 Information Service Interfaces . . . . . . . . . . . . . . 11
4.2 Messages Exchanges . . . . . . . . . . . . . . . . . . . . 12
4.3 Information Service Discovery . . . . . . . . . . . . . . 14
4.4 Transport-Layer Issues . . . . . . . . . . . . . . . . . . 15
4.5 Security Association Negotiation . . . . . . . . . . . . . 15
5. Requirements for Transport over IP . . . . . . . . . . . . . . 16
5.1 Summary of requirements . . . . . . . . . . . . . . . . . 16
6. Outstanding Issues . . . . . . . . . . . . . . . . . . . . . . 18
6.1 Transport Issues . . . . . . . . . . . . . . . . . . . . . 18
6.2 Discovery Issues . . . . . . . . . . . . . . . . . . . . . 19
6.3 Security Issues . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7.1 Attacks against service entities . . . . . . . . . . . . . 21
7.2 Attacks against information . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1 Normative References . . . . . . . . . . . . . . . . . . . 22
9.2 Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
A. 802.21 Media Independent Handover Services . . . . . . . . . . 25
A.1 802.21 Handover Service Classification . . . . . . . . . . 26
A.2 802.21 MIHS SAP Relations . . . . . . . . . . . . . . . . 26
A.3 802.21 MIIS Message Processing . . . . . . . . . . . . . . 27
A.4 Information flows in 802.21 . . . . . . . . . . . . . . . 28
A.5 802.21 MIIS Information Classes . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . 31
Daley, et al. Expires April 15, 2006 [Page 2]
Internet-Draft Some Requirements for an IS October 2005
1. Introduction
Handover services are a class of network services, which aim to
assist the quality of handovers available to wireless devices. In
order to support more intelligent handover services it is often
necessary to be able to exchange information between mobile and fixed
nodes within the network.
At this time, three broad classes of services for handover assistance
are under consideration within the IEEE 802.21 Working Group. They
require passing of information within hosts, as well as between them:
1. Event Services (ES) provide indications from lower layers about
changes in the connectivity state. This is particularly relevant
to wireless interfaces [22].
2. Command Services (CS) provide mechanisms for controlling
handovers. They provide mechanisms to establish, redirect, or
remove state in either the network or mobile terminal, so that
handovers occur smoothly.
3. Information Services (IS) are used to provide additional
handover-related information. This allows the network or host to
make informed decisions of which handover operations to undertake
either in response to an event, or when planning controlled or
commanded handovers.
As shown in Figure 1, one or more handover services may exist in a
node, including services which aren't yet described. Each service
may require communication with peer services on other nodes, and this
communication may be transported transport over IP, to communicate
with peer services on other nodes.
The diagram transfers data over a mobility service transport
protocol. This protocol provides transparent message delivery, as
well as server discovery and security association configuration. As
such, it may encompass multiple layers of the TCP/IP protocol model.
Daley, et al. Expires April 15, 2006 [Page 3]
Internet-Draft Some Requirements for an IS October 2005
+-------------+ ^
| Mobility | |
| Service 2 | |
+------------| (e.g. ES) | | Mobility Service
| Mobility +-------------+ | Signaling
| Service 1 | +-------------+ | Layer
| (e.g. IS) | | Mobility | |
+--------------+ | Service 3 | |
| (other) | |
+-------------+ V
================================================
+---------------------------------------+ ^ Mobility Service
| Mobility Service Transport Protocol | | Transport
+---------------------------------------+ V Layer
================================================
+---------------------------------------+
| IP |
+---------------------------------------+
Figure 1: Handover Services over IP
A current focus for handover services over IP is on Information
Services delivery and transport. This document is primarily focused
on this issue.
While the IETF is primarily interested in how handover services can
be used to assist mobility signaling protocols, and interactions
between handover services and network/transport layers, other groups
have been taking a more generally applicable view (see Section 2).
This document provides a view of the authors, and doesn't represent
the official view of either IEEE 802.21 or an IETF WG. Assistance is
sought to improve this document, in order to reflect consensus
viewpoints from the appropriate groups.
1.1 Information Services
Information Services are considered to be an important component of
handover services, for providing local network information to
wireless devices in a non-real-time fashion [1].
Information services provide additional information about the
environment a mobile device is operating in. These services
typically require one or more servers within a set of access
networks, which distribute knowledge that can assist hosts performing
handovers between cells.
Information provided varies dependent on the purpose and operation of
Daley, et al. Expires April 15, 2006 [Page 4]
Internet-Draft Some Requirements for an IS October 2005
the information service, but may consist of: wireless channel state,
adjacent base-station channel occupation, neighboring network
information or upper-layer mobility service information. While each
of these is possible, it is important to note that information
services described in this document have a restricted scope described
below in Section 1.2. This scope is limited in order to achieve
timely outcomes for document development and standardization.
1.2 Scope of work on information services
The development of information services covered in this document
assume a set of models compatible with IEEE 802.21's descriptions of
a Handover Information Service,as described in Section 2. In this
context, a system would need to provide discovery, security
association bootstrap and transport of information services over IP,
in a variety of deployment scenarios. These scenarios are described
in Section 3. The extent of protocol development work to be
undertaken is elaborated on in Section 4.
Further descriptions of information services are possible, for
example it may be possible to describe information services and
FMIPv6 interaction [21]. Having a single framework for FMIPv6
network discovery is important for compatability, though, so it may
be valuable for FMIPv6 development not depend on that of a
generalized IS.
Initial specification of use cases will focus on delivery services
required by the existing client (802.21), in the hope that the scheme
is general enough to be of use in the other cases [1].
2. Relationship to 802.21
IEEE 802.21 is currently developing Media Independent Handover
Services (MIHS). These services are aimed at providing a common
framework for handover assistance regardless of the underlying
technology. The 802.21 framework is aimed to be deployed in a number
of different scenarios, where additional specification will be
required.
This draft provides an incomplete description of the 802.21's
progress, and people are encouraged to read the 802.21 draft
themselves [1].
2.1 802.21 Media Independent Information Services
IEEE is currently working on Information Services as part of 802.21
Media Independent Handover Services (MIHS).
Daley, et al. Expires April 15, 2006 [Page 5]
Internet-Draft Some Requirements for an IS October 2005
Amongst media independent handover services, information services are
most readily deployed over IP [1]. In the 802.21 case, link-layer
oriented information would then be distributed over IP and upper-
layer protocols.
For these information services, it is possible that network
information may be either centrally stored on a server or distributed
in each individual access network. Presumably, an L2 or L3 based
mechanism to identify or discover a valid information server would be
required. Such scenarios are described in more detail in
Section 3.1.
In order to accomplish this, it will be necessary to describe IS
discovery and specify transport services over IP. Interactions with
IP in delivering handover services over IP therefore need
consideration in the IETF, both for use with 802.21 and for other
instances of handover services [21].
This document describes a distillation of the requirements from the
current draft for 802.21's media independent information service, in
order describe uses for handover information services, and start
describing requirements for alike information services transported
over IP.
As synergies exist between this work and existing work within the
IETF, the authors of this document aim to exchange knowledge amongst
participants of IEEE 802 and IETF. This may allow specification of
information services transport over IP, which would be suitable for
802.21's MIIS, as well as other compatible information services.
3. Scenarios for IS Transported over IP
In the general case, Information Services delivery over IP may be
applicable to more than just media independent handovers. What is
likely to be held in common are deployment scenarios, which detail
particular challenges dealt with by the information service, and the
consequent requirements from these services.
In Section 3.1 below, these scenarios are detailed, along with the
implications of particular topologies. The union of these
requirements are then described in Section 4.
3.1 Information Service Scenarios
The models described above for information services allow deployment
of IS Information Servers anywhere within the visited network domain.
In this section example scenarios are described indicating where
information services are likely to be deployed. Descriptions of
Daley, et al. Expires April 15, 2006 [Page 6]
Internet-Draft Some Requirements for an IS October 2005
particular characteristics of these deployments are made, especially
where the deployments place requirements on any information service
transportation deployed over IP.
In each of the diagrams (Figure 2, Figure 3 and Figure 4) below, a
mobile device is currently connected to a particular wireless cell,
serviced by an Access Point. In order to gain information about
other wireless cells in the vicinity, it contacts an information
server within the fixed network.
In Figure 2, the information service has been deployed on a wireless
Access Point. This is considered to be a likely scenario, as
wireless devices themselves may be aware of local channel conditions,
and may have information about administratively adjacent devices
(such as first-hop routers) and base stations within the same subnet.
In this scenario, transport of information services over IP isn't
strictly necessary, as the IS-Server is the MAC peer of the wireless
host. If information services over IP are deployed though, no
changes to the link-layer protocol are required.
Conversely, if transport of information services over IP is required,
the host is still has to discover the server's IP address and
presence. This discovery requires transmission IS discovery queries
to a known address, group, or directory service.
/--------\
I / \
----- -------- -------- /----/ \----\
|[ ]| | ---- |--+--| |---/ \
|ooo|<---------->|IS| | | | | / \
|ooo| | ---- | | | | \ /
----- -------- | -------- \ /
Host Access | Router \----\ /----/
Point | \ /
| -------- / \--------/
+--| | / Distribution
| |-------/ Network
| |
--------
Router
Figure 2: IS-Server on Access Point
When an IS-Server is placed within the access network,once again it
may be possible to run information services without using IP. No
advantage is gained from omitting IP, though, as server discovery
Daley, et al. Expires April 15, 2006 [Page 7]
Internet-Draft Some Requirements for an IS October 2005
still needs to occur.
If IP is used for information services transport, For example, in
(Figure 3), the server is co-located in the router. There the router
has access to the upper layer information required to assist
handovers [1][21].
While information services delivery in this scenario is partly
addressed by experimental information services in CARD and FMIPv6,
the authors consider a fresh look at these issues are warranted,
particularly to establish the applicability of security association
establishment mechanisms in these and other environments [20][21].
/--------\
I / \
----- -------- -------- /----/ \----\
|[ ]| | |--+--| ---- |---/ \
|ooo|<----------------------->|IS| | / \
|ooo| | | | | ---- | \ /
----- -------- | -------- \ /
Host Access | Router \----\ /----/
Point | \ /
| -------- / \--------/
+--| ---- | / Distribution
| |IS| |-------/ Network
| ---- |
--------
Router
Figure 3: IS-Server on Subnet Router
Information service servers deployed outside the mobile node's subnet
present both advantages and challenges. As illustrated in Figure 4,
an IS-Server outside a subnet doesn't require explicit support from
devices the mobile's link. Therefore the server is able to be
deployed in networks which are not able to be modified easily.
Additionally, the server is in a position to serve many access
subnets simultaneously, which reduces administrative overheads.
Conversely, network support for discovering the IS-Server becomes
critically important. Since a mobile device may roam within a domain
though, it may not be necessary to discover the server each time it
changes subnet, so long as the mobile remains in the set of networks
covered by the server. Discovery mechanisms are covered in more
detail in Section 4.3.
Additionally, the location of information services addressable
Daley, et al. Expires April 15, 2006 [Page 8]
Internet-Draft Some Requirements for an IS October 2005
outside the subnet has security implications which are described in
Section 7.
/--------\
I / \
----- -------- -------- /----/ -------- \----\
|[ ]| | |-----| |---/ | ---- | \
|ooo|<----------------------------------------->| |IS| | \
|ooo| | | | | \ | ---- | /
----- -------- -------- \ -------- /
Host Access Router \----\ Information/----/
Point \ Server /
-------- -------- / \--------/
| |-----| | / Distribution
| | | |-------/ Network
| | | |
-------- --------
Access Router
Point
Figure 4: Standalone IS-Server
3.2 Further Scenario Considerations
The IS needs to be in a position to provide useful information to
hosts about their current visited environments. In many cases, the
network side infrastructure is in a position to store overall network
information, such as neighborhood cell lists and the location of
mobile devices. The wide variation in potential locations for
Information Servers though, makes their discovery challenging.
Description of information services transported over IP requires
detailed analysis of potential Security Association building
techniques, and identification of anchors for trust. It also
requires determination of IS discovery mechanisms which are
deployable in today's networks.
In some scenarios, link-layer devices may be modified sufficiently to
provide discovery services for IS servers contactable over the
internet. In this case, the discovery operations can be abbreviated
in all scenarios where transport over IP is provided, if the link-
layer mechanism is sufficiently secured against advertisement
spoofing.
Daley, et al. Expires April 15, 2006 [Page 9]
Internet-Draft Some Requirements for an IS October 2005
3.3 Specific Use Information Services
As described in Appendix A.5, information services may potentially
retrieve different types of data from different sources. Where this
data is also used for different purposes within the recipient host,
it may be useful to segregate the discovery and operation of
information services for different classes of data onto separate
servers.
At discovery time, the discovery operation could then respond with
service advertisements describing which services are provided on
which servers, potentially indicating that one information class is
available on one server and one on another.
While this scenario is not explicitly supported in 802.21, where
service discovery is provided over IP networks, it is feasible to
request/identify if an information server has a particular service.
The scenario is illustrated below:
/--------\
I -------- -------- / -------- \
----- HLSI | | | | /----/ | ---- | \----\
|[ ]|<------------------------------------------->|IS| | \
|ooo| | ---- | | | / | ---- | \
|ooo|<---------->|IS| |-----| |--\ | | /
----- LLI | ---- | | | \ -------- /
Host -------- -------- \----\ Network /----/
Access Router \ Server /
Point / \--------/
-------- -------- / Distribution
| ---- | | | / Network
| |IS| |-----| |------/
| ---- | | |
-------- --------
Figure 5: Separation of Information Content Option
In Figure 5, separate information classes are shown on the different
servers. Link-layer services are serviced by access-points or other
local devices, while topological and network information is serviced
by a centrally located device. Discovery of services may indicate
that a current SA and communication channel to the IS may be reused
(for example to the central server), while link-specific information
services would be accessed for local information services.
This is to be contrasted with the previous unified information
Daley, et al. Expires April 15, 2006 [Page 10]
Internet-Draft Some Requirements for an IS October 2005
services deployment model from deploying the information server at
one of the particular locations in Figure 2, Figure 3 or Figure 4.
If information services are deployed in multiple servers, it may
require additional operations to discover all required services.
Also, it could lead to additional signalling and computation expenses
in bootstrapping security associations for each communication.
As development of information services over IP proceeds, it may be
valuable to deploy the same discovery and security association
bootstrap mechanisms for subsequent non-link-layer oriented services.
In this case, the discovery mechanism would need to be flexible
enough to accomodate additional information services, or combinations
of services.
At this stage, no intention to follow a multiple information-server
design is inferred. The scenario is illustrated to elicit feedback
about the desirability of specific use information services over IP,
for either use with 802.21 or further development of information
services.
4. Protocol Development Scope
This section describes the areas requiring investigation or
standardization to provide transport of information services over IP.
At this stage, significant feedback is required from both MIPSHOP
working group and 802.21 Task Group, to confirm the validity of the
scenarios from Section 3, and develop the descriptions in the
subsections below.
Once these are more stable, a summary of requirements can be produced
in Section 5.1.
4.1 Information Service Interfaces
Entities involved with handover information services perform the
roles of an Information Services client (IS client) or an Information
Services server (IS-Server). Relative positions of client and
server, and the interfaces between them produce different
requirements, depending on the type of communication.
Illustrated in Figure 6, are a number of devices participating in
information services exchanges. On the left-hand side of the figure,
a mobile IS client contacts an IS-Server in a network device. If
this server requires additional information, it may contact another
IS-Server by becoming a client itself. This new IS-Server may reside
either within its administrative domain, or in another domain.
Daley, et al. Expires April 15, 2006 [Page 11]
Internet-Draft Some Requirements for an IS October 2005
--------- ----------- -----------
|mobile |-------->|IS-Server|-------->|IS-Server|
--------- ----------- -----------
|
domain A |
- - - - - - - - - - - -|- - - - - - - - - - - - -
domain B |
V
----------- -----------
|IS-Server|-------->|IS-Server|
----------- -----------
Figure 6: Relationships between Information Service entities
The mobile/IS-Server interface is the primary interface requiring
standardization by IETF. Initially, an information server must be
discovered, as the mobile device will not be preconfigured with the
server identity. Subsequently, secured communications are
established. This security association may allow the mobile to be
anonymous, but in some environments, mobile device authentication may
be used to prevent resource exhaustion attacks. In any case, message
authentication needs to be provided.
To ensure the validity of data, the IS-Server itself needs to
authenticate itself to the mobile. This proves that it is the origin
of the messages, and prevents man-in-the-middle attacks.
After security association establishment, information requests and
responses are exchanged.
The IS-Server/IS-Server interface is required if information servers
need to retrieve additional information from each other. For this
interface, message formats are the same as the mobile/IS-Server
interface. The lifetime of the security association may change
though, especially in environments where servers each act as a
requester and a responder. If this is the case, mutual
authentication is required between the servers. Discovery is
considered to be out-of-scope, as in many networks, this will be
under the control of other network management systems.
4.2 Messages Exchanges
On the mobile/IS-Server interface a series of steps are required
before information is able to be delivered back to the mobile node.
In Figure 7, the steps are illustrated. The mobile device is
involved in all exchanges, although dependent on the discovery scheme
developed for Information Services, it may contact a separate
Daley, et al. Expires April 15, 2006 [Page 12]
Internet-Draft Some Requirements for an IS October 2005
directory service in order to locate the IS-Server's address.
/ \ -----------
| 1) IS-Server Discovery | |Directory|
| ----------------------> \ | or |
| 2) IS-Server Address / | Group |
| <---------------------- | -----------
-------------- | /
| Mobile | |
|Information | /
| Service | \ 3) IS-Server Contact \
| Client | | ----------------------------> |
-------------- | 4) Build Security Associations | -------------
| <============================> \ |Information|
| 5) Information Request / | Service |
| -----------------------------> | | Server |
| 6) Information Response | -------------
\ <----------------------------- /
Figure 7: Message exchanges required for Information Service
Operation
1. IS-Server Discovery - A message from the mobile to either a
multicast/anycast group, or a directory service which can be used
to find an IS-Server.
2. IS-Server Address - The response from either a member of a
multicast/anycast group or the directory server, indicating the
address of the IS-Server.
3. IS-Server Contact - The initial contact operation where the
mobile tests if the IS-Server is reachable. This may occur
within the first message used for Security Association (SA)
bootstrap.
4. Build Security Associations - Messages exchanged to bootstrap SAs
with which to protect the data exchange.
5. Information Request - The data query packets typically sent from
the mobile to the IS-Server, protected by the SAs.
6. Information Response - A responding set of response packets sent
from the IS-Server to the requester. This message is protected
by the SAs already negotiated. Where the direct requester was an
IS-Server, the response goes back to the requester rather than a
mobile.
Daley, et al. Expires April 15, 2006 [Page 13]
Internet-Draft Some Requirements for an IS October 2005
Discovery exchanges (1 and 2) rely upon the underlying discovery
protocol, as described in Section 4.3.
Subsequently, secure communications are established (steps 3/4).
This should make use of an existing applicable, dependent on the
transport required for information request and responses (steps 5 and
6).
Transport layer requirements for information exchanges are described
in Section 4.4, and additional considerations for security
association negotiation are provided in Section 4.5.
4.3 Information Service Discovery
Discovery by the mobile device of the IS-Server either requires
Information Server participation in a discovery protocol, network
entity discovery support or use of a directory service. The
directory service can then refer mobiles to an appropriate server for
their location.
Discovery mechanisms need to provide IP layer contact information for
the IS-Server. Such a discovery system should provide protection
against spoofing, to prevent attackers substituting bogus information
servers.
In IP networks, numerous directory and configuration services already
exist. Use of these services either requires support from locally
discoverable resources within the same IP hop [4][15][18], or rely on
prior configuration of the unicast address of the directory service
[12][13][17]. Prior configuration itself may be performed
dynamically, along with other host services [4][15].
Network entity discovery, such as Router Discovery [9] could allow
discovery of an IS server during routing configuration operations.
If server discovery can be achieved through existing configuration
discovery procedures, no additional packet exchanges would be
required to perform discovery. Strict procedures for modifying
packet formats with these primitive discovery mechanisms may limit
the applicability of these techniques though.
Other non-directory discovery methods require participation by the
IS-Server in multicast or anycast communication [12]. In this case,
the access network needs to support this form of routing, although it
is not aware of the content. Multicast routing itself requires
additional routing protocols. These protocols, while simple to
operate in constrained domains such as this, are not yet deployed on
all access routers. Where the IS server is not on the first IP, this
prevents discovery protocol operation.
Daley, et al. Expires April 15, 2006 [Page 14]
Internet-Draft Some Requirements for an IS October 2005
4.4 Transport-Layer Issues
The existing ready use of IETF developed transport layer protocols is
a compelling reason to develop information services transported over
IP. Particularly, it is valuable to determine if IS requirements
match existing transport models and protocols.
While information services are non-real time, in some scenarios (IS-
Server within a subnet), the lifetimes of communications with a
particular server are short. As such, the sequenced delivery of
packets using TCP may be too complicated for this application heavy
handed [2]. TCP fast recovery relies upon delivery of additional
packets to stimulate additional transmissions of acknowledgements
from a receiver back to a transmitter. Where packet exchanges are
short and sporadic, loss of a packet may not be detected except using
long retransmission timeouts [3][10][11][14].
Where existing transport protocols do not incorporate their own
congestion control and rate limitation, basic mechanisms for network
protection and congestion recovery may need to be added to IS
application protocols.
Alternatively, the rich development of security mechanisms which work
with TCP and other stream oriented communications, encourage its use
[5]. Recent developments allowing similar session oriented security
services for datagrams may allow either stream oriented services or
datagram oriented services to be used, dependent on the handover
service required (for example, both ES and CS may be datagram
oriented) or the mobile node's preference [25].
4.5 Security Association Negotiation
Security is important in IP networks, since there is a danger that
attacking devices can attempt to adopt roles as information service
devices. Such bogus devices could cause service degradation through
spurious message exchanges, or by providing false information to
mobile devices.
IS-Servers need both to protect themselves from attack, and to
provide mobile clients provable trust, in order that they can make
handover decisions without fear of malicious inaccuracies or
mischief.
Therefore, before exchanging information requests with a new
information server, a set of Security Associations (SAs) are
established. Each SA must to provide message authentication, and
should provide encryption, for the purposes of mobile device
anonymity from eavesdroppers.
Daley, et al. Expires April 15, 2006 [Page 15]
Internet-Draft Some Requirements for an IS October 2005
The exact SA negotiation mechanism described depends on the transport
layer used, and security services required. For example, TLS may be
applicable if upper layer protocols use TCP, while ESP using IPSec/
IKE will work in most situations, regardless of the upper layer
protocol, so long as the IS protocol identifiers are handled by IKE
[5][6][7].
While a mobile device moves within an area serviced by the same IS-
Server, it can continue to use the same security association, so long
as the clients IP address doesn't change. Where the IS-Server is not
on the same LAN as the mobile, the mobile may move between IP
networks covered by the same server. In this case, the IP address of
the mobile changes.
If the mobile's address changes, it may be possible to reuse an
existing SA by updating the addresses to use for communication
endpoint addresses using Mobile IPv6 Route Optimization, or IKEv2
session mobility [19][23]. If address update services are not
available, then it will be necessary to reestablish the security
association each time the mobile device's address changes.
5. Requirements for Transport over IP
At this stage feedback is sought on the preceding sections before
development of a complete recommendation summary. The summary below
is to be considered as a starting point for discussion.
5.1 Summary of requirements
o Provide an information service transport mechanism which works
with both IPv6 and IPv4.
o Allow multiple packet responses to queries.
o Allow fragmented message responses to queries.
o Provide robust query and response delivery over wireless networks.
o Distinguish between the packet source and query source (allow
proxies).
o Provide transport of information services through NAT for IPv4.
o Optionally allow for multiple queries per transport session
o Optionally ensure compatability between the information services
transport, and those required for Event and Command Services.
Daley, et al. Expires April 15, 2006 [Page 16]
Internet-Draft Some Requirements for an IS October 2005
o Describe an information service discovery mechansism for IPv6
hosts
o Describe an information service discovery mechansism for IPv4
hosts
o Provide a common discovery method regardless of whether the IS-
Server is the adjacent AP, on the same subnet, or deep within the
network.
o Information services discovery should be protected from discovery
service impersonation and exchange modification attacks.
o Optionally ensure compatability between the information services
discovery mechansisms, and those required for Event and Command
Services over IP.
o Allow for distinct classes Information Servers to be discovered.
o Allow for more than one Information Server to be discovered at a
time.
o Allow for context sensitive IS server discovery (per AP, per
visited Subnet, per Mobile).
o Optionally allow discovery messages being transported through NAT.
In this case, support for requester specific knowledge needs to
use both the NAT source address and the query original address.
o Provide a common SA negotiation method regardless of whether the
IS-Server is the adjacent AP, on the same subnet, or deep within
the network.
o Protect against IS-Server impersonation.
o Provide confidentiality of query and response contents.
o Protect the identity of a querier against eavesdroppers.
o Protect IS-Server and discovery resources against denial of
service.
o Minimize computational and transmission resources for mobile
clients.
o Provide compatability with Address or Security Association
Mobility management, to allow use of an IS server after host
movements without renegotiating an SA.
Daley, et al. Expires April 15, 2006 [Page 17]
Internet-Draft Some Requirements for an IS October 2005
6. Outstanding Issues
At this stage, there are a wide range of possible scenarios for
information services. Below are a set of questions which may limit
the range of potential deployed ISs, to an achievable subnet.
The following subsections describe issues to resolve which may allow
development of information services with applicability to 802.21.
Each is outlined by an issue task which needs to be resolved in order
to develop an IS protocol. Therefore it is felt that this process
may to assist shaping the requirements for IETF standardization
processes.
As design choices are made, they will be cataloged here, and this
section may eventually move to an appendix.
6.1 Transport Issues
The following design issues impact on the choice of transport
mechanisms for Information systems.
o Response timing constraints
o Stream or datagram oriented service
o Reliability in transport layer or above
Task: Determine what delivery and timing constraints exist (in
absolute time or proportional to maximum wireless medium RTT)
If IS applications have inbuilt timing constraints, it is necessary
to determine what these are. This is because existing transfer
mechanisms may delay new transfers of data for multiple seconds in
packet loss situations (for example TCP [3]). As such, protocols
which don't meet these constraints may be ruled out-of-scope for
development.
Task: Determine if Stream or Datagram oriented services are required
for IS.
It's necessary to determine which of stream and datagram oriented
services are required. This is because choices of services impact on
the security and packet delivery services are needed (or available)
at the transport layer. Additionally, it may be useful to make use
of a generalized transport model, not only for IS, but also for event
or command services. In that case, the union of the requirements
would need to be supported.
Daley, et al. Expires April 15, 2006 [Page 18]
Internet-Draft Some Requirements for an IS October 2005
Task: Determine if reliability is required at transport layer.
Even if TCP isn't being used, an IS may still require reliable packet
transfer [2]. If the messages exchanged for the information service
are assumed to be processed in-order for particular exchanges,
reordering of packets over the Internet may cause problems for IS
function. In that case, transport-layer reliability services may be
required.
Alternatively, where message sequence numbers are incorporated into
the Information Service messages, ordering of packets may be possible
using application-layer information. In this case, it may also be
possible to provide message reliability, on top of a datagram
oriented transport service.
6.2 Discovery Issues
The following design issues impact on the choice of discovery of IS-
Servers.
o Single or multiple methods of discovery
o Information Server participation in discovery
o IS-Servers' use of discovery
o Only one Server or allow one Server per class
Task: Determine how many discovery methods are required.
Having multiple discovery mechanisms allows for deployment
flexibility, but requires hosts to test all possible mechanisms for
IS-Server discovery, when hosts are not constrained to use only one
discovery mechanism.
It is necessary to determine whether any discovery systems will be
mandatory-to-deploy, which may allow optimization of discovery
processes.
Task: Determine if Information Server itself needs to participate in
discovery
If the information service is able to be discovered using an existing
directory service, then it may not be necessary for the IS-Server
itself to participate in discovery.
If there's no directory service preconfigured in the mobile host, it
is necessary for the server to understand discovery messages and
Daley, et al. Expires April 15, 2006 [Page 19]
Internet-Draft Some Requirements for an IS October 2005
respond on its own behalf.
Task: Determine if IS-Servers are required to discover further IS-
Servers.
If IS-Servers can be assumed to be preconfigured with information
about which IS-Servers hold relevant information to service queries,
they can avoid performing discovery processes to find the servers.
Task: Identify if separate servers for different information services
should be supported
Servers for multiple classes allow additional flexibility, but
potentially incur additional signalling costs. This issue is
described in Section 3.3.
6.3 Security Issues
The following issues impact on the design of security mechanisms for
communications between IS entities.
o Mutual authentication requirements
o Do IS-Server to IS-Server communications require mutual
authentication?
o Rate limitation of queries and responses
o Session or host based SAs
Task: Determine if mutual (strong or shared key) authentication is
required for the SAs.
If mutual authentication is required, then the mobile needs to have
credentials verifiable in the network (using an AAA server, or PKI
for example). If the Mobile is allowed to be anonymous, additional
requirements for protection of resources may be required.
Task: Determine if the Server-to-Server interface requires mutual
authentication.
If the mobile devices don't require mutual authentication, servers
may still do so, due to differences in the trust accorded servers.
In that case additional requirements on infrastructure are needed, as
described above.
Task: Determine rate limitation requirements for information requests
and responses.
Daley, et al. Expires April 15, 2006 [Page 20]
Internet-Draft Some Requirements for an IS October 2005
Rate limitation of queries on clients allow a server to delay or
ignore queries from clients which exceed valid query rates,
Similarly, rate limitation of server responses can help protect
wireless media, but can also be used to deny service.
Task: Determine if session based or host based SAs are required.
Typically, layer 3 security such as IPsec is host based, where all
users of a device are given the same authentication. Alternatively,
a session based authentication (often tied to a user's own
privileges) is used for transport and upper-layer security.
Different assumptions about numbers of users may apply on the mobile
and the information server. Since servers may be shared by many
users, session based mobility may prevent abuse of security
mechanisms by attackers co-located at the server.
7. Security Considerations
Exchange of Link-layer and handover related information over upper-
layer protocols such as IP has the potential effect of widening the
scope of attacks against both the information service's interfaces
with the network, and the information itself.
7.1 Attacks against service entities
Attacks upon information services may prevent one or more devices
being able to receive handover related information. As such this may
cause degradation in handover performance.
New attacks against information services become possible where link-
layer information which would otherwise be limited to only one medium
or bridge span, is subsequently available through an arbitrarily
large IP subnet.
Additionally, where information service packets may be requested or
supplied from beyond the boundaries of a single routed hop, the
potential scope for attack upon either of the (client or server) IS
entities is Internet-wide.
Discovery of the information server is implied as a requirement in
providing information services transported over IP. Where the server
is indicated through link-layer signaling, the robustness of the
discovery mechanism is largely based on the security of the existing
link-layer signaling mechanisms. Where the server discovery is
performed over IP, special care needs to be taken to ensure that
discovery may not be hijacked, especially since the underlying
wireless medium may in some cases be considered vulnerable to such
Daley, et al. Expires April 15, 2006 [Page 21]
Internet-Draft Some Requirements for an IS October 2005
attack.
Link-local scope signaling for either discovery, or both discovery
and client-server communications reduce the origin of attacks to
those who are on-link [8]. This may provide a mechanism which
mitigates the effect of external attacks, but will require service
entities to exist on every subnet.
7.2 Attacks against information
Attacks against the information exchanged between the information
server and the information client may potentially modify the behavior
and trust of the client protocol stack.
Where the integrity and origin of the information delivered to the
client is not verifiable, the value of the information is degraded,
as hosts are less able to rely upon the data received.
Where the client's request is spoofed or modified, additional
information may be sent to the IS client. As the mobile node is
typically upon a lower bandwidth medium than the server, there exists
potential to deny service to devices on that medium. Additionally,
spoofed responses may be acted upon instead of legitimate
information. This may lead to handover toward undesirable networks,
or erratic connectivity.
Systems which ensure data origin authentication and message integrity
may be able to remove or mitigate some of these effects, by ensuring
that data arrives as intended back to the client. It may be
difficult, though, to bootstrap some types of security association
considering a potential lack of keying material, computation and
network bandwidth resources from mobile devices. Any specified
integrity protection mechanism therefore needs to be deployable on
low-powered battery-operated devices which are commonly deployed in
wireless environments.
8. Acknowledgements
Many thanks to James Kempf for an informed and thorough review of
this document.
9. References
9.1 Normative References
[1] "Draft IEEE Standard for Local and Metropolitan Area Networks:
Media Independent Handover Services", IEEE LAN/MAN Draft IEEE
P802.21/D00.01, July 2005.
Daley, et al. Expires April 15, 2006 [Page 22]
Internet-Draft Some Requirements for an IS October 2005
9.2 Informative References
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[3] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", RFC 2001,
January 1997.
[4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[5] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[9] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[10] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[11] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's
Fast Recovery Algorithm", RFC 2582, April 1999.
[12] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service
Location Protocol, Version 2", RFC 2608, June 1999.
[13] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[14] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option for
TCP", RFC 2883, July 2000.
[15] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
Daley, et al. Expires April 15, 2006 [Page 23]
Internet-Draft Some Requirements for an IS October 2005
[16] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[17] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[18] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[19] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[20] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim,
"Candidate Access Router Discovery (CARD)", RFC 4066,
July 2005.
[21] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[22] Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-02 (work
in progress), July 2005.
[23] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol",
draft-ietf-mobike-design-01 (work in progress), January 2005.
[24] Williams, M., "Directions in Media Independent Handover", IEICE
Transactions on Fundamentals Special Section on Multi-
dimensional Mobile Information Networks, July 2005.
[25] Rescorla, E., "Datagram Transport Layer Security",
draft-rescorla-dtls-02 (work in progress), December 2004.
[26] Brickley, D. and R. Guha, "RDF Vocabulary Description Language
1.0: RDF Schema", W3C
Recommendation http://www.w3.org/TR/rdf-schema, February 2004.
[27] Prudhommeaux, E. and A. Seaborne, "SPARQL Query Language for
RDF", W3C Working
Draft http://www.w3.org/TR/2004/WD-rdf-sparql-query-20041012,
October 2004.
Daley, et al. Expires April 15, 2006 [Page 24]
Internet-Draft Some Requirements for an IS October 2005
Authors' Addresses
Greg Daley
Centre for Telecommunications and Information Engineering
Department of Electrical and Computer Systems Engineering
Monash University
Clayton, Victoria 3800
Australia
Phone: +61 3 9905 4655
Email: greg.daley@eng.monash.edu.au
Stefano Faccin
Nokia
6000 Connection Dr
Irving, TX 75229
USA
Phone: +1 973 894 5000
Email: stefano.faccin@nokia.com
Eleanor Hepworth
Siemens/Roke Manor Research
Roke Manor
Romsey SO51 0ZN
UK
Phone:
Email: eleanor.hepworth@roke.co.uk
Qiaobing Xie
Motorola, Inc.
1501 W. Shure Drive, 2-F9
Arlington Heights, IL 60004
US
Phone: +1-847-632-3028
Email: qiaobing.xie@motorola.com
Appendix A. 802.21 Media Independent Handover Services
The union of the Media Independent Information Service, the Media
Independent Event Serviced and the Media Independent Command Service
compose a Media Independent Handover Service.
Daley, et al. Expires April 15, 2006 [Page 25]
Internet-Draft Some Requirements for an IS October 2005
Certain characteristics are shared amongst all three services. Of
particular note to IETF are the common SAPs, and information flows.
Appendix A.1 802.21 Handover Service Classification
Information exchanges in 802.21 classified as either Event, Command
or Information services.
The Media Independent Event Service (MIES) provides timely
communications of wireless environment information, through an event
delivery service. Both events generated from local link-layer
devices, and remote events from by a peer Media Independent Handoff
Function (MIHF) on the other end of the link-layer, are supported.
An example event would indicate that it is now possible to send
generic upper-layer frames.
The Media Independent Command Service (MICS) provides instructions
which change state of the wireless link, or a host's point-of-
attachment. Commands can be sent to entities within the local host,
or to a device on the other end of the link-layer medium. Such
command mechanisms may cause further event generation, either from
the local MIHF, or on the peer. As an example, a command may be able
to instruct a station to handover to another network.
The Media Independent Information Service (MIIS) distinguishes itself
from the other mechanisms in that the messages are typically larger
and do not have the same time critical delivery requirements. It
provides several classes of handover service related information to
hosts including Link-Layer and Network-Layer status information.
These service classifications have been adopted throughout this
document, It provides several classes of handover service related
information to hosts including Link-Layer and Network-Layer status
information. as the basis for ES, CS and IS descriptions.
Of importance to 802.21 is the fact that the endpoint for remote
communication may be a directly adjacent link-layer peer or another
device. As described in the 802.21 draft, in this case, it is
believed an upper-layer protocol could be used to deliver
information. In the current context, this means delivery over IP,
and related transport services.
Appendix A.2 802.21 MIHS SAP Relations
The 802.21 Media Independent Handover Function (MIHF) provides a
unified SAP for its component services to upper layers such as IPv6,
or mobility management applications, like MIPv6 [8][9][19]. These
applications are saved the difficulty of dealing with individual
Daley, et al. Expires April 15, 2006 [Page 26]
Internet-Draft Some Requirements for an IS October 2005
Link-layer modules for handover control and monitoring.
Within the MIHS, each of the entities is able to interface to media
dependent operations in order to gain information from or provide
control over the physical medium and MAC.
In the diagram below, the MIIS is shown as being able to interface to
upper layer protocols, in order to provide information service data
transport.
+-----------+--------------------+------------+
Upper Layer | Other | | |
Services |Upper Layer| IPv4 | IPv6 |
| ^ | ^ | ^ |
| | | | | | |
| \----------------+----------------+--------\
| | | | \
| /-------+--------------------+--------\ | |
+--+ MIH SAP +--+ |
| \-------------------------------------/ | |
| | |
| Media Independent Handover Function | |
| | |
| +----------+ +-----------+ +----------+ | |
| | | | | | | | /
| | MIES | | MICS | | MIIS ?------/
| | | | | | | |
| +----------+ +-----------+ +----------+ |
| |
+---------+-----------+-----------+-----------+
Media | | | | |
Depend | 802.16 | 802.11 | 802.11 | UMTS |
Handover | | | | |
Services | | | | |
+---------+-----------+-----------+-----------+
Figure 8: Abstraction using the MIH SAP, showing delivery of MIIS
services over IP
Communications are primarily up/down the stack, although transport of
information services over IP, breaks this model by relying in turn
upon existing configuration of IP connectivity in order to receive
MIIS messages.
Appendix A.3 802.21 MIIS Message Processing
The Information Service is primarily a request/response based system.
The information server processes queries containing a set of filter
Daley, et al. Expires April 15, 2006 [Page 27]
Internet-Draft Some Requirements for an IS October 2005
constraints on the response, as specified by the requester. It then
composes a response and sends it back to the requester. Given the
size and non-real time nature of the response, more than one packet
of data may be required to transport all the information required.
Upon reception at the MIHF of the querier, information may be
filtered for content, and then passed through MIH SAPs to interested
upper-layer protocols.
While content of IS messages is considered out of scope in
development of generic IS transport over IP, the message formats and
SAP contents are further described in [1].
Appendix A.4 Information flows in 802.21
As mentioned earlier, there are different incarnations of the
Information Service depending on whether information is being passed
between two link-layer peers, or is stored on a server accessible
over an upper-layer protocol.
While this document is concerned solely with IS transport over IP
networks, the information flow for both of 802.21's L2 and L3 based
exchanges are presented for comparison:
STA (Client) AP/BS
MIH SAP MAC MAC MIH SAP
| | | |
Request |MIH_Info. | |MIH_Info. |
info from | request| | indication|
peer |--------->|------------------->|----------->|
| |Information REQUEST | |
| | | |
| | | |Neighbor Map
| | | |Report Gen
|MIH_Info. | |MIH_Info. |
| confirm| | response|
Neighbor |<---------|<-------------------|<-----------|
Map Report | |Information RESPONSE| |
| | | |
Figure 9: L2-based MIIS information flow from 802.21
Note that the primary logical differences between the information
flows at the link-layer and upper layers are the endpoints for
message transport. The use of a particular mechanism should be
transparent to systems interfacing to the MIH Service Access Point.
Daley, et al. Expires April 15, 2006 [Page 28]
Internet-Draft Some Requirements for an IS October 2005
STA (Client) AR/Server
MIH SAP T'sport/IP T'sport/IP MIH SAP
| | | |
Request |MIH_Info. | |MIH_Info. |
info from | request| | indication|
peer |--------->|------------------->|----------->|
| |Information REQUEST | |
| | | |
| | | |Neighbor Map
| | | |Report Gen
|MIH_Info. | |MIH_Info. |
| confirm| | response|
Neighbor |<---------|<-------------------|<-----------|
Map Report | |Information RESPONSE| |
| | | |
Figure 10: Example L3-based MIIS information flow
In information services deployment over IP, the topological location
of the IS-Server doesn't modify the message exchange. In fact,
802.21 allows the server to be present either within the access
network or core network of a service provider. [1].
Implications for a generic handover services delivery mechanism are
that a variety of topologies are required to be supported for IS
transport over IP, while message containers are likely to remain
unmodified, so long as the channel used for communications is
secured.
Appendix A.5 802.21 MIIS Information Classes
The media independent information service provides three classes of
data to mobile hosts. These classes of data are related to different
origins and use of data:
1. General Network Information (GNI): A general overview of the
network and its nearby Points of Attachment.
2. Link Layer Information (LLI): Link-layer specific information
useful to identify capabilities of a specific network.
3. Higher Layer Information (HLI): Information about upper layer
protocols like IPv4 and IPv6, configuration systems such as DHCP
and mobility management applications like MIPv4 [4][16].
Information from each of these classes may be queried from an
Daley, et al. Expires April 15, 2006 [Page 29]
Internet-Draft Some Requirements for an IS October 2005
information server, with different filters applied for each data set.
As such, it may be possible to configure different aspects of
information service queries, for example, an 802.11 handover
management subsystem may only be interested in Link-Layer
Information.
It is notable that Link-Layer information is likely to be gathered
most readily at the edge of the network where devices are directly
involved in wireless communications, whereas Higher-Layer information
will be available to devices which have IP layer configuration.
As such it is not entirely implausible to use different information
servers for local link-layer oriented information, and for wider-
region topological information. This issue is described in
Section 3.3 This may imply a useful role for interaction between IS-
Servers in order to configure or update held information.
Daley, et al. Expires April 15, 2006 [Page 30]
Internet-Draft Some Requirements for an IS October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Daley, et al. Expires April 15, 2006 [Page 31]
| PAFTECH AB 2003-2026 | 2026-04-23 20:21:09 |