RE: [Mip4] Comments on draft-sastry-mip4-string-extension-01

["Kent Leung \(kleung\)" <kleung at cisco.com>]

Hi TJ.  Thanks for the detailed review.  Comments below.
 

> -----Original Message-----
> From: mip4-bounces at ietf.org [mailto:mip4-bounces at ietf.org] On 
> Behalf Of T.J. Kniveton
> Sent: Thursday, September 29, 2005 6:20 PM
> To: mip4 at ietf.org
> Subject: [Mip4] Comments on draft-sastry-mip4-string-extension-01
> 
> Hi,
> 
> I was asked to take a look at this draft. Well it expired 2 
> weeks ago, but hopefully this will be useful for the next rev.
> 

Yes, we're just about to submit a new revision.  So the timing is good
to incorporate some of your feedback.


> General:
> This document proposes a new extension to MIP4 to allow a 
> text string to be sent from the HA or FA to the MN. The draft 
> does not mandate that a string be handled in a certain way; 
> this is left to implementors. The only requirement is that 
> the string is "intended for the user of the Mobile Node."
> 

Yes, this is the intention.


> 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.


> Editing:
> 
> Section 1, 2nd paragraph.
> "it's" -> "its"
> might want to insert a hyphen in "implementation dependent"
> 
> Section 4, 2nd paragraph.
> "it's" -> "its"
> 
> recommend adding a pronoun, "a" or "the", before each 
> occurrence of Home Agent and Foreign Agent. This is already 
> done in the abstract, but the rest of the document lacks it.
> 
> 

OK.  Will make changes.

Kent

--
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/