Re: [rtcweb] Resolving RTP/SDES question in Paris

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Ravindran, Parthasarathi [mailto:[e-mail]]
> Sent: Thursday, March 22, 2012 11:40 PM
> To: Dan Wing; 'Roman Shpount'; 'Harald Alvestrand'; 'Ted Hardie'
> Cc: [e-mail]
> Subject: RE: [rtcweb] Resolving RTP/SDES question in Paris
> 
> Even in case disabling encryption is not the desired behavior, I don't
> see the problem in using RTP-IPSec instead of SRTP-DTLS.

Several.

IPsec ESP tunnel or transport mode?  With NAT-T support?  Is there
an API for applications to determine if the underlying OS provides
IPsec ESP for that flow (I know for Cisco IOS, the answer to that
API question is 'no'.  And that was my understanding in the version 
of Windows Server that we used to use for our call control system,
although of course that could have changed with Windows 7 or 8).
RTP over IPsec breaks link header compression (cRTP and ROHC),
which are used by some networks.

> I understand
> that web-browser has no standard way to identify whether plain IP or
> IPsec in Layer 3. So, it shall be configured by browser-user and it
> shall be considered as user consent. This approach helps in case in
> avoiding double encryption technically wherein IPSec is mandated. I
> know the argument that double encryption is not problem in the endpoint
> as it has huge CPU and memory resources but in case web-browser as part
> of access devices, it will have impact on performance. My issue is with
> mandating to use SRTP-DTLS in WebRTC and not with mandate to implement
> SRTP-DTLS.

'Double encryption' is done because it's the only way to achieve
security at various layers.

Let's take a simple example:  someone is using their PC at a coffee
shop or a conference, and (because the person is using a possibly-hostile
network, and the person is ostensibly working) they bring up a VPN.  All 
of the person's traffic goes into their VPN.  The person then accesses
paypal (or gmail, or hundreds of other example sites), which forces them 
to use HTTPS.  They are now "double encrypted".  

Can you see the difficulty in removing the HTTPS connection to Paypal
(or gmail, etc.).  Can you see the difficulty in the PC determining
the HTTPS connection is "good enough" and routing that outside the 
VPN -- it can't be done simply by port number or else someone could
accidentally run un-encrypted traffic on port 443.

And this person may well even be triple encryption, if the WiFi access 
point uses wireless encryption.  Taking your argument further, if we 
are running IPsec we should have a way to disable the WiFi encryption?
But the WiFi encryption is being used to protect that layer -- just
like the IPsec is used in the VPN to protect that layer and the HTTPS
to PayPal is used to protect that layer.

> Also, AFAIK HTTPS certificate is not free of cost. Whereever the cost
> matters like social welfare site, educational site and some free blogs,
> the tendency will be towards HTTP

Ok.  (Separate problem.)

> and user of those sites will have the
> consent to use RTP.

I don't see why those sites cannot use SRTP.

-d


> Thanks
> Partha
> 
> >-----Original Message-----
> >From: [e-mail] [mailto:[e-mail]] On
> Behalf
> >Of Dan Wing
> >Sent: Friday, March 23, 2012 4:14 AM
> >To: 'Roman Shpount'; 'Harald Alvestrand'; 'Ted Hardie'
> >Cc: [e-mail]
> >Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Roman Shpount
> >> Sent: Thursday, March 22, 2012 7:19 AM
> >> To: Harald Alvestrand
> >> Cc: [e-mail]
> >> Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris
> >...
> >> Yes, I was worried about supporting the interceptor. This is all
> >> related to my question of support of WebRTC applications in
> military,
> >> prisons, or financial organizations. I think WebRTC would be
> >> completely disabled in such locations unless web browser can be
> >> configured to confirm to some sort of communications and monitoring
> >> policy. I do not think enabling only certain applications is a
> >> sustainable solution, since application can only be enabled based on
> >> its URL, but this in no way implies that the actual protocol used
> for
> >> signaling exchange by this application will stay the same. In the
> best
> >> case this will result in tens of specialized monitoring rules that
> >> will need to be maintained. In the worst case, WebRTC would be
> simply
> >> disabled. At this point the only workable solution that I see is
> some
> >> sort of media proxy protocol.
> >
> >The SIPREC working group, formed in March 2010, has solutions for this
> >problem.  The problem is not created by RTCWEB.  Disabling encryption
> is
> >not necessary -- nor desirable.  "Jails" get brought up in this
> context
> >often, so using that same example, consider a prisoner at a jail
> >communicating with their lawyer.  The prisoner needs secure
> >communications with their lawyer without the risk of the
> communications
> >being leaked to the press by anyone along the media path.  For details
> >see http://tools.ietf.org/wg/siprec/
> >
> >We will have a brietf presentation on SIPREC during my session at
> >RTCWEB, explaining how it can work with RTCWEB.
> >
> >-d
> >
> >
> >
> >_______________________________________________
> >rtcweb mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/rtcweb