Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 07 May 2015 09:10 UTC

Return-Path: <christer.holmberg@ericsson.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 A7C021A0025 for <rtcweb@ietfa.amsl.com>; Thu, 7 May 2015 02:10:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 uL6SkC4FmWO0 for <rtcweb@ietfa.amsl.com>; Thu, 7 May 2015 02:10:24 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393011A0023 for <rtcweb@ietf.org>; Thu, 7 May 2015 02:10:24 -0700 (PDT)
X-AuditID: c1b4fb25-f79b66d000001131-60-554b2bfeb778
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 15.F5.04401.EFB2B455; Thu, 7 May 2015 11:10:22 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0210.002; Thu, 7 May 2015 11:10:21 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>, "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>, Alissa Cooper <alissa@cooperw.in>, Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11
Thread-Index: AQHQg6ZCX3ABhhDJOU+APBu3+BbmbJ1nNjYAgABrhwCABulYUIABP/oAgAA7v/D///4jAIAAPj2Q
Date: Thu, 07 May 2015 09:10:21 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D7EBB8D@ESESSMB209.ericsson.se>
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>
In-Reply-To: <913383AAA69FF945B8F946018B75898A47833F10@xmb-rcd-x10.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGfG3RveftneowYmFMhbTz/xltLh25h+j xfKuHYwWa/+1s1uc2L2N0YHVY8rvjaweX568ZPLYOesuu8eSJT+ZAliiuGxSUnMyy1KL9O0S uDKervrHVHBItqLtyDf2Bsbv4l2MnBwSAiYS054vY4SwxSQu3FvP1sXIxSEkcJRRouvHbCYI ZxGjxJufb5i7GDk42AQsJLr/aYPERQS2M0p0XrjHDtLNLKAucWfxOXaQGmGBIInVZ3hBwiIC wRKbd7xigbCjJP7372QFsVkEVCRmPG8Gs3kFfCV2Nrxlhdi1glni8/YXYBdxAiVa1m5lArEZ ga77fmoNE8QucYlbT+YzQVwtILFkz3lmCFtU4uXjf6wQtqLEzrPtzBD1ehI3pk5hg7C1JZYt fM0MsVhQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBkWcUoWpxanJSbbmSsl1qUmVxcnJ+nl5da sokRGHMHt/xW3cF4+Y3jIUYBDkYlHl6F416hQqyJZcWVuYcYpTlYlMR57YwPhQgJpCeWpGan phakFsUXleakFh9iZOLglGpg5PIuLck+cK3kheUqs/9VnZNblirxfP1/z/f29U1s5zqOHXeU lZyaeeI782mbF/V3fc5Pv2d583PJh0P7D6ncDJ+633Xdy8UX94kLfkl+ktpx1bK1OJpxoeJO xsdM7LevS3Iu5DB4VfV8wt2GvgT3eKOHzLbC8568y+gOZTOe0Xk18bkX57TSBCWW4oxEQy3m ouJEAFy06IqaAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/15vY54wlaLY7dW7hTX3dvNCL-6g>
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: Thu, 07 May 2015 09:10:26 -0000

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