[icecast] a new directory service

[Allen Landsidel]

At 08:19 PM 10/17/2001 -0600, you wrote:

>I apologize for the delay in response time :)
>
>I got busy.  Now I'm back :)

Cool, and you replied to me first! ;)

> > over and over for every station, wasting screen real estate and 
> bandwidth both.
>
>Ah, in general I'm not dicussing here what's shown on screen.  Only how
>the information is stored and used.  Once we lock this down, I imagine
>we'll ahve 101 good ideas about how to present this information in a
>good way.  That's the hard part :)

Roger that.

>There will also be another ogg substream for metadata only.  This will
>allow you to do all kinds of wacky stuff.  It's not done yet though.  In
>the meantime you'll have much better metadata support than shoutcast to
>tide you over.

Right on.

>I'm not sure why this didn't make it into 2.77.  But I've been told it's
>expected for 2.78.  They have to get it approved or something.  It'll be
>there.

Hopefully.. considering their DSP guy and a handful of others were laid 
off.. the new DSP they have really blows too so I'm forced into using the 
old one.. oh well.

>The current plugin is quite reliable now.  After lots of testing on
>people's test icecast2 streams I think Peter has nailed most of the
>bugs.  Also, the Windows Media Player plugins support streaming as well.
>And if I ever finish the RealPlayer one, it will too.

Oh that's cool.. and I assume the WMP plugin is available through the wacky 
MS codec plugin thing, so that it can automagically find and download it if 
it needs to?  That's just as good as default support, if not plain better.

>Icecast 1.x metadata is crap.  I know it's crap.  You guys know it's
>crap.  It isn't crap in 2.x. :)

Consider yourself quoted on that. ;)

>Intent is the same, but your suggestion is certainly clearer.

Ah ok cool.

>The only title in the directory is the title of the station.  This is a
>constant.  Show titles and song titles are transmitted in the comment
>headers for vorbis streams or in mp3-metadata.

Well since this was cleared up with the (max)TTL discussion paragraph just 
before this, it's a non-issue.

>It's easy enough to stop this kind of attack, even automatically.  Note
>that having every server send updates every 2 seconds is also going to
>be a problem.  I'm trying to find some reasonable compromise.  We can't
>100% stop cheating.  But I can certainly make cheating 'different'.
>Taking away the listener count removes a strong temptation to cheat.
>The idea is that if the temptation is weakened, cheating will not be as
>big of a problem.

True enough, but I would still like to see it there.. If it's not listed in 
this directory in particular that's not a big deal I suppose, as long as 
Icecast maintains the capability of connecting to multiple servers and 
types of servers simultaneously.

I've actually been looking for some YP "out there" to run myself for some 
of the reasons that went back and forth in this thread.  The most 
compelling one being that I want to get nice, homogenous statistics from 
all my servers, be they Icecast, Shoutcast, or something else, without 
mucking around with template files for each one.  I figured if I could just 
get them all on the same YP, by configuring Icecast and faking out 
Shoutcast via some ipfw/natd trickery, that I could generate the page 
fragments I want off the YP and stop worrying about the server software 
doing it.. but listener counts is one thing I really need here if just for 
my station homepage.

If you could point me in the direction of where I can find one of these I'd 
appreciate it.. unless you'd rather I wait until the new project we're 
discussing is ready. ;)

> > This should without a doubt be an admin tunable knob, not something to be
> > set by clients.  If you intend this directory lister to achieve widespread
> > use, especially as the software-of-choice for running public directory
> > servers, this must absolutely not be tuneable by the client.
>
>I'm not sure what you mean.  If you mean MAXTTL, it's certainly

I was talking about listener counts, not MAXTTL.

> > Applied Cryptography begs to differ with you.
> >
> > Sending a hash across the network is no more secure than sending a
> > cleartext password, if all that is required to authenticate is the
> > hash.  What you really need is something like Diffie-Hellman to do the
> > negotiation, or a public-key system.
>
>This is not to protect against sniffing.  This is to protect against
>spoofing and stealing.  It is certainly adequate to do that.  It would
>be unreasonable to bruteforce the 'password'.

Well it's not protecting against spoofing either.  Someone can sniff the 
hash and then they don't have to spoof, they can connect and send the hash 
without ever knowing the password that it was before it was hashed.

What you really need for reliable client-server authentication is a 
challenge-response system (like NT password authentication or Kerberos) or 
an encrypted transport layer (like SSL or SSH).

>When I 'check' the password on the other server, I certainly won't be
>transmitting it :)  There will be some challenge response type action
>going on.

There we go.. challenge response. :)

>We don't need absolute security.  We need security to protect against
>specific attacks.  If you'd like me to outline these in detail, I can in
>a separate email.  I have notes on the attacks and how these methods
>prevent them and also on which attacks are still possible.

I'm always interested in this sort of thing, and as you've probably 
guessed, very forthcoming with my technical critique. ;)

>In the end, it's likely we will support all three models.  There's
>nothing difficult about any of them.  I hadn't thought about the XSLT
>stuff, but that is an elegant way to do it.

Cool enough.

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.