tsv-dir review of draft-ietf-mip4-fmipv4-07.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]