Subject: [Mip4] WG: tsv-dir review of draft-ietf-mip4-fmipv4-07.txt

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 7 Jun 2007 16:43:11 +0200

Resend...

 -----Ursprüngliche Nachricht-----
Von: Tschofenig, Hannes 
Gesendet: Donnerstag, 7. Juni 2007 16:23
An: Perkins, Charles (NSN, US/Palo Alto); [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Betreff: tsv-dir review of draft-ietf-mip4-fmipv4-07.txt

Hi all, 
 
I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. 

draft-ietf-mip4-fmipv4-07.txt aims to reduce handover delays of Mobile IPv4. Since there is already a specification for FMIP support for IPv6 published (namely RFC 4068 published in July 2005) this specification adapts the RFC 4068 to IPv4 networks with minor adjustments.

A few minor comments:

In Section 4.2 I believe you have to use RFC 2119 language for the following text parts: 
"
      "Home Address" field must be the PCoA (which can be either the
      Home Address or the co-located CoA)

      Home Agent field must be set to PAR's IP address

      Care-of Address field must be the NAR's IP address discovered via
      PrRtAdv message

      Destination IP address must be PAR's IP address

      Source IP address must be the PCoA (which can be either the Home
      Address or the co-located CoA)
"
and in 
"
When sent in this "reactive" mode, the Destination IP address must be NAR's IP address;
"

With respect to the predictive fast handover it seems that you assume that the PAR is able to detect a disconnect of the MN before the bidirectional tunnel is established between the PAR and the NAR. I understand that you don't want to describe the different ways how the PAR is able to detect the disconnect but you might just say that it somehow detects it and then initiates the procedure. Makes sense? 

I am not sure what the purpose of Section 5 is. You refer to a long expired draft but why does it matter. Can this section be deleted?

Section 6: 

You write: "

The Code values below are the same as those in [rfc4068],
   and do not require any assignment from IANA.
" 

Maybe you want to add "However, IANA actions are required for type numbers."

In Section 6.1 you write: 

"
         Lifetime: The number of seconds remaining before binding
         expires.  MUST NOT exceed 10 seconds.
" 

You might want to replace "MUST NOT exceed 10 seconds." with 
"The value in this field MUST NOT exceed 10 seconds." to have a complete sentence. 

In several places you write that the FBACK is bitwise identical to the messages used in RFC3344. I wonder whether this is true since you have a new type code. I think you might just write that the message layout uses the format of RFC 3344. 

For the security between the access routers you write: 

"
   The HI and HAck messages need to be secured using a pre-existing
   security association between the access routers to ensure at least
   message integrity and authentication, and should also include
   encryption.
"

I think you want to recommend IPsec usage. 

Do you assume that the two nodes, PAR and NAR, in the same administrative domain or potentially in different domains? 
The key management could be more difficult if the two nodes are in different domains. 

In case of "Secure FBU, malicious or inadvertent redirection" isn't it quite likely that an attack by a mobile node can be punished later since the key management used to create the security association for the FBU is likely going to be associated with the network access authentication and hence the identity of the user can be traced back. 

There are certainly some impacts on transport layer protocols due to the way how the handover procedure works. I am sure that there are papers available (maybe even written by the authors) that describe some of the affects. It could be useful to point to such a paper. 

Ciao
Hannes

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/