Subject: Re: ASCII text message option (option 56)

From: Tony McAuley <[email-masked]>
Date: Fri, 30 Jun 2000 10:55:54 -0400

I too like that the idea of a "welcome message" and "network sign-on."
However, I agree with Barr Hibbs' comments on not putting it into DHCP,
but into a separate registration (user-AAA) protocol, with DHCP only
giving the IP address of the domain registration agent.

Our motivation comes form liking the idea of using DHCP in 3G+ IP
wireless networks. We now believe that registration and configuration
should be done in two independent protocols, such as:

  . DHCP/DRCP for configuring a node with a new IP address when it
    moves to a new subnet, ... and optionally the IP address of a
    "Domain Registration Agent."

  . URAP (User Registration and Authentication Protocol) sent to the
    "Domain Registration Agent" when a node first moves into a domain.
    URAP then interfaces to inter-domain AAA protocols such as DIAMETER.

    RADIUS/DIAMETER main user interface Today is through PPP (which
    also does configuration and framing).

URAP is a new idea (so far as we know the AAA group has not yet looked
at a user-AAA protocol like this for IPv4). Appreciate any thoughts on
the idea.

Thanks
 Tony

----------------------------------------------------------------------------

Anthony J. McAuley                     email:
[email-masked]
MCC 1C235B, Telcordia Technologies                    phone: +1 973 829
4698
445 South Street, Morristown, NJ 07960                  fax: +1 973 829
5888
----------------------------------------------------------------------------

----------------------------------------------------------------------------

> Date: Thu, 29 Jun 2000 15:54:25 -0700
> From: Ted Lemon <[email-masked]>
>
> That was probably a poor choice of words.   I'm talking about network
> registration.   You walk into a new site, plug in your laptop, and
> bang, up comes a registration page where you can identify yourself to
> the network and potentially register so that you can get access to
> it.   I'm not talking about network signon in the sense of a known
> user authenticating him- or herself.
>
> This sort of thing would be a big boon for cable modem and DSL ISPs,
> for example, and could also be useful for things like the
> much-talked-about but rarely-seen airport 100baseT service.   More to
> the point, this is an existing application that people already do -
> what Stuart is proposing would merely make telling the end-user how to

> register a lot easier - essentially, they would be able to say "just
> plug it in and follow the instructions that appear on your screen."
> I don't _think_ the AAA people are doing anything like this.
----------------------------------------------------------------------------

----------------------------------------------------------------------------

> Date: Thu, 29 Jun 2000 18:45:49 -0400
> From: John Schnizlein <[email-masked]>
> Subject: AAA - was RE: ASCII text message option (option 56)
>
> Are you advocating Diameter instead of DHCP to identify and give
network
> parameters to hosts?  While I agree that convergence between
traditionally
> separate dial-up and LAN-attached startup parameters is inevitable, it
is
> not clear that the DCHP WG should just defer to the Diameter WG.
> (-: Sorry, I guess it is actually still called the AAA WG.  :-)
> I expected more of the time-honored competition between approaches.
----------------------------------------------------------------------------

----------------------------------------------------------------------------

> From: "Barr Hibbs" <[email-masked]>
> Date: Thu, 29 Jun 2000 15:24:21 -0700
>
> I really don't see the need for using DHCP as a network messaging
> system.  As for network sign-on, look at the AAA (Accounting,
> Authentication, and Authorization) working group to see how network
sign-on
> is being approached.
----------------------------------------------------------------------------

----------------------------------------------------------------------------

> Date: Thu, 29 Jun 2000 15:05:41 -0700
> From: Ted Lemon <[email-masked]>
>
> Limited purpose?   What about as the basis for a network sign-on?
> The potential here is huge, and IMHO entirely appropriate for DHCP.
> Where else would you put this?   Invent an entirely new protocol?
----------------------------------------------------------------------------

----------------------------------------------------------------------------

> From: "Barr Hibbs" <[email-masked]>
> Date: Thu, 29 Jun 2000 15:04:14 -0700
>
> ...you're actually missing the point of this option a bit, I believe.
> [Ralph, please jump in here and correct any misstatements I make!]
>
> ...this option is more typically used to convey descriptive error
messages
> when the server NAKs a client request.  That's not to say that your
use is
> wrong, but it does reflect my view that DHCP is an underlying service,
not a
> replacement for MOTD or login banner messages.
>
> ...as we go forward, the English-centric nature of many network
protocols
> will change, and with it, NVT-ASCII for messages will probably change
to
> accommodate non-English speakers.
>
> ...I would oppose the creation of a new option for such a limited
purpose as
> you are proposing, because I doubt its value in general, and don't
believe
> the more common clients will handle it in a universally-acceptable way

> [having said that, I probably should run out and test my
assertion....]
>
> ...I also oppose overloading it with a URL through redefinition of the

> option:  not because a URL can't be expressed in an NVT-ASCII field,
but
> because that would require client modifications to utilize
effectively.  As
> far as Apple shipping clients and servers that make some appropriate
use of
> the existing option, and even recognize a URL embedded in it, I don't
> believe such a use is contrary to the nature of the option -- just
don't
> expect non-Apple clients to effectively use this mechanism for
broadcasting
> messages to your client users.
>
> --Barr
----------------------------------------------------------------------------

----------------------------------------------------------------------------

> Date: Thu, 29 Jun 2000 14:57:22 -0700
> From: Ted Lemon <[email-masked]>
>
> I think it's a brilliant idea, but encourage you to write a draft and
> submit it to the WG rather than overloading the text message option.
> I'd also suggest in your security section that you say that the web
> browser that fetches this page MUST NOT (or at the very least SHOULD
> NOT) reveal any information about the user when it fetches the page.
> If you write up the draft, I'll second it, and argue for a quick
> turnaround.  I can definitely think of applications for this, and if
> you implement it, everybody else probably will too!  :')
----------------------------------------------------------------------------

----------------------------------------------------------------------------

> From: Stuart Cheshire <[email-masked]>
> Date: Thu, 29 Jun 2000 14:29:13 -0700
>
> Here at Apple, we're using the DHCP ASCII text message option (option
56)
> to display a "welcome message" when a user first connects to the
network
> and acquires a DHCP address (a bit like the "Message Of The Day" when
you
> log on to a unix system).
>
> However, in this modern world, some people want more than plain ascii
> text. They want the DHCP server to provide the URL of a web page that
the
> client machine should fetch, render, and display in a window.
>
> I see two ways to do this:
>
> 1. Define a new DHCP option code for an explicit welcome page URL.
>
> 2. Overload the DHCP ASCII text message option, so that if you set the

> text message to be a string of the form:
>
> <URL:http://www.apple.com/welcome.html>
>
> then the client recogises this string as "special" and instead of
> displaying that actual text in the window, it parses the URL and
displays
> the web page instead.
>
> Solution 1 is better, but DHCP is running out of option codes, and the

> process of getting new ones allocated can be slow. Apple want to ship
> code that does this, like, yesterday.
>
> Solution 2 is ugly, but easy to do.
>
> Comments?
----------------------------------------------------------------------------

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 30 Jun 2000 09:41:14 -0700

MOTD messages should either be associated with a login prompt or with a
system messaging protocol, but not with system boot. Messages like
"printer nn is being serviced today" are messages that all users that
login to the network should see, not something that only the first user
to login on that system should see. Conversely, something like "company
meeting at 3pm" may be something that you want to broadcast or multicast
to all users a couple of times during the day, not something you want to
rely on a week-old DHCP lease for. Unless you are tying DHCP leases to
logins somehow then DHCP messages just aren't the best place for this
kind of notification.

In general, I'd say that network-wide announcements should either use a
multicast messaging service (a wall derivative or IMSP or something
similar that allows for easy sending by admins, and easy ignoring by
users) or should use login banners as part of an access protocol.

For automated network-access events (plugging in to airport networks),
that sounds good but it's such a special case scenario I'm not sure. It
doesn't make sense for corporate or home users if the leases renew
overnight, or if the cable modem is renewing a lease that the user never
sees because their PC is NAT-attached. There are a lot of assumptions
all around that, and the special case where it would actually be
meaningful is extremely narrow...

I'd say if there's a really good reason for it, then overflow the text
but please document the usage somewhere and keep it as simple as
possible. But I am having trouble thinking of a good reason for using
DHCP for this. Stuart, can you share with us what the idea is in a
general way?

-- 
Eric A. Hall                                      http://www.ehsco.com/
Internet Core Protocols        http://www.oreilly.com/catalog/coreprot/

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 30 Jun 2000 13:07:14 -0700

There seem to be two topics in the same thread:

   1) URL-encoding within the ASCII text option

   2) A generic exec option

(1) is easy. Extend the option so that <a href=url>text</a> is allowed
and should be intepreted as a link to some external resource, which
should call an application that can handle the url if selected. yadda
yadda yadda. This appeases various things like "this system is not
authorized for network acces. <a href=mailto/http:>click here</a> to
request access."

(2) is more difficult. There would need to be a lot of discussion about
how you would represent the action, do you need to represent the command
and parameters differently, what kind of actions are to supported (URLs
only? command-line apps? both?), etc. Very tricky.

These two things need to be separated IMHO, although the generic URL
encoding in (1) could also be "application encoding" that calls local
app instead of url.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Jun 2000 13:34:22 -0700

> only? command-line apps? both?), etc. Very tricky.

I don't think anybody's proposing (2).   (2) would be an extremely
dangerous enhancement, and I'd have trouble getting behind such a
proposal for the same reason that having Java in my web browser gives
me the willies.

			       _MelloN_

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 30 Jun 2000 13:49:34 -0700

> proposal for the same reason that having Java in my web browser gives

If you want to automatically fire up a web browser that takes a user to
a registration URL then you're talking about an exec option (2).

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Jun 2000 14:07:38 -0700

> a registration URL then you're talking about an exec option (2).

No, you aren't.   An exec option (2) means firing up an arbitrary
program on command of the DHCP server.   A URL means that you'll do an
HTTP request to get the contents of a web page and arrange to display
it.   It has no other specific implications.   Implementation is left
up to the implementor, and the implementation that I have in mind for
NetBSD doesn't involve automatically firing up a full-fledged
browser.   I can't speak to what Stuart or Nathan have in mind, of
course.

			       _MelloN_