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

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

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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 12 Jun 2007 11:54:11 +0200

Thanks Rajeev for the quick rsponse. The modifications look good to me. 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: Rajeev Koodli [mailto:[email-masked]] 
> Gesendet: Montag, 11. Juni 2007 22:53
> An: ext Jari Arkko
> Cc: Perkins, Charles (NSN, US/Palo Alto); 
> [email-masked]; [email-masked]; [email-masked]; 
> Rajeev Koodli; Tschofenig, Hannes; [email-masked]
> Betreff: [tsv-dir] Re: tsv-dir review of draft-ietf-mip4-fmipv4-07.txt
> 
> 
> 
> Hi Jari,
> 
> Below are the additions in the OLD/New format.
> 
> -Rajeev
> 
> 
> On 6/8/07 3:46 PM, "Rajeev Koodli" <[email-masked]> wrote:
> 
> > Okay. Francis also noted this.
> > 
> 
> Section 4.2 (first paragraph)
> 
> OLD:
> 
> When sent in this "predictive" mode, the
> fields in the FBU are used as follows:
> 
> NEW:
> When sent in this "predictive" mode, the
> fields in the FBU MUST be used as follows:
> 
>       "Home Address" field is the PCoA (which can be either the
>       Home Agent field is set to PAR's IP address
> 
>       Care-of Address field is the NAR's IP address discovered via
>       PrRtAdv message
> 
>       Destination IP address is the PAR's IP address
> 
>       Source IP address is the PCoA (which can be either the Home
> Section 4.2 (fourth paragraph, below Figure 1)
> 
> OLD:
> 
> " When sent in this "reactive" mode, the Destination IP 
> address must be
> NAR's IP address;.."
> 
> NEW:
> 
> "When sent in this "reactive" mode, the Destination IP 
> address MUST be NAR's
> IP address;.."
> 
> > Purely informational. I am okay one way or the other.
> > 
> 
> OLD:
> 
> Section 5:
> 
> NEW:
> 
> Delete Section 5. 
> 
> Add 
> 
> "Sending FBU from the new link (i.e., reactive mode) is similar to
> using the extension defined in [draft-mip4-ro]; however, this 
> document also
> addresses movement detection and router discovery latencies."
> 
> At the end of the Acknowledgment (Section 10).
> 
> 
> >> 
> > Ok.
> Section 6.1
> OLD:
> NEW:
>          expires.  This value MUST NOT exceed 10 seconds.
> 
> 
> >> 
> > Ok, I can add that.
> Section 8:
> OLD:
> NEW:
>    encryption. IPsec ESP SHOULD be used.
> 
> 
> >> 
> > It's possible to trace it, yes.
> > 
> 
> Section 8 (paragraph 5)
> 
> OLD:
> 
> ".. Hence, the extent of this
>    vulnerability is small."
> 
> NEW:
> 
> " Hence, the extent of this
>    vulnerability is small. It is possible to trace the 
> culprit MN with an
> established security association at the access router"
> 
> 
> 
> >> 
> > We wrote a paper for ACM CCR a while ago (October 2001). 
> More recent results
> > are documented in an upcoming book.
> > 
> 
> The last paragraph in Section 3.
> 
> OLD:
> 
> ".. These delays contribute to the handover performance..."
> 
> NEW:
> 
> ".. These delays contribute to the handover performance. See 
> [fh-ccr] and
> Chapter 20, Chapter 22 in [mi-book]"
> 
> Section 10:
> 
> ADD:
> 
> Thanks to Francis Dupont and Hannes Tschofenig for the 
> GEN-ART and TSV-DIR
> reviews.
> 
> 
> References:
> 
> [fh-ccr] R. Koodli and C. E. Perkins., "Fast Handovers and 
> Context Transfers
> in Mobile Networks," ACM Computer Communications Review 
> Special Issue on
> Wireless Extensions to the Internet, October 2001.
> 
> [mi-book] R. Koodli and C. E. Perkins, "Mobile 
> Internetworking with IPv6:
> Concepts, Principles and Practices," John Wiley & Sons, June 2007.
> 
> 
> 
> > Thanks for your review.
> > 
> > -Rajeev
> > 
> >> 
> >> Ciao
> >> Hannes
> 
> -- 
> http://people.nokia.net/~rajeev
> 
> 
> 
> 
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 12 Jun 2007 13:44:36 +0300

Thanks -- I added the relevant RFC Editor notes for
this.

(I'm still awaiting IANA's OK to proceed with the
approval of the document. We've answered their
questions but I want to make sure that the
answers were satisfactory from their point of
view.)

Jari

Tschofenig, Hannes kirjoitti:
>>>>       "Home Address" field must be the PCoA (which can be 
>>>>         
>> either the
>>     
>>>>       Care-of Address field must be the NAR's IP address 
>>>>         
>> discovered via
>>     
>>>>       PrRtAdv message
>>>>
>>>>       Source IP address must be the PCoA (which can be 
>>>>         
>> either the Home
>>     
>>>> When sent in this "reactive" mode, the Destination IP 
>>>>         
>> address must be
>>     
>>>> NAR's IP address;
>>>> "
>>>>         
>>>> "The value in this field MUST NOT exceed 10 seconds." to 
>>>>         
>> have a complete
>>     
>>>> sentence. 
>>>>         
>>> Ok.
>>>
>>>       
>> Section 6.1
>>
>> OLD:
>>
>>>> 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
>>     
>>>> 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
>>

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 11 Jun 2007 13:52:37 -0700

Hi Jari,

-Rajeev

OLD:

NEW:

OLD:

" When sent in this "reactive" mode, the Destination IP address must be
NAR's IP address;.."

NEW:

"When sent in this "reactive" mode, the Destination IP address MUST be NAR's
IP address;.."

OLD:

Section 5:

NEW:

Delete Section 5. 

Add 

"Sending FBU from the new link (i.e., reactive mode) is similar to
using the extension defined in [draft-mip4-ro]; however, this document also
addresses movement detection and router discovery latencies."

Section 6.1

OLD:

NEW:

Section 8:

OLD:

NEW:

Section 8 (paragraph 5)

OLD:

NEW:

" Hence, the extent of this
   vulnerability is small. It is possible to trace the culprit MN with an
established security association at the access router"

> We wrote a paper for ACM CCR a while ago (October 2001). More recent results

OLD:

NEW:

".. These delays contribute to the handover performance. See [fh-ccr] and
Chapter 20, Chapter 22 in [mi-book]"

Section 10:

ADD:

Thanks to Francis Dupont and Hannes Tschofenig for the GEN-ART and TSV-DIR
reviews.

References:

[fh-ccr] R. Koodli and C. E. Perkins., "Fast Handovers and Context Transfers
in Mobile Networks," ACM Computer Communications Review Special Issue on
Wireless Extensions to the Internet, October 2001.

[mi-book] R. Koodli and C. E. Perkins, "Mobile Internetworking with IPv6:
Concepts, Principles and Practices," John Wiley & Sons, June 2007.

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 08 Jun 2007 15:46:02 -0700

Hi Hannes,

> somehow detects it and then initiates the procedure. Makes sense?

The bidirectional tunnel is established as a result of processing the FBU
message and HI/Hack exchange. This is done in predictive and reactive cases.

See

" The Handover Initiate (HI) and Handover Acknowledge (HAck) messages
   serve to establish a bidirectional tunnel between the routers to
   support packet forwarding for PCoA.  The tunnel itself is established
   as a response to the FBU message."

below Figure 2.

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

Not all the messages need Type assignment though. In fact, only FBU and
FBack need Type assignment.

Ok.

> new type code. I think you might just write that the message layout uses

I found only one occurrence of "bitwise" for FBack, at the beginning of
Section 6.2. :-)

Ok, I can add that.

> The key management could be more difficult if the two nodes are in

The protocol does not make any assumption. Agree that the deployment
considerations differ based on who owns what.

Thanks for your review.

-Rajeev