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

"Ram Mohan R (rmohanr)" <rmohanr@cisco.com> Thu, 07 May 2015 09:19 UTC

Return-Path: <rmohanr@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 128571A005A for <rtcweb@ietfa.amsl.com>; Thu, 7 May 2015 02:19:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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_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 7SzMmi-8duzH for <rtcweb@ietfa.amsl.com>; Thu, 7 May 2015 02:19:32 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E8C1A0056 for <rtcweb@ietf.org>; Thu, 7 May 2015 02:19:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7218; q=dns/txt; s=iport; t=1430990372; x=1432199972; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fozvNs6YdA8+3JhGqmoqd5rSax/a/C82QzzsBz6E68Q=; b=lRyIdqcZKWdZo1iVlRGSEYlA85esoOX3DKKqXI6iIuv2t8c7AcKjzsiC aNw+ykDGQm3ELl39eRotuWtTfZzSuPZdyrhNG+FvfHZOThut9FGdH8vkt 04ysoHR8QR8hzd2/O0Koku4Sy2D2pLi3JDKMjk0niXzekH3x6p50D6ipc g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C1BAAeLUtV/5hdJa1cgwxUXgaDGMI9CYFMCoU3TgIcgQ04FAEBAQEBAQGBCoQgAQEBBAEBATETJwsMBAIBCBEDAQEBAQQjBQICHwYLFAkIAgQBDQWIFwMSDZRfnH8GhRiIfw2FAwEBAQEBAQEBAQEBAQEBAQEBAQEBAReBG4oegk2CBTMHBoJcgUsFkiiEFIRvgVWBYY1vhmkjgWaCEG+BRIEBAQEB
X-IronPort-AV: E=Sophos;i="5.13,384,1427760000"; d="scan'208";a="147807717"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP; 07 May 2015 09:19:31 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t479JUkT015496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 May 2015 09:19:30 GMT
Received: from xmb-aln-x05.cisco.com ([169.254.11.61]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Thu, 7 May 2015 04:19:30 -0500
From: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "Tirumaleswar Reddy (tireddy)" <tireddy@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: AQHQiKbrGbwEV1fvNkOtBVNfuaQEWQ==
Date: Thu, 07 May 2015 09:19:29 +0000
Message-ID: <D1712C03.2DDBA%rmohanr@cisco.com>
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>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D7EBB8D@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.7.141117
x-originating-ip: [173.39.64.98]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <B435C98ACACC3D4A84C27102EF64CAE1@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/BK3cig3zKARV4Pn43O4oI4Eh5u4>
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:19:34 -0000

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