Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11
Alissa Cooper <alissa@cooperw.in> Fri, 08 May 2015 13:11 UTC
Return-Path: <alissa@cooperw.in>
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 5141A1A0193 for <rtcweb@ietfa.amsl.com>; Fri, 8 May 2015 06:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 ivc7QLfVMURv for <rtcweb@ietfa.amsl.com>; Fri, 8 May 2015 06:11:42 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6611D1A0242 for <rtcweb@ietf.org>; Fri, 8 May 2015 06:11:17 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 78EFE20C1E for <rtcweb@ietf.org>; Fri, 8 May 2015 09:11:16 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 08 May 2015 09:11:16 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=8J0vtO1Z68e5IulisM5VIuOll+g=; b=10hDL7 ej0N9+MPQXrVOd1ak/zW6X/ROOQBKMj9nGpp3R+6A3lyhCoiEFI1FR9C2TDwIF80 2DFHT5mAD9ISzWE41JWRyTzcz/sXvKTtzBrH4WKmfxNu0Uut8oHg3OE0DeZMFrzr XGRuBx0SzE/Vgf8FHgaYzufuMw67I7wFMAsko=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=8J0vtO1Z68e5Iul isM5VIuOll+g=; b=f1B6ojztbCJ7XyU1cj4P4QmgauGUzM6lRptF9lg++2u+9q9 nX3D/XCug22PMqOfZOPsSJ4QyyGC4ri6nxYbk1X+ih+PbnfPFNeJe/594FG8IRUh de0wJSkqGE901Zos5zoJ3TzT5QR+pW9w7wc7BzFYKvaDh/Vv80JWV2nVyyHA=
X-Sasl-enc: ZQxVRLsaPdpyKIKM6g80EuI+cJi+GGxZLFllyjAAI86K 1431090676
Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.241.190]) by mail.messagingengine.com (Postfix) with ESMTPA id 8BD9AC00017; Fri, 8 May 2015 09:11:14 -0400 (EDT)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D7EBCDD@ESESSMB209.ericsson.se>
Date: Fri, 08 May 2015 06:11:14 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D8BB2A42-3840-4C60-A7AC-503E359F8662@cooperw.in>
References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> <CABkgnnU=NeP7MzqxE1Mg+ZN8EZf=3FtayyLP1Q-z=6vaPUtAuA@mail.gmail.com> <3BE7E012-A474-4CEA-889A-B611EEFC4AEC@cooperw.in> <7594FB04B1934943A5C02806D1A2204B1D7EA1AE@ESESSMB209.ericsson.se> <D170E03C.2DAC3%rmohanr@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D7EB649@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47833F10@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1D7EBB8D@ESESSMB209.ericsson.se> <D1712C03.2DDBA%rmohanr@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D7EBCDD@ESESSMB209.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/z_gGveTD8Ms0HJMEObkiPrfhYJs>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11
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, 08 May 2015 13:11:44 -0000
Ok with me. Alissa On May 7, 2015, at 2:49 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote: > Hi, > > The text looks ok, but I think we can simplify/clarify it a little. > > For example, the usage of "flow" is a little strange, since we explicitly say that no media is sent :) > > Also, "failure" is the wrong wording in my opinion, because there is no failure. > > What about: > > An endpoint that is not sending any application data does not need to > maintain consent. However, not sending any traffic could cause NAT or > firewall mappings to expire. Furthermore, having one peer unable to send > is detrimental to many protocols. Absent better information about the > network, if an endpoint needs to ensure its NAT or firewall mappings do > not expire, it can be done using keepalive or other techniques (see > Section 10 of [RFC5245] and see [RFC6263]). > > Regards, > > Christer > > > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: 7. toukokuuta 2015 12:19 > To: Christer Holmberg; Tirumaleswar Reddy (tireddy); Alissa Cooper; Martin Thomson > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 > > Hi Christer, > > How about the below text. Does it sound better ? > > OLD: > > An endpoint that is not sending any application data does not need to > maintain consent. However, failure to send could cause any NAT or > firewall mappings for the flow to expire. Furthermore, having one > peer unable to send is detrimental to many protocols. Absent better > information about the network, an endpoint SHOULD maintain consent if > there is any possibility that a flow might be needed again. > > NEW: > > An endpoint that is not sending any application data does not need to > maintain consent. However, failure to send could cause any NAT or > firewall mappings for the flow to expire. Furthermore, having one > peer unable to send is detrimental to many protocols. Absent better > information about the network, if an endpoint needs to ensure its NAT > or firewall mappings persist which can be done using keepalive or > other techniques (see Section 10 of [RFC5245] and see [RFC6263]). > > > > Ram > > -----Original Message----- > From: Christer Holmberg <christer.holmberg@ericsson.com> > Date: Thursday, 7 May 2015 2:40 pm > To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>, Cisco Employee <rmohanr@cisco.com>, Alissa Cooper <alissa@cooperw.in>, Martin Thomson <martin.thomson@gmail.com> > Cc: "rtcweb@ietf.org" <rtcweb@ietf.org> > Subject: RE: [rtcweb] AD evaluation: > draft-ietf-rtcweb-stun-consent-freshness-11 > >> Hi, >> >>>>> Martin¹s statement says SHOULD here and does not mandate. ICE >>>>> keepalives could also be used to keep the NAT state >>>> >>>> There needs to be a good justification for a SHOULD, and consent was >>>> never intended for NAT keep-alives. >>>> >>>> Also keep in mind that, with the "virtual connection" concept, there >>>> might be a big number of ICE connections - some of which you may >>>> never use. Why send consent on those, if there is no media? >>> >>> ICE keepalives or consent is only required for candidate pairs >>> selected for media, >> >> Correct. But, you may have multiple candidate pairs "selected for >> media", but that doesn't mean you are sending media on all of them. >> Very likely you are, at any given time, only sending media on one of them. >> >>> http://tools.ietf.org/html/rfc5245#section-10 mandates sending >>> keepalives if no packet is sent on the candidate pair ICE is using for >>> a media component for Tr seconds. STUN Binding Indication or consent >>> can be used for keepalives. >> >> Correct. My issue is why there should be a "SHOULD send consent" on >> candidate pairs currently not used for sending media. In such case, >> only the NAT bindings need to be maintained, and the keep-alives take >> care of that. >> >> Regards, >> >> Christer >> >> >> >>> -----Original Message----- >>> From: Christer Holmberg <christer.holmberg@ericsson.com> >>> Date: Wednesday, 6 May 2015 12:23 pm >>> To: Alissa Cooper <alissa@cooperw.in>, Martin Thomson >>> <martin.thomson@gmail.com> >>> Cc: "rtcweb@ietf.org" <rtcweb@ietf.org> >>> Subject: Re: [rtcweb] AD evaluation: >>> draft-ietf-rtcweb-stun-consent-freshness-11 >>> >>>> Hi, >>>> >>>> I don't think you need to continue doing consent because of NAT >>>> issues, if you are sending normal STUN keep-alives. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> -----Original Message----- >>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Alissa >>>> Cooper >>>> Sent: 2. toukokuuta 2015 2:20 >>>> To: Martin Thomson >>>> Cc: rtcweb@ietf.org >>>> Subject: Re: [rtcweb] AD evaluation: >>>> draft-ietf-rtcweb-stun-consent-freshness-11 >>>> >>>> >>>> On May 1, 2015, at 9:54 AM, Martin Thomson >>> <martin.thomson@gmail.com> >>>> wrote: >>>> >>>>> On 30 April 2015 at 17:32, Alissa Cooper <alissa@cooperw.in> wrote: >>>>>> "An endpoint that is not sending any application data does not >>>>>> need >>> to >>>>>> maintain consent. However, failure to send could cause any NAT or >>>>>> firewall mappings for the flow to expire. Furthermore, having one >>>>>> peer unable to send is detrimental to many protocols." >>>>>> >>>>>> It sounds like the unstated implication here is that if you are >>>>>> such an endpoint, you should keep doing consent checks anyway to >>>>>> maintain consent. Should that be stated explicitly, or am I >>> misunderstanding? >>>>> >>>>> Can you tell that this is my text? >>>>> >>>>> Yep, the unspoken implication is that if you stop maintaining >>>>> consent, a flow is highly likely to break. I'm OK with making >>>>> that >>> explicit. >>>>> >>>>> ... . Absent better information about the network, an endpoint >>>>> SHOULD maintain consent if there is any possibility that a flow >>>>> might be needed again. >>>> >>>> WFM >>>> >>>>> >>>>> (Thanks for the suggestion on Sec7. I wasn't happy with it >>>>> before.) >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >
- [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-co… Alissa Cooper
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stu… Ram Mohan R (rmohanr)
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stu… Martin Thomson
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stu… Bernard Aboba
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stu… Martin Thomson
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stu… Alissa Cooper
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stu… Ram Mohan R (rmohanr)
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stu… Christer Holmberg
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stu… Ram Mohan R (rmohanr)
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stu… Christer Holmberg
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stu… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stu… Christer Holmberg
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stu… Ram Mohan R (rmohanr)
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stu… Christer Holmberg
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stu… Ram Mohan R (rmohanr)
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stu… Martin Thomson
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stu… Alissa Cooper
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stu… Ram Mohan R (rmohanr)
- Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stu… Ram Mohan R (rmohanr)