Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions

Martin Thomson <> Thu, 20 November 2014 07:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D62ED1A009E for <>; Wed, 19 Nov 2014 23:19:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dvUKA5Ixq1ga for <>; Wed, 19 Nov 2014 23:19:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B82F91A0099 for <>; Wed, 19 Nov 2014 23:19:21 -0800 (PST)
Received: by with SMTP id gq1so1762391obb.40 for <>; Wed, 19 Nov 2014 23:19:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2fxtnqFpH2LYEWz1er6qCExvQvZTp3N/bAhvEkLUSjw=; b=HobaEP0+j0ovSTxEW1wz9OWOs66z/EyYh8iMjZvvHj1TOp8BXM4HMVYtoO8bufxCmD 2SRd0Y/WeU0Evxy1QHC9+1uEzWE/6XXA64sN1jY94/G+rut8XCmwJsv/aaDFNB6VeTSg Avh6gayY4ub1MyR/hGgwSV+KZ2mpFqPTXbgya2txBpqb7A//OixAg6prfGt63ExZdgSg G7l8M8V7Xf3THxBi5/aL+0g5ZqfirD1hNOEuTTUKlsxasiF7Npgb6Lr2XOSyx0OGHyvY tTjAUn3NPA7JOEA9e8VmjruJoac7+NMTuRR2+qzirrb4z8Ir9ujIOmil9tHjkVyLgD0W S5fg==
MIME-Version: 1.0
X-Received: by with SMTP id fl5mr40631003obb.24.1416467961017; Wed, 19 Nov 2014 23:19:21 -0800 (PST)
Received: by with HTTP; Wed, 19 Nov 2014 23:19:20 -0800 (PST)
Received: by with HTTP; Wed, 19 Nov 2014 23:19:20 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Wed, 19 Nov 2014 23:19:20 -0800
Message-ID: <>
From: Martin Thomson <>
To: "Ram Mohan R (rmohanr)" <>
Content-Type: multipart/alternative; boundary="089e0149d172a6fa95050845253f"
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Nov 2014 07:19:24 -0000

It is really hard following these threads, but it looks like this is being

"This document defines what it takes to obtain, maintain, and lose consent
to send. Consent to send applies to a single 5-tuple. What applications
choose to do with this information is not described in this document."

Add that to the introduction perhaps. We run the risk of expanding scope

As for the question of re-acquisition of consent, I think that we should
keep it simple. For this:

"After consent is lost for any reason, the same ICE credentials MUST NOT be
used on the affected 5-tuple again. That means that a new session, or an
ICE restart at least, is needed to obtain consent to send."

Better to keep the rule simple, and we don't want to leave an option open
for a packet-drop-based attack here.

And one more thing ...

On Nov 19, 2014 6:41 PM, "Ram Mohan R (rmohanr)" <> wrote:
> >>>
> >>>There IS text saying:
> >>>
> >>>     "An endpoint that is not sending any application data does not
need to
> >>>     maintain consent.  However, the endpoint needs to ensure its NAT
> >>>     firewall mappings persist which can be done using keepalive or
> >>>     techniques (see Section 10 of [RFC5245] and see [RFC6263])."
> >>>
> >>>However, that seems to be more related to cases where I don't intend to
> >>>send application data to begin with.
> >>>
> >>>So, perhaps the text above can be modified, to clarify that keepalives
> >>>etc will still be sent if consent expires.

I think that we should consider akeep alive as application data, and
subject to to rules of consent.

The text should note that firewall and NAT bindings could be lost, instead.