RE: [Mipshop] Comments on draft-melia-mipshop-mstp-solution-00

[<Gabor.Bajko at nokia.com>]

Please see inline: 

-----Original Message-----
From: ext Yoshihiro Ohba [mailto:yohba at tari.toshiba.com] 
Sent: Friday, October 05, 2007 3:53 PM
To: mipshop at ietf.org
Subject: [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.

<gabor> I guess you meant mandatory for the server side only.

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.
"
<g> well, the result of the discovery is not necessarily a node, but rather
a set of (transport) addresses where services are reachable. But yes, a
reformulation is needed there.


   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.
"
Again, it is not necessarily 'a peer node', rather peer MIHFs.


   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.

<g> the options we have here are:
Mandate one transport protocol to be used by one specific service (eg TCP)
Mandate two transport protocols to be supported by the server side (UDP and
TCP) and let the client choose
Mandate the above two for server side and allow all other possible ones; in
this case we need different NAPTR application tags for each additional
transport and support transport protocol discovery. Would the added value
justify this?

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.

<g> we could add SCTP, I could see value in that. But I do not want to flood
the documents with additional service tag definitions and transports which
are anyway not used in real life deployments.

   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.

<g> right. I made the same point but the other authors seem deaf on this.

   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.

<g> again, the support of other transports must come along with transport
discovery mechanism and service tag definitions. We can not support
arbitrary, undefined, noname transports.

thanks for comments,
- gabor

   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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Mipshop mailing list
Mipshop at ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop