Re: [straw] Alissa Cooper's Discuss on draft-ietf-straw-b2bua-dtls-srtp-09: (with DISCUSS and COMMENT)

["Ben Campbell" <[e-mail]>]

On 2 Dec 2015, at 23:17, Alissa Cooper wrote:

> Could you articulate the reasons why someone would build a B2BUA that
>>>> follows the recommendations in this draft?
>
>
>>
>> B2BUAs used in deployments like the above mentioned scenarios can use 
>> the
>> recommendations in this draft.
>
>
> Ok. What I am still missing is why this draft needs to be published to 
> make that happen. This is the type of SBC to which the Section 3.1.1 
> guidance is directed. How does the behavior of existing media-latching 
> SBCs differ from what 3.1.1 tells them to do? And if this type of SBC 
> implementation is the key target audience, doesn’t that make the 
> 3.1.2 guidance essentially no-ops?

Authors:

After discussion on today's telechats, and some side discussions with 
Alissa, I believe this question is the lynch-pin for making any 
progress. I advise people to work this out first before worrying about 
the rest of the discussion: Can we articulate how we expect this draft 
will change implementer and/or operator behavior?

Obviously B2BUAs that exist for reasons that require modification of 
RTP/RTCP, or cleartext access to the encrypted bits of SRTP are not 
going to conform, and are therefore out of scope. The draft doesn't seem 
to concern itself with b2buas that are not in the media path at all. 
(Maybe it should, since there are plenty of purely signaling-plane ways 
to break dtls-srtp?).

That leaves the question of b2buas in the media path that do not require 
modification or cleartext access to protected bits in srtp--effectively 
media-relays as described in 3.1.1 Do we believe people do not know how 
to build or use such devices without breaking dtls-srtp? Are people 
aware of such devices that break dtls-srtp when they don't need to? 
Perhaps by misconfiguration, or because they use SBCs designed for more 
invasive use cases?

Thanks!

Ben.