Hi Hannes, On 6/7/07 7:22 AM, "ext Tschofenig, Hannes" <hannes.tschofenig@xxxxxxx> wrote: > 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; > " Okay. Francis also noted this. > > 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? > 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. > 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. > 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." > Not all the messages need Type assignment though. In fact, only FBU and FBack need Type assignment. > 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. Ok. > > 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. > I found only one occurrence of "bitwise" for FBack, at the beginning of Section 6.2. :-) > 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. > Ok, I can add that. > 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. The protocol does not make any assumption. Agree that the deployment considerations differ based on who owns what. > > 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. > > 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. Thanks for your review. -Rajeev > > Ciao > Hannes -- http://people.nokia.net/~rajeev _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf