IETF Logo Mail Archive

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

"Ram Mohan R (rmohanr)" <rmohanr@cisco.com> Fri, 21 November 2014 05:28 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 CBCB51AD0B2 for <rtcweb@ietfa.amsl.com>; Thu, 20 Nov 2014 21:28:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.095
X-Spam-Level:
X-Spam-Status: No, score=-15.095 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, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 oBP4zdrj80cc for <rtcweb@ietfa.amsl.com>; Thu, 20 Nov 2014 21:28:13 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F397D1A0052 for <rtcweb@ietf.org>; Thu, 20 Nov 2014 21:28:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2085; q=dns/txt; s=iport; t=1416547692; x=1417757292; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Lp0Tu5GP9NscsYzpdzWuxXiiQcLrnCIV1aR+ALeMFAI=; b=YCymUuO9PM7wisVFswbRIpQvA7ButjJIHJ9lF9rYHaZLBCzSdBFOadBD qsvhQV3ySIOn8sKCCLLKF3PPEDLeaOkZIB94O5BVcaM7kEvG4Pn9BF2KJ TtpxAxCp2G2zf7TllC69VvfLcOoETaaYKuWHdaee8Ogbi394ZlOPEL+xe Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AicFAC7NblStJA2J/2dsb2JhbABagw6BLgTTKwKBBBYBAQEBAX2EAgEBAQQ6SwQCAQgRAwECHwULIREdCAIEARKILAMSzVANhk8BAQEBAQEBAQIBAQEBAQEBARqOTYJCBoRFBZJXhTaEQIIUgTOOUoZ2gjaBRW2BSIEDAQEB
X-IronPort-AV: E=Sophos;i="5.07,428,1413244800"; d="scan'208";a="98770727"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 21 Nov 2014 05:28:12 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sAL5SBTD032135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Nov 2014 05:28:12 GMT
Received: from xmb-aln-x05.cisco.com ([169.254.11.185]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Thu, 20 Nov 2014 23:28:11 -0600
From: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Martin Thomson <martin.thomson@gmail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions
Thread-Index: AQHQBUvwJjfjOKAbZ06T7Mg5VhaLYw==
Date: Fri, 21 Nov 2014 05:28:10 +0000
Message-ID: <D094CC9C.19B79%rmohanr@cisco.com>
References: <7594FB04B1934943A5C02806D1A2204B1D4CE861@ESESSMB209.ericsson.se> <D0898477.19024%rmohanr@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D525F52@ESESSMB209.ericsson.se> <D0936AAE.19A4C%rmohanr@cisco.com> <CABkgnnU-Cxj5CUR-BQM9o-FeOCWWdOqcViWovwBDV_sdcVTi-Q@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D52C623@ESESSMB209.ericsson.se> <CABkgnnUa6_h8kcj11F42QsJh--oQoeaWpFopp_MD1TDE1Y1DrA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D52E22D@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D52E22D@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.3.140616
x-originating-ip: [173.39.64.84]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <30E151219456714F9E3F912158F71B37@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8YIkljDvOczjRkykExruU2fJT-I
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions
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, 21 Nov 2014 05:28:15 -0000


-----Original Message-----
From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Friday, 21 November 2014 7:45 am
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Cisco Employee <rmohanr@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: RE: [rtcweb] I-D Action:
draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions

>Hi,
>
>> I don't understand this concern.  You can't use the credentials (see
>>above), and you can't send anything else.  That's a terminal condition.
>
>So, we need to add text explicitly saying that the credentials can no
>longer be used, once consent has expired. That makes it clear that one
>cannot simply "wait for a while", and then start sending media again...
>
>> Though there is a real mistake in the draft here:
>>
>> OLD:
>>   An endpoint MUST NOT send paced STUN connectivity checks toward any
>>   transport address unless the receiving endpoint consents to receive
>>   data.  That is, no application data (e.g., RTP or DTLS) can be sent
>> NEW:
>>   An endpoint MUST NOT send data other than paced STUN connectivity
>>checks or responses toward any
>>   transport address unless the receiving endpoint consents to receive
>>   data.  That is, no application data (e.g., RTP or DTLS) can be sent
>
>Looks good.

+1.

Looks this text was broken in ver 08. Ver 07 has proper text.

Ram

>
>>> What about DTLS heartbeats, and other information sent on the
>>> transport layer? I ASSUME the entity will maintain those, as it still
>>> may receive media
>>
>> That is unquestionably application-layer data.
>>
>> The upshot here is that you will probably break RTP because you can't
>>generate an RR.  You can't generate SCTP acknowledgements either.
>> Fact is, virtually all protocols are bidirectional and will break if
>>one party can't send.
>
>So, adding a few words about that would be useful, to inform people.
>Because, as you say, expired consent for sending media will often cause
>trouble also for received media.
>
>Regards,
>
>Christer
>
>

v2.27.8 | Report a Bug | By Email | System Status