[802.21] IETF draft on IS
Title: Vice Chair candidate
Hello,
Here is a draft
version of the internet-draft that is due on 6th March to the IETF that contains
the 802.21 transport requirements. Your comments are most
welcome.
Regards,
Srini
Network Working Group S. Sreemanthula
Internet-Draft Nokia
Expires: September 2, 2006 G. Daley
Panasonic
S. Faccin
Nokia
E. Hepworth
Siemens/Roke Manor Research
Q. Xie
Motorola
S. Das
Telecordia
March 2006
Requirements for a Handover Information Service
draft-faccin-mih-infoserv-02.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 September 2, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Sreemanthula, et al. Expires September 2, 2006 [Page 1]
Internet-Draft Requirements for an IS March 2006
Handover Information Services may be used to assist handovers between
one network to another network or within a network, based on stored
network knowledge. Information Services can be used to provide
essential network related information e.g. topology and channel
information which may allow a moving host to select an appropriate
link-layer connection to make, amongst available networks, whether
using the same technology or heterogeneous technologies.
This document is an effort to describe use cases and transport
requirements for handover information services, when they are
transported over IP networks.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Information Services . . . . . . . . . . . . . . . . . . . 3
1.2. Scope of work on information services . . . . . . . . . . 4
2. 802.21 Media Independent Information Services . . . . . . . . 4
3. Information Service Reference Model . . . . . . . . . . . . . 4
4. Scenarios for IS Transported over IP . . . . . . . . . . . . . 5
5. Protocol Development Scope . . . . . . . . . . . . . . . . . . 8
5.1. Information Service Interfaces . . . . . . . . . . . . . . 9
5.2. Messages Exchanges . . . . . . . . . . . . . . . . . . . . 10
5.3. Information Service Discovery . . . . . . . . . . . . . . 11
5.4. Transport-Layer Issues . . . . . . . . . . . . . . . . . . 12
5.5. Security Association Negotiation . . . . . . . . . . . . . 13
6. Requirements for Transport over IP . . . . . . . . . . . . . . 13
6.1. Summary of requirements . . . . . . . . . . . . . . . . . 14
7. Outstanding Issues . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Transport Issues . . . . . . . . . . . . . . . . . . . . . 16
7.2. Discovery Issues . . . . . . . . . . . . . . . . . . . . . 17
7.3. Security Issues . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8.1. Attacks against service entities . . . . . . . . . . . . . 19
8.2. Attacks against information . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Sreemanthula, et al. Expires September 2, 2006 [Page 2]
Internet-Draft Requirements for an IS March 2006
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.
Information Services (IS) are one part of handover services used to
provide network related information about the current or neighboring
networks with same or different access link technology. This allows
the network or host to make informed decisions of which network to
handover to or handover operations to undertake either in response to
certain events, or when planning controlled or commanded handovers.
The Information Services work complementary to the mobility
management protocols in the capacity that they are utilized before
making decisions for handovers.
A current focus for handover services over IP is on Information
Services delivery and transport.
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).
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
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.
Sreemanthula, et al. Expires September 2, 2006 [Page 3]
Internet-Draft Requirements for an IS March 2006
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 4. The extent of protocol development work to be
undertaken is elaborated on in Section 5.
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. 802.21 Media Independent Information Services
IEEE is currently working on Information Services as part of 802.21
Media Independent Handover Services (MIHS).
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 4.
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].
3. Information Service Reference Model
Entities involved with handover information services perform the
roles of an Information Services client (IS client), Information
Services Proxy and an Information Services server (IS-Server).
Relative positions of client and server, and the interfaces between
them may produce different requirements, depending on the type of
communication. Essentially, they fall under the category of i) user
to network communications (UNC) or ii) network to network
Sreemanthula, et al. Expires September 2, 2006 [Page 4]
Internet-Draft Requirements for an IS March 2006
communications (NNC).
Figure 1 presents a reference model for both for single and mutihop
communication of Information Services. The reference model shows
both client-server, client-proxy-server and client-server-server
models. The IS-Proxy role is to forward or route the IS
communications to the intended destination IS-Server. IS-Server
terminated IS communications, however it may initiate a new IS
communications with another IS-Server. It is possible that IS-Proxy
may present server-server communication path. The IS-Proxy and the
IS-Server may reside either within its administrative domain, or in
another domain.
------------ -----------
| IS-client|<-------|------>|IS-Server|
------------ UNC -----------
------------ ----------- -----------
| IS-Client|<-------|------>|IS-Proxy | <-----|------> | IS-Server|
------------ UNC ----------- NNC -----------
------------ ----------- -----------
| IS-Client|<-------|------>|IS-Server| <-----|------> | IS-Server|
------------ UNC ----------- NNC -----------
Figure 1: Information Services Reference Model and Interfaces
In order to support the above models, an Information Service system
would need to provide more services than just a transport functions
such as, discovery of proxy and Information servers, security
association between client-server, client-proxy-server, proxy-server
and server-server in a variety of deployment scenarios.
4. 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.
Sreemanthula, et al. Expires September 2, 2006 [Page 5]
Internet-Draft Requirements for an IS March 2006
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
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 and Figure 3) 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.
If IP is used for information services transport, for example, in
(Figure 2), 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 2: IS-Server on Subnet Router
Information service servers deployed outside the mobile node's subnet
present both advantages and challenges. As illustrated in Figure 3,
an IS-Server outside a subnet doesn't require explicit support from
devices the mobile's link. Therefore the server is able to be
Sreemanthula, et al. Expires September 2, 2006 [Page 6]
Internet-Draft Requirements for an IS March 2006
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 5.3.
Additionally, the location of information services addressable
outside the subnet has security implications which are described in
Section 8.
/--------\
I / \
----- -------- -------- /----/ -------- \----\
|[ ]| | |-----| |---/ | ---- | \
|ooo|<----------------------------------------->| |IS| | \
|ooo| | | | | \ | ---- | /
----- -------- -------- \ -------- /
Host Access Router \----\ Information/----/
Point \ Server /
-------- -------- / \--------/
| |-----| | / Distribution
| | | |-------/ Network
| | | |
-------- --------
Access Router
Point
Figure 3: Standalone IS-Server
As described in [1], 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
Sreemanthula, et al. Expires September 2, 2006 [Page 7]
Internet-Draft Requirements for an IS March 2006
request/identify if an information server has a particular service.
The scenario is illustrated below:
/--------\
I -------- / -------- \
----- | | /----/ | ---- | \----\
|[ ]|<------------------------------------------->|IS| | \
|ooo| | ---- | / | ---- | \
|ooo|<----------------------|>|IS| |--\ | | /
----- | ---- | \ -------- /
Host -------- \----\ Network /----/
Router \ Server /
/ \--------/
-------- / Distribution
| | / Network
|Router|------/
| |
--------
Figure 4: Separation of Information Content Option
In Figure 4, separate information classes are shown on the different
servers. 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 or access-specific information services
would be accessed for local information services.
This is to be contrasted with the previous unified information
services deployment model from deploying the information server at
one of the particular locations in or Figure 3. 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.
5. Protocol Development Scope
This section describes the areas requiring investigation or
Sreemanthula, et al. Expires September 2, 2006 [Page 8]
Internet-Draft Requirements for an IS March 2006
standardization to provide transport of information services over IP.
5.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 5, 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.
--------- ----------- -----------
| | |IS-Proxy/| | |
|mobile |-------->|IS-Server|-------->|IS-Server|
--------- ----------- -----------
|
domain A |
- - - - - - - - - - - -|- - - - - - - - - - - - -
domain B |
V
----------- -----------
|IS-Proxy/| | |
|IS-Server|-------->|IS-Server|
----------- -----------
Figure 5: Relationships between Information Service entities
The mobile to IS-Proxy/IS-Server (UNI) 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.
Sreemanthula, et al. Expires September 2, 2006 [Page 9]
Internet-Draft Requirements for an IS March 2006
After security association establishment, information requests and
responses are exchanged.
The IS-Proxy to IS-Server or the IS-Server to IS-Server (NNI)
interface is required if information servers need to retrieve
additional information from each other. For this interface, message
formats are the same as the UNI 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.
5.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 6, 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
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 6: 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.
Sreemanthula, et al. Expires September 2, 2006 [Page 10]
Internet-Draft Requirements for an IS March 2006
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. Optionally, 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.
Discovery exchanges (1 and 2) rely upon the underlying discovery
protocol, as described in Section 5.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 5.4, and additional considerations for security
association negotiation are provided in Section 5.5.
5.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
Sreemanthula, et al. Expires September 2, 2006 [Page 11]
Internet-Draft Requirements for an IS March 2006
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.
5.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.
Additionally, 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
Sreemanthula, et al. Expires September 2, 2006 [Page 12]
Internet-Draft Requirements for an IS March 2006
datagram oriented services to be used or the mobile node's preference
[25].
5.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.
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.
6. 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
Sreemanthula, et al. Expires September 2, 2006 [Page 13]
Internet-Draft Requirements for an IS March 2006
is to be considered as a starting point for discussion.
6.1. Summary of requirements
o Provide an information service transport mechanism which works
with both IPv6 and IPv4.
o Distinguish between the packet source and query source (allow
proxies).
o Provide transport of information services through NAT for IPv4.
o Provide transport of information services through firewall for
IPv4.
o Provide transport of information services through firewall for
IPv6.
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.
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).
Sreemanthula, et al. Expires September 2, 2006 [Page 14]
Internet-Draft Requirements for an IS March 2006
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 and wireless device impersonation (with
authentication).
o Protect against data insertion and modification (provide message
authentication).
o Protect against replay attacks.
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.
o Allow for security services to be diabled.
o Changes to the IS payload should not affect the security
mechanisms defined in the underlying transport mechanism to ensure
protocol modifications and evolutions defined in payload.
7. 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
Sreemanthula, et al. Expires September 2, 2006 [Page 15]
Internet-Draft Requirements for an IS March 2006
processes.
As design choices are made, they will be cataloged here, and this
section may eventually move to an appendix.
7.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.
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
Sreemanthula, et al. Expires September 2, 2006 [Page 16]
Internet-Draft Requirements for an IS March 2006
using application-layer information. In this case, it may also be
possible to provide message reliability, on top of a datagram
oriented transport service.
7.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
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
Sreemanthula, et al. Expires September 2, 2006 [Page 17]
Internet-Draft Requirements for an IS March 2006
Servers for multiple classes allow additional flexibility, but
potentially incur additional signalling costs. This issue is
described in Section 4.
7.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.
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.
Sreemanthula, et al. Expires September 2, 2006 [Page 18]
Internet-Draft Requirements for an IS March 2006
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.
8. 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
within the network, and the information itself.
8.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
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.
8.2. Attacks against information
Attacks against the information exchanged between the information
Sreemanthula, et al. Expires September 2, 2006 [Page 19]
Internet-Draft Requirements for an IS March 2006
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.
9. Acknowledgements
Many thanks to James Kempf for an informed and thorough review of
this document.
10. References
10.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.
10.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.
Sreemanthula, et al. Expires September 2, 2006 [Page 20]
Internet-Draft Requirements for an IS March 2006
[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.
[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.
Sreemanthula, et al. Expires September 2, 2006 [Page 21]
Internet-Draft Requirements for an IS March 2006
[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.
Sreemanthula, et al. Expires September 2, 2006 [Page 22]
Internet-Draft Requirements for an IS March 2006
Authors' Addresses
Srinivas Sreemanthula
Nokia
6000 Connection Dr.
Irving, Texas 75039
USA
Phone: +1 972 894 4356
Email: Srinivas.Sreemanthula@nokia.com
Greg Daley
Panasonic Digital Networking Laboratory
2 Research Way
Princeton, New Jersey 08540
USA
Phone: +1 609 734 7334
Email: greg.daley@research.panasonic.com
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
Sreemanthula, et al. Expires September 2, 2006 [Page 23]
Internet-Draft Requirements for an IS March 2006
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
Subir Das
Telecordia
Subir's Address
Subir's Address 00
US
Phone: +1-732-699-2483
Email: subir@research.telecordia.com
Sreemanthula, et al. Expires September 2, 2006 [Page 24]
Internet-Draft Requirements for an IS March 2006
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 (2006). 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.
Sreemanthula, et al. Expires September 2, 2006 [Page 25]