Re: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt

[Ari Keränen <[e-mail]>]

Hi,

The proposed text looks good to me (just need to expand the CGN acronym 
since it seems to be the first instance; and check if you can find good 
reference of CGN).

Regarding the RFC3424 UNSAF considerations, I discussed this together 
with our co-chair and AD, and we agreed that a full 3424 treatment is 
unnecessary considering that this is documenting existing behavior, not 
a new mechanism.

If this clears the remaining WGLC comments, we could move forward with 
the document.


Cheers,
Ari

On 6/11/13 10:52 AM, Emil Ivov wrote:
>
>
> On 11.06.13, 08:15, Cullen Jennings (fluffy) wrote:
>>
>> Well, do you think the draft should say that this approach MUST NOT
>> be used with uncarpeted media because it allows and attacker behind
>> the same CGN can intercept the media ?
>
> I am assuming uncarpeted means unprotected here. Is this right?
>
> If so, then I think we shouldn't be doing any kind of (non-S) RTP
> because, regardless of whether or not we are using latching, our media
> would be exposed to eavesdropping from our ISP, hotspot provider, VoIP
> service provider, potentially people on the same link as us, MiTM
> attackers that have fooled us into using them as a default gateway,
> Wi-Fi monitors and possibly many others.
>
> As for the draft saying "MUST NOT", I wouldn't mind at all, however we
> don't even have a 2119 section. Also, we are not specifying a NAT
> traversal mechanism, we are just describing one that people are using
> overwhelmingly so that we can have something to point to as a
> descriptive reference.
>
> I agree that this point can be stressed upon however so, what if we
> added the following:
>
> ... actually participating in the SRTP key exchange then it would
>     simply refuse to latch onto a source unless it can authenticate
>     it.
>
>     *Failing to implement this would represent а serious threat to
>      users connecting from behind CGNs and is considered a harmful
>      practice.*
>
> Would this work?
>
> Emil
>
>
>
>> On Jun 11, 2013, at 3:03 PM, Emil Ivov <[e-mail]> wrote:
>>
>>> Hey Cullen,
>>>
>>> On 11.06.13, 04:55, Cullen Jennings (fluffy) wrote:
>>>>>
>>>>>> and discussing the issues it raises with relation to this
>>>>>> draft.
>>>>>>
>>>>>> Next I think you need to add a specific attack where two
>>>>>> people are both behind the same CGN.
>>>>>
>>>>> This exact case was already described in the security
>>>>> considerations section:
>>>>>
>>>>> tools.ietf.org/html/draft-ietf-mmusic-latching-02#page-11
>>>>>
>>>>> (last paragraph on the page)
>>>>
>>>> It was exactly this paragraph that I thought was pretty
>>>> misleading. When I read " SBCs have various mechanisms to prevent
>>>> this as well." I really wonder what they when both end points are
>>>> behind a CGN.
>>>>
>>>> I think this paragraph should make it very clear that in the
>>>> CGN case, this technic allows interception of the media. If there
>>>> are specific ways to stop that from happening, the draft should
>>>> say it and if there are not it should be very explicitly clear
>>>> about that.
>>>
>>> I was actually referring to text that came later in that same
>>> paragraph:
>>>
>>> The attacker could also redirect all media to the real SIP UA after
>>> receiving it, in which case the attack would likely remain
>>> undetected and succeed.  Again, this would be of particular concern
>>> with larger scale NATs serving many different endpoints such as
>>> carrier grade NATs.  The larger the number of devices fronted by a
>>> NAT is, the more use cases would vary and the more the number of
>>> possible attack vectors would grow.
>>>
>>> Naturally, SRTP [RFC3711] would help mitigate such threats and
>>> should be used independently of HNT.  For example, in cases where
>>> end-to-end encryption is used it would still be possible for an
>>> attacker to hijack a session despite the use of SRTP and perform a
>>> denial of service attack.  However, media integrity would not be
>>> compromised. Additionally if the SBC that performs the latching is
>>> actually participating in the SRTP key exchange then it would
>>> simply refuse to latch onto a source unless it can authenticate
>>> it.
>>>
>>> Cheers, Emil
>>>
>>>
>>> -- https://jitsi.org
>>> _______________________________________________ mmusic mailing
>>> list [e-mail] https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>