Subject: [Seamoby] CT Design Reviews from Review Board

From: "James Kempf" <[email-masked]>
Date: Mon, 16 Jun 2003 13:25:43 -0700

Pat and I solicited a few outside reviewers for the Seamoby CT Review
Board. Of the people asked, Pekka Savola and Raj Patil sent reviews.
Pekka and Raj should be well known as long time IETF participants.
Pekka is co-chair of the v6ops WG and prodigious technical commentator
on MIPv6 and IPv6. Raj is co-chair of the MIP WG.

I've attached copies of their reviews here. We plan to incorporate
their comments into the issues list, but please feel free to address
their comments on the list.

            jak

---

From: [email-masked]
Date: Tue, 17 Jun 2003 16:47:12 +0300

Hi all, 

I logged several of Basavaraj's comments, I will log the rest
tomorrow, along with Pekka's.

Thanks,
John

> -----Original Message-----
> From: ext James Kempf [mailto:[email-masked]]
> Sent: 16 June, 2003 23:26
> To: [email-masked]
> Subject: [Seamoby] CT Design Reviews from Review Board
> 
> 
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: [email-masked]
Date: Fri, 27 Jun 2003 15:46:51 +0300

Comments on Basavaraj's comments:

1. The Protocol Messages (CTAR, CTDR, CTR) described in sections 2.4.x
   need to have descriptions of each of the fields and flags. Also the
   type numbers need to be requested from IANA for these messages.

--> assigned Issue 18.

2. Error codes have not been defined in the document.

--> assigned Issue 18.

3. Formatting:
   a. No page numbers in the draft

--> fixed.
   b. The ToC does not include page numbers as well

--> fixed.

   c. Number the references (In the references section)

--> Why numbers?  I prefer text lables, easier to remember.

   d. There is no link from references in the text of the document to
   the references section.

--> fixed

4. s/to reducing latency, packet losses and avoid/to reduce latency,
   packet loss and avoiding

--> fixed

5. Section 1. Introduction
   a. The introduction relies on the justification for CT as described in
   RFC3374. The introduction should focus on what this draft is about
   rather than the justification which is provided in the 1st
   paragraph.

--> fixed
  
   b. "context transfer-candidate services" - Please describe what
   these candidate services are. Or at least provide a few examples of
   the services being considered.

--> fixed

   c. Argument 2: "interoperable solution that works for any Layer 2
   radio access technology" is a lofty claim or goal. Not required in
   the scope of this protocol.

--> fixed, changed to:

	An additional motivation is to provide an interoperable solution 
	that supports various Layer 2 radio access technologies.

   d. s/of application streams./of application streams:
      s/benefits./benefits:
      s/savings./savings:
      s/to errors./to errors:

--> removed text

   e. i/over an expensive, low-speed link/over an expensive, low-speed
   link (MN-AR)
      i/higher-speed wire/higher-speed wire (between ARs).

--> removed text

   f. "operates over reliable networks" - State that this is an
   assumption about reliability of inter-AR links.

--> removed text

   g. s/In this document we describe/This document describes

--> Fixed

6. Section 1.2
   Would be good to define terminology such as FPT or point to a
   proper reference if this has been defined elsewhere

--> Fixed

7. Section 2
   a. Pargaraph 1 - CT is initiated by the MN or the network as a
   result of Handover. Is this the only case? Or can this be a result
   of network failure or service disruption because of maintenance?

--> Right now, I think that is out of scope of this document, it is for
	further study.

   b. "We assume that pAR and nAR share an appropriate security
   association, set up independently and prior to context transfer." -
   It would be good to say that the details of how this SA is setup
   and the type of SA (IPsec or other)e are outside the scope this
   document. 

--> Some clarify text is added.

   c. The protocol overview section would be clearer if organized into
   multiple subsections:
      2.0 Prototool Overview
      2.1 Use of FPT
      2.2 Scenarios
      2.2.1 Scenario 1
      2.2.2 Scenario 2

      Also having flow diagrams that are shown later in the document
      as part of the scenarios would help.

--> still open.

      d. "Doing this locally at nAR when the MN attaches to it
      improves performance, " - Is it not also a requirement for
      security reasons?

--> yes, text added.

      e. "Performing context transfer in advance of the MN attaching to nAR
      clearly has potential for better performance" - This is an
      assumption that would need further justification. State that
      this is an assumption or backup the claim.

--> modified text to:

	Performing context transfer in advance of the MN attaching 
	to nAR can increase handover performance.  

      f. "This is feasible for instance in Mobile IP fast handovers."
      - Most cellular networks also have the capability to determine
      that a mobile needs to be handed off. So mention this to be the
      case in most cellular networks.

--> Yes, text added.

      g. "must be properly synchronized with appropriate handover
      messages, such as Mobile IP (Fast) Binding Update." - Do not
      need this dependency. Delete statement.

--> deleted

      h. The last paragraph discusses again the SAs between
      ARs. Mention that this is outside the scope of this document and
      be done. No reason to get into details of an SA being easier for
      intra-domain vs inter-domain etc.

--> agreed

8. Section 2.4
   a. "The Mobile Node, for which context transfer protocol operations are
   undertaken, is always identified by its previous IP access
   address." - Is uniqueness of the address at the previous AR
   guaranteed? For example in the case of Mobile IPv4, MNs which have
   private addresses may use the FA advertised CoA and reverse tunnel
   to the HA. In that case there could be multiple MNs with the same
   IP address(HoA). The FA is able to differentiate them based on the
   HA, HoA combination.

--> assigned issue 20.

   b. "At any one time, only one context transfer operation may be in
   progress" - I could not understand whether this is the case on a
   per MN basis or for a pair of ARs

--> per MN

9. Section 2.4.1
   a. "Always sent by" - Dont start a sentence of a paragraph with a
   verb (Nit - Sorry :) )

--> fixed.

   b. "it should also be relayed to pAR." - Why?

--> assigned issue 21

10. Section 2.4.2
   "The Authorization Token is obtained by truncating the results of
   the HMAC_SHA1 computation to retain only the leading 32 bits." 
   - Is this sufficient? I mean just the leading 32 bits? But maybe
   this is more of a question for security experts.

--> Issue 222

11. Section 2.4.4
    "If transfering a context requires an ongoing process (i.e., is not
    short-lived)," - CT is most useful as described earlier for
    reducing packet loss and performance degradation of apps. Hence it
    is critical that CT has to be relatively quick. So I dont
    understand what you mean by CT not being short-lived. If it is not
    short-lived, it is useless.

--> text changed to:
	If transferring a context cannot be completed in a timely fashion, 
	then nAR may send CTC to pAR to cancel an ongoing CT process.

12. Section 3

    a. "CTP runs over UDP using port number <TBD>. - This needs to be
    requested from IANA. Hence properly documented as such.

--> text added:

	7.2 UDP Port

	CTP requires a UDP port assignment.

    b."because of the physical proximity of the access routers" - This
    is an assumption of the topology and need not be the case.

--> text deleted.

    c. i/UDP provides a optional checksum/UDP provides an optional...

--> fixed

    d. "the status value BAD_UDP_CHECKSUM," - Where in the document
    are these error codes specified?

--> see Issue19: Error codes have not been defined in the document. 

13. Section 4
    Keep the list of open issues in an appendix.

--> deleted.

14. Section 5
    Flow diagrams are good. However more text is needed to explain
    each of these in the document.

    In 5.3:
    a. "CTAR request to nAR (nAR must be able to authenticate MN for CT,
    security details later)" - When later?

-> text covered already.

    b. How does the MN know if the new AR is capable of processing
    CTAR?

--> see issue 5, still open.

    c. What happens to the context at the pAR after transfer is
    complete? Not explained in document.

--> Issue 23, my comment: -> I think we should have a timer for context at the pAR.  When the timer expires, context is deleted.

    In 5.4:
    "routed through nAR (routing details later)."
    When later?

--> soon ;)  see issue 15.

15. Section 6

    It would be good to have the security considerations section split
    up into the threats that exist and how they are tackled.

--> some initial text added.

    From paragraph 2 it appears that there is an assumption about the
    topology of the network connecting the ARs. It would be good to
    keep it more general.

--> I am sorry, but I don't understand your comment, I don't see this assumption.

    Is it also not the case that AAA based mechansisms can be used for
    setting up the SA between ARs?

--> out of scope.

16. Section 7
   
    The IANA section is not well written and does not provide enough
    guidelines for assigning type numbers and error codes and for the
    setup of the registry proposed by this document.

--> some clean-up already done.

17. Section 8
    s/during the creating of/during the creation of

--> fixed.

18. Appendix A

    "This diagram illustrates the method for specifying context type
    data"
    What diagram?

    Also more text explaining the Context Type and how it fits into
    the CTD message would help.

-> deleted.