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