Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness
"Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> Fri, 22 May 2015 17:29 UTC
Return-Path: <tireddy@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873491A1BA3; Fri, 22 May 2015 10:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.911
X-Spam-Level:
X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3LTLdrsXKHT; Fri, 22 May 2015 10:28:54 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120321A874D; Fri, 22 May 2015 10:28:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8590; q=dns/txt; s=iport; t=1432315734; x=1433525334; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pTYze2wDKYbmXTHuv3CWcMKXaGNCZvsAgH7C08FUa2g=; b=IqOA/NjGUCszkdnmIVOB250YUlPyTGicnOd679EdfcMt5KcbC+pQp83P +2zBPCr1uCJkyKq/tUMm+568m33HPnjo7etX7OtQqy+mHc2/08JnYTC1w V/SivzpiKoAqB+XNrgqYEj5PyrJwKL0kEoJwSTceWKt0uKlImwOnj5ttI w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B4BAATZ19V/5NdJa1cgxBUXgaDGb8ZZgmBXYVzAhyBHTgUAQEBAQEBAYEKhCIBAQEDASMRPgcFBwQCAQgRBAEBAQICBh0DAgICHxEUAQgIAgQBDQUIiA8DCggNr3afDg2EcgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGKGYJNggcWGwcGgmIvgRYBBJMBhDWEf4MBjnyDKINZI4IHAxyBUm+BRoEBAQEB
X-IronPort-AV: E=Sophos;i="5.13,477,1427760000"; d="scan'208";a="152492928"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP; 22 May 2015 17:28:53 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t4MHSrjV001193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 May 2015 17:28:53 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.253]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Fri, 22 May 2015 12:28:52 -0500
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: Martin Thomson <martin.thomson@gmail.com>, Bernard Aboba <bernard.aboba@gmail.com>, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Thread-Topic: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness
Thread-Index: AQHQk1eS1ZbgKeHyC0Cjwx+443SghJ2HY76AgAAMcwCAARhNAP//ujjg
Date: Fri, 22 May 2015 17:28:51 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A4785AE60@xmb-rcd-x10.cisco.com>
References: <CAOW+2dsv8CVpaKoBsUvc5MGh2s3xD2J5NiXPAnFUMOhYqSmjzQ@mail.gmail.com> <CABkgnnWgpSYDjRQpk16Z0mCLietUcK1dSiNL-Y+jmFCpqan4Gg@mail.gmail.com> <CAOW+2dtDBxBBC7ToBGvP8cqYjGKUAYuR-5uL=NSjzE5iVwLRrA@mail.gmail.com> <CABkgnnUmcWUJDuems=P=vmifRGmhNvxv6=ps5O9-vmaQPYr=Ew@mail.gmail.com>
In-Reply-To: <CABkgnnUmcWUJDuems=P=vmifRGmhNvxv6=ps5O9-vmaQPYr=Ew@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.37.83]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/emSnKZwlOykVEWkqrnP9pErWdh0>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 May 2015 17:29:02 -0000
> -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Friday, May 22, 2015 10:08 PM > To: Bernard Aboba; Muthu Arul Mozhi Perumal; Tirumaleswar Reddy > (tireddy) > Cc: rtcweb@ietf.org; The IESG; Emil Ivov; Robin Raymond > Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness > > Tiru/Muthu, where the hell is the master copy of the draft? This requires a > little care and I'd like to propose several pull requests. https://github.com/Draft-Mafia/IETF-drafts/blob/master/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-13.xml -Tiru > > On 21 May 2015 at 16:54, Bernard Aboba <bernard.aboba@gmail.com> > wrote: > > Martin said: > >> 1. Adaptation of the RTO via RTT measurement > > > > [Martin] I agree that this is a concern, but we have a means of > > determining RTO, so we just need to add text that says something like: > > The initial STUN transaction produces a value for RTO on any given > candidate pair. > > That value is used in determining how long to await a STUN response, > > it is updated as new STUN responses are received. > > > > [BA] If you cite the RFC 5389 text relating to initial RTO, caching, > > estimation algorithm, etc. you can then use the calculated value to > > determine how long to await a STUN response. > > That's reasonable. I'll propose text as soon as I can lay my hands on a copy of > a draft. > > >> 2. Consistent number of requests sent without a response (Rc) before > >> transaction failure 3. Total time to transaction failure robust > >> against routing transients > > > > I don't agree that either of these is a problem. It's a design, > > certainly, but it suffers from a dire lack of determinism in running > > time, something that might be exploited to increase denial of service > > exposure time. > > > > [BA] The effective transmission rate matters in DDOS more than running > > time > > - which is why the RFC 5389 backoff algorithm makes a difference. > > Here an Rc value of 7 is not as critical as having it be a constant. > > The draft requires at most one check every 4s for a pair and only when > consent is active. ICE sends at 20ms intervals. Open loop. That matters far > more for DDOS. > > >> 1. No RTT/RTO estimation - and given that responses to a request that > >> arrive after a new request is sent are ignored, no ability to make > >> use of the information that is available. Effectively, the > >> specification sets the RTO to be a random value between 4 and 6 > >> seconds, with no relationship to network characteristics. > > > > If response i arrives after i+1, that's not going to provide any > > useful information about RTO itself (RTO jitter perhaps). > > > > [BA] That is true if the transaction ID doesn't change (e.g. RFC > > 5389). But if the transaction ID changes, then you can use the > > arrival time of response i to get a better RTO estimate, even if i+1 > > arrives first. This is valuable since it is most likely to happen when > > the originally calculated RTO value is too low, making a false > > retransmission timeout more likely. RFC 5682 describes some of the > concerns relating to F-RTO. > > Sure, but I don't think that we *need* that level of sophistication. > There's nothing stopping an implementation from doing smarter things, but > we are only looking to ensure that consent doesn't persist indefinitely. > > > [BA] Varying Rc will produce a false retransmission probability that > > will vary by network conditions, particularly if Rc can be small (e.g. > > only a few retransmissions prior to declaring consent revocation). > > See above regarding unnecessary sophistication. > > >> 3. Unclear timer behavior. Does an implementation continue to send > >> requests until 30 seconds has elapsed, or does it stop before then so > >> as to allow for a response to the last request to arrive? One could > >> interpret the above to imply that requests continue to be sent for up > >> to 30 seconds, but the last request is considered failed as soon as > >> the 30 second timer expires. > > > > How can we make this clearer? > > > > [BA] If consent expires at 30 seconds + RTO (or better, at last > > request sending time plus RTO) then that would clarify things. > > I can see where you are coming from here. I think that we need a different fix, > if anything. > > 1. STUN requests are sent at a regular interval (with variance). > 2. Each STUN request is tracked for RTO+delta. > 3. If a successful STUN response has been received in the last 30 seconds, you > have consent. > > That is a subtle change, but it would allow for connections with an RTO > greater than 30 seconds. The only actual problem I can detect with the > current formulation. > > > I like that. Note that "excessive traffic" was intended to be in > > time, not volume. > > > > [BA] Why would time matter if consent packets aren't being sent (e.g. > > backoff)? > > Let me rephrase. The mechanism in this draft prevents packets from being > sent to an unwilling recipient. It does that by limiting the > *time* that this can happen. It does nothing about the *volume*, either in > number of packets or number of bytes. I agree that "excessive" implies the > latter (and hence think that your proposed text in this regard was good.) > > > That's easy, let's just say that this process applies *after* consent > > has been acquired. maybe we could move this up to Section 4: > > > > [BA] The question is when consent is acquired. I'd assume that this > > begins when media starts being sent - which according to RFC 5245 can > > occur after a successful connectivity check response. So ICE isn't necessarily > complete. > > Right. We can clarify that too. If only I had a copy of the damned draft, I'd > propose some changes. > > > ... is needed to obtain consent to send *on that candidate pair*. > > > > [BA] That part makes sense - but if there is another valid pair, it > > should be possible to start sending media on that pair without having > > to do an ICE restart. That is allowed under RFC 5245. > > Correct. We can add that clarification too.
- [rtcweb] Review of draft-ietf-rtcweb-stun-consent… Ted Hardie
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Ram Mohan R (rmohanr)
- [rtcweb] Review of draft-ietf-rtcweb-stun-consent… Bernard Aboba
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Emil Ivov
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Bernard Aboba
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Martin Thomson
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Bernard Aboba
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Christer Holmberg
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Bernard Aboba
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Christer Holmberg
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Martin Thomson
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Bernard Aboba
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Martin Thomson
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Emil Ivov
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Martin Thomson
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Martin Thomson
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Bernard Aboba
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Martin Thomson