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

From: "Hepworth, Eleanor" <[email-masked]>
Date: Tue, 14 Mar 2006 14:09:32 -0000

Hi Jari,

Many apologies on the delay in getting back to you.

We have now submitted a revised problem statement draft:
http://www.ietf.org/internet-drafts/draft-hepworth-mipshop-mih-problem-s
tatement-01.txt

We have tried to address your comments within this version of the draft,
but please find specific responses below.

(snip)
> 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.
>
This draft discusses providing a secure transport service where the type
of security service provided is believed to be generally useful to
mobility support service applications.  The analysis of how to satisfy
the security requirements of the mobility support service taking into
account the capabilities of the transport has to be considered case by
case as part of the support service application design.  It is not
required that the transport provides a complete security solution for
all the support service applications at once. Mobility support services
may introduce their own additional security mechanisms to suit their
needs.

> 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.

I think these are good questions that need to be discussed further. It's
not clear how much impact proxy operation will have on the transport
(see revised draft); this may be more of a service layer issue.

It seems fairly clear at the moment that both 'trivial'and 'real'
transport capabilities are required, depending on the message being
sent.  Obvioulsy we want to avoid overweight negotiation solutions, so
really this is a question of allowing the option of turning off the real
transport functions if necessary.
> 
> 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.

The revised draft is hopefully a bit clearer on this issue.  We have
enumerated the proxy operation options in a bit more detail.
> 
> > 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.

Text updated accordingly.

> 
> > 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.
> 

This is a good point, and perhaps one that needs further consideration.
It may be that there is no requirement for handover of services between
old and new links (you could imagine this could be the case for a
mobility support service such as the event service, where the terminal
is no longer interested in events from the old network after it has
moved).  In other cases, it may be possible to assume that the mobility
protocol itself could also support mobility of the service (e.g. for an
Information Service based in ther users home network).  However, there
still seem to be cases where you want to deliver information independent
of the mobility protocol whilst the terminal is moving, and it is these
cases that need more investigation.  It could be that the process of the
terminal registering with a new mobility support service function in the
new access network has a knock-on effect of informing the old mobility
support service function that the MN has moved, and any final
responses/acknowledgements should be relayed via the new mobility
support service function (analogous to CT approaches where the old AP
may communicate with the MN via the new AP). 

> > 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.
> 
The security considerations section has been updated to include this.
> 
> Editorial:
> 
> > responsibility of other standards bodies other that the IETF.
> 
> s/that/than/

Fixed.

Thanks

Ele

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