Subject: [MMUSIC] RE: [Sip] Removing security preconditions from manyfolks

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 25 Feb 2002 16:11:41 -0600

One of the reasons why you need a special preconditions flag (and the rest
of the manyfolks apparatus) for QoS is because you use a separate protocol
(like RSVP) to negotiate the reserved path end-to-end. Nothing about SIP or
SDP or RTP would otherwise tell you that reservation of the path has been
expected or achieved. IMHO, this would be unwise, and probably infeasible,
for a security mechanism. The use of sRTP e2e will be obvious to the
respective user agents, for example, and the parameters of the sRTP session
should be correlated easily to information in SDP or SIP so the UAs can have
verifiable expectations about the session's security. I think all e2e media
security mechanisms will probably need to have these sorts of properties
(regardless of whether or not you use RTP, secure media will still be
secured, and that will always be obvious to the user agents). Therefore, I
think that a separate preconditions flag for security should always be
superfluous for any useful security mechanism. I think we can ditch it.

That much said, I don't necessarily oppose the IANA registration suggested
by Flemming below, although I think as a motivation for it we'd need to
understand, generally speaking, what sort of other preconditions people
might find desirable.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Sunday, February 24, 2002 9:42 PM
> To: Gonzalo Camarillo
> Cc: sip; mmusic; Fredrik Lindholm (ERA); Jonathan Rosemberg;
> [email-masked]
> Subject: Re: [Sip] Removing security preconditions from manyfolks
> 
> 
> Not all media streams use RTP or SRTP, and there are other security
> mechanism than MIKEY. While I don't feel strongly about keeping the
> "security" precondition, I don't see much gained from removing it. Perhaps
> more importantly, since you are going to break the existing manyfolks-03
> draft mechanism anyway, it would make sense to make the preconditions
> extensible (with suitable IANA registration procedures of course).
> 
> -- Flemming
> 
> 
> Gonzalo Camarillo wrote:
> 
> > Hi,
> >
> > we are thinking of removing security preconditions from 
> manyfolks. Right
> > now manyfolks handles QoS and security preconditions. However, with
> > MIKEY, this feature seems useless to establish secure channels.
> >
> > If somebody thinks that removing security preconditions 
> from manyfolks
> > is a bad idea, please speak up.
> >
> > Regards,
> >
> > Gonzalo
> > --
> > Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> > Columbia University                  Mobile:  +358 40 702 35 35
> > 472 Computer Science Building        Fax   :  +358  9 299 30 52
> > 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> > New York, NY 10027
> > USA                              [email-masked]
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments on the application of sip
> 
> --
> Flemming Andreasen
> Cisco Systems
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic