 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
Hi Kent,
My main question is how to guarantee interoperability. The draft says that the message can be displayed on a UI, logged, or handled any other way, as the implementor wishes. This obviously creates issues in terms of interoperability and reliability of the system.
The message is purely informational on the MN. And how this information
is conveyed to a user is implementation dependent.
It is easy to imagine displaying or logging a message when we have a traditional UI or syslog, and the message is the suggested registration failure or welcome/motd. In other circumstances it might be unpredictable what a message will cause. This is especially an issue when interoperating between one vendor's HA/FA and another's MN.
Typically, a MN will have some UI for configuration, monitering, and
debugging purpose, as well as some logging facility. So it's up to the
software to decide how to handle this information from the HA about the
registration response.
The Text field's definition says the text "is intended to be human readable, and MUST NOT affect operation of the protocol." However, I would assert that this is not the case at all -- what is the purpose of the text if no effect is desired? It suggests user intervention on failure, which would somehow have to affect the operation of the protocol (i.e. causing configuration changes) to be useful. To go even further, the example given shows a case where the HA would reject the Reg. Req. due to timestamp mismatch, and the MN's implementation would shield the user from the text message, sending another registration. How would this be possible unless the MN somehow parsed the text message on behalf of the user?
Sorry if this example is confusing. The timestamp mismatch is part of
normal Mobile IPv4 operation to synchronize the timestamp between the MN
and HA. So actually, the MN sending another registration is in response
to the error code received and has nothing to do with the informational
message. Maybe we should come up with a different example instead.
Maybe along the line that HA sends a registration deny with a message
"Prepaid quota reached. Please contact www.paymore.com to update
balance."
One final question: in the security considerations section, what is your interpretation of the difference for HA and FA, and what if a malicious node tries to insert the message after the M-H auth ext?
This is the same issue brought up on FA Error Extension draft. We
recommend using MN-FA Auth Ext whenever possible. If not, then the harm
is really some annoying message. For example, if the user goes to
www.paymore.com to add more money to his account, he'll see that the
fund is sufficient already. We should recommend that the message should
not compromise any user or MN information as the text string is clear
and may be added by an unscrupulous node.
Thanks for your reply. TJ
-- Mip4 mailing list: Mip4 at ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/