Re: [SWMP] My understanding so far

Roland Weber <ossfwot@dubioso.net> Fri, 31 August 2007 17:05 UTC

Return-path: <swmp-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR9vY-00027o-Ii; Fri, 31 Aug 2007 13:05:00 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR9vW-0001s0-Eu for swmp@ietf.org; Fri, 31 Aug 2007 13:04:58 -0400
Received: from moutng.kundenserver.de ([212.227.126.177]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IR9vV-00040F-RP for swmp@ietf.org; Fri, 31 Aug 2007 13:04:58 -0400
Received: from e180008012.adsl.alicedsl.de [85.180.8.12] (helo=[85.180.8.12]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2xA-1IR9vU3T8b-0002KV; Fri, 31 Aug 2007 19:04:57 +0200
Message-ID: <46D84A4C.6070007@dubioso.net>
Date: Fri, 31 Aug 2007 19:05:16 +0200
From: Roland Weber <ossfwot@dubioso.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070807 SeaMonkey/1.1.4
MIME-Version: 1.0
To: swmp@ietf.org
Subject: Re: [SWMP] My understanding so far
References: <OFE08B3427.B3EA5603-ON8525732C.0077710F-85257333.0024F03B@lotus.com> <46BC9717.4060103@dubioso.net>
In-Reply-To: <46BC9717.4060103@dubioso.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Provags-ID: V01U2FsdGVkX18WW2eoD5ristNVSjtSRTYHWEofkomZ1yk0bCG /5xtY1g1Rs2nmZAP/+iLZ0WYlfuuK0qvN+eBQYjgXmEbjeGipn BPr+jZZVJPxSP0fyyuQ4RRoQAHcd/dO
X-Spam-Score: 1.7 (+)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
X-BeenThere: swmp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of a Simple Wide-area Multiuser-3D Protocol <swmp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/swmp>, <mailto:swmp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/swmp>
List-Post: <mailto:swmp@ietf.org>
List-Help: <mailto:swmp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/swmp>, <mailto:swmp-request@ietf.org?subject=subscribe>
Errors-To: swmp-bounces@ietf.org

Hi all,

I've read the paper[1] by now, and it answered some of
my questions while raising new ones.

A question that is answered is about tickets. They are
representing peers rather than connection, so a ticket
is sent once over the initial channel, then received
later over all side channels too. Sending an unmodifiable
ticket as an authentication token with every UDP packet
sounds somehow like HTTP basic auth. Once somebody has
intercepted the ticket, that entity can generate new
messages that will look genuine. Some hashing technique
including a secret value that is exchanged only once in
advance could improve on both security and message size,
but it's probably too early to discuss security now.

The paper mentions limited support for multicast, but
does not elaborate. There's some more background reading
I'll have to do, but for now I imagine that a multicast
channel is unidirectional, and typically from a server
to many clients. There are two problems with that:
- no HELLO message exchange, because a client can't
  send back (over that side channel)
- no client-specific ticket in the messages sent
I understand that multicast has a low priority here, but
maybe it is still useful to give it a thought occasionally.

Then there are the message IDs. In the paper, they are
per channel and used for UDP packets only. All messages
in a packet share the same message ID. In John's summary,
message IDs are suggested for two purposes:
  a) to identify requests in FAILNOTIFY
  b) as a replacement for timestamps in SUBSCRIBE
The former has the problem that a message ID as presented
in the paper is not unique for a request, and requests via
TCP will not even have a message ID. There is a huge gap
between the interpretations in the paper and the summary.
Did I miss some discussion on that?
The latter has the problem that it is impossible to map
message IDs to unique points in (virtual) time because
they are per-channel, non-persistent, and not unique even
on a single channel. In order to implement a mechanism like
"send all changes since my last login from this machine",
a server will need some kind of timestamp, probably based
on a virtual time in the model.

cheers,
  Roland

[1] www.mediamachines.com/hydra/swampweb3d2007.pdf

_______________________________________________
SWMP mailing list
SWMP@ietf.org
https://www1.ietf.org/mailman/listinfo/swmp