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: > Thanks Rajeev for the quick rsponse. The modifications look good to me. > > Ciao > Hannes > > >> -----Ursprüngliche Nachricht----- >> Von: Rajeev Koodli [mailto:rajeev.koodli@xxxxxxxxx] >> Gesendet: Montag, 11. Juni 2007 22:53 >> An: ext Jari Arkko >> Cc: Perkins, Charles (NSN, US/Palo Alto); >> francis.dupont@xxxxxxxxxx; mip4@xxxxxxxx; ietf@xxxxxxxx; >> Rajeev Koodli; Tschofenig, Hannes; tsv-dir@xxxxxxxx >> 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" <rajeev.koodli@xxxxxxxxx> wrote: >> >> >>>> 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; >>>> " >>>> >>> 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: >> >> "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) >> >> >> 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 Address or the co-located CoA) >> >> 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 >> Address or the co-located CoA) >> >> >> 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;.." >> >> >>>> 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? >>>> >>>> >>> 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). >> >> >> >>>> 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. >>>> >>> Ok. >>> >>> >> Section 6.1 >> >> OLD: >> >> Lifetime: The number of seconds remaining before binding >> expires. MUST NOT exceed 10 seconds. >> >> NEW: >> >> Lifetime: The number of seconds remaining before binding >> expires. This value MUST NOT exceed 10 seconds. >> >> >> >>>> I think you want to recommend IPsec usage. >>>> >>>> >>> Ok, I can add that. >>> >>> >> Section 8: >> >> OLD: >> >> 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. >> >> NEW: >> >> 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. IPsec ESP SHOULD be used. >> >> >> >>>> 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. >>>> >>> 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" >> >> >> >> >>>> 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. >>>> >>> 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 >> >> >> >> >> >> >> > > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf