Internet DRAFT - draft-hepworth-mipshop-mih-design-considerations
draft-hepworth-mipshop-mih-design-considerations
MIPSHOP E. Hepworth
Internet-Draft R. Hancock
Intended status: Informational Roke
Expires: April 26, 2007 S. Sreemanthula
Nokia Research Center
S. Faccin
Intel Corporation
October 23, 2006
Design Considerations for the Common MIH Protocol Functions
draft-hepworth-mipshop-mih-design-considerations-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The MIPSHOP working group is currently developing functionality to
support media independent handover services, which are intended to
aid IP handover mechanisms between heterogeneous wired and wireless
access systems. These handover services provide a mechanism by which
Hepworth, et al. Expires April 26, 2007 [Page 1]
Internet-Draft MIH Design Considerations October 2006
information such as the presence of neighbouring links and networks,
and their associated characteristics, can be delivered to mobile and
other network nodes for the purposes of supporting better handover
decisions. A key component of the solution is the set of protocols
that is used to deliver the various types of information to the
appropriate destination node. A separate problem statement draft
outlines a structure for this set of protocols as a unified set of
common functions, supporting a more diverse set of application
specific protocols. This draft outlines the key considerations that
have to be considered when selecting or designing protocols for such
common functionality. This draft is offered for use as a mechanism
to capture working group discussions on the design of the common
protocol functions during their initial development, without imposing
a particular solution on the discussion process. It is not intended
as a long term output.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Inter-layer Interactions . . . . . . . . . . . . . . . . . . . 4
3. Protocol Design Considerations . . . . . . . . . . . . . . . . 5
3.1. Initial Discovery and Routing . . . . . . . . . . . . . . 5
3.2. Signalling Peer Changes . . . . . . . . . . . . . . . . . 8
3.3. Message Transport . . . . . . . . . . . . . . . . . . . . 9
3.4. State Management . . . . . . . . . . . . . . . . . . . . . 10
3.5. Mutiplexing and Extensibility . . . . . . . . . . . . . . 12
3.6. Network Layer Interactions . . . . . . . . . . . . . . . . 12
3.7. Message Security . . . . . . . . . . . . . . . . . . . . . 13
3.8. Overload Management . . . . . . . . . . . . . . . . . . . 14
3.9. Failure Handling . . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Hepworth, et al. Expires April 26, 2007 [Page 2]
Internet-Draft MIH Design Considerations October 2006
1. Introduction
The MIPSHOP working group is currently developing functionality to
support media independent handover services, which are intended to
aid IP handover mechanisms between heterogeneous access systems, both
wired and wireless. These handover services provide a mechanism by
which information such as the presence of neighbouring links and
networks, and their associated characteristics, can be delivered to
mobile and other network nodes for the purposes of supporting better
handover decisions. An initial set of handover services, and the
information that these services exchange between two peers, is under
development within IEEE 802.21. These services are referred to as
the Media Independent Handover Services (MIH Services) and the
initial set consists of the event, command and information services
(ES, CS and IS); there are also System Management messages which
configure the operation of the other MIH protocols themselves. The
transport security and related aspects associated with delivery of
these messages across the network at the IP level (including over the
air where direct layer 2 transport is not being used) will not be
addressed by IEEE 802.21. It is the expectation that this area will
be addressed by the MIPSHOP working group.
An architectural framework and set of common requirements is proposed
in the problem statement draft [1], which includes a decomposition of
the overall MIH problem into a common part and a set of MIH services
that are layered over the top. It is intended that the common part
is suitable not only for the delivery of IEEE 802.21 MIH services
(ES/CS/IS), but can also be applied to non-802.21 architectures and
handover services.
This draft outlines detailed design considerations for the common
part delivery mechanism, with the goal of providing a basis for
discussing different solutions and providing a means to ensure that
important solution requirements are considered by subsequent
proposals. This draft is not intended as a comprehensive analysis of
different solutions, but does include some discussion of solution
characteristics and possible solution options as examples where
appropriate. It is assumed that the requirements on the common part
imposed by the IEEE 802.21 MIH services are wholly captured in the
problem statement draft [1]. This draft is offered for use as a
mechanism to capture working group discussions on the design of the
common protocol functions during their initial development, without
imposing a particular solution on the discussion process. It is not
intended as a long term output.
The structure of this document is as follows. Section 2 introduces
some general design goals for the common part, Section 3 describes a
set of design considerations that should be taken into account when
Hepworth, et al. Expires April 26, 2007 [Page 3]
Internet-Draft MIH Design Considerations October 2006
developing a solution, Section 4 provides security considerations,
and Section 5 summarises the conclusions and open issues.
2. Inter-layer Interactions
The framework presented in [1] decomposes the MIH protocol problem
into two parts; the Information and Information Exchange mechanism,
and the functionality common to all MIH services. This is
subsequently referred to as common protocol functionality. The
intention of the separation is to allow all MIH services access to
this functionality from a single protocol module without having to
re-implement or re-integrate the same functionality individually for
each MIH service. The problem statement presents an outline of this
decomposition; however, the precise details of the split of
functionality and interaction between the layers need to be refined
as the design of the common part proceeds. Indeed, one important
design consideration is that it should be possible to define these
interactions precisely and in an easily implementable manner. This
section indicates some specific inter-layer interaction issues that
need to be taken into account in this way.
One of the key questions is how MIH service peer identity knowledge
is split between the service and the common part. In other words,
does the MIH service have knowledge about the location of a peer (in
terms of IP address), or does it simply pass a message to the common
protocol functionality and expect it to be delivered. If the MIH
service manages the resolution of peer identities to IP addresses,
issues such as NAT traversal can become more complicated (as
discussed in Section 3.6).
It is assumed that the peer entities supporting an MIH service hold
some sort of service layer state information (such as link
measurements or event subscriptions) that is being accessed or
updated in some way. So, a second issue is whether there is any
relationship between the management of this state lifetime and the
common protocol functionality. This draft assumes that service layer
state lifetime is transparent to the common protocol functionality,
and operations such as soft state refresh are not explicitly visible
at the lower level. However, note that the common protocol
functionality can be used to transmit refresh messages generated by
an MIH service if such a refresh mechanism is required, but the
generation and timing of these messages is the responsibility of the
MIH service.
In the overall problem description it can be seen that some
signalling transactions involve a sequence of three or more nodes
rather than a simple peer to peer communication. There is therefore
Hepworth, et al. Expires April 26, 2007 [Page 4]
Internet-Draft MIH Design Considerations October 2006
a question of whether the common protocol functionality should be
explicitly aware of the complete chain of nodes involved in a
transaction, or whether it should see only the directly adjacent
peers. In this draft, we assume the latter case; therefore, the
concatenation of message exchanges along a sequence of nodes is
something that has to be managed within the MIH service itself; it
may even be an implementation issue for the MIH services, in the same
way that chains of SIP signalling nodes can be built up out of back-
to-back user agents.
In the long term, in order to make the inter-layer separation
precise, a service interface between the MIH service and the common
protocol functionality should be defined. This service interface
would expose a set of functionality that can be used by the MIH
service to discover and send messages to peer entities, and could
allow the common protocol functionality to be configured to suit
particular needs associated with an MIH service.
3. Protocol Design Considerations
There are a number of key considerations that should be considered
when designing a solution to support MIH message delivery. These are
described in the following subsections.
3.1. Initial Discovery and Routing
When an MN joins a network, it must be able to discover various
network nodes that support the MIH services that it wishes to use.
The location of the MIH services in the network is not fixed. Some
may be supported locally by the access network, whilst others may be
supported by a node deeper in the network, or a sequence of such
nodes. The sequence may reach back all the way to the user's home
network.
The process of discovering a suitable peer and establishing a route
towards it has a number of aspects that need to be considered. The
first of these is how MIH services are identified. For an MN
interested in a particular MIH service, the identity of the service
must be usable in some discovery and name resolution procedure that
ultimately returns an IP address to the interested MN. Therefore,
the name space within which MIH services are identified has an
interaction with the set of possible discovery mechanisms. For
example, use of a particular discovery procedure may require
extensions to support a new namespace or new registrations within an
existing one. The selection of a suitable peer and its subsequent
use may be based on a number of aspects including the capabilties of
the MIH peer and the ability to setup a secure communications channel
Hepworth, et al. Expires April 26, 2007 [Page 5]
Internet-Draft MIH Design Considerations October 2006
to that device. Therefore, the discovery process has interactions
with other transport layer functionality, which may need to be
considered as part of the discovery procedure itself.
In the simplest case, the selection of an appropriate peer can be
left entirely to the network, based purely on the service identifier.
Where the MIH service is entirely implemented in the local access
network, this is probably sufficient. In such a scenario, the MN
could send a query to the network requesting support for a particular
MIH service, and allow the network to select the most appropriate MIH
peer. Some options for this are discussed below.
More sophisticated services may require interactions further into the
network, for example involving the user's home operator; this would
be an example of "proxy operation". This may be influenced by
configuration information provided by the MN, such as operator
identity. There are two basic approaches that can be considered:
o a simple method, especially from the MN perspective, is to treat
this as a generalisation of the basic case where the discovery
process is repeated recursively along the proxy chain.
o a more complex method is to require the MN to discover the
complete set of nodes up to and including the signalling endpoint.
This gives more control over the process to the MN at the cost of
having to expose more details about inter-network relationships.
A particular issue is the precision with which the initial discovery
process takes place. One possibility is that the initial discovery
detects a candidate set of nodes supporting any MIH services;
subsequently, messages within the MIH protocols themselves determine
the detailed capabilities of each node, and decide which nodes to use
for which specific purpose. The alternative is that the initial
discovery process incorporates these selection criteria directly,
which allows a more targeted discovery of the initial candidate set,
at the cost of requiring a richer definition of the set of possible
service at the layer boundary between the MIH services and the common
protocol functions. The first approach is simplest and may be
appropriate in limited scale networks (or where the equivalent
functionality is being developed at Layer 2). However, it can easily
lead to scaling difficulties in larger scale networks, where, even
though the final set of communicating nodes may be small, the size of
the candidate set could be very large. Therefore, the ability of the
initial discovery criteria to include such additional criteria needs
to be considered. The openness in this question is reflected in the
openness of the term 'MIH service'; in the 802.21 context for
example, it could refer either to the complete set of 802.21 MIH
services, or to a specific one, such as IS. This issue affects
Hepworth, et al. Expires April 26, 2007 [Page 6]
Internet-Draft MIH Design Considerations October 2006
primarily the discovery process; for the rest of this document, we
continue to use the term MIH service, always bearing in mind this
spectrum of possibilities for what it could refer to.
The discovery and routing functionality could either be invoked
directly by the MIH service, or could be integrated with the common
protocol functionality. In the former case, the MIH service would be
responsible for carrying out the discovery exchange with the network,
and would have to indicate the results of the discovery procedure to
the common part to allow delivery of mesasges to the appropriate
peer. In the latter case, the MIH service would simply request the
delivery of a message from the common protocol functionality, and
leave the discovery and resolution procedures to the lower layers.
Either approach is feasible, but the following issues should be
considered when designing a solution:
o support for discovery before full IP connectivity. In some cases,
the MN may want to communicate with an MIH service before full IP
connectivity is available.
o transparency of the network topology. The internal structure of
the network should be hidden from the MIH service, which allows
arbitrary network deployments, and changes to those deployments
without impacting the MIH service.
o localisation of information. The information associated with
supporting a particular MIH service should be located in as few
places as possible to aid failure recovery, and reduce
requirements on MNs to hold large amounts of state information.
o elimination of duplicates and reduction of round trips. To reduce
latency and network load, the required information should be
discovered using as few signalling messages as possible both in
the initial discovery case and post handoff where it is necessary
to check that the signalling relationships are still valid. For
example, if a peer for a particular MIH service has already been
discovered that can be used for an alternative MIH service as
well, it would be preferable to avoid performing a duplicate
discovery procedure when the information is already known.
o adaptation of the discovery mechanisms. Some approaches to
discovery may be particularly applicable to specific technologies
or in particular administrative environments and therefore a
single perfect solution may not be attainable. However, it is
important to localise the impact of this variability as much as
possible.
Given the above considerations, it seems likely that the most
Hepworth, et al. Expires April 26, 2007 [Page 7]
Internet-Draft MIH Design Considerations October 2006
appropriate place to implement the discovery and routing
functionality is as part of the common protocol functionality. It is
possible that the discovery process could be bootstrapped from other
protocol state or protocol exchanges, but the suitability of these
approaches and the architectural assumptions associated with their
use needed to be assessed. For example, DHCP [3][4] is a possible
candidate, but would only be most suitable for link technoloiges
where this is used as an address assignment method. Another
possibility is SLP [5], although this is not curently widely
deployed; mDNS [2] falls into the same category. DNS itself can also
be used (for example, SRV records [6] support the discovery process
for services associated with a particular DNS domain), however, it is
difficult to use them to do service discovery in a way that
automatically takes into account the current network point of
attachment. Router level advertisements are also an option, but the
mechanism may be hard to extend to support advertisement of all MIH
services, so this would be mainly to provide bootstrap to some other
approach.
3.2. Signalling Peer Changes
As well as the initial discovery of the peers for signalling, it must
also be considered how to handle the case where the correct
signalling peer changes while the MN is attached to the network.
Several scenarios can be considered:
o The MN point of attachment changes, and according to the local
network architecture a new signalling peer is now the appropriate
serving node for it.
o The signalling peer fails, and a backup must be used instead.
o The network infrastructure is reconfigured internally (changing
the topology or set of available services at a given node), which
means that a different peer or set of peers should be used.
In so far as the common protocol functions take responsibility for
the initial discovery process, they must also take care of the
rediscovery and rerouting needed in these types of circumstances.
(Conversely, if external discovery approaches are used, then it must
be defined how these handing the peer change problem.)
A very simple and robust approach is simply to repeat the initial
discovery process periodically. This always works after some time
lag, but leads to an awkward tradeoff between efficiency (which is
reduced if the repetition rate is high) and reactiveness (which
requires a high refresh rate). This problem can be mitigated if a
long period is used but hints are allowed to trigger the process on
Hepworth, et al. Expires April 26, 2007 [Page 8]
Internet-Draft MIH Design Considerations October 2006
particular events. Indeed, the MIH services themselves can be used
to deliver such triggers during periods of correct operation,
requiring fallback to periodic discovery only to handle failure
scenarios.
Whatever approach is used here, it should be noted that there needs
to be an interaction between the service layer and common protocol to
convey not just the possibility that rediscovery is needed, but also
to indicate that a peer change has taken place.
3.3. Message Transport
Message transport is responsible for the actual delivery of messages
between peer entities, and should be configurable to suit the needs
of the particular MIH service, for example, reliable versus expedited
delivery. Note that it is not assumed that a single instance of the
common protocol functions has to be configured and used in exactly
the same way by all the MIH services at any given node. Different
services might request different levels of transport support from a
single instance; indeed, a service might request different transport
characteristics for different transaction types. The main transport
considerations include:
Congestion Avoidance: some form of congestion control is required to
guarantee that MIH service operation cannot damage the network.
This is particularly critical for services that may transport
large volumes of data (e.g. to prevent them issuing large numbers
of parallel requests if messages are already being dropped because
of congestion effects). Congestion control could either be
provided in a specialised way as part of a custom transport
protocol directly over IP, or provided through the use of an
existing protocol such as TCP or SCTP. In the latter case,
standard transport parameter estimation algorithms may need to be
assessed in order to work out their suitability for different MIH
services. It is assumed that the various MIH services do not have
specialised requirements for congestion handling.
Reliability: some MIH services require reliable delivery of their
messages and this has to be achieved efficiently in an environment
(i.e. mobile/wireless) where data transfer latency can be highly
variable between different technology types and data loss may be
high. This reliability can either be implemented within the MIH
services themselves or provided by the common transport. While
implementation within the MIH service is technically possible, it
does not make best use of the sophistication that has been
achieved in transport layer optimisation in recent years. For
example, a full implementation would need to consider
functionality such as windowing, adaptive retransmission timeouts
Hepworth, et al. Expires April 26, 2007 [Page 9]
Internet-Draft MIH Design Considerations October 2006
and loss detection mechanisms, which are non-trivial to design.
In addition, relying on the service layer to handle all
reliability issues opens the question of whether timer values
should be based on message transfer latency or application
processing latency, and these two can differ significantly.
Allowing the option of a reliable transport service means that the
additional recovery mechanisms within the service layer can be
made very simple and robust because they do not need to be
optimised for efficient recovery of message loss within the
network.
Fragmentation: the transport protocol must be capable of performing
fragmentation when the amount of data in a message to be sent is
too big to fit into a single IP packet. IP fragmentation could be
used, but would require Path MTU discovery procedures to be
supported, unless very conservative path MTU estimates could be
assumed by default. However, note that fragmentation at the IP
layer amplifies packet loss rates because the loss of a single
fragment destroys the entire packet, and also the entire packet
has to be retransmitted. Therefore, it is preferable to support
the fragmentation requirements within a reliable transport.
Re-ordering and Head of Line Blocking: depending on the lower layer
in use, messages may arrive out of order. If the transport does
not provide in order delivery, it will be the responsibility of
the MIH services themselves to handle this problem. In addition,
head of line blocking may be an issue in cases where multiple MIH
services are using a single connection between two peer entities.
Duplicate Message Detection: multiple copies of a message may arrive
at a node. Does the transport layer provide duplicate message
detection, or is this left up to the MIH service?
3.4. State Management
The operation of the MIH services requires the existence of service
layer state within the network, for example, registrations of
interest for particular types of events or location information to
configure the delivery of neighbourhood lists. Various transaction
models can be identified that allow different entities to initiate an
MIH message exchange to set up such state. The transaction sequences
that are permitted to install and manipulate this state will most
likely be MIH specific (it is unlikely that a single transaction
model will be applicable to all MIH services), but even so there will
be impacts on the common protocol functionality, for example,
influencing the symmetry required in the message delivery mechanism.
In addition, the dependency of one set of MIH transactions on another
has to be considered, for example, can transactions be nested, or can
Hepworth, et al. Expires April 26, 2007 [Page 10]
Internet-Draft MIH Design Considerations October 2006
they overlap with each other.
Example transaction sequences include:
1. MN initiated only; where exchanges can only be initiated by the
MN, and the network only responds to explicit requests for
information.
2. MN and NN intiated; where both the MN can request information,
and the NN can deliver information asynchronously to the MN.
The current MIH services that have been identified require MN and NN
initiated exchanges as a minimum.
The types of state information that are manipulated during an MIH
exchange include:
o MIH Service Layer State: information related to the particular MIH
service, that is accessed and maintained by that service.
o Peer State: including peer capabilities, and any negotiated
parameters.
o Routing State: such as next hop information for routing to a peer
entity.
o Security State: associated with a particular message exchange.
o Transport State: counters and timers associated with the delivery
of individual message fragments (datagrams) and their
retransmission and reassembly.
The first type of state is MIH service specific, and should be
transparent to the common protocol functionality. The latter four
types could be managed by either the MIH service or the common
protocol functionality, although the second option seems preferable
(as will be discussed in Section 3.1 and Section 3.7). A fundamental
question that has to be considered is how these different types of
state information are related to each other. For example, if a
connection to a peer entity is lost, is the MIH service state now
considered to be invalid? Typically, it is preferable to avoid such
hard dependencies between the state at different layers, since it
reduces the freedom within the common protocol part to manage
connections most efficiently. In other words, the service layer
state is assumed to be managed entirely within the service layer
itself.
Hepworth, et al. Expires April 26, 2007 [Page 11]
Internet-Draft MIH Design Considerations October 2006
3.5. Mutiplexing and Extensibility
Multiple MIH services have already been defined, and it is highly
likely that different MIH services will be co-located within single
nodes (this will definitely be true of the MN, and may be true for
infrastructure nodes depending on the MIH deployment). A
consideration that needs to be addressed is how multiple MIH services
are handled by the common protocol functionality.
One option would be to hide the presence of multiple MIH services
completely. However, this would limit the ability of a node to talk
to different MIH peers depending on which service is being used, if
the discovery is handled as part of the common protocol
functionality. An alternative is to expose the multiple MIH services
individually to the common protocol functionality, and allow it to
multiplex MIH service messages at the transport level if appropriate
(for example, if both messages are destined for the same peer entity
and have the same transport requirements).
In addition, the extensibility of the MIH services needs to be
considered. For example, if multiple versions of an MIH service are
available, this may impact the common protocol functionality in terms
of discovery of compatible MIH service implementations (see
Section 3.1).
3.6. Network Layer Interactions
The MIH functionality interacts with the network layer in two
distinct ways.
Firstly, the signalling messages must be able to pass through the
network between signalling peers even when the network infrastructure
contains addressing boundaries and firewalls where policies on
allowed traffic types are imposed. Therefore, it is important to
limit the protocols used to support the common functionality as far
as possible to those that such middlebox devices can be configured to
process and support. For example, standard transport protocols such
as TCP or UDP are relatively easy to deploy especially if
transactions are initiated from the internal side of the middlebox
whereas ICMP extensions are much more problematic.
Secondly, if some parts of the MIH service payload contain addressing
information, such as the current IP address associated with a device
or addresses of other access routers, NAT traversal becomes much more
difficult as the NAT may have to change these payloads. It is
preferable to standardise the location of such information across all
the different MIH services so that NATs do not have to support
different Application Layer Gateways for each and every MIH service
Hepworth, et al. Expires April 26, 2007 [Page 12]
Internet-Draft MIH Design Considerations October 2006
that has been or will be defined. This suggests that addressing
information should be carried at the lowest possible level in the MIH
protocol stack.
3.7. Message Security
Message security is needed to protect the information exchanges
between MIH service peers. This section focuses on authentication
and authorisation aspects associated with MIH service support; DoS
and overload situations are considered in Section 3.8.
It is highly desirable to reuse standard channel security protocols,
but there are still several possible protocol choices. There are a
number of considerations:
Authentication and Key Management: authentication can either be
performed unilaterally, where only one party confirms the identity
of the other, or mutually, where both parties confirm each other's
identity. For some MIH services, it is important that mutual
authentication is possible, since the information exchanged
initiates complex processing in both peers. Although this does
not necessarilty imply that the MIH service must perform the
authentication itself, it may still be important for the service
to be aware of the authenticated identity of the peer it is
communicating with. Because standard channel security protocols
necessarily include peer authentication to provide keying
material, it is natural to think of the authentication
functionality as being part of the common protocol functionality.
Credential Reuse: message security depends on the existence of
credentials to identify the peers taking part in the signalling
exchange; the credentials are used in the protocols to provide
node authentication and keying material for message protection
itself. Different protocols can exploit different credential
types and so it may be possible to select protocols in order to
build on existing relationships in the network.
Authorisation: authorisation controls who is allowed to perform what
actions on state information and message exchanges between MIH
peers. It may also be possible to build MIH trust models that
reuse existing relationships in the network, for example, if an
MIH service is provided locally by an access network to an MN, the
fact that the information is being relayed by a trusted AP may
indicate to the MN that the information is from a valid source.
In cases where the MIH service is provided by an operator deeper
in the network, roaming relationships could be re-used to support
delivery of MIH information. However, in this draft we assume
that the authorisation problem is handled primarily within the MIH
Hepworth, et al. Expires April 26, 2007 [Page 13]
Internet-Draft MIH Design Considerations October 2006
services themselves.
Privacy: various identifiers will be used by the MIH service and the
common protocol functionality to support authentication, peer
discovery and message delivery. These identifiers will relate in
some cases to users and organisations whose privacy needs to be
respected and whose identity should not be freely disclosed except
to authorised parties. Therefore, any security solution needs to
consider how such identifier information is protected.
The visibility that the MIH service has of the security functionality
also needs to be thought about. One extreme would be for the MIH
service to be responsible for setting up the secure channel over
which to communicate, but this may require the MIH service to have
more knowledge about the underlying network topology than is
otherwise necessary. Alternatively, the common protocol
functionality can include the security aspects, and the MIH service
can request a secure channel from the lower layers when establishing
a relationship with an MIH peer based on some MIH specific security
policy. This has the added advantage that different security
protocols can more easily be integrated into the MIH protocol suite
(once into the common part, as opposed to once for every MIH
service).
3.8. Overload Management
Overload management handles situations where a node is flooded with
messages. These situations can occur both during normal use, or as a
result of a flooding attack by a malicious user. In either case, the
common protocol functionality has a role to play in handling such
situations needs to be considered, because these problems are closely
associated with the message security and congestion control aspects.
In particular, it is important that overload situations are
considered for the design of the common protocol functionality as it
is impossible to support reliability without overload management
strategies in place.
The overload issue is related to processing within a node when it
starts to receive messages faster than it can process them, and what
facilities are provided within the common protocol functionality and
MIH service to handle these situations. In addition, nodes should
also detect that a peer is overloaded, and try and mitigate the
situation somehow. One solution is to provide some rate control
either at the MIH service, in the common protocol functionality or
both. The common protocol functionality cannot entirely solve this
problem because the adaptation to overload situations may be MIH
service specific. However, the overload situation can be detected
and indicated to the MIH service. It may be necessary to provide one
Hepworth, et al. Expires April 26, 2007 [Page 14]
Internet-Draft MIH Design Considerations October 2006
or more signalling channels to cope with different message priorities
in this case. Some elements of the common functionality must operate
even in the absence of a congestion or flow-controlled transport
connection, such as the initial discovery process. Typically their
design must incorporate some sort of robust overload management
mechanism, such as exponential backoff. If a standard discovery
protocol (like DHCP) is being used, this behaviour is built in.
3.9. Failure Handling
Nodes may fail at any time, and some mechanism is needed to allow
graceful recovery. Failure situations include:
o inability to discover a peer - this is related to discovery and
routing Section 3.1.
o the loss of a peer, which must be detected.
o local shutdown, and informing current peer nodes.
As for overload management, the common protocol functionality cannot
be solely responsible for addressing this issue since some failure
conditions will affect only the MIH service and not the lower
communications layers. Also, the recovery procedure will be partly
application specific. However, other failure conditions can be
detected more rapidly and efficiently at lower layers of the protocol
stack; for example, rather than implementing a keepalive mechanism
within each MIH service, a single mechanism at the lower level can be
used to check the overall status of a given node. Therefore, the MIH
service must be partially responsible for detecting the loss of an
MIH peer, but may use hints provided by the common protocol
functionality to speed up the detection process.
For local shutdown cases, it should be the responsibility of the MIH
services to inform peer nodes of the situation.
4. Security Considerations
When developing a solution for supporting the exchange of MIH service
information between two peer devices, there are a number of security
issues that need to be taken into account.
The discovery and information exchange may occur in situations where
full IP connectivity is unavailable. In this case, the secure
transport cannot be provided end-to-end, but could potentially be
provided between a proxy device and the peer MIH, for example,
between an access router and appropriate server. The trust model and
Hepworth, et al. Expires April 26, 2007 [Page 15]
Internet-Draft MIH Design Considerations October 2006
security implications of supporting this mode of operation needs to
be investigated. In the alternative scenario with end-to-end IP
connectivity, the security issues are slightly simpler though
securing the discovery remains an issue. The co-existence of the
security mechanisms for the full and partial IP connecivity will need
to be considered.
The effect of Denial of Service attacks also needs to be managed, for
example, by reacting to overload situations (see Section 3.8). State
information is installed in nodes for both transport and MIH service
purposes; the processing associated with installing or managing this
state by nodes in the network should be kept to a minimum prior to
secure channel setup.
The identifier space that is used to support authentication, and how
privacy is managed for these identities is also a key concern. The
use of these identifiers to support authorisation needs to be
analysed, and these issues are discussed in more detail in section
Section 3.7. It is currently assumed that the common protocol
functionality must provide message (channel) security for the MIH
services to support message integrity/authentication.
5. Conclusions
This Internet Draft outlined a number of design considerations that
need to be taken into account when developing the common
functionality required by MIH services to exchange information
between peers. The main issue that needs to be considered is how to
split reponsibility for various parts of the functionality between
the MIH service and the common protocol part.
There is good justification for supporting certain aspects of the
required functionality in a common part that can be used by multiple
MIH services. This independence provides a way to hide the specifics
of a particular network from the MIH service, prevents the same
functionality being re-implemented multiple times, and supports
easier integration of new or enhanced protocols into the overall MIH
solution.
However, it is also possible that different MIH services will
ultimately have slightly different requirements from the underlying
transport, depending both on the type of information managed by the
MIH service, and the particular message that is being exchanged.
Therefore, it is important that the transport mode used for
particular message exchanges can be configured in some way by the MIH
service to suit its requirements.
Hepworth, et al. Expires April 26, 2007 [Page 16]
Internet-Draft MIH Design Considerations October 2006
It should also be noted that the common protocol functionality cannot
be wholly responsible for providing some aspects of the solution, for
example, reliability and overload management requires support at both
the lower layer, where information about network conditions is
readily available, and at the MIH service itself, where specific
information about the state managed by the service and the strategies
to react to certain conditions is maintained.
In terms of the protocols used by the common part, it is clear that a
single protocol will not be sufficient to meet all identified
requirements. Therefore, it is likely that the common part will in
fact be implemented as multiple protocols that are integrated below a
simple service interface exposed to the MIH services above.
6. References
[1] Hepworth, E., "Mobility Services: Problem Statement",
draft-melia-mipshop-mobility-services-ps-00 (work in progress),
September 2006.
[2] Cheshire, S. and M. Krochmal, "Multicast DNS",
draft-cheshire-dnsext-multicastdns-06 (work in progress),
August 2006.
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 3315, July 2003.
[5] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service
Location Protocol, Version 2", RFC 2608, June 1999.
[6] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
Appendix A. Acknowledgements
Thanks to Andrew McDonald for his inputs. This revised version of
the draft followed comments from Subir Das, Junghoon Jee, Yoshihiro
Ohba, Akbar Rahman, Behcet Sarikaya and Qiaobing Xie.
Eleanor Hepworth and Robert Hancock are partly funded by Ambient
Networks, a research project supported by the European Commission
Hepworth, et al. Expires April 26, 2007 [Page 17]
Internet-Draft MIH Design Considerations October 2006
under its Sixth Framework Program. The views and conclusions
contained herein are those of the authors and should not be
interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the Ambient Networks
project or the European Commission.
Authors' Addresses
Eleanor Hepworth
Roke Manor Research Ltd
Roke Manor
Romsey, SO51 0ZN
UK
Email: eleanor.hepworth@roke.co.uk
Robert Hancock
Roke Manor Research Ltd
Roke Manor
Romsey, SO51 0ZN
UK
Email: robert.hancock@roke.co.uk
Srinivas Sreemanthula
Nokia Research Center
6000 Connection Dr.
Irving, TX 75028
USA
Email: srinivas.sreemanthula@nokia.com
Stefano Faccin
Intel Corporation
Santa Clara, CA
USA
Email: stefano.m.faccin@intel.com
Hepworth, et al. Expires April 26, 2007 [Page 18]
Internet-Draft MIH Design Considerations October 2006
Full 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.
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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hepworth, et al. Expires April 26, 2007 [Page 19]
