Subject: Comments on draft-ietf-malloc-api-04.txt

From: Peter Parnes <[email-masked]>
Date: Sat, 21 Nov 1998 13:18:07 +0100

Hi

Here are some comments on the "draft-ietf-malloc-api-04.txt" draft. If this 
have been discussed earlier on the malloc mailing list then just ignore my 
rambling :-)

[email-masked] said:
> [*] An open question is: Who is allowed to deallocate (or query or
> change the lifetime of) a previously allocated multicast address?
> This is an implementation-specific decision, dependent upon the
> security policy of the host system, and is not specified in this
> abstract API.  One possible starting point, however, is the following:
>         A previously allocated multicast address can be deallocated
> (or have
>         its lifetime queried or changed) by the same "principal", and
> on the
>         same node, as that which originally allocated it.
> ("principal" might,
>         for example, be a "user" in the host operating system.)

>From a practical point of view, isn't that quite useless? I'm thinking of how 
easy it is to impersonate another "principal".  A very simple proposal is 
instead to associate a secret key when the session is allocated and only those 
that can present that key can later "modify" the address-allocation? (But then 
we get into snooping problems instead :-/  )

What I'm questioning here is if the security issues really should be left for 
future  implementations or be defined by the WG?

> future allocation and not using the addresses

Isn't this quite hard to enforce in todays MBone? What if a session announced 
is to start at some future point in time and this announcement is shown to a 
user and that user joins the session before it has started? Even if the user 
don't want to send any traffic to the session s/he most likely will send RTCP 
packets anyhow (for RTP based media of course).  E.g. We usually announce our 
sessions for live lectures with times that exactly matches the times of the 
real lecture. This means that video transmission from the lecture room  
usually begins about 5-10 minutes before the actual start-time. It also means 
that listeners usually join in a couple of minutes before the lecture starts.

Perhaps there is a need to separate the SDP active time from the actual mcast 
address allocation time?

****

Other error messages. It might be useful to add something like a "server busy" 
error message to notify the client that there are currently to many request 
being thrown at the server at the same time (on the other hand this might not 
ever happen :-).

/P

---

From: Dave Thaler <[email-masked]>
Date: Sat, 21 Nov 1998 20:14:27 -0500 (EST)

> future  implementations or be defined by the WG?

The WG could either decide that deallocation before the lease expires
is a good thing, and take on the security problem associated with it.
Or the WG could decide that deallocation before the lease expires
is not worth it at this point.

I'm interested in hearing the WG's opinions on this, and if
Ross or someone else wanted to give a presentation at IETF on
the tradeoffs, that'd be great.

> that listeners usually join in a couple of minutes before the lecture starts.

This one has been discussed once before (but not at any great length,
and I can't remember whether it was on the list or in a meeting), 
and the consensus at the time was that it is not a problem.

This is equivalent to booking a meeting room at IETF.
If you show up 30 minutes early, there may be another meeting going on
in the room, and if you enter the room, others will see you.
Likewise, if you join a multicast group early, some other session may be 
using it at the time, and others in that session may see you.

It would be reasonable in my opinion, to suggest that address allocators
may/should actually allocate 5-10 minutes on either end of the requested 
start and end times.

I'm also interested in the WG's opinion on this as well, so thanks
for bring this up again.

> being thrown at the server at the same time (on the other hand this might not 

I'm not sure I understand how that would be used.  If it's too busy,
it probably wouldn't see the request to respond to.  And I'm not sure
what you're proposing that a client could do upon receiving such a
message.

-Dave

---

From: Ross Finlayson <[email-masked]>
Date: Thu, 26 Nov 1998 21:17:17

At 01:18 PM 11/21/98 +0100, Peter Parnes wrote:

>easy it is to impersonate another "principal".

Well, that, of course, depends on how you define "principal" :-)

I agree that this section of the abstract API document could be clearer.
The intention is merely to explain that a concrete realization of this API
may decide, for security reasons, not to allow 'just anyone' to deallocate
(or query or change the lifetime of) a previously allocated address.
Beyond this, there's not much more that the abstract API can really say.
(The "principal" discussion was intended merely to give designers of
concrete APIs a possible starting point to work from.  However, this is not
the first time that readers have been puzzled by this, so I may end up just
removing it.)

However, this same security issue also applies to the underlying
*inter-node* protocols - MDHCP and/or AAP - that will actually implement
multicast address allocation.  Here, however, we can actually say something
concrete, because these protocols are the actual 'products' that this
working group hopes to standardize.

In particular, the current MDHCP draft - in the "Security Considerations"
section - notes this issue, although it 'hand waves' by merely referring to
the possibility of adding (optional) access control (with client
authentication).  However, I wonder if perhaps we should try to do better
than this, by adding explicit support in the MDHCP protocol.  E.g., each
successful 'allocate' operation could return (in addition to the multicast
address) a randomly-generated token that a client would have to present in
order to later be able to deallocate the address???

(As far as I can tell, this issue does not arise with AAP, because AAP
doesn't have a 'deallocate' operation, and, in any case, uses digital
signatures to protect against spoofing.)

>is not worth it at this point.

As I noted above (but please correct me if I'm wrong), this seems to be an
issue only for MDHCP, not for AAP or MASC.  Note, however, that even if we
were to remove the 'deallocate' operation from MDHCP, there are still (the
same) security issues associated with the 'extend lifetime' operation.

>the tradeoffs, that'd be great.

I probably won't be attending this IETF, unfortunately (I'm too poor right
now :-(, so I'd probably have to leave this to someone else.

	Ross.