On 7 Dec 1999, Perry E. Metzger wrote:
> Tripp Lilley <[EMAIL PROTECTED]> writes:
> >
> > Is this really the "right" model for that sort of interaction?
>
> Yes. I don't want to invent fifteen thousand different protocols to
> handle things. IP already does what I need most of the time.
Perhaps I wasn't clear... IP (v4 or v6 or what have you) is a fine way of
determining the end points of the communication. But at higher levels
(MEGACO, SIP, LBMP, etc.), I believe it makes sense to allow in the
protocol design that people might want to consolidate funcionality in an
ALG (more below)
> I'm not sure that's the right model, actually. IP addresses are too
> easy to forge. The right way to stop people from doing that sort of
> thing is to deploy end to end security protocols that strongly
> authenticate both ends.
Realistically, in the home environment (which is quite specifically the
domain I'm constraining these statements to, even though they might have
broader applicability), it's unreasonable to expect that every light bulb
(light fixture) is going to carry the silicon to handle authentication
(and/or encryption).
I think it makes sense to consider a boundary (firewall+ALG) that defines
a "trusted zone" within the house, establishes ACLs for a given
"connection", be it a tunnel or otherwise, defined by an authentication
event, and mediates the activity over that connection as long as it's
active.
Treating each and every action into that trusted zone as a separate
request, carrying separate overhead for connection setup and teardown
(over the WAN), and separate overhad for authentication and encryption
puts us in the same boat as HTTP/1.0.
I'm not saying we should consider anything other than IP to establish the
desired endpoints of the given transacion. I'm not saying we should try to
hide topology and addressing behind a NAT. I'm saying that even *with* a
connection that's end-to-end for the purposes of designating participants,
we might want to consider that someone in the middle will be mediating the
conversation, acting on behalf of one or both participants.
An example to wit: I want to be able to plug my Extend-A-Home 2000 (tm)
intelligent brick into the ethernet jack in my hotel room, then unpack all
the rest of my goodies (portable printer, portable scanner, wireless
IP phone, Palm Connected Organizer(tm), MP3 player, etc.) and have them
"just work". Now, I realize that all of this can be accomplished through a
combination of DHCP, DDNS, and IP Mobility. But that requires an awful lot
of complexity in each device, when that complexity *could* be hidden
inside the Extend-A-Home 2000 (tm). I plug it in and *voila*, my hotel
room is an extension of my home. All of my permissions into my home remain
intact (with only an authentication exchange between the Extend-A-Home
2000 and the Home-Weiller 2000 Border Establishment Unit(tm)).
You also have to consider that just because IP is the "right" answer
doesn't mean it's what will end up in the stacks of all of these micro
devices (especially light bulbs). There will be gateways and proxies for
LON and CANbus and X-10 and so forth for a while to come, possibly
forever.
All I'm saying is that taking ALGs into account for reasons *other* than
NAT doesn't seem like such a bad idea as we're doing new work.
--
Tripp Lilley * [EMAIL PROTECTED] * http://stargate.sg505.net/~tlilley/
------------------------------------------------------------------------------
"There are plenty of things out there that people should be offended about.
Put your indignation into some more productive and appropriate fight."
- Larry Rosensweig
in http://www.cnn.com/1999/US/12/03/pokemon.swastika.ap/index.html
