Subject: [MIPSHOP-MIH-DT] FW: AD review of draft-ietf-mipshop-mis-ps

From: Sam Xia <[email-masked]>
Date: Sat, 29 Sep 2007 09:51:45 +0800

Best Regards, Sam Xia
-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Friday, September 28, 2007 7:56 PM
To: Mipshop Chairs; [email-masked]
Subject: AD review of draft-ietf-mipshop-mis-ps

I have made my AD review of this document. I mostly agree with everything
that the document says (except for some issues, noted below).

However, some aspects of the document provide too vague explanations to help
us in guiding the creation of solutions.
In particular, I would like to see crisper requirements around discovery and
proxying, and possibly also about security and congestion/reliability.

I am expecting a revised version of the draft, after discussion.

Substantial:

> For instance traditional host-based handover solutions
>    could be complemented with more sophisticated network-centric
>    solutions reducing terminal complexity. 
IMHO, it seems very unlikely that a reduction of complexity can be achieved.
First, you have to take into account that MIH services aren't universally
deployed, so hosts probably have to have support for falling back to other
mechanisms anyway. Secondly, MIH isn't simple.

Suggested edit:

OLD:
For instance traditional host-based handover solutions could be complemented
with more sophisticated network-centric solutions reducing terminal
complexity. 
NEW:
For instance traditional host-based handover solutions could be complemented
with more sophisticated network-centric solutions. 

> The
>       security mechanism may provide mutual authentication of MN and NN
>       and it may provide one way authentication of either of MN and NN.
Vague. Plus, you probably meant to say "Must provide at least one one way
... and may provide mutual ..."

It might have better to simply refer to the security considerations section,
which has a more complete discussion of this topic.

>       *  Pushing information to the MN, where the information is
>          delivered to the MN as part of other configuration operations,
>          for example, in a Router Discovery exchange.
I would suggest adding DHCP.

OLD:
for example, in a Router Discovery exchange.
NEW:
for example, via DHCP or Router Discovery.

>       The definition of a service also needs to be determined, including
>       the granularity of the description (for example, should the MN
>       look for an "IS" service, or "IS-local information", and "IS-home
>       network information" services?).
Another vague requirement. Without a detailed understanding of what is truly
needed, its hard to make decisions such as whether a new transport protocol
is needed.

>    In this case, the proxy performs some processing on the Information
>    Exchange before forwarding the information on.  This can be viewed as
>    concatenating signalling exchanges between a number of EPs.
>   
You need to define the role of the proxy better. What operations it needs to
perform has a big impact on what kind of protocol and security model you
need.
Are the proxies there just to route the messages?
To add information AVPs? To filter out unwanted commands? To do anything?

>    Secure delivery:  The Mobility Service information must be delivered
>       securely (integrity and confidentiality) between trusted peers,
>       where the transport may pass though untrusted intermediate nodes
>       and networks.  The Mobility Service information should also be
>       protected against replay attacks and denial of service attacks.
>   
Is "node" above a router or a proxy? There's a big difference for your
protocol...

>    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.
>   
It seems counter-intuitive that a component in the mobility infrastructure
wants to avoid using mobility mechanisms itself...

In any case, I think this item needs rethinking because the issue is not
just the use of a different link or path; when you are connected to multiple
networks, it is likely that you need to get information from *different
endpoints*.

I would simply state here that the protocol needs to be capable of receiving
information from multiple endpoints at the same time and be able to change
the information source upon movements. Then I would add that where a MIH
session should survive a movement, it is expected that the mobility
protocols deal with it.

> The control and
>    maintenance of mobile nodes becomes challenging where authentication
>    and authorization credentials used to access a network are
>    unavailable for the purpose of bootstrapping a security association
>    for handover services.

I'm not sure I see why. I could imagine that at least information services
could be run based on web-like server-side certs. Or even unsecured in some
cases, cf. DHCP security.

But the next paragraph explains the issue better; I'd suggest deleting this
statement.

Editorial:

>    1.  The Information: the information elements being exchanged.  The
>        messages could be of different nature, such as Information,
>        Command or Event, potentially being defined following a common
>        structure.
>   

>   The initial requirement for this protocol comes from the need to
>    provide a transport for the MIH protocol being defined by IEEE
>    802.21[1] (specifically the IS/ES/CS components) which is not bound
>    to any specific link layer and can operate over more that one
>    network-layer hop.
All terms and abbreviations here appear without explanation or even
expansion. Starting from MIH... I would suggest the following revisions to
keep the introduction free of too much acronyms:

OLD:
1.  The Information: the information elements being exchanged.  The
     messages could be of different nature, such as Information,
     Command or Event, potentially being defined following a common
     structure.
NEW:
1.  The Information: the information elements being exchanged.  The
     messages could be of different nature, such as information,
     commands to perform an action, or events informing of a change,
     potentially being defined following a common
     structure.

OLD:
   The initial requirement for this protocol comes from the need to
   provide a transport for the MIH protocol being defined by IEEE
   802.21[1] (specifically the IS/ES/CS components) which is not bound
   to any specific link layer and can operate over more that one
   network-layer hop.
NEW:
   The initial requirement for this protocol comes from the need to
   provide a transport for the Media Independent Handover (MIH)
   protocol being defined by IEEE 802.21[1] which is not bound
   to any specific link layer and can operate over more that one
   network-layer hop.

> Also, neighborhood
>    discovery, potentially a complex operation in heterogeneous wireless
>    scenarios, can result in a more simple step if implemented with an
>    unified interface towards the access network.
OLD:
more simple step
NEW:
simpler operation

> Speaking 802.21
>    terminology MoS can be reagarded as IS, ES, CS.

Undefined terms.

OLD:

Speaking 802.21 terminology MoS can be reagarded as IS, ES, CS

NEW:

Speaking 802.21 terminology MoS can be reagarded as Information Services
(IS), Event Services (ES), and Command Services (CS).

>    IPv4 and IPv6 support:  The MSTP must support both IPv4 and IPv6
>       including NAT traversal for IPv4 networks and firewall pass-
>       through for IPv4 and IPv6 networks.
>   

RFC 2119 terms used without reference to RFC 2119.
Use the standard boilerplate, or rewrite the text.

> For example, if the local
>    network is just aware that an anonymous user with a subscription to
>    operatorXYX.com is accessing the network, the user should not have to
>    divulge their true identity in order to access the Mobility Support
>    Services available locally.
Please use the reserved example domain names, such as example.com.

Jari

_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt