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

From: Emil Ivov <[email-masked]>
Date: Mon, 10 Jun 2013 17:16:09 +0200

Hey Cullen,

On 30.05.13, 16:22, Cullen Jennings (fluffy) wrote:
>
> I think you need to start by putting in a reference to
>
> http://tools.ietf.org/html/rfc3424

Indeed. While the issues do not apply to hosted NAT traversal, the 
document does describe many of the reasons why people resorted to 
latching rather than using UNSAF. This is now mentioned and ref-ed in 
the introduction.

> 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)

Cheers,
Emil

> CGN is becoming increasingly common and
> will result in a large number of people having the same IP address.
> Unless you have a solutions that secures this type of environment, I
> think you should put harmful in the title and make the abstract very
> clear that the IETF does not recommend this and this document
> explains why.
>
>
>
> On May 11, 2013, at 3:59 AM, Emil Ivov <[email-masked]> wrote:
>
>> Hey Cullen,
>>
>> On 10.05.13, 23:53, Cullen Jennings (fluffy) wrote:
>>>
>>> I think the security section series underestimates the security
>>> vulnerabilities this introduces.
>>
>> If you think we've missed any specific attacks we'd be happy to add
>> them.
>>
>>> I'm very sad to see the IETF publishing this at all with anything
>>> other than "This is not the recommended way to solve this
>>> problem" and why.
>>
>> Well that's pretty much what we say:
>>
>> In no way does this document try to make a case for HNT or present
>> it as a solution that is somehow better than alternatives such as
>> ICE. The mechanisms described here, popular as they may be, are not
>> necessarily considered best practice or recommended operation.
>>
>> The security considerations section also specifically outlines
>> cases where DoS attacks can be performed even with the use of
>> SRTP:
>>
>> 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.
>>
>> The point was to show that in spite of all the threat mitigating
>> techniques users of latching are still left vulnerable to those.
>>
>> I certainly don't understand IETF processes as well as you do, but
>> it is my understanding that as an informational document the draft
>> can only do so much and that making explicit recommendations for or
>> against technologies was for Standards Track documents only. Am I
>> wrong about this?
>>
>> My recollection of the Paris and Vancouver meetings (and a quick
>> skim through the notes) is that this was also the direction chosen
>> by the WG.
>>
>> Again, if you believe that additional text would make things
>> clearer we are wide open to suggestions.
>>
>> Cheers, Emil
>>
>>
>>>
>>>
>>>
>>>
>>> On May 7, 2013, at 12:29 PM, [email-masked] wrote:
>>>
>>>>
>>>> A New Internet-Draft is available from the on-line
>>>> Internet-Drafts directories. This draft is a work item of the
>>>> Multiparty Multimedia Session Control Working Group of the
>>>> IETF.
>>>>
>>>> Title           : Latching: Hosted NAT Traversal (HNT) for
>>>> Media in Real-Time Communication Author(s)       : Emil Ivov
>>>> Hadriel Kaplan Dan Wing Filename        :
>>>> draft-ietf-mmusic-latching-01.txt Pages : 14 Date            :
>>>> 2013-05-07
>>>>
>>>> Abstract: This document describes behavior of signalling
>>>> intermediaries in Real-Time Communication (RTC) deployments,
>>>> sometimes referred to as Session Border Controllers (SBCs),
>>>> when performing Hosted NAT Traversal (HNT).  HNT is a set of
>>>> mechanisms, such as media relaying and latching, that such
>>>> intermediaries use to enable other RTC devices behind NATs to
>>>> communicate with each other.  This document is non-normative,
>>>> and is only written to explain HNT in order to provide a
>>>> reference to the IETF community, as well as an informative
>>>> description to manufacturers, and users.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching
>>>>
>>>> There's also a htmlized version available at:
>>>> http://tools.ietf.org/html/draft-ietf-mmusic-latching-01
>>>>
>>>> A diff from the previous version is available at:
>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-latching-01
>>>>
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________ mmusic mailing
>>>> list [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>> _______________________________________________ mmusic mailing
>>> list [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> -- https://jitsi.org
>
>

-- 
https://jitsi.org

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 11 Jun 2013 02:55:11 +0000

> This exact case was already described in the security considerations section:
> 

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.

---

From: Emil Ivov <[email-masked]>
Date: Tue, 11 Jun 2013 08:03:21 +0200

Hey Cullen,

On 11.06.13, 04:55, Cullen Jennings (fluffy) wrote:
>>> Next I think you need to add a specific attack where two people
>>> are both behind the same CGN.
>>
> 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

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 11 Jun 2013 06:15:26 +0000

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 ?

On Jun 11, 2013, at 3:03 PM, Emil Ivov <[email-masked]> wrote:

> _______________________________________________
> mmusic mailing list
> [email-masked]

---

From: Emil Ivov <[email-masked]>
Date: Tue, 11 Jun 2013 09:52:24 +0200

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

>>>>> Next I think you need to add a specific attack where two
>>>>> people are both behind the same CGN.
>>>>
>>> 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.
>>
>> 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
>> list [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>
>

-- 
https://jitsi.org

---

From: Ari Keränen <[email-masked]>
Date: Fri, 14 Jun 2013 19:04:20 +0300

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