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

From: [email-masked]
Date: Tue, 07 May 2013 11:29:05 -0700

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/

---

From: Emil Ivov <[email-masked]>
Date: Tue, 07 May 2013 21:32:51 +0300

Hey all,

We believe this draft addresses all comments that we've received during
the last call so far. Thanks to everyone for the reviews!

(The WGLC is still active for a few more hours so any other comments
would of course be welcome).

Cheers,
Emil

On 07.05.13, 21:29, [email-masked] wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 
https://jitsi.org

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 10 May 2013 20:53:10 +0000

I think the security section series underestimates the security vulnerabilities this introduces. 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.

---

From: Emil Ivov <[email-masked]>
Date: Sat, 11 May 2013 12:59:58 +0300

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

>> 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.
>> 
>> 
>> _______________________________________________ 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

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 30 May 2013 14:22:45 +0000

I think you need to start by putting in a reference to 

http://tools.ietf.org/html/rfc3424

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