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