Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft STRAW minutes]

[Christer Holmberg <[e-mail]>]

Hi Partha,

I am glad you are triggering a discussion on this :)

However, I would ask you to change the subject. The purpose of my e-mail was simply to request whether people have any issues with the meeting minutes as such, e.g. whether they think something is missing, and/or whether the minutes don't reflect what was discussed during the meeting :)

Regards,

Christer

From: Parthasarathi R [mailto:[e-mail]]
Sent: 30 July 2014 04:34
To: Christer Holmberg; [e-mail]
Cc: 'Richard Barnes'; 'Sean Turner'; 'Stephen Farrell'
Subject: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: Draft STRAW minutes]

Hi all,

I have different view than the security folks look at this draft. This draft intention is not to violate RFC 2804. In case this draft is not standardized, all B2BUA handling DTLS-SRTP will end up in violating RFC 2804 due to the lack of guidelines/standards to follow. Please look into this draft from SIP recording architecture in B2BUA (Fig 1 of RFC 7245) usage perspective wherein the senders/receiver is informed about the call recording (like call centre usage scenario) and no RFC 2804 violation.

In IETF-90 meeting, the security concerns are raised about this draft usage. It will be good to document as part of this document if it is really security issue. I'm not seeing any major security concerns as B2BUA is yet another UA. Please let me know the list of security concern specific to B2BUA in DTLS-SRTP.

In reality, B2BUA terminating DTLS-SRTP is not avoidable because of the different codec profile between the deployed SIP UAs. Say SIPoWS in browser (WebRTC endpoint/SIP UA) uses Opus/G711/VP8 as a codec as of today and SIP Mobile devices uses AMR/AMR-WB/H.264. There is a compulsion to terminate the media in the middle as there is no solution exists in IETF for the same. The lack of standard leads to proprietary session border controller (SBC) solutions which breaks other SIP enhancements as well.

Thanks
Partha

From: straw [mailto:[e-mail]] On Behalf Of Christer Holmberg
Sent: Saturday, July 26, 2014 7:54 PM
To: [e-mail]<mailto:[e-mail]>
Cc: Richard Barnes ([e-mail]<mailto:[e-mail]>); Sean Turner; Stephen Farrell
Subject: [straw] IETF#90: Draft STRAW minutes

(Co-chair)

Hi,

Below are the STRAW minutes that the chairs intend to upload.

However, before we do that, we would like to ask the community to take a look at least at the notes associated with the DTLS-SRTP presentation, as it caused lots of discussion.

Note that the minutes do not contain who-said-what information (that can be found elsewhere), but if you think there are some important things missing, or if you think something is wrong, please let the chairs now.

Thanks!

Regards,

Christer & Victor

-------------------


IETF 90 - STRAW

1150-1320 EDT    Friday Afternoon Session I





Topic:     Agenda bashing, IETF Note Well and WG status

Presenter: Christer Holmberg (co-chair)

Slides:       http://www.ietf.org/proceedings/90/slides/slides-90-straw-0.pdf

Draft:     N/A





No issues were identified.







Topic:     Guidelines to support RTCP in B2BUAs

Presenter: Lorenzo Miniero

Slides:       http://www.ietf.org/proceedings/90/slides/slides-90-straw-1.pdf

Draft:     draft-ietf-straw-b2bua-rtcp





It was indicated that XR needs to be looked into, to see whether something needs to be covered in the draft.



It was indicated that the terminology will be aligned with the grouping-taxonomy draft. In case there are conflicts, or other issues are found, the STRAW community is requested to provide comments on the grouping-taxonomy draft.



It was requested whether the draft should also cover RTP specific issues. It was indicated that the scope of the RTCP, and that we should be very careful about introducing RTP issues. It was recommended to talk to Colin Perkins whether he has any opinions regarding the need to cover RTP.



I was asked how the document will relate to the work on multisource optimisation taking place in AVTEXT.



It was indicated that the text recommending man in the middle functionality for SRTP most likely will cause issues with IESG. After the DTLS-SRTP discussion (see further down) it was suggested that the RTCP draft should not talk about SRTP.







Topic:     Taxonomy Discussion

Presenter: Lorenzo Miniero

Slides:       http://www.ietf.org/proceedings/90/slides/slides-90-straw-2.pdf

Draft:     All STRAW deliveries





It was agreed the STRAW shall use the terms in the avtext-grouping-taxonomy document in preference to definitions elsewhere is they are appropriate, with a note indicating any differences in other documents that may influence understanding.







Topic:     STUN handling in B2BUAs

Presenter: Lorenzo Miniero (on behalf of the draft authors)

Slides:       http://www.ietf.org/proceedings/90/slides/slides-90-straw-3.pdf

Draft:     draft-ram-straw-b2bua-stun





It was indicated that B2BUA, due to policy reasons, may strip candidates from SDP.



It was indicated that B2BUAs must be very careful to not perform actions that will cause ICE mismatch.



The chair informed the community that a WG adoption request will be sent out within the upcoming weeks.



It was indicated that the group needs to follow the ICE bis work taking place in MMUSIC, in case there will be any impacts on the STRAW draft.







Topic:     DTLS-SRTP handling in B2BUAs

Presenter: Lorenzo Miniero (on behalf of the draft authors)

Slides:       http://www.ietf.org/proceedings/90/slides/slides-90-straw-4.pdf

Draft:     draft-ram-straw-b2bua-dtls-srtp





The presentation triggered lots of discussions and controversy, as it was seen as an attempt to standardize MITM (man in the middle procedures). While people did realize such actions take place in deployments, they claimed that IETF/STRAW should not standardize such procedures. It was also indicated that it goes against a number of BCP specifications, and RFC 2804. Others indicated that the purpose is to make sure that entities doing this kind of functionality do it in a way which does not cause interoperability problems, which could cause people to not use security to begin with.



It was indicated that one possible way forward could be to simply document, in an informal delivery, how different vendors do things in the network, but in such case the vendors should also be listed in the document.



Before the draft is adopted as a WG item, further discussions need to take place. The ADs will help with finding the correct people (security, IESG, etc) to involve in such discussions. The chair indicated that the draft implements a charter delivery, but that one possible outcome will be to remove/re-scope the charter delivery.