Subject: Re: Session Announcement Protocol Draft Draft

From: Ross Finlayson <[email-masked]>
Date: Fri, 21 Jun 1996 11:05:22 -0700

Mark (cc. confctrl),

Thanks for writing this up.  There are some good thoughts here, e.g., wrt.
security.  In fact, I'd originally anticipated using a somewhat different
announcement protocol with similar features for my extended browser (when
making non-SDP announcements in other than the default directory), but after
reading your draft I'm hoping that I can just use SAP after all.  (And yes,
I wasn't able to keep my promise to have a beta version of my browser ready
by Montreal.  Sigh...)

Here are some comments on your draft, just in time (I hope) for your
presentation at Montreal.

One concern that I have about your draft is that it's rather confusing about
the issue of "announcement identity", which is a bit strange considering
that in developing the earlier SDP spec, we made a special effort to nail
this down.  In the SDP spec, we made it clear that the triple
"<username><session id><address>" (in the "origin" field) forms a unique id
for a session description (with the monotonically-increasing "<version>"
field being used to distinguish versions).

But now, in the SAP draft, you talk about a new 16-bit "message id(entifier)
hash" (and also a "version hash", which I think is the same thing).  I don't
see the need for this.  It sounds like you're intending this to be used as
an id that receiver implementations could use to quickly locate their
internal description of a session - e.g., a hash table index.  This seems
rather pointless.  First, because of the possibility (albeit remote) of hash
colisions, it can never be more than a hint.  To get the real 'identity' of
a session, you always have to look inside the SDP fields (as described
above).  Second, CPUs these days are fast.  Don't get in their way by trying
to do too much of their job for them.  Let the receivers compute their own
hash table ids from the "<username><session id><address>", using whatever
algorithm they choose.  Also, it seems that bandwidth, not CPU, is the
resource that's most constrained.  Omitting this 16-bit value will help a
little in this respect.

The various discussions (on pages 3 and 8) of the security implications of
the authentication header being optional - and what happens if modifications
and/or deletions are received - seem more convoluted than they need to be.
A perhaps simpler way of looking at this (which I think leads to the same
conclusions) is as follows:
- An announcement either has no authentication header, in which case its
unique id is defined by "<username><session id><address>" (as noted above),
or it has an authentication header, in which case its unique id also
includes the <public key> that's present in the AH.
- This means that - *by definition* - an announcement with an AH is
considered different from an announcement without an AH, or from one that
has an AH but with a different <public key>.
- For announcements with an AH, the digital signature (i.e., signed by the
<public key>) prevents tampering or fake announcements
- For announcements with no AH, the source address check provides the only
authentication (albeit weak), and *all bets are off* wrt denial of service.

I agree, btw, that the SAP authentication header that you describe is
different in purpose from the IPSEC one (although where possible we should
try to use the same security mechanisms that the IPSEC folks are proposing).
In fact, I would go a step further than suggest that the <public key>
perhaps be moved into *SDP*.  (This would allow session descrptions
announced by other means - e.g., by email or on Web pages - to be identified
and authenticated in the same way.)

The "explicit deletion" mechanism is a good idea (I think), but it may need
to be fleshed out a bit.  E.g., what happens if a deletion is received
before the corresponding announcement (e.g., because the announcement was
lost)?  In this case implementations should probably hold on to deletions
until a corresponding announcement arrives, or the deletion "times out".
(Which suggests that perhaps deletion messages should also have an "end time"?)

On page 4 you introduce "multicast address test" messages, but then don't
say anything more about them (including possible responses to them).
Perhaps these things should have a start/end time, just like SDP
announcements?  In fact, maybe they should really *be* SDP announcements:
announcing the use of one or more multicast addresses for a certain period
of time, but without any further details about the 'session'.

The assumption behind "multicast address test" messages seems to be that you
intend SAP to be used for dynamic multicast address allocation for *all*
applications - not just for sessions described using SDP.  Is this in fact
the intention?  If so, are you sure that this is going to scale in the
future if the MBone starts getting used in new ways - e.g., the use of large
numbers of low-bandwidth but high-TTL groups?  If, however, it's the
intention that SAP be used to allocate multicast addresses only for
SDP-described sessions, then why do you need separate "multicast address
test" messages?

Some comments on page 7:
- "add a random value (+/- 1/3 of the base interval)...".  You probably
should make this a bit clearer - e.g., "choose a random value in the range
[base interval*2/3, base interval*4/3]...".  In any case, the choice of
"1/3" needs to be justified a bit better.  It sounds like this is some Van
folklore that only he and a handful of others fully understand :-)
- The idea of having 'hard-coded' bandwidth limits in a protocol spec makes
me uneasy.  One alternative (warning: half-baked idea) would be to define
just the *ratios* between the bandwidth limits for each TTL range, plus a
minimum bandwidth limit.  Then, include a "scaling factor" to be included in
each SAP packet.  An implementation, when making its own announcements,
would use the lowest scaling factor that it sees for that TTL range.  (One
possibility: a 1-byte scaling factor, and compute: scale =
2**(scaling_factor/10).  This allows for a potential future bandwidth
improvements of up to ~47 million (2**25.5), which should be enough for a
while.)
- Is the paragraph about the choice of TTL for admin scoped announcements
really needed?  With admin scoping, couldn't you always just choose TTL = 255?
- You also need to mention the address range to choose from when creating
*non* admin scoped announcements?

The discussion of "implicit timeout" on page 2 needs to be deemphasized or
reworded, I think.  This is really a *user interface* issue rather than a
protocol issue.  I.e., implementations can choose to do anything they like
with 'stale' announcements, without affecting the protocol[*].  With my
browser for instance, a user can create multiple windows for a directory,
possibly setting different "staleness thresholds" for each window.  And in
my case, stale announcements are just 'hidden', not deleted.

[*]Come to think of it, I guess it can affect multicast address allocation -
i.e., should a previously announced address now be considered available,
just because the original announcement is 'stale'?  My preference is to
consider 'stale' announcements as being real for the purposes of address
allocation, but to allow implementations to do whatever they like in
deciding whether/how to present them.

In any case, specifiying a rigid interval like 1/2 hour is usually
inappropriate for trying to deal network partitions.  It's also way too
short - in the MBone announcement world, turning a machine off for the
weekend can constitute a "network partition".

Some comments on page 5:
- "a random field is encrypted along with the text payload".  Presumably
this is to prevent known plaintext attacks?  In any case, it should be
explained.
- "SAP is not tied to"...  Maybe true in principle, but at some point these
mechanisms have to be defined (or at least referenced).  (Implementors will
want to know what they should do.)  This document is as good a place as any.

Some comments on page 6:
- "Originating Source" field: Why is this needed, given that there's already
an "o=" field in the SDP payload?  Is this needed only for (weak)
authentication if there's no AH?  Does this field serve any useful purpose
if there *is* an AH?
- "Timeout" field.  Is this really needed?  Do any proxys do more than just
directly relay announcements?  (And for any that do, could we not also
expect them to also have the decryption key(s)?)

Anyway, enough rambling for now.  Time to go pack...

        Ross.

---

From: Mark Handley <[email-masked]>
Date: Mon, 24 Jun 96 02:10:31 +0100

>presentation at Montreal.

Hi Ross,

We can talk this through in more detail when you get here (Montreal),
but I'll comment on a couple of the points you raise by email for the
benefit of people on the list...

>resource that's most constrained.  Omitting this 16-bit value will help a

There are two new aspects which make this hash field useful:

 - encrypted announcements
 - proxies

A proxy (for example) cannot decrypt the SDP payload, but still needs to
be able to do session deletion, etc, hence the hash serves as an id field.

Receivers receiving encrypted announcements have to attempt to decrypt
them by trying each of the keys they know in turn.  This is expensive,
and you need someting to cache the results against (whether you
succeeded or not).  

Thus the hash/orig src pair forms a unique id that can be used for
this purpose, and can also be used to optimise the handling of
unencrypted messages (though this is somewhat less important).

It's also possible that some time in the future we might
revise/replace SDP and it would be good if we didn't need to replace
such proxies too - it would be just a different payload format.

>conclusions) is as follows:

I think you neglected proxies and encrypted announcements... these do add
a little complexity.

>and authenticated in the same way.)

Van has (90%) convinced me we can use the IPSEC AH, but not in the
obvious way.  I haven't had a chance to read it in enough detail, but
the draft he pointed me at is draft-ietf-cat-idup-gss-05.txt "
Independent Data Unit Protection Generic Security Service Application
Program Interface (IDUP-GSS-API)"

Putting the AH in SDP would stop us being able to authenticate
encypted announcements :-(  Interesting idea though...

>say anything more about them (including possible responses to them).

Yes, that ommission was a mistake.  You have to be *very* careful how
you implement this if it's not to cause more problems than it's worth.

>really needed?  With admin scoping, couldn't you always just choose TTL = 255?

How much do you trust your scope zone not to have leaks?  That section
is however probably not as clearly worded as it should be.

>protocol issue.

Careful here - it is a protocol issue - you can never assume a
deletion message reaches you - it is a basic soft-state protocol
design principle that state stimes out.  The timeouts have to be
stated in the protocol if they are to be meaningful.

>just because the original announcement is 'stale'?  

Correct, but SAP doesn't directly address multicast address allocation.

>weekend can constitute a "network partition".

Yes, and your announcement will be timed out :-) If you want it
maintained you require a local proxy, which is part of the intended
architecture, but not part of SAP directly.

>expect them to also have the decryption key(s)?)

This is debatable either way.  Certainly I do not believe proxies
should (normally) have decryption keys.  But whether they really need
this timeout is debatable.

>Anyway, enough rambling for now.  Time to go pack...

See you...

Mark