[Mipshop] Comments on draft-melia-mipshop-mstp-solution-00
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Mipshop] Comments on draft-melia-mipshop-mstp-solution-00
First of all, I appreciate the Design Team members to work hard to
come up with the draft to meet IEEE 802.21 WG's expectation.
My comments are given below. As part of my IETF liaison task in
802.21 WG, I also requested two 802.21 WG members to review the draft.
Their review comments will come in a week or two.
---------------------------------------------------------------------
General comments: I like the document organization, especially
sections 3 and 5 to cover all possible deployment scenarios. I have
no issue with combined use of DHCP and DNS for MIH PoS discovery. I
have an issue with allowing only either TCP or UDP for L3-MSTP. I
think that we can make TCP and UDP mandatory supported transport
protocols to ensure interoperability, but we should not exclude other
transport protocols if appropriate and available for a particular
deployment.
More specific comments are inline. Please find [YO] tags for them.
1. Introduction
This document proposes a solution to the issues identified in the
problem statement document [I-D.ietf-mipshop-mis-ps] for the
transport of IEEE 802.21 MIH protocols.
[YO] s/the transport/the layer 3 transport/.
s/MIH protocols/MIH (Media-Independent Handover) protocol/.
The MIH Layer 3 transport problem is divided in two main parts: the
discovery of mobility services (MoS) and the transport of the
information between MN and MoS.
[YO] I have two comments here. First, according to Section 5.2 of
[I-D.ietf-mipshop-mis-ps], "the discovery of mobility services (MoS)"
means "service discovery" (i.e., discovery of services provided by a
certain node). On the other hand, it seems that this document is
trying to solve "node discovery" (i.e., discovery of nodes that
support certain services). Second, since the term MoS is not used for
representing nodes, it is incorrect to say "the transport of the
information between MN and MoS".
So, the sentence should read:
"
The MIH Layer 3 transport problem is divided in two main parts: the
discovery of a node that supports certain mobility services (MoS) and
the transport of the information between a MN and the discovered node.
"
The discovery process is required
for MIH function located in the MN to discover the peer MIHF (e.g.
the IP address) of the MoS in the network (e.g. the Point of Service,
PoS) either during attachment or during handover. Upon successful
discovery, the MIH peers can then exchange information in the form of
MIH messages.
[YO] I don't think we need the wording "either during attachment or
during handover" here, because discovery can happen at any time
whenever needed. Also, I would suggest rewriting the above two
sentences to:
"
The discovery process is required for the MN to obtain the
information needed for MIH protocol communication with a peer node.
The information includes the transport address (e.g., the IP
address) of the peer node and the types of MoS provided by the
peer node.
"
This document considers firstly standard track IETF-based solutions
for the design and recommendations of the discovery and transport
protocol components.
[YO] Meaning of the above sentence is not clear. Perhaps the above
sentence could be revised to:
"
This document provides the overall solution for discovery and
transport protocol components while parameters and formats specific to
particular discovery components are defined in separate documents
[doc1],[doc2].
"
2. Terminology
The following terminology is being used:
MIH Media Independent Handover
MIHF Media Independent Handover Function
MIHF USER MIH client initiating and terminating MIH signalling
[YO] s/MIHF USER/MIH User/.
MIHFID Media Independent Handover Function Identifier
MoS As defined in the problem statement document it includes IS, CS,
ES services defined by the IEEE 802.21 standard.
[YO] s/the problem statement document/[I-D.ietf-mipshop-mis-ps]/.
MoSh Mobility Services assigned in the Home Network
MoSv Mobility Services assigned in the Visited Network
MoS3 Mobility Services assigned in a 3rd Party Network
[YO] I would suggest to use the terms PoSh (Point of Service in the
Home Network), PoSv (Point of Service in the Visited Network) and PoS3
(Point of Service in a 3rd Party Network) for the above three terms.
The reason for this is that, strictly speaking in terms of
[I-D.ietf-mipshop-mis-ps], the document deals with node discovery not
service discovery as I mentioned above. For the same reason, I also
suggest rewrite Section 3 and Section 5 using PoSh, PoSv and PoS3.
MN Mobile Node
NN Network Node
[YO] The term NN is unused in the document.
[YO] Please also add the following terms.
"
PoS (Point of Service) A network-side MIHF instance that exchanges MIH
messages with an MN-based MIHF.
MSTP (Mobility Services Transport Protocol)
"
3. Deployment Scenarios
(snip)
MoS can be provided independently and there is no strict relationship
between ES, CS and IS. However, while IS contain more a static sort
of information, ES and CS are services of a dynamic nature and
sometimes some relationships between them could be expected, e.g. a
handover command could be issued upon reception of a link event.
Hence, while in theory services can be implemented in different
locations, it is expected that ES and CS will be collocated, whereas
[YO] s/in different locations/on different nodes/
IS can either be collocated with ES/CS or not. Therefore, having the
[YO] s/collocated/co-located/ in the above two lines.
flexibility at the MSTP to discover different services in different
locations is an important feature
[YO] s/to discover different services in different locations/to
discovery different nodes with different services/.
[YO] s/feature/feature./.
4. Solution Overview
As mentioned in Section 1 the solution space is being divided in
discovery and transport. The following assumptions have been made:
o The solution is aimed at supporting 802.21 MIH services, namely
Information Services (IS), Event Services (ES), and Command
Services (CS).
[YO] s/Information Services/Information Service/.
s/Event Services/Event Service/.
s/Command Services/Command Service/.
o If the MIHFID is available, FQDN or NAI's realm is used for
mobility service discovery. The recommendation to the IEEE 802.21
WG is to restrict to only these two.
[YO] I think that this recommendation is only for MIHFID of PoS. I
think that MN can still use other types of MIHFID. Also, I think that
this recommendation is specific to L3-MSTP which is part of IETF work,
and I think we don't need recommend this to the 802.21 WG.
o The solutions are chosen to cover all possible deployment
scenarios as described in Section 3.
o MIHF discovery can be performed during initial network attachment
or thereafter.
For the discovering the location of an MoS, the MN could either be
pre-configured with the address of the MoS, or this address could be
dynamically assigned through DHCP or DNS by the network. The dynamic
assignation methods are described in Section 5.
The configuration of the MoS could be executed either upon network
attachment or after successful IP configuration. The methodology to
be used depends on the considered deployment scenario.
Once the MIHF peer has been discovered, MIH information can be
exchanged between peers over UDP and TCP. The usage of these
protocols is described in Section 6.
[YO] Why only UDP and TCP? Please see my comment on Section 4.1 and
Section 6 as well.
4.1. Architecture
The following Figure 5 depicts the MSTP reference model and its
components within a node.
+--------------------------+
| MIHF USER |
+--------------------------+
||
+--------------------------+
| MIHF |
+--------------------------+
|| || ||
+---------+ +------+ +-----+
| TCP/UDP | | DHCP | | DNS |
+---------+ +------+ +-----+
[YO] s/MIHF USER/MIH User/.
Figure 5: MN stack
As it can be seen, the MIHF relies on the services provided by TCP
and UDP for transport, as well as DHCP and DNS for peer discovery.
In cases where peer MIHF IP address is not pre-configured, source
MIHF needs to discover it either via DHCP or DNS or using a
combination of both as described in Section 5. Once peer MIHF is
discovered, MIHF must exchange messages with its peer over either UDP
or TCP. Specific recommendations on choice of transport protocols
are provided in Section 6.
[YO] I am not sure why transports other than UDP and TCP should not be
allowed in some deployment, while I think that UDP or TCP should be
mandatory supported transport in any deployment.
The above reference architecture however does not provide the model
for other services such as, fragmentation and security. Depending
upon the MIH services (e.g., ES, CS and IS) the message size can be
very large. In cases where underlying layer does not support
fragmentation, this may be an issue. There is no security available
currently at the MIH protocol level. However, security can be
provided either at the transport or IP layer where it is necessary.
Section 8 provides some guidelines and recommendations for security.
4.2. MIHF Identifiers (FQDN, NAI)
An MIHFID is an identifier required to uniquely identify the MIHF end
points for delivering the mobility services (MoS). Thus an MIHF
identifier needs to be unique within a domain whereby mobility
services are provided and invariant to interface IP addresses. An
MIHFID MUST be represented either in the form of an FQDN [RFC2181] or
NAI [RFC2486]. An MIHFID can be pre-configured or discovered through
the discovery methods as described in Section 5.
[YO] RFC 4282 the latest specification for NAI.
5. MoS Discovery
[YO] We should use the term PoS discovery for the reason I explained
above.
The MoS discovery method depends on whether the MN wants to discover
an MoS in the local network, home network or a remote network other
than home network.
[YO] s/discover an MoS/discovery a PoS/
s/local network/visited network/.
s/remote network/third-party network/.
In case MoS is provided locally (scenarios S1 and S2)
[I-D.bajko-mos-dhcp-options] and [I-D.bajko-mos-dns-discovery] could
be used to transfer MoS information from the network to the MN (via
DHCP or DNS). In case MoS is provided in the home while the MN is
attached in visited (scenario S3) an interaction between the DHCP and
AAA infrastructure is required similarly to what specified in
[I-D.ietf-mip6-bootstrapping-integrated-dhc]. It is assumed
therefore that MoS assignment is performed during access
authentication and authorization. In case MoS is provided in a
remote network other than visited or home (scenario S4) only DNS
based methods apply.
(snip)
5.3. MOS Discovery in a roaming Network and Services are at Home
To discover an MoS in the roaming network when services are provided
by the home network MN SHOULD use the DHCP option along with network
access authentication. Upon network access authentication and
[YO] Why DHCP is recommended in the roaming scenario? I think it is
also possible to use DNS query in the same way as Section 5.1.
interaction with the NAS the AAAh verifies in the AAA profile that
the MN is allowed to use the MoS in home. The AAAh assigns the MoS
in the home and sends back the information to the NAS. MN sends a
DHCP information request as per [RFC3315] containing Home Network
Identifier Option indicating the need to allocate the MoS in the
home. The relay agent intercepts the Information request from the MN
and it forwards to the DHCP server inserting the MIH Relay Agent
Option containing the info received by the AAAh. The DHCP server can
then reply to the MN by sending the Home Network Information Option.
The MN receives the MoS address.
(snip)
6. MIH Transport
Once the Mobility Services have been discovered, MIH peers MUST
exchange information over either TCP or UDP. While either protocol
[YO] Why only TCP or UDP? We would need TCP or UDP for mandatory
supported transport protocols to ensure interoperability, but IMO
other transport protocols should also be allowed if they are
appropriate and available for a particular deployment.
can provide the basic transport functionality required, there are
performance trade-offs and unique characteristics with each that need
to be considered in the context of the MIH services for different
network loss and congestion conditions. Thus, the objectives of this
section are to discuss these trade-offs for different MIH settings
such as the MIH message size and rate, and the retransmission
parameters. In addition, factors such as NAT traversal are also
discussed. Given the reliability requirements for the MIH transport,
it is assumed in this discussion that the MIH ACK mechanism is to be
used in conjunction with UDP, while it is preferred to avoid using
with TCP since TCP includes a similar functionality.
(snip)
6.2. MIH Message rate
The frequency of MIH messages varies according to the MIH service
type. It is expected that CS/ES message arrive at a rate of one in
hundreds of milliseconds in order to capture quick changes in the
environment and/ or process handover commands. On the other hand, IS
[YO] Is this the rate based on CS/ES messages coming from a single
source or multiple sources?
messages are exchanged mainly every time a new network is visited
which may be in order of hours or days. Therefore a burst of either
[YO] IS exchange can happen more frequently if the MN is moving at a
high-speed. In general, we should be careful when showing
actual numbers.
short CS/ES messages or long IS message exchanges (in the case of
multiple MIH nodes requesting information) may lead to network
congestion. While the built-in rate-limiting controls available in
TCP may be well suited for dealing with these congestion conditions,
this may result in large transmission delays that may be unacceptable
for the timely delivery of ES/CS messages. On the other hand, if UDP
is used, a rate-limiting effect similar to the one obtained with TCP
may be obtained by adequately adjusting the token bucket parameters
defined in the MIH specifications. Recommendations for parameter
settings are specific to the scenario considered.
(snip)
7. Operation Flows
Following Figure 10 gives an example operation flow between MIHF
peers when an MIH user requests for an IS service. Scenario 1 is
chosen whereby DHCP is used for MoS discovery and TCP is used for
establishing a transport connection. When MOS is not pre-configured,
MIH user needs to discover the IP address of MOS to communicate with
the remote MIHF. Therefore MIH user requests the local MIHF via a
discovery message as defined in IEEE 802.21.
[YO] I don't understand why the MIH user needs to request the local
MIHF for discovering the IP address of PoS. I think that another
scenario is possible where the MIH user directly invokes DHCP and
obtains the IP address, and then communicating the obtained IP address
to the local MIHF when invoking an MIH primitive.
(snip)
8. Security Considerations
There are a number of security issues that need to be taken into
account during node discovery and information exchange via a
transport connection [I-D.ietf-mipshop-mis-ps]
In case where DHCP is used for node discovery and authentication of
the source and content of DHCP messages are required, it is
recommended that network administrators should use DHCP
authentication option described in [RFC3118]. This will also protect
the denial of service attacks to DHCP server.[RFC3118] provides
mechanisms for both entity authentication and message authentication.
[YO] I think that use of DHCP authentication option is a hard
recommendation considering the fact that there is few deployment of
RFC 3118 as far as I know. I think that recommending use of
link-layer security for the link where DHCP operates is more
realistic, although it does not provide a complete solution to address
all DHCP security issues.
In case where DNS is used for discovering MoS, fake DNS requests and
responses may cause DoS and the inability of the MN to perform a
proper handover, respectively. Where networks are exposed to such
DoS, it is recommended that DNS service providers use the Domain Name
System Security Extensions (DNSSEC) as described in [RFC4033].
Readers may also refer to
[I-D.ietf-dnsop-dnssec-operational-practices] to consider the aspects
of DNSSEC Operational Practices.
In case where reliable transport protocol such as TCP is used for
transport connection between two MIHF peers, TLS [RFC4346] should be
used for message confidentiality and data integrity. In particular,
TLS is designed for client/server applications and to prevent
eavesdropping, tampering, or message forgery. Readers should also
follow the recommendations in [RFC4366] that provides generic
extension mechanisms for the TLS protocol suitable for wireless
environments.
In case where unreliable transport protocol such as UDP is used for
transport connection between two MIHF peers, DTLS [RFC4347] should be
used for message confidentiality and data integrity. The DTLS
protocol is based on the Transport Layer Security (TLS) protocol and
provides equivalent security guarantees.
Alternatively, generic IP layer security, such as IPSec [RFC2401] may
be used instead of a specific transport layer secuity for a specific
transport.
[YO] Is there a specific reason for why TLS or DTLS is a should while
IPsec is a may? If there is such a reason, it's better to describe
it. Also, why don't use SHOULD/MAY language here?
(snip)
Best Regards,
Yoshihiro Ohba
_______________________________________________
Mipshop mailing list
Mipshop at ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
