Hi Hannes,
On 6/7/07 7:22 AM, "ext Tschofenig, Hannes"
<hannes(_dot_)tschofenig(_at_)nsn(_dot_)com>
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf