Subject: some bizarre thoughts on 802.11 equipped trains, MIPv6 and SEND.

From: Michael Richardson <[email-masked]>
Date: Fri, 29 Nov 2002 12:32:36 -0500

-----BEGIN PGP SIGNED MESSAGE-----

Background:
Richard and I are on a VIA rail train, with laptops, on the way to Toronto
for some meetings.

I am complaining that the train doesn't go fast enough, or at least that 
there isn't the view out the window doesn't really impress me how fast it
goes, but that seeing out the front would help. We decided that the engine
needs an 802.11 equipped webcam on the front of the locomotive. Geeks like
me can then hit Shift-Reload, or use streaming media to see where we are
going.

We then discussed the fact that the train system ought to be using IP for
management (talking to the virtual caboose, telemetry back to HQ,
etc.). Wouldn't it be nice if the infrastruture was really secure enough that
passenger train operators felt comfortable sharing their management infrastructure with
the passengers.  (I know that some trains in Japan have 802.11, but I'm sure
it is seperate from the operator's networks)

Is this a new model for SEND? Or just a combination of models?

It is quite possible that the train would contain a mobile *network* of some
kind. My laptop, using the train's mobile network, would actually want to be
mobile from its home. I think that this is just a complicated form of
roaming.... I'm on a network that itself is moving. Whether the train is
getting new prefixes as it travels along vs doing some layer 2 thing is
debatable. 

======

We then had an interesting thought - some guy (in the middle of Montana,
i.e. nowhere) with a laptop, waiting for a train to zip past.  Assuming that
he can actually hear the train long enough to do 802.11, this guy, despite
being stationary, may in fact manage to get some packets in/out.

First observation - if the train operator lets me roam onto his network
for free (well, included in my ticket) there is likely little reasonable
ways for them to keep the hill-billie from accesing things.

More curious - if the prefixes for the train are not mobile (they remain
geographically attached to cell towers), and the train moves from tower
to tower (say using 802.11a to talk to the tower, and 802.11b for inside
the train). The hill-billie is actually moving from base station to base
station (i.e. it is getting a new default router), but actually isn't 
moving at all - neither physically, nor from prefix to prefix.

=====

Just some random thoughts.
There is no point.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 30 Nov 2002 09:05:22 +0200

Michael Richardson wrote:
> ... Wouldn't it be nice if the infrastruture was really secure enough
> that passenger train operators felt comfortable sharing their
> management infrastructure with the passengers. ...
> 

Hmm.  To me it sounds basically like the second trust model, with
some extensions.  That is, everybody trusts the operator (the train
router), and most probably the rest of security is on application
layer.  At the ND level it seems enough that the passangers
can't cause DoS preventing the train instrumentation system from
working.  And speaking about that, IMHO it would not be very wise
to use 802.11(a/b) for something like instrumentation in a fast
moving vehicle...

> It is quite possible that the train would contain a mobile *network*
> of some kind. My laptop, using the train's mobile network, would
> actually want to be mobile from its home. I think that this is just a
> complicated form of roaming.... I'm on a network that itself is
> moving. Whether the train is getting new prefixes as it travels along
> vs doing some layer 2 thing is debatable.

That sounds very much like a NEMO.  Have you checked the NEMO charter
and discussions?

> More curious - if the prefixes for the train are not mobile (they
> remain geographically attached to cell towers), and the train moves
> from tower to tower (say using 802.11a to talk to the tower, and
> 802.11b for inside the train). The hill-billie is actually moving
> from base station to base station (i.e. it is getting a new default
> router), but actually isn't moving at all - neither physically, nor
> from prefix to prefix.

This one I didn't get.  Are you assuming a very long train or what?
Anyway, didn't make much sense to me.

--Pekka

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Sat, 30 Nov 2002 13:30:13 -0800

Hello,

> the passengers.

This has more to do with application-layer security. Unless,
getting on the network means getting to every bit of resources
on the network (which is not the best model for this scenario).
But even than, this wouldn't be related to SEND, but to PANA.

> (I know that some trains in Japan have 802.11, but I'm sure

We had that at the Yokohama IETF. Trains had FOMA (3G) for
Internet connectivity, and WLAN for the access networks for
passengers.

> Is this a new model for SEND? Or just a combination of models?

I think the problems in this scenario are missing the SEND scope.

> the train).

(again, this is out-of-scope, but) using 802.11a for train-to-Internet
connection is not a good idea, unless the train is stationary.
Range of 802.11a is limited, and a moving train is too fast to utilize
the network.

alper

> The hill-billie is actually moving from base station to base
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> Comment: Finger me for keys
>
> iQCVAwUBPeeksIqHRg3pndX9AQFZywP/bSTgtvzCg2LBSj+dz5FUWO5tcEFMwGK+
> 2XRLC9mdcTSqxrkXp+EnVeZZcVgtPP6OPKg10qVtYn7OZdl5DvNximGU2aExSn5z
> qb09u2Z3JTyhQSgGr9MlHeXwz8FDUitKNo7Iyb9X+xMzTe3iopco/H8TmnDG7dRX
> 5l9k7Y7lRxQ=
> =CT0W
> -----END PGP SIGNATURE-----