Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[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]