Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 14 Dec 2004 11:55:00 +0200

See in-line. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of Stephen Casner
> Sent: 14 December, 2004 9:46 AM
> To: Romascanu, Dan (Dan)
> Cc: Alan Clark; Mark Baugher; Colin Perkins; Magnus 
> Westerlund; [email-masked]
> Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP
> 
> 
> On Mon, 13 Dec 2004, Romascanu, Dan (Dan) wrote:
> 
> > Previous discussions revealed concerns about extensive complexity,
> > especially in implementation and testing, in the situation that
> > today we know that only there is a need only for the 3611 report
> > type to be transmitted as selectively unencrypted. My suggestion is
> > that we define in IANA the subset of the report types that need to
> > be transmitted unencrypted. The list would include only XR extended
> > reports 207 by now and may be extended in the future.
> 
> This means I write my application today using the selectively
> unencrypted RTCP option knowning that only XR is unencrypted, then
> tomorrow my implementation talks to some new implementation that
> knows the IANA registry has changed to include XR and FOO, so both
> packet types are sent to me unencrypted when I don't expect it!
> 
> This is not feasible.  Security policies would be violated.

The alternative is to define that only XR packets can run un-encrypted and every time new cases requiring other types to run un-encrypted show up re-write the standard. This looks to un-flexible to me. 

Note that security policies may require in some cases that even XR be encrypted. In the enterprise space I can assure you that requiring end devices to transmit data unencrypted over Service Providers backbones may be a problem, because one is trading security for monitoring. That's why I believe that we need anyway some means of refusing to receive un-encrypted packets of a certain type - for example do not start sending un-encrypted packets until you received the information from the other end that it intends to do the same. 

>                                                         -- Steve

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

---

From: "Alan Clark" <[email-masked]>
Date: Tue, 14 Dec 2004 11:29:06 -0500

Dan

The concept is to allow all RTCP packets to be sent in encrypted form if the
security policy requires it, and to allow either all RTCP packets or
selected types of payload to be sent unencrypted if that is acceptable to
the network operator/ enterprise/ service provider.  What's the problem?

Alan

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Tuesday, December 14, 2004 4:55 AM
To: Stephen Casner
Cc: Alan Clark; Mark Baugher; Colin Perkins; Magnus Westerlund;
[email-masked]

See in-line.

Regards,

Dan

> This is not feasible.  Security policies would be violated.

The alternative is to define that only XR packets can run un-encrypted and
every time new cases requiring other types to run un-encrypted show up
re-write the standard. This looks to un-flexible to me.

Note that security policies may require in some cases that even XR be
encrypted. In the enterprise space I can assure you that requiring end
devices to transmit data unencrypted over Service Providers backbones may be
a problem, because one is trading security for monitoring. That's why I
believe that we need anyway some means of refusing to receive un-encrypted
packets of a certain type - for example do not start sending un-encrypted
packets until you received the information from the other end that it
intends to do the same.