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

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 29 Oct 2014 04:57:46 +0530

Hi all,

One of the way to address MITM issue in STRAW WG B2BUA handling of DTLS-SRTP milestone is to focus only on Media relay (Sec 3.1 of draft-ram-straw-b2bua-dtls-srtp-00) and removing "Media Aware or Media Termination" (Sec 3.2 of draft-ram-straw-b2bua-dtls-srtp-00). 

By this proposal, the scope of the work is to cover only end-to-end DTLS-SRTP through B2BUA. The media relay provides end-to-end security but there are challenges w.r.t NAT, forking, ICE, identity (RTCWeb IdP, RFC4474bis, etc.,) which shall be sorted out in this milestone. 

During IETF-90 and in the mailing alias, I haven't heard any concern for Media relay handling in B2BUA. please let me know your opinion on the same.

Thanks
Partha

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, July 30, 2014 3:05 PM
> To: Parthasarathi R; 'Christer Holmberg'; [email-masked]
> Cc: 'Richard Barnes'; 'Sean Turner'
> Subject: Re: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90:
> Draft STRAW minutes]
> 
> 
> on vacation, back in a week
> 
> terminating DTLS-SRTP is maybe fine but means being one of the
> endpoints intended to be involved in the TLS session. Doing a
> MITM on TLS is  not at all fine.
> 
> S.
> 
> On 30/07/14 02:34, Parthasarathi R wrote:
> > 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:[email-masked]] On Behalf Of Christer
> Holmberg
> > Sent: Saturday, July 26, 2014 7:54 PM
> > To: [email-masked]
> > Cc: Richard Barnes ([email-masked]); 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.
> >
> >
> >
> >
> >
> >

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Oct 2014 06:49:17 +0000

(As co-chair)

Hi,

If anyone has an issue with the general approach suggested by Partha, please indicate to on the list, so that we in Honolulu can focus on the technical aspects.

Regards,

Christer

-----Original Message-----
From: Parthasarathi R [mailto:[email-masked]] 
Sent: 29. lokakuuta 2014 1:28
To: 'Stephen Farrell'; Christer Holmberg; [email-masked]
Cc: 'Richard Barnes'; 'Sean Turner'
Subject: RE: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: Draft STRAW minutes]

Hi all,

Thanks
Partha

> endpoints intended to be involved in the TLS session. Doing a MITM on 
> TLS is  not at all fine.
> 
> S.
> 
> > lack of standard leads to proprietary session border controller 
> > (SBC) solutions which breaks other SIP enhancements as well.
> >
> >
> >
> > Thanks
> >
> > Partha
> >
> >
> >
> > 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.
> >
> >
> >
> >
> >
> >
> >

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 29 Oct 2014 08:19:10 +0100

On Wed, 29 Oct 2014 06:49:17 +0000

> If anyone has an issue with the general approach suggested by Partha, please indicate to on the list, so that we in Honolulu can focus on the technical aspects.

I'm not convinced that we should give up on those. Media Aware and Media Termination are part of the STRAW taxonomy, and act as if they just didn't exist doesn't seem the right thing to do IMHO.

In Toronto it has been made clear that there are issues and concerns about what looked like standardizing a MITM for media. My personal feeling is that this can be considered mostly a matter of trust. The B2BUA should not necessarily be a sneaky or "transparent" component as long as participants are involved. This means that, as long as I trust the B2BUA in any scenario that involves Media Aware/Terminartion stuff, and so trust the B2BUA to secure the session on the other end or not do anything I didn't sign up for, the B2BUA is actually my "peer" in that respect. Without preventing additional mechanismsto be involved for end-to-end validation of some kind, of course. Everytihng outside of that is, I agree, MITM and shouldn't be avalled or fostered in any way.

These are just some thoughts I tried to give to the idea, and how I basically changed the related text in the RTCP draft as well to try and address the issue, so I guess there will be plenty of time to bash me when I talk about this in Honolulu :-)

Lorenzo

> _______________________________________________
> straw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/straw

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Oct 2014 07:23:06 +0000

(As co-chair)

People are of course also welcome to (actually, encouraged to) bash on the list, between meetings :)

Regards,

Christer

-----Original Message-----
From: Lorenzo Miniero [mailto:[email-masked]] 
Sent: 29. lokakuuta 2014 9:19
To: Christer Holmberg
Cc: Parthasarathi R; 'Stephen Farrell'; [email-masked]; 'Richard Barnes'; 'Sean Turner'
Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft STRAW minutes]

Lorenzo

> > endpoints intended to be involved in the TLS session. Doing a MITM 
> > on TLS is  not at all fine.
> > 
> > S.
> > 
> > > perspective wherein the senders/receiver is informed about the 
> > > call recording (like call centre usage scenario) and no RFC 2804
> > violation.
> > >
> > >
> > >
> > > 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
> > > I was asked how the document will relate to the work on 
> > > multisource optimisation taking place in AVTEXT.
> > >
> > >
> > >

--
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools http://www.meetecho.com

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 30 Oct 2014 05:20:37 +0530

Hi Lorenzo,

I'm not seeing the convincing mechanism in your proposal which overcome MITM
issue except trusting B2BUA. The most complex requirement in your e-mail is
that 

<snip>
" Without preventing additional mechanismsto be involved for
> end-to-end validation of some kind, of course.
</snip>

Could you please elaborate end-to-end validation in your mind.

Thanks
Partha

> Sent: Wednesday, October 29, 2014 12:49 PM
> To: Christer Holmberg
> > If anyone has an issue with the general approach suggested by Partha,
> please indicate to on the list, so that we in Honolulu can focus on the
> technical aspects.
> >
> 
> 
> I'm not convinced that we should give up on those. Media Aware and
> Media Termination are part of the STRAW taxonomy, and act as if they
> just didn't exist doesn't seem the right thing to do IMHO.
> 
> In Toronto it has been made clear that there are issues and concerns
> about what looked like standardizing a MITM for media. My personal
> feeling is that this can be considered mostly a matter of trust. The
> B2BUA should not necessarily be a sneaky or "transparent" component as
> long as participants are involved. This means that, as long as I trust
> the B2BUA in any scenario that involves Media Aware/Terminartion stuff,
> and so trust the B2BUA to secure the session on the other end or not do
> anything I didn't sign up for, the B2BUA is actually my "peer" in that
> respect. Without preventing additional mechanismsto be involved for
> end-to-end validation of some kind, of course. Everytihng outside of
> that is, I agree, MITM and shouldn't be avalled or fostered in any way.
> 
> These are just some thoughts I tried to give to the idea, and how I
> basically changed the related text in the RTCP draft as well to try and
> address the issue, so I guess there will be plenty of time to bash me
> when I talk about this in Honolulu :-)
> 
> Lorenzo
> 
> 
> > Regards,
> >
> > Christer
> >
> > One of the way to address MITM issue in STRAW WG B2BUA handling of
> DTLS-SRTP milestone is to focus only on Media relay (Sec 3.1 of draft-
> ram-straw-b2bua-dtls-srtp-00) and removing "Media Aware or Media
> Termination" (Sec 3.2 of draft-ram-straw-b2bua-dtls-srtp-00).
> >
> > By this proposal, the scope of the work is to cover only end-to-end
> DTLS-SRTP through B2BUA. The media relay provides end-to-end security
> but there are challenges w.r.t NAT, forking, ICE, identity (RTCWeb IdP,
> RFC4474bis, etc.,) which shall be sorted out in this milestone.
> >
> > During IETF-90 and in the mailing alias, I haven't heard any concern
> for Media relay handling in B2BUA. please let me know your opinion on
> the same.
> >
> > Thanks
> > Partha
> >
> call
> really
> > > > The presentation triggered lots of discussions and controversy,
> as
> > > > it
> > > was
> > > > Before the draft is adopted as a WG item, further discussions
> need
> > > > to
> > > take

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 30 Oct 2014 08:07:12 +0100

On Thu, 30 Oct 2014 05:20:37 +0530

> Could you please elaborate end-to-end validation in your mind.

Hi Partha,

sorry, I should have been clearer about an aspect. I agree it's still MITM: when I said "everything else's MITM" I actually meant "everything else is not any different from a MITM attack", and that's why I believe the trust is an important aspect.

About the additional mechanism, I don't have any specific solution in mind. It's my understanding, though, that the IETF community has understood there's a problem to solve there, and is already trying to address it somehow, which is why I continue to believe we shouldn't give up on it either. For insta,ce, I do recall a presentation at the AVTCORE session in Toronto which tried to address a similar concern:

	http://www.ietf.org/proceedings/90/slides/slides-90-avtcore-6.pdf

The presentation was called "Requirements for Secure RTP Media Switching", which should at least allow for a more proper management of media-aware as well, for instance.  I believe there are use cases that justify both media-aware and media-termination in secure scenarios, and ignoring them will result in the same unpredictable consequences that lead to WGs like BLISS or STRAW itself: without some guide from IETF documents, developers will either drop security entirely (something we obviously don't want) or start doing things one way or another to make it work.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 Oct 2014 10:56:18 +0000

On 30/10/14 07:07, Lorenzo Miniero wrote:
> On Thu, 30 Oct 2014 05:20:37 +0530 "Parthasarathi R"
> <[email-masked]> wrote:
> 
>> Hi Lorenzo,
>> 
>> I'm not seeing the convincing mechanism in your proposal which
>> overcome MITM issue except trusting B2BUA. The most complex
>> requirement in your e-mail is that
>> 
>> <snip> " Without preventing additional mechanismsto be involved
>> for
> sorry, I should have been clearer about an aspect. I agree it's still
> MITM: when I said "everything else's MITM" I actually meant
> "everything else is not any different from a MITM attack", and that's
> why I believe the trust is an important aspect.

And the IETF has also decided a number of times to not MITM TLS.
The impact of making that mistake would be huge and none of the
proponents of the various MITM schemes have ever evaluated that
impact as part of their proposal. That, and the fact that changing
from a two-part to a multi-party security protocol is very very
hard are among the reasons that all such proposals so far have
been DOA.

Gratuitously throwing the misplaced word "trust" into such a
discussion does not help.

S.

> 
> About the additional mechanism, I don't have any specific solution in
> mind. It's my understanding, though, that the IETF community has
> understood there's a problem to solve there, and is already trying to
> address it somehow, which is why I continue to believe we shouldn't
> give up on it either. For insta,ce, I do recall a presentation at the
> AVTCORE session in Toronto which tried to address a similar concern:
> 
> The presentation was called "Requirements for Secure RTP Media
> Switching", which should at least allow for a more proper management
> of media-aware as well, for instance.  I believe there are use cases
> that justify both media-aware and media-termination in secure
> scenarios, and ignoring them will result in the same unpredictable
> consequences that lead to WGs like BLISS or STRAW itself: without
> some guide from IETF documents, developers will either drop security
> entirely (something we obviously don't want) or start doing things
> one way or another to make it work.
> 
> Lorenzo
> 
> 
>> Thanks Partha
>> 
>>> -----Original Message----- From: Lorenzo Miniero
>>> [mailto:[email-masked]] Sent: Wednesday, October 29, 2014
>>> 12:49 PM To: Christer Holmberg Cc: Parthasarathi R; 'Stephen
>>> Farrell'; [email-masked]; 'Richard Barnes'; 'Sean Turner' 
>>> On Wed, 29 Oct 2014 06:49:17 +0000 Christer Holmberg
>>> <[email-masked]> wrote:
>>> 
>>>> (As co-chair)
>>>> 
>>>> Hi,
>>>> 
>>> please indicate to on the list, so that we in Honolulu can focus
>>> on the technical aspects.
>>>> 
>>> 
>>> 
>>> I'm not convinced that we should give up on those. Media Aware
>>> and Media Termination are part of the STRAW taxonomy, and act as
>>> if they just didn't exist doesn't seem the right thing to do
>>> IMHO.
>>> 
>>> In Toronto it has been made clear that there are issues and
>>> concerns about what looked like standardizing a MITM for media.
>>> My personal feeling is that this can be considered mostly a
>>> matter of trust. The B2BUA should not necessarily be a sneaky or
>>> "transparent" component as long as participants are involved.
>>> This means that, as long as I trust the B2BUA in any scenario
>>> that involves Media Aware/Terminartion stuff, and so trust the
>>> B2BUA to secure the session on the other end or not do anything I
>>> didn't sign up for, the B2BUA is actually my "peer" in that 
>>> respect. Without preventing additional mechanismsto be involved
>>> for end-to-end validation of some kind, of course. Everytihng
>>> outside of that is, I agree, MITM and shouldn't be avalled or
>>> fostered in any way.
>>> 
>>> These are just some thoughts I tried to give to the idea, and how
>>> I basically changed the related text in the RTCP draft as well to
>>> try and address the issue, so I guess there will be plenty of
>>> time to bash me when I talk about this in Honolulu :-)
>>> 
>>> Lorenzo
>>> 
>>> 
>>>> Regards,
>>>> 
>>>> Christer
>>>> 
>>>> -----Original Message----- From: Parthasarathi R
>>>> [mailto:[email-masked]] Sent: 29. lokakuuta 2014
>>>> 1:28 To: 'Stephen Farrell'; Christer Holmberg; [email-masked] 
>>>> Cc: 'Richard Barnes'; 'Sean Turner' Subject: RE: B2BUA handling
>>>> in DTLS-SRTP [was RE: [straw] IETF#90:
>>> Draft STRAW minutes]
>>>> 
>>>> Hi all,
>>>> 
>>> DTLS-SRTP milestone is to focus only on Media relay (Sec 3.1 of
>>> draft- ram-straw-b2bua-dtls-srtp-00) and removing "Media Aware or
>>> Media Termination" (Sec 3.2 of
>>> draft-ram-straw-b2bua-dtls-srtp-00).
>>>> 
>>> DTLS-SRTP through B2BUA. The media relay provides end-to-end
>>> security but there are challenges w.r.t NAT, forking, ICE,
>>> identity (RTCWeb IdP, RFC4474bis, etc.,) which shall be sorted
>>> out in this milestone.
>>>> 
>>> for Media relay handling in B2BUA. please let me know your
>>> opinion on the same.
>>>> 
>>>> Thanks Partha
>>>> 
>>>>> -----Original Message----- From: Stephen Farrell
>>>>> [mailto:[email-masked]] Sent: Wednesday, July 30,
>>>>> 2014 3:05 PM To: Parthasarathi R; 'Christer Holmberg';
>>>>> [email-masked] Cc: 'Richard Barnes'; 'Sean Turner' Subject:
>>>>> Re: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: 
>>>>> Draft STRAW minutes]
>>>>> 
>>>>> 
>>>>> terminating DTLS-SRTP is maybe fine but means being one of
>>>>> the endpoints intended to be involved in the TLS session.
>>>>> Doing a MITM
>>> on
>>>>> TLS is  not at all fine.
>>>>> 
>>>>> S.
>>>>> 
>>>>>> 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
>>>>>> 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
>>>>>> 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
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Sent: Saturday, July 26, 2014 7:54 PM To: [email-masked] 
>>>>>> Cc: Richard Barnes ([email-masked]); Sean Turner; Stephen
>>>>>> Farrell Subject: [straw] IETF#90: Draft STRAW minutes
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> (Co-chair)
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 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,
Draft:     N/A
>>>>>> 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.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> was indicated that the scope of the RTCP, and that we
>>>>>> should be
>>> very
>>>>> careful
>>>>>> 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.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> with a note indicating any differences in other documents
>>>>>> that
>>> may
>>>>> influence
>>>>>> understanding.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> The chair informed the community that a WG adoption request
>>>>>> will
>>> be
>>>>> sent out
>>>>>> 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
>>>>>> implements a charter delivery, but that one possible
>>>>>> outcome will
>>> be
>>>>> to
>>>> _______________________________________________ straw mailing
>>>> list [email-masked] 
>>> -- Lorenzo Miniero, COB
>>> Meetecho s.r.l. Web Conferencing and Collaboration Tools 
>>> http://www.meetecho.com
>> 
>> _______________________________________________ straw mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/straw
> 
>

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 30 Oct 2014 20:25:28 +0100

On Thu, 30 Oct 2014 10:56:18 +0000

> discussion does not help.

I don't disagree, so I won't argue (especially since I'm all but a security expert). I'll just reinstate that my only concern, and I'm sure I'm not alone in this, is the risk of dropping a whole set of scenarios STRAW identified, and leave them in the wild without guidance on how to address them. The text I proposed is probably not the right one, and one can do better, but I'd rather say something than nothing at all. I already mentioned some attempts in other WGs to accomodate similar scenarios that *might* be first steps in the right direction, and I'm sure more will follow.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.