I plan to update the draft based on comments. let me try to repley each of unresolved comments based on Sri's last time presentation slides. thanks for all your reviews.
2008/7/28 Kent Leung (kleung)
<kleung at cisco.com>
Hi folks. I think this draft needs more review. Some comments on
version 06.
1) Sect. 3.2.
It's confusing to show "notificaton" from AAA to FA. Maybe the arrow
can be named "trigger" since the notification message is from FA to MN
and to HA?
[Hui] Revised, thanks
2) Sect. 3 usage scenarios clarificaton. Can MN send notification to
FA? MN to HA via FA or direct?
[Hui] Basically, I feel MN could send notification according to security SA.
but current document doesn't make any example, so let it be.
3) Sect. 4.1. Reference RFC 3115 for VSE and RFC 4917 for generic
string. Not clear how binding revocation is applied in GNM?
A generic notification message is sent by a mobility agent to inform
another mobility agent, or a mobile node, of MIP-related information
such as vendor specific extensions, generic string notification or
binding revocation.
[Hui] I plan to remove revocation support in this message, does any other people
has different idea about it?
3b) Sect. 4.1. The IP destination address should be "Same as the last
Registration Reply/Request message received". Also, shouldn't the
source IP address and port be same as the last registration message?
This would support NAT traversal and ensure same security association
used for GNM/GNA and RRQ/RRP.
... These messages must use the same IP and UDP
headers as any previous Registration Request or Reply message to the
same entity. The generic notification message is defined as follows:
IP Fields:
Source Address Sender's address.
Destination Address Receiver's address.
UDP Fields:
Source Port variable.
Destination Port Same as the last Registration Reply/Request
message.
[Hui] I can't remeber previous discussion, but it seems your suggestion is reasonable, updated
IP Fields:
Source Address Same as the last Registration Reply/Request
message received.
Destination Address Same as the last Registration Reply/Request
message.
UDP Fields:
Source Port Same as the last Registration Reply/Request
message.
Destination Port Same as the last Registration Reply/Request
message.
4) Sect. 4.1. What is the Binding Revocation extension? RFC 3543
specifies Revocation Support Extension to indicate MN or FA supports
revocation function. But this extension does not provide notification
or revocation.
3 Information carried in Binding Revocation extension
[Hui] You are correct, here is mistake, I plan to remove revocation support from this document.
5) Typo "foreing" -> "foreign":
5 -- Message sent by the foreing agent to the home agent
[Hui] Revised, thanks
6) Using nonce method requires much more operational description (e.g.
HA does not have nonce value with MN after registration). Replay
protection using timestamp should be covered in a section for clarity.
For example, FA -> MN GNM security is not covered by RFC 3344.
Identification
A 64-bit number, constructed by the sender, used for matching
Generic Notification with Generic Notification Acknowledgement,
and for protecting against replay attacks of notification
messages. Here is the same as Sections 5.4 and 5.7 of [RFC3344].
Timestamps is mandatory and nonces is optional.
[Hui] I plan to remove nouce support by only support timestamp.
will make a independent section to describe replay protection, it will be done soon.
7) Sect. 4.2. Why is the GNA's source UDP port not copied from the GNM?
NAT traversal issue (when NAT between FA and HA) if not copied.
UDP Fields:
Source Port variable.
[Hui] Revised thanks,
8) Sect. 4.2. Why values 2 and 3 are not described? As noted before,
I'm not clear about value 3.
The value 0 is reserved and should not be used. The value 1
indicates that the actual information is carried in vendor
specific extensions. Other values are reserved for future
extensions.
[Hui] will remove value 3. add value 2 description
9) Sect. 4.2. Is MD needed in GNA? GNA is in response to GNM so MD
should be known. Also, not sure if HA and CoA address fields needed in
GNA?
[Hui] I think if this message mightbe relayed by FA, then MD will be useful
sometime, to make packet visible clearly., probably HA and CoA is not needed,
orginal intention is to match notification with acknowledgement.
10) Sect. 4.2. The description does not cover Identification field.
Identification
The fixed portion of the Generic Notification Message is followed
by one or more extensions which may be used with this message, and
by one or more authentication extensions (as defined in Section
3.5 of [RFC3344].
[Hui] Revised thanks,
11) Sect. 4.2. There are 3 defined cases: VSE, generic string, and
revocation extension. VSE is handled by each vendor. I assume that
generic string handling is based on RFC 4917. Revocation is unclear.
If the mobile node accepts the home agent's generic
notification message, it will process it according to the specific
rules for that extension.
[Hui] will revise to say RFC 4917, and will remove revocation.
12) Sect. 4.3.2. source address should be MN's HoA in the case of
FA-CoA. Destination address should be FA.
In the case of a FA-CoA, the source address is the mobile node's CoA
address and the destination address is the home agent's address ("MD"
value is set to 2),
[Hui]revised, thanks,
13) Sect. 4.4.1. FHAE is optional for GNM from HA to MN via FA, right?
If the "MD" value is set to 0, the foreign agent MUST check the FA-HA
AE and Authenticator value in the Extension if the Foreign-Home
Authentication extension is presented. if more than one Foreign-Home
Authentication Extension is found, or if the Authenticator is
invalid, the foreign agent MUST silently discard the Notification
message.
[Hui] Revised, thanks
14) Sect 4.4.3. How does FA know the timestamp of the HA to send GNM?
Does FA have to glean the Identification field in the RRP? Need
clarification here. Also, if FA maintains some timestamp value for each
HA, and vice versa, that needs to be added to FA and HA considerations.
[Hui] thanks for your input, will revise to ask FA to glean identification field of RRP.
15) 4.5. Since RFC 4917 was intended for MN to receive a message from
the network, it's unclear what HA or FA will do when generic string is
received?
[Hui] plan to add the descrition in section 5.1
16) 4.5. Shouldn't HA acknowledge the receipt of the GNM in this case?
If the home agent receives a notification message
from a foreign agent and there is no corresponding mobile node
registration, the home agent should drop the notification message.
[Hui] I will append a code field for GNA.
17) 4.5.2. Should specify that HA sends GNM with A bit set when GNA is
not received. Or this can be generically covered.
[Hui] revised , generically covered, will resend the GNM message.
18) sects. 5 and 5.1. The example for revoking the CDMA session can be
handled by revocation message (RFC 3543). This adds to the confusion
when revocation message vs. GMN should be used. May be good to clarify
that point.
[Hui] remove revocation to remove the concrn.
19) 5.1. Typo "notificaiton". There are other typos that can be checked
later.
[Hui] revised and thanks
20) 5.2. Not clear how this is different from revocation message with
generic message string extension?
[Hui] will remove revocation support
21) Agree with Pete on the timestamp sync issue. That means some use of
code 133 in GNA. Should there be some Code field in GNA to confirm
positive or negative operation after receiving GNM?
[Hui] I will append a code field for GNA. and describe the sync issue.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | MD | code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
code
A value indicating the result of the Generic Notification Message.
See below for a list of currently defined Code values.
Notification suceessful
0 -- notification accepted
Notification denied by the home agent
128 -- reason unspecified
129 -- administratively prohibited
130 -- insufficient resources
131 -- mobile node failed authentication
132 -- foreign agent failed authentication
133 -- notification Identification mismatch
Notification denied by the foreign agent
64 -- reason unspecified
65 -- administratively prohibited
66 -- insufficient resources
67 -- mobile node failed authentication
68 -- home agent failed authentication
69 -- notification Identification mismatch
Notification denied by the mobile node
192 -- reason unspecified
193 -- administratively prohibited
194 -- insufficient resources
195 -- mobile node failed authentication
196 -- home agent failed authentication
197 -- notification Identification mismatch
22) NAI extension should be covered in draft. Home Address is not
typically sufficient to identify the MN.
[Hui] will describe it and add a reference.
Kent
Thanks kent again.
