Re: [SWMP] My understanding so far

[[e-mail]]

Roland:

My responses are mixed in.

jfp

Roland Weber <[e-mail]> wrote on 08/31/2007 01:05:16 PM:

> 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.
> 

I did not understand that about tickets.  The security concern seems 
legitimate.  The solution sounds sensible, especially because it will 
apply to all channels.  I agree that it might be too early to worry deeply 
about security, but it can't hurt to have it in mind.

> 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.
> 

I share the impression that multicast was a bit of an afterthought in the 
paper.  Nevertheless, the sentiment to support it is a good one.  It 
sounds like we need to think more deeply about how that might happen.

> 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?

No, you didn't miss any discussion on that.  My adoption of the message 
IDs to solve some of the problems I was encountering was rather "glib".  I 
did not understand that message IDs were per packet and not per message. I 
also did not understand that they were only used with UDP.  The paper did 
not anticipate using message IDs in this way because it does not support 
queries, failure notifications, or subscriptions with an indication of the 
relative completeness of the current state.  As I have mentioned 
elsewhere, I no longer believe that message IDs are a good idea for 
subscriptions.  I still think that failure notifications and queries will 
be needed.

> 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.
> 

I agree with your point about using message IDs on subscriptions.  We 
could just say that all subscriptions are followed by a full accounting of 
the state.  Or, if we want to manage the traffic better, we will need some 
notion of time to account for how far back the subscriber's state is 
valid.  If we can figure out how to use time in this fashion, it might 
decrease the traffic a lot.

> cheers,
>   Roland
> 
> [1] www.mediamachines.com/hydra/swampweb3d2007.pdf
> 
> _______________________________________________
> SWMP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/swmp

_______________________________________________
SWMP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/swmp