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

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Sat, 1 Oct 2005 09:11:34 -0700

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of T.J. Kniveton
> Sent: Thursday, September 29, 2005 6:20 PM
> To: [email-masked]
> 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: [email-masked]
    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/

---

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 4 Oct 2005 13:20:06 -0700

Hi Kent,

> is conveyed to a user is implementation dependent.

OK, I understand the basic goal.. But I haven't seen many examples of  
protocol extensions designed to simply carry user-oriented  
informational messages about a low-layer protocol. Is there something  
here that couldn't be achieved by SNMP?

> "Prepaid quota reached.  Please contact www.paymore.com to update

Right. My point was simply that you described how a MN could suppress  
the informational message if it could "figure out" and fix what the  
problem was without user intervention (here, based on the error  
code). But since the message is informational, the MN has no idea  
that the message intended for the user was that the prepaid quota had  
run out! Maybe it was an unrelated informational message.

I do understand your goal, if it is that informational messages  
should only be displayed if (1) an error condition exists that the MN  
can't figure out how to rectify with another attempt, or (2) the  
registration was successful. But then it should be stated as such.

> and may be added by an unscrupulous node.

I guess it depends on the message itself. It could be used for social  
engineering or some sort of phishing attack that's not as innocuous  
as a simple error message. Of course, that would depend on what the  
implementors use the messages for.

Thanks for your reply.
TJ