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

["Parthasarathi R" <[e-mail]>]

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]
Cc: Richard Barnes ([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.