Subject: [Seamoby] Review of draft-ietf-seamoby-ctp-01.txt

From: "James Kempf" <[email-masked]>
Date: Thu, 6 Mar 2003 13:37:01 -0800

Pat has been following CT more closely than I, so some of my comments may be due
to unfamiliarity with the topic, but unfortunately he hasn't had much time
recently to spend on CT.

I have a few general comments, including editorial comments, then some more
detailed comments.

                jak

--------------------------------------------

General Comments
--------------------

1) The draft begins rather abruptly. I think there is a need for some, shall we
say, context transfer :-) from the problem statement and requirements draft at
the very beginning to ease the transition. There should be a section with goals
and nongoals, so people have an overall impression about what the protocol is
trying to do. In addition, the ladder diagrams in Section 5 would probably be
better at the beginning so that people have some idea about how the protocol
works before diving into detials. For example, when I read through Section 2, it
was unclear to me whether pAR could send context to  nAR in response to a link
trigger, which seems clearly needed for certain time critical handovers.

2) I was quite disappointed to see that the transport issue has still not been
resolved. This was certainly at the top of my list for topics that should be
complete by this stage. If I recall correctly, I asked the DT about this in
Atlanta and was assured that the issue would be resolved quickly, yet it has not
been. My technical opinion is that the ladder diagrams in Section 5 suggest two
transport modes: one between the MN and AR and another between ARs. More
detailed consideration of this might help sort out some aspects of transport.

3) The security model in this draft is extremely vague. An "authorization token"
from the MN is specified, but the construction of the token, its security
properties, and the provisioning of the participants in the trust relationships
involved in CT are left as an exercise to the reader. My opinion is that the DT
and WG should revisit this decision and consider whether using more standardized
security mechanisms, such as IPsec or TLS, might make more sense. New security
algorithms a very hard to design, it took over a year for the MIP group to
design the RR security algorithm, for example. I frankly don't think that the
security problems of CT are so different that they need a new algorithm. In
addition, there was nothing said about security on individual feature contexts.
I don't know if the topic was discussed in the DT, but it certainly is something
that needs consideration.

Detailed Comments
--------------------

I've included actual text from the draft, with comments:

Seamoby WG                                         J. Loughney (editor)
Internet Draft                                              M. Nakhjiri
Category: Standards Track                                    C. Perkins
<draft-ietf-seamoby-ctp-01.txt>                               R. Koodli
Expires: September 2003                                      March 2003

                       Context Transfer Protocol

jak> Why not "Context Transfer Protocol (CTxP)"?

Abstract

   This document presents a context transfer protocol that enables
   authorized context transfers.  Context transfers allows better
                                                                          ^^^^
allow
   support for node based mobility so that the applications running on
   mobile nodes can operate with minimal disruption.  Key objectives are
   to reducing latency, packet losses and avoid re-initiation of
   signaling to and from the mobile node.

jak> The abstract is not very descriptive of what the draft is about. What is a
context? What is node based mobility?

1.0 Introduction

jak> Terms are used here before being defined. What is a context? What is a
feature? These need to be defined in the text or in a terminology section, and
should in any event be defined before being used.

   Access Routers typically establish state in order to effect certain
   forwarding treatments to packet streams belonging to nodes sharing
   the access router.  For instance, an access router may establish an

^^ remove
   AAA session state and a QoS state for a node's packet streams.  When
                                      ^^ remove

      * Bandwidth savings.  Re-establishing multiple contexts over an
        expensive, low-speed link can be avoided by relocating contexts
                                         ^ wireless
        over a potentially higher-speed wire.
    * Either nAR or pAR may request or start (respectively) context
      transfer based on internal or network triggers (see Appendix B).
                                                 ^^^^^^^ don't you mean link
triggers? I don't think you are talking about ICMP Host Unreachable or anything
like that.

   Typically, the source node is a MN's Previous Access Router (pAR) and
   the target node is MN's New Access Router (nAR). We assume that pAR
   and nAR share an appropriate security association, set up
                                                  ^^^^^^^^^^^^^^^ is IPsec meant
here or something different?
   independently and prior to context transfer. Any appropriate
   mechanism may be used in setting up this security association; it
   enables the CT peers to utilize a secure channel for transferring
   contexts, providing authentication, integrity, and (if needed)
   confidentiality.

   Context Transfer takes place when an event, such as a handover, takes
   place. We call such an event as a Context Transfer Trigger. In
                                               ^^ remove
   response to such a trigger, the pAR may transfer the contexts; the
   NAR may request contexts and the MN may send a message to the PAR to
   transfer contexts. Such a trigger must be capable of providing the
   necessary information, such as the MN's IP address with which the
   contexts are associated, the IP addresses of the access routers, and
   authorization to transfer context.

   Context transfer protocol messages use Context Types that identify
   the way that data is organized for the particular feature contexts.
   The Context Types (CPTs) are registered in a number space (with IANA
   Type Numbers) that allows a node to unambiguously determine the type
   of context and the context parameters present in the protocol
   messages.  Contexts are transferred by laying out the appropriate
   feature data within Context Data Blocks according to the format in
   section 2.3, as well as any IP addresses necessary to associate the
   contexts to a particular MN.  The context transfer initiation
   messages contain parameters that identify the source and target
   nodes, the desired list of feature contexts and IP addresses to

^^^^^^^^^^^ What IP addresses? At this point in the document, it is not clear
how the IP address would work. If you mean a care of address, is it the address
on the old link or new? If a home address, how does the AR associate that with a
particular host?

   The Previous Access Router transfers feature contexts under two
   general scenarios.  First, it may receive a Context Transfer Start
                                ^^^ A quick summary of the scenarios with
reference to the ladder diagrams would help the reader.

   Request (CTSR) message from the MN whose feature contexts are to be
   transferred, or it receives an internally generated trigger (e.g., a
   link-layer trigger on the interface to which the MN is connected).

Loughney et al.           expires August 2003                   [Page 5]

Internet-Draft                                             February 2003

   The CTSR message, described in Section 2.4.1, provides the IP address
   of NAR, the IP address of MN on PAR, the list of feature contexts to
   be transferred (by default requesting all contexts to be
   transferred), and a token authorizing the transfer. It also includes
   the MN's new IP address (valid on NAR) whenever it is known. In
   response to a CT-Start Request message or to the CT trigger, PAR
   predictively transmits a Context Transfer Data (CTD) message that
   contains feature contexts. This message, described in Section 2.4.2,
   contains the MN's previous IP address and its new IP address

^^^^^^^^^^^ How can the MN know this prior to getting on the new link and doing
DAD? If there are specific dependencies on other protocols, for example FMIP,
then that needs to be called out.

   (whenever known). It also includes a key, and an indication to use a
   particular algorithm to assist NAR in computing a token that it could
   use to check authorization prior to making the contexts available to
   the MN.

   In the second scenario, pAR receives a Context Transfer Request (CT
   Request) described in Section 2.4.5, message from nAR.  The nAR
   itself generates the CT Request message either as a result of
   receiving the CTSR message or as a response to an internal trigger
   (that indicates the MN's attachment). In the CT-Req message, nAR
   supplies the MN's previous IP address, the feature contexts to be
   transferred, and a token (typically generated by the MN) authorizing
   context transfer. In response to CT Request message, pAR transmits a
   Context Transfer Data (CTD) message that includes the MN's previous
   IP address and feature contexts.  When it receives a corresponding
   CTD message, nAR may generate a CTD Reply message (See Section 2.4.3)
   to report the status of processing the received contexts.   In this
   "reactive" transfer of contexts, PAR verifies authorization token
   before transmitting the contexts, and hence does not include the key
   and the name of algorithm in the CTD message.

jak> I'm having trouble understanding how the authentication token would work if
the AR sends the context in response to a link trigger. Must the MN negotiate
with the AR first to provide it with the token, at some point prior to the
handover? Or does the AR ask the MN for the token? What is the basic motivation
for having a token anyway? If the routers have a trust relationship, verified
via the (presumably IPsec) security relationship cited previously in the draft
and a (presumably AH) MAC or digital signature on the CT signaling, shouldn't
they trust each other to not send deceptive information? If the MN has
negotiated an AAA exchange to get into the network, then shouldn't the MN trust
the provider's network to handle its routing and handover information
expeditiously and with discretion? Otherwise, wouldn't the MN put source routing
headers on all its packets because it wouldn't trust the provider's IGP to set
up routing tables correctly? There is an issue with MN to router signaling being
trusted, but, again, shouldn't that be handled by a standard IPsec security
relationship, or, alternatively, TLS if TCP is used?

   Performing context transfer in advance of the MN attaching to NAR
   clearly has potential for better performance.  For this to take
   place, certain conditions must be met.  For example, PAR must have
   sufficient time and knowledge about the impending handover. This is
   feasible for instance in Mobile IP fast handovers. However, when the
   advance knowledge of impending handover is not available, or if a
   mechanism such as fast handover fails, retrieving feature contexts
   after the MN attaches to NAR is the only available means for context
   transfer. Performing context transfer after handover might still be
   better than having to re-establish all the contexts from scratch.
   Finally, some contexts may simply need to be transferred during
   handover signaling. For instance, any context that gets updated on a
   per-packet basis must clearly be transferred only after packet
   forwarding to the MN on its previous link is terminated.  Transfer of
   such contexts must be properly synchronized with appropriate handover
   messages, such as Mobile IP (Fast) Binding Update.
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^ This is an assumption
of a particular (version of) a particular handover protocol.

2.2 Context Types

   Contexts are identified by context type, which is a 32-bit number.
   The meaning of each context type is determined by a specification
   document and the context type numbers are to be tabulated in a
   registry maintained by IANA, and handled according to the message
   specifications in this document.  The instantiation of each context

jak> The above isn't enough to tie down how CT feature contexts are
standardized. Is the method of IETF concensus used, or can anybody just submit
an individual contribution to the IESG? Please see RFC 2608 for an example of
text that precisely specifies the steps needed to standardize different
extensions to a protocol.

2.3 Context Data Block

jak> I'm sorry, but this went completely over my head. What is the purpose of
the presence vector? I can't see what this is trying to achieve. Why not use a
simple TLV format?

2.4 Messages

   In this section, a list of the available context transfer message
   types is given, along with a brief description of their functions.
   Generally, messages use the following generic message header format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Message Type           |reserve|       Length          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Mobile Node's Previous Care-of Address            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                         message data                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

jak> Why is the length 12 bits? Why not byte align it? Actually, I think in IPv6
it must be
byte aligned.

2.4.1 Context Transfer Start Request (CTSR) Message

   Sent by MN to nAR to request start of context transfer.  It is for

jak> Must the MN be on link when this is sent, or can it be sent from the old
link?

   ICMP and UDP do not provide congestion control, while TCP/SCTP do
   provide congestion control.  The connection setup for those
   congestion control transport protocols may introduce delays in start
   of data transfer, but do protect the network from becoming

jak> There are well-known ways to handle start up delays: cache the connections.
This should be especially possible with the interrouter CT since the topology
won't change often.

    It is assumed that intra-domain time-critical context transfer should
   take no more than one kilobyte, based on existing implementation of

jak> Where did this number come from? If you have some experimental data to
support this, then why not present a table in the draft, or a reference to a
paper where the experiment is discussed in detail. As it currently stands, it
looks as if the number was picked out of the air.

   some context transfer solutions.   Contexts that are significantly
   larger are assumed not so time critical. For a larger number of
   users, say one thousand users requesting a smooth handover all in the
   same second, the total bandwidth needed is still a small fraction of
   a typical Ethernet or frame relay or ATM link between access routers.
   So even bursty traffic is unlikely to introduce local congestion.
   Furthermore, physically adjacent access routers should be within one
   or two IP hops of each other, so the effects of context transfer
   should be localized.  If transferring real-time contexts triggers
   congestive errors, the access network may be seriously under-
   provisioned.

jak> The discussion above assumes that intra-provider CT won't go over the
Internet. This isn't clear to me. Suppose I have a hotspot network in which I
can move from Starbucks across the street to The Lunchtime Cafe on this side,
and both are handled by T-Mobile. Both sides are in the same ISPs network, but
the wired traffic may have to go over the Internet if there is no direct
connnection. Since the wireless cells may overlap, a mobile could move between
the two wirelessly, and it would not involve an inter-domain move, because both
hotspots are managed by T-Mobile.

4.3 Failure Handling

   Failure of Context Transfer should at least cause no harm to the
   network or to the user session.  Failure reporting to the mobile node
   may be needed.  The details about how failure can be reported for
   some individual contexts but not requiring retransmission of all
   contexts should be straightforward but remain to be worked out.
                                                        ^^^^^^^^^^^^^^^^^^^^^
Another big, unresolved issue. :-(

4.4 Zone of Operation

   Currently, the authors are restricting discussion of CTP to intra-
   domain signaling.  Discussion of inter-domain signaling left for
   later discussions.

jak> This should be stated at the beginning in a section called "Goals and
Nongoals" or something like that.

   Is a new message CT request needed?
                               ^^^^^^^^^^^^^^^ Sure seems that way to me from
your diagram.

5.3 Mobile controlled, Predictive New L2 up/old L2 down

jak> If this is predictive, then why is the CTSR being sent to nAR? Predictive
means the MN or pAR has information prior to the handover that could be used to
optimize.

   The CTSR relay is the CTSR message that is destined to pAR and is
   routed through nAR (routing details later). In case CT cannot be
   supported, a CTSR reject maybe sent to the MN through nAR.

jak> I don't understand the CTSR relay. Why is this needed? It was not
introduced in the draft until this point.

   Furthermore, either one or both of the pAR and nAR need to be able
   authenticate the mobile and authorize mobile's credential before

jak> Why is this necessary? It sounds like you are saying that prior to every
handover, this must be done. If the MN is authenticated to use the router, then
why must it be authenticated again for the handover? Isn't it enough to have
signaling triggering CT from the MN that can be authentically tied the the MN?

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