Subject: [Mipshop] review of draft-hepworth-mipshop-mih-problem-statement

From: Jari Arkko <[email-masked]>
Date: Fri, 13 Jan 2006 16:07:42 +0200

Hi,

I reviewed this draft. Comments:

Overall:

This is a well written document and describes the framework
through which the authors see this problem. In this framework
there are certain transport needs.  The description of the
problem is restricted to the description of these needs and
not so much on what the overall system should do; this may
have an impact when we later look at, e.g., security -- the
actual function may have a big impact on what type of security
is needed.

Overall the proposed functionality makes sense, but does
also contain potentially complex parts. The whole thing would
be simpler if we didn't need to have proxies or configurable
transport characteristics, for instance.

Technical:

>    o  EP: endpoint, intended to represent the terminating endpoints of
>       the transport protocol used to support the signalling exchanges
>       between nodes.

(snip)

>            +------+           +-------+          +------+
>             |  MN  |           |  NN   |          |  NN  |
>             | (EP) |           |(Proxy)|          | (EP) |
>             +------+           +-------+          +------+
>                          Information Exchange
>                 <-----------------> <------------------>
>
>                 /---------------\     /----------------\
>                <    Transport    >   <    Transport     >
>                 \---------------/     \----------------/

I'm not sure why the proxy is not an EP here,
according to your definition. But I think what
we really have here is two layers: the transport
layer (a la TCP) and the MIH transport on top
of it; TCP may terminate in the proxy but the
overall MIH transport does not.

>    Information from a trusted source: The MN uses the Mobility Service
>       information to make decisions about what steps to take next.  It
>       is essential that there is some way to ensure that the information
>       received is from a trustworthy source.  This includes cases where
>       trusted proxies along the path have access to, and may modify,
>       parts of the Mobility Service information.  This requirement has
>       interactions with the AAA infrastructure for the purposes of
>       authenticating and authorising the information exchange itself.

I see an interaction with AAA infrastructure as one
potential solution, but maybe you should not list it as
a requirement. There may be other solutions, too, such
as certificates given to access networks that you would
also need with SEND.

>    Multihoming: For some information services exchanged with the MN,
>       there is a possibility that the request and response messages can
>       be carried over two different links e.g. a handover command
>       request is on the current link while the response could be
>       delivered on the new link.  Depending on the IP mobility
>       mechanism, there is some impact on the transport option for the
>       mobility information services.  This may potentially have some
>       associated latency and security issues, for example, if the
>       transport is over IP there is some transparency but Mobile IP may
>       introduce additional delay and both TCP and UDP must use the
>       permanent address of the MN.

I am not sure I understand the above completely. Are you suggesting
that a mobility protocol be used to handle IP address changes
within the MIH? Wouldn't that have some chicken-and-egg problems,
if the mobility protocol itself needs information from MIH before
it can make a wise decision, and now making that wise decision
is dependent on the mobility protocol. Of course, it may be that
there are some cases where, e.g., a download of the database
of local access points can be in progress while you move, and
then I see that mobility protocol can be used here.

Anyway, the same problem appears hold also for transports.
But I could be missing something.

>    Sensitive and identifying information about a mobile device may be
>    exchanged during handover service message exchange.  Since handover
>    decisions are to be made based upon message exchanges, it may be
>    possible to trace a user's movement between cells, or predict future
>    movements, by inspecting handover service messages.  In order to
>    prevent such tracking, message confidentiality should be available.
>    This is particularly important since many mobile devices are
>    associated with only one user, as divulgence of such information may
>    violate the user's privacy.  Additionally, identifying information
>    may be exchanged during security association construction.  As this
>    information may be used to trace users across cell boundaries,
>    identity protection should be available if possible, when
>    establishing SAs.

This addresses the privacy of the user against the general public,
but it does not address the privacy of the user against the network
nodes (e.g. local access network).  While there are cases where we
need to make the identity of the user available to the network,
I wouldn't like the protocol to always require that to be the case.
The home network, for instance, can authorize a mobile node
to receive information even without the access network knowing
more than that its a customer of XYZ telecom.

Editorial:

>    responsibility of other standards bodies other that the IETF.

s/that/than/

--Jari

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop