Subject: [Seamoby] Comments from Antti Tuomin on CT Draft

From: "James Kempf" <[email-masked]>
Date: Fri, 20 Jun 2003 11:59:12 -0700

Don't remember if I forwarded these or not. Antti is co-lead for the Linux
MIPL implementation. He is also a member of the Seamoby CT review board.

            jak

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

I-D: draft-ietf-seamoby-ctp-02.txt

Review comments
---------------

1. IPv4 and/or IPv6?

   The draft does not say if this protocol is to be used with IPv4,
   IPv6, or both.  Of course, from the FMIPv6 references and 32 bit
   address fields one can assume that it can be used with both.  You
   could state this explicitly, and in message format description,
   indicate that address fields may be 32 or 128 bits long.  There is
   also the question of having separate message type numbers for IPv4
   and IPv6.  If this is IPv4 only, then some later comments may not
   hold.

2. Security

   Section 2. paragraph 3 says: "CT peers to utilize a secure channel
   for transferring contexts, providing authentication, integrity, and
   (if needed) confidentiality."  Subsection 2.4.2 and 2.4.3 say
   "message SHOULD be protected by use of IPsec Authentication Header
   (AH)".  Couldn't you just use ESP?  AH alone is not able to give
   confidentiality mentioned earlier.  Is there a specific reason to
   use AH (like need for IP header authentication)?  Also, Mobile IPv6
   uses ESP, so the chances are that ESP is already implemented in all
   the entities.

3. CTAR format and use

   Section 2. paragraph 6 says: "The CTAR nessage, described in
   Section 2.4.1, provides the IP address of nAR, the IP address of MN
   on pAR" whereas 2.4.1 says CTAR message has pAR address rather than
   nAR.  Later it is said: "It also includes the MN's new IP address
   (valid on nAR)".  Where does it include this?  I can't find a field
   for new CoA for MN in the CTAR.  I assume the text in section
   2. paragraph 6 "provides the IP address of nAR, the IP address of
   MN on pAR" is wrong.  MN's IP on pAR is not carried in the message,
   only in the IP header.

   It would be clearer, if 2.4.1 would call Mobile Node's Previous IP
   Address as Mobile Node's (previous/new) Care-of Address, Previous
   Router IP Address as (previous/new) Access Router Address, and
   describe the use of these fields in both CTAR to pAR and to nAR
   cases.

   I would recommend adding an example signaling flow for the CTAR to
   pAR case, and perhaps take out 5.4 diagram, since I don't
   understand why nAR would do 5.4 instead of 5.3.

   As Basavaraj already noted, there should be descriptions for each
   field in the message format description.  Makes implementor's life
   much easier.

4. Use of MN's new care-of address

   If MN's new care-of address is included in CTAR or CTD before it is
   assigned on the MN, nAR must defend new CoA (at least for IPv6 DAD)
   until MN claims it.  Should this requirement be stated?  Or can the
   new CoA only be used in CTAR or CTD if it is already assigned to
   the MN?  If so, then it should be clearly stated.

5. Generic message header

   Section 2.4 describes a generic message header format.  Why is this
   broken in 2.4.2?  64 bit alignment?  With IPv4, it probably buys
   you nothing.  When using IPv6 addresses, the 64bit alignment is
   screwed anyway for all other messages than CTD.

6. Optional fields and alignment

   In CDB (2.3) and CTD (2.4.2), there are optional fields in the
   message format.  Section 2.3 says that Presence Vector field is not
   present ("length of the context data block is ... plus 4 bytes if
   the 'V' bit is set") if 'V' bit is not set.  However, 2.4.2 does
   not clearly state if Mobile Node's New Care-of Address field,
   should be present if 'C' bit is not set.  Having the 'C' bit does
   suggest that it is not present.  Also, Section 2.4.2 says "The
   Authorization token type field is present in the predictive
   scenario only."  I guess Type=Auth is the Authorization token type,
   you should use Type=Auth-Token as in 2.4.1.  Does it mean that
   Type=Auth field is not present or it is zero (or some other
   undefined value)?  Further, if Key or Context Data Block is not
   multiple of 32 bits (or Type=Auth is not present), CDBs will not
   start at 32 bit boundary.  If alignment is desired, you must have
   padding or force the 32 bit alignment on the key and CDB.

7. CTAR relay

   Section 5.4 says "routing details later".  Can't find them.

8. Typos

   Section 6: s/MSUT/MUST/

   Section 2.4 paragraph 2: s/unambigously/unambiguously/

   Author's Addresses (shouldn't it be Authors')
   s/Itdmerenkatu/Itämerenkatu/ or s/Itdmerenkatu/Itamerenkatu/ (it's
   'a' with umlaut)  Nit :)

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

---

From: [email-masked]
Date: Sat, 21 Jun 2003 09:46:33 +0300

Hi James,

Thanks - I'll add this to the issue tracker on Monday.

John

> -----Original Message-----
> From: ext James Kempf [mailto:[email-masked]]
> Sent: 20 June, 2003 21:59
> To: [email-masked]
> Subject: [Seamoby] Comments from Antti Tuomin on CT Draft
> 
>

---

From: [email-masked]
Date: Tue, 24 Jun 2003 15:00:23 +0300

Hi James,

My replies.

>    and IPv6.  If this is IPv4 only, then some later comments may not

Both should be possible - assigned issue 9.

>    uses ESP, so the chances are that ESP is already implemented in all

Text suggest seems reasonable - assigned issue 10.

>    field in the message format description.  Makes implementor's life

-> resolution, suggestion seems reasonable, will update text.  Assigned issue 11.

>    the MN?  If so, then it should be clearly stated.

Good question - I don't have an answer - assigned issue 12.

>    screwed anyway for all other messages than CTD.

Agreed, will fix.  Assigned issue 13.
	
>    padding or force the 32 bit alignment on the key and CDB.

Proposal seems reasonable - assigned issue 14.

>    Section 5.4 says "routing details later".  Can't find them.

Yup, text needed.  Rajeev / Charlie - do you have text for this?  Assigned
issue 15.

>    s/Itdmerenkatu/Itämerenkatu/ or s/Itdmerenkatu/Itamerenkatu/ (it's

Fixed - no need to assign an issue.

thanks!
John