From behave-bounces@ietf.org Tue Apr 1 09:26:56 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51DE328C313; Tue, 1 Apr 2008 09:26:56 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFCFC3A6E63 for ; Tue, 1 Apr 2008 09:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.783, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi5XTd5-4DKG for ; Tue, 1 Apr 2008 09:26:55 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D8D453A68D6 for ; Tue, 1 Apr 2008 09:26:54 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 1 Apr 2008 12:26:26 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 1 Apr 2008 12:26:26 -0400 From: Hadriel Kaplan To: Eric Rescorla Date: Tue, 1 Apr 2008 12:26:26 -0400 Thread-Topic: [BEHAVE] TURN: Proposed conf call Thread-Index: AciUDNMFjfZo6U82QiWU0o3CQulBOgAAoR1w Message-ID: References: <9567300E-395B-4EDF-BD70-B35907F824EB@magma.ca> <200804011639.10034.remi.denis-courmont@nokia.com> <20080401152908.46A1D5081A@romeo.rtfm.com> In-Reply-To: <20080401152908.46A1D5081A@romeo.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] TURN: Proposed conf call X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: Tuesday, April 01, 2008 11:29 AM > To: Hadriel Kaplan > Cc: R=E9mi Denis-Courmont; behave@ietf.org > Subject: Re: [BEHAVE] TURN: Proposed conf call > > At Tue, 1 Apr 2008 10:48:24 -0400, > Hadriel Kaplan wrote: > > > > > > > > > -----Original Message----- > > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf > > > Of R=E9mi Denis-Courmont > > > > > > I believe, TWIST would be is very complicated to implement without > special > > > privileges. > > > > Actually, I think "special privileges" (if by that you mean > > root/administrative level access) are actually appropriate to > > require, to make a PC into a TURN/TWIST relay or client, imho. > > Why would it make sense to require admin access to be a *client*? Because a client as currently defined in TURN and TURN-tcp can use TURN to = create a long-lived, publicly reachable TURN relay listen port for server-t= ype services to itself. Although there is some wording in TURN security se= ction saying it cannot be run as such, I don't see any such restriction in = the protocol itself - for example the permissions section as defined does n= ot prevent a willing client app and/or TURN server from doing so. (though I= could be wrong) And because I fear the perception this thing will have is of being just ano= ther "p2p" type thing that corporate IT types will freak out over and set t= heir firewalls to block. So I'm thinking letting them have control over th= eir PCs and uses of it will possibly allay their fears. (although I recogni= ze that may be a hopeless cause for some, and that current TURN properties = may be sufficiently controllable for others) I am relating the concept of "special privileges" to mean those only availa= ble to the owner of the host system, vs. a user of the system who does not = own it. But maybe my semantic interpretation is wrong? -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 1 09:41:21 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C36928C1AA; Tue, 1 Apr 2008 09:41:21 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BB3E3A687B for ; Tue, 1 Apr 2008 09:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFjHlWTLAv-G for ; Tue, 1 Apr 2008 09:41:19 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 356EC3A68BC for ; Tue, 1 Apr 2008 09:41:19 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id CCBD150850; Tue, 1 Apr 2008 09:43:04 -0700 (PDT) Date: Tue, 01 Apr 2008 09:43:04 -0700 From: Eric Rescorla To: Hadriel Kaplan In-Reply-To: References: <9567300E-395B-4EDF-BD70-B35907F824EB@magma.ca> <200804011639.10034.remi.denis-courmont@nokia.com> <20080401152908.46A1D5081A@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080401164304.CCBD150850@romeo.rtfm.com> Cc: "behave@ietf.org" , =?ISO-8859-1?Q?R=E9mi?=@core3.amsl.com Subject: Re: [BEHAVE] TURN: Proposed conf call X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Tue, 1 Apr 2008 12:26:26 -0400, Hadriel Kaplan wrote: > = > = > = > > -----Original Message----- > > From: Eric Rescorla [mailto:ekr@networkresonance.com] > > Sent: Tuesday, April 01, 2008 11:29 AM > > To: Hadriel Kaplan > > Cc: R=E9mi Denis-Courmont; behave@ietf.org > > Subject: Re: [BEHAVE] TURN: Proposed conf call > > > > At Tue, 1 Apr 2008 10:48:24 -0400, > > Hadriel Kaplan wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf > > > > Of R=E9mi Denis-Courmont > > > > > > > > I believe, TWIST would be is very complicated to implement without > > special > > > > privileges. > > > > > > Actually, I think "special privileges" (if by that you mean > > > root/administrative level access) are actually appropriate to > > > require, to make a PC into a TURN/TWIST relay or client, imho. > > > > Why would it make sense to require admin access to be a *client*? > = > Because a client as currently defined in TURN and TURN-tcp can use > TURN to create a long-lived, publicly reachable TURN relay listen > port for server-type services to itself. Although there is some > wording in TURN security section saying it cannot be run as such, I > don't see any such restriction in the protocol itself - for example > the permissions section as defined does not prevent a willing client > app and/or TURN server from doing so. (though I could be wrong) I'm not sure what you mean by "in the protocol"? It's explicitly forbidden by the permission mechanism. Obviously, the server could be noncompliant, but how is this a TURN issue? > I am relating the concept of "special privileges" to mean those only > available to the owner of the host system, vs. a user of the system > who does not own it. But maybe my semantic interpretation is wrong? As far as I know, the way that nearly all desktop machines are configured that person who uses the machine has or can get admin access. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 1 12:16:59 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C60128C208; Tue, 1 Apr 2008 12:16:59 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71FA428C14D for ; Tue, 1 Apr 2008 12:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ITsUTyvsxvv for ; Tue, 1 Apr 2008 12:16:53 -0700 (PDT) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.186]) by core3.amsl.com (Postfix) with ESMTP id 7B7DF28C598 for ; Tue, 1 Apr 2008 12:15:14 -0700 (PDT) Received: by gv-out-0910.google.com with SMTP id i36so374892gve.15 for ; Tue, 01 Apr 2008 12:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=ApEScxdEsEhcjkwlFVfQ5dxHnkqOFkTrVE9HTxg0svY=; b=RkA1SGLu2kF+Aa+ofT3OnXllSnu1ZVNLeUZMcxD1Pfu/R827esicFqUsjB/7nqzqymojG51Hnd8whUfQUazHm3O1y4622MLjCPUaXwyffIpA7NS5IPg3aelQxKLigme8Ls9FGzX8R+MyymJi27f6DVR4Wp8mSZ6qqzkz6ghxD8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=CN8KRD8YoYcEX9MDKWSqpwZvl1TS37eZz7TvvG4Op0SjSfz7R2uyF9Edz1ZIIDQvGIz3lwYW+E8V1+ImqadWEZ96cEjyUKhoi2p5Th++WODOZy2ESmmaEKAuaU3SMJm1K/6YQcQqiOuXqYVsBroaZ6j8T76GSE6JCRarJxQTLTY= Received: by 10.142.217.17 with SMTP id p17mr5224170wfg.139.1207077311003; Tue, 01 Apr 2008 12:15:11 -0700 (PDT) Received: by 10.142.14.9 with HTTP; Tue, 1 Apr 2008 12:15:10 -0700 (PDT) Message-ID: Date: Tue, 1 Apr 2008 12:15:10 -0700 From: "Derek MacDonald" To: "Eric Rescorla" In-Reply-To: <20080401164304.CCBD150850@romeo.rtfm.com> MIME-Version: 1.0 References: <9567300E-395B-4EDF-BD70-B35907F824EB@magma.ca> <200804011639.10034.remi.denis-courmont@nokia.com> <20080401152908.46A1D5081A@romeo.rtfm.com> <20080401164304.CCBD150850@romeo.rtfm.com> X-Google-Sender-Auth: e7ec2ce28b3db3ae Cc: "behave@ietf.org" Subject: Re: [BEHAVE] TURN: Proposed conf call X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0122448326==" Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org --===============0122448326== Content-Type: multipart/alternative; boundary="----=_Part_42455_31217742.1207077311008" ------=_Part_42455_31217742.1207077311008 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 2 Points: Special Privileges There are many scenarious where getting administrative access on the client is impossible. One example is a client on a USB stick that a user is runnin= g at an internet cafe or other public computer. Another common scenario is corporate computing environments where getting admin access requires sacrificing a goat. Running a "Server" on the TURN server This is forbidden by TURN even though the operation could be accomplished using the protocol. I don't see how this is too different from running a relay server on 443. A non-compliant implementation can't really be considered a core TURN issue. -Derek On Tue, Apr 1, 2008 at 9:43 AM, Eric Rescorla wrote: > At Tue, 1 Apr 2008 12:26:26 -0400, > Hadriel Kaplan wrote: > > > > > > > > > -----Original Message----- > > > From: Eric Rescorla [mailto:ekr@networkresonance.com] > > > Sent: Tuesday, April 01, 2008 11:29 AM > > > To: Hadriel Kaplan > > > Cc: R=E9mi Denis-Courmont; behave@ietf.org > > > Subject: Re: [BEHAVE] TURN: Proposed conf call > > > > > > At Tue, 1 Apr 2008 10:48:24 -0400, > > > Hadriel Kaplan wrote: > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > > Behalf > > > > > Of R=E9mi Denis-Courmont > > > > > > > > > > I believe, TWIST would be is very complicated to implement withou= t > > > special > > > > > privileges. > > > > > > > > Actually, I think "special privileges" (if by that you mean > > > > root/administrative level access) are actually appropriate to > > > > require, to make a PC into a TURN/TWIST relay or client, imho. > > > > > > Why would it make sense to require admin access to be a *client*? > > > > Because a client as currently defined in TURN and TURN-tcp can use > > TURN to create a long-lived, publicly reachable TURN relay listen > > port for server-type services to itself. Although there is some > > wording in TURN security section saying it cannot be run as such, I > > don't see any such restriction in the protocol itself - for example > > the permissions section as defined does not prevent a willing client > > app and/or TURN server from doing so. (though I could be wrong) > > I'm not sure what you mean by "in the protocol"? It's explicitly > forbidden by the permission mechanism. Obviously, the server could > be noncompliant, but how is this a TURN issue? > > > > I am relating the concept of "special privileges" to mean those only > > available to the owner of the host system, vs. a user of the system > > who does not own it. But maybe my semantic interpretation is wrong? > > As far as I know, the way that nearly all desktop machines are configured > that person who uses the machine has or can get admin access. > > -Ekr > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > ------=_Part_42455_31217742.1207077311008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 2 Points:

Special Privileges

There are many scenarious where = getting administrative access on the client is impossible. One example is a= client on a USB stick that a user is running at an internet cafe or other = public computer.  Another common scenario is corporate computing envir= onments where getting admin access requires sacrificing a goat. 

Running a "Server" on the TURN server

This is forbidde= n by TURN even though the operation could be accomplished using the protoco= l.  I don't see how this is too different from running a relay ser= ver on 443. A non-compliant implementation can't really be considered a= core TURN issue.

-Derek

On Tue, Apr 1, 2008 at 9:43 AM= , Eric Rescorla <ekr@networkresonance.com> wrote:
At Tue, 1 Apr 2008 12:26:26 -0400,
Hadriel Kaplan wrote:
>
>
>
> > -----Original Message-----
> > From: Eric Rescorla [mailto:ekr@networkresonance.com]
> > Sent: Tuesday, April 01, 2008 11:29 AM
> > To: Hadriel Kaplan
> > Cc: R=E9mi Denis-Courmont; behave@ietf.org
> > Subject: Re: [BEHAVE] TURN: Proposed conf call
> >
> > At Tue, 1 Apr 2008 10:48:24 -0400,
> > Hadriel Kaplan wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> > Behalf
> > > > Of R=E9mi Denis-Courmont
> > > >
> > > > I believe, TWIST would be is very complicated to implem= ent without
> > special
> > > > privileges.
> > >
> > > Actually, I think "special privileges" (if by that= you mean
> > > root/administrative level access) are actually appropriate t= o
> > > require, to make a PC into a TURN/TWIST relay or client, imh= o.
> >
> > Why would it make sense to require admin access to be a *client*?=
>
> Because a client as currently defined in TURN and TURN-tcp can use
> TURN to create a long-lived, publicly reachable TURN relay listen
> port for server-type services to itself.  Although there is some<= br> > wording in TURN security section saying it cannot be run as such, I > don't see any such restriction in the protocol itself - for exampl= e
> the permissions section as defined does not prevent a willing client > app and/or TURN server from doing so. (though I could be wrong)

I'm not sure what you mean by "in the protocol"? = It's explicitly
forbidden by the permission mechanism. Obviously, the server could
be noncompliant, but how is this a TURN issue?


> I am relating the concept of "special privileges" to mean th= ose only
> available to the owner of the host system, vs. a user of the system > who does not own it.  But maybe my semantic interpretation is wro= ng?

As far as I know, the way that nearly all desktop machines are config= ured
that person who uses the machine has or can get admin access.

-Ekr

_______________________________________________
Behave mailing list
Behave@ietf.org = https://www.ietf.org/mailman/listinfo/behave

------=_Part_42455_31217742.1207077311008-- --===============0122448326== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave --===============0122448326==-- From behave-bounces@ietf.org Tue Apr 1 13:07:44 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8673128C40F; Tue, 1 Apr 2008 13:07:43 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ADCF3A6EFF for ; Tue, 1 Apr 2008 13:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKLE8l4jMHUh for ; Tue, 1 Apr 2008 13:07:36 -0700 (PDT) Received: from mail-07.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id D6A8128C591 for ; Tue, 1 Apr 2008 13:07:28 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JgmlP-00040r-1N for behave@ietf.org; Tue, 01 Apr 2008 16:07:23 -0400 Message-Id: From: Philip Matthews To: Behave WG Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 1 Apr 2008 16:07:26 -0400 X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Subject: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I have gotten the feedback that some people are unclear on the goals for the proposed conf call on TURN encapsulations. So let me try to clarify what I hope to achieve. I have two goals: 1) TURN-UDP currently allows TCP or TLS over TCP connections between the client and the server. That is, the user data flows over TCP to the server, and then over UDP to the peer. However, the justification for these two transports in the document is weak, and it has been recently suggested that this can be used to violate firewall policy. I would like to talk about this and agree on good reasons why these transports are needed, or agree to remove them. 2) In my opinion, the TWIST proposal is essentially an alternative encapsulation proposal for TURN. In my personal opinion, the working group should not pursue both the existing TURN proposal and TWIST at the same time. So I would like to discuss TWIST vs TURN and see if we can select one of these as the encapsulation that we will pursue in the short term. (Note that the WG may disagree with me, and elect to pursue both of these at the same time, but I feel we need to consciously make this decision). Another motivation to have this call is that discussion of these topics on the mailing list was rather thin last week. I am hoping that a conference call with provide better discussion. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 1 13:08:29 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473323A6CFC; Tue, 1 Apr 2008 13:08:29 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F6D3A6CFC for ; Tue, 1 Apr 2008 13:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.839 X-Spam-Level: X-Spam-Status: No, score=-1.839 tagged_above=-999 required=5 tests=[AWL=0.760, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJJuUl69+9qL for ; Tue, 1 Apr 2008 13:08:27 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7528C3A68DC for ; Tue, 1 Apr 2008 13:08:27 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 1 Apr 2008 16:08:00 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 1 Apr 2008 16:08:00 -0400 From: Hadriel Kaplan To: Eric Rescorla Date: Tue, 1 Apr 2008 16:07:59 -0400 Thread-Topic: [BEHAVE] TURN: Proposed conf call Thread-Index: AciUFyfK/ZV17Md/TcCB03JI7RcdKAAFVESA Message-ID: References: <9567300E-395B-4EDF-BD70-B35907F824EB@magma.ca> <200804011639.10034.remi.denis-courmont@nokia.com> <20080401152908.46A1D5081A@romeo.rtfm.com> <20080401164304.CCBD150850@romeo.rtfm.com> In-Reply-To: <20080401164304.CCBD150850@romeo.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] TURN: Proposed conf call X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > > Hadriel Kaplan wrote: > > > > Because a client as currently defined in TURN and TURN-tcp can use > > TURN to create a long-lived, publicly reachable TURN relay listen > > port for server-type services to itself. Although there is some > > wording in TURN security section saying it cannot be run as such, I > > don't see any such restriction in the protocol itself - for example > > the permissions section as defined does not prevent a willing client > > app and/or TURN server from doing so. (though I could be wrong) > > I'm not sure what you mean by "in the protocol"? It's explicitly > forbidden by the permission mechanism. Obviously, the server could > be noncompliant, but how is this a TURN issue? I meant afaict the permission mechanism didn't stop a normal TURN client from allocating a relay address and a normal TURN server from sending it a DATA indication of receiving something for that relay address, if a permission was not in effect. But I think I was wrong. After reading it again carefully, I think what it's saying is a UDP permission is only created when a TURN client sends something to that peer first, and a TCP listen request must have a peer address for a permission, and TURN server silently discards any inbound messages on its relay side not matching a permission? If so, then it's good. > > I am relating the concept of "special privileges" to mean those only > > available to the owner of the host system, vs. a user of the system > > who does not own it. But maybe my semantic interpretation is wrong? > > As far as I know, the way that nearly all desktop machines are configured > that person who uses the machine has or can get admin access. OK then why are we worried about a mechanism needing "special privileges" to work? (ie, why is it bad if one needs to be root/admin?) -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 1 13:42:14 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF64128C568; Tue, 1 Apr 2008 13:42:14 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA51328C4CB for ; Tue, 1 Apr 2008 13:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGjfwH16JpGi for ; Tue, 1 Apr 2008 13:42:13 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id D419F28C571 for ; Tue, 1 Apr 2008 13:40:38 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 08AA75081A; Tue, 1 Apr 2008 13:42:25 -0700 (PDT) Date: Tue, 01 Apr 2008 13:42:24 -0700 From: Eric Rescorla To: Hadriel Kaplan In-Reply-To: References: <9567300E-395B-4EDF-BD70-B35907F824EB@magma.ca> <200804011639.10034.remi.denis-courmont@nokia.com> <20080401152908.46A1D5081A@romeo.rtfm.com> <20080401164304.CCBD150850@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080401204225.08AA75081A@romeo.rtfm.com> Cc: "behave@ietf.org" , =?ISO-8859-1?Q?R=E9mi?=@core3.amsl.com Subject: Re: [BEHAVE] TURN: Proposed conf call X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Tue, 1 Apr 2008 16:07:59 -0400, Hadriel Kaplan wrote: > > As far as I know, the way that nearly all desktop machines are configured > > that person who uses the machine has or can get admin access. > > OK then why are we worried about a mechanism needing "special > privileges" to work? (ie, why is it bad if one needs to be > root/admin?) Just because something is not an effective security barrier does not mean that it's not a PITA. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 1 15:45:27 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B838F3A6A26; Tue, 1 Apr 2008 15:45:27 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7491B3A6A9D for ; Tue, 1 Apr 2008 15:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.737 X-Spam-Level: X-Spam-Status: No, score=-0.737 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZkQ+4akoLsq for ; Tue, 1 Apr 2008 15:45:25 -0700 (PDT) Received: from s200aog10.obsmtp.com (s200aog10.obsmtp.com [207.126.144.124]) by core3.amsl.com (Postfix) with SMTP id AD8CF3A6B3A for ; Tue, 1 Apr 2008 15:45:09 -0700 (PDT) Received: from source ([64.233.184.226]) by eu1sys200aob010.postini.com ([207.126.147.11]) with SMTP; Tue, 01 Apr 2008 22:45:08 UTC Received: by wr-out-0506.google.com with SMTP id c55so1597105wra.0 for ; Tue, 01 Apr 2008 15:45:07 -0700 (PDT) Received: by 10.141.172.6 with SMTP id z6mr4787864rvo.54.1207089907121; Tue, 01 Apr 2008 15:45:07 -0700 (PDT) Received: by 10.141.186.2 with HTTP; Tue, 1 Apr 2008 15:45:07 -0700 (PDT) Message-ID: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> Date: Tue, 1 Apr 2008 23:45:07 +0100 From: "Benny Prijono" To: "Philip Matthews" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: X-Google-Sender-Auth: 477af2984bcf7691 Cc: Behave WG Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Tue, Apr 1, 2008 at 9:07 PM, Philip Matthews wrote: > I have gotten the feedback that some people are unclear on the goals > for the proposed conf call on TURN encapsulations. So let me try to > clarify what I hope to achieve. > > I have two goals: > > 1) TURN-UDP currently allows TCP or TLS over TCP connections between > the client and the server. That is, the user data flows over TCP to > the server, and then over UDP to the peer. However, the justification > for these two transports in the document is weak, and it has been > recently suggested that this can be used to violate firewall policy. > I would like to talk about this and agree on good reasons why these > transports are needed, or agree to remove them. As implementer working on client side, my holy grail is to have a client that will "just work", and the TCP/TLS connection helps me a lot here as I don't have to implement more complex protocol like ICE-TCP. Not being conscious with policy matters, I'm still puzzled on why are we not allowing this. I mean, if I run my RTP over TCP over TURN (with UDP peers), how is this any different than RTP over TCP, or RTP over ICE-TCP, from the policy point of view? So I think probably what we're looking is just the appropriate and softer wording on the issue rather than dropping the (nice) feature altogether. Something that doesn't say "helloo we are breaking firewall policies here". > 2) In my opinion, the TWIST proposal is essentially an alternative > encapsulation proposal for TURN. In my personal opinion, the working > group should not pursue both the existing TURN proposal and TWIST at > the same time. So I would like to discuss TWIST vs TURN and see if we > can select one of these as the encapsulation that we will pursue in > the short term. (Note that the WG may disagree with me, and elect to > pursue both of these at the same time, but I feel we need to > consciously make this decision). In own my personal opinion, let TWIST be TWIST and TURN be TURN. Maybe TURN is not good enough for everyone, maybe it may not be able to run on certain hardware, I know it would not run on my wrist watch, but that's good enough for me. And I think it's good enough for most people who want a working solution for VoIP vs symmetric NATs. And we need this solution ASAP. As implementor, I've been waiting for STUN/TURN/ICE trio to be published since quite long time. Almost exactly a year ago I finished my implementation and I wrote in my blog [1] how I thought we were finally getting somewhere with STUN/ICE and that TURN was still nowhere from stable. With what you're proposing, heck look where we're at now. :) Maybe nobody will care, but I will say here anyway that for implementors like me it's been painful to keep up with the changes in these protocols. I just re-wrote my software from scratch for TURN-07, re-did interop tests (for the N-th time), and you're saying we'll have to do these all over again with TURN-08 (and maybe every subsequent TURN releases)? I wonder if implementors will still have the energy to carry on with these. [1] http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source-ice-stun-and-turn/ > Another motivation to have this call is that discussion of these > topics on the mailing list was rather thin last week. I am hoping that > a conference call with provide better discussion. The way I see it, the lack of discussions indicate the lack of interest to take on board the issues, and perhaps the lack of strong arguments on to why we're changing the hard-fought TURN-07. Just my 0.02p. Cheers Benny > - Philip > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 1 21:08:55 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84E433A6D37; Tue, 1 Apr 2008 21:08:55 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8023A6D37 for ; Tue, 1 Apr 2008 21:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=0.678, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OihjLE8m9bBx for ; Tue, 1 Apr 2008 21:08:53 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C70D53A68F2 for ; Tue, 1 Apr 2008 21:08:52 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 2 Apr 2008 00:08:26 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 2 Apr 2008 00:08:26 -0400 From: Hadriel Kaplan To: Benny Prijono , Philip Matthews Date: Wed, 2 Apr 2008 00:08:25 -0400 Thread-Topic: [BEHAVE] Goals for the proposed conf call on TURN encapsulations Thread-Index: AciUSgd7qZZxC6iBQfeHX96tPzFeygAI9OhQ Message-ID: References: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> In-Reply-To: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Behave WG Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi Benny, Comments inline... > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Benny Prijono > > As implementer working on client side, my holy grail is to have a > client that will "just work", and the TCP/TLS connection helps me a > lot here as I don't have to implement more complex protocol like > ICE-TCP. I am not sure what you mean by not having to do ICE-TCP - you mean not doing RFC4571 framing? Or you mean not using ICE connectivity checks and SIP/SDP pieces? In other words you mean you plan to just use the TURN relay addresses, period? > Not being conscious with policy matters, I'm still puzzled on > why are we not allowing this. I mean, if I run my RTP over TCP over > TURN (with UDP peers), how is this any different than RTP over TCP, or > RTP over ICE-TCP, from the policy point of view? I'm no expert on that either - I personally only keep up with the network provider side of life. From what I'm told by folks in my company who do deal with enterprises, though, firewall policies are not a fixed well-defined rule-set, and vary for a bunch of reasons. Regardless, there is a "difference" between running RTP/TURN/TCP and RTP/TCP. For the former, it allows multiple RTP sessions (like audio+video) to run over a single TCP connection, or for example both RTP and RTCP over the single TURN-TCP connection, or MSRP file transfer and RTP over the same TURN-TCP connection, or Bitorrent and MP3 streams over the same connection, ad infinitum. It is going down a slippery-slope of firewall avoidance, such that the natural conclusion is not just to use TURN, but to use it on port 80 or 443. That *will* "just work" for you. It is what some p2p apps resort to, to get their apps to work. It is also something the ietf has avoided, afaik. Obviously there is some middle-ground. I'm just not sure what it is personally. RTP/TCP (RFC4571) is a single TCP connection for a single m-line stream, including one for RTP and one for RTCP. Furthermore, RFC4571 does not define a general application use-case - it is for RTP/RTCP and RTP/RTCP only, signaled in SDP. TURN is not media specific, nor SIP specific, nor anything specific. And given the interest lately to use TURN for any protocol, that raises the stakes. There are though issues that have nothing to do with firewall policies. Worse than UDP, TCP as a transport presents a number of issues with multiplexing different application streams in the same connection (e.g., HOL blocking, congestion avoidance backoff, flow shaping or RED in routers). -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 1 21:17:10 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA753A6D07; Tue, 1 Apr 2008 21:17:10 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C25E3A6E44 for ; Tue, 1 Apr 2008 21:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJBBZYiasG9X for ; Tue, 1 Apr 2008 21:17:03 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7DD783A6BAA for ; Tue, 1 Apr 2008 21:17:03 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 2 Apr 2008 00:16:37 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 2 Apr 2008 00:16:37 -0400 From: Hadriel Kaplan To: Benny Prijono , Philip Matthews Date: Wed, 2 Apr 2008 00:16:24 -0400 Thread-Topic: [BEHAVE] Goals for the proposed conf call on TURN encapsulations Thread-Index: AciUSgd7qZZxC6iBQfeHX96tPzFeygALGz7g Message-ID: References: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> In-Reply-To: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Behave WG Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi Benny, I think Philip was looking for email responses like yours, to get a sense of what people are thinking, so thanks for that! Other comment inline... > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Benny Prijono > > In own my personal opinion, let TWIST be TWIST and TURN be TURN. Maybe > TURN is not good enough for everyone, maybe it may not be able to run > on certain hardware, I know it would not run on my wrist watch, but > that's good enough for me. And I think it's good enough for most > people who want a working solution for VoIP vs symmetric NATs. And we > need this solution ASAP. Yes, that was what I proposed as well in an earlier email. I did not mean to submit TWIST as a replacement for TURN, or to cause chaos. It's like a Venn-diagram I think, of overlapping use-cases but not complete overlap of either. Let the market(s) decide what they will. I do, though, think TURN itself should be cleaned up, or at least consensus reached, on multiplexing and other issues - and here I'm talking about TURN-TCP, not TURN-UDP. -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 1 21:42:27 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A20D3A6B1B; Tue, 1 Apr 2008 21:42:27 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B75428C182 for ; Tue, 1 Apr 2008 21:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.38 X-Spam-Level: X-Spam-Status: No, score=-4.38 tagged_above=-999 required=5 tests=[AWL=1.920, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V84D8JYCLcy0 for ; Tue, 1 Apr 2008 21:42:25 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id DB4BE3A6B1B for ; Tue, 1 Apr 2008 21:42:24 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m324gJCd003201; Wed, 2 Apr 2008 07:42:21 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 07:42:21 +0300 Received: from esdhcp04036.research.nokia.com ([172.21.40.36]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 07:42:20 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia Devices R&D To: behave@ietf.org Date: Wed, 2 Apr 2008 07:42:52 +0300 User-Agent: KMail/1.9.9 References: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> In-Reply-To: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804020742.52873.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 02 Apr 2008 04:42:20.0913 (UTC) FILETIME=[F009EE10:01C8947B] X-Nokia-AV: Clean Cc: Philip Matthews Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Wednesday 02 April 2008 01:45:07 ext Benny Prijono, vous avez =E9crit=A0: > As implementer working on client side, my holy grail is to have a > client that will "just work", and the TCP/TLS connection helps me a > lot here as I don't have to implement more complex protocol like > ICE-TCP. I know TCP could help in some cases: braindead UDP support in the NAT, = braindead firewall configuration that blocks UDP but lets outgoing TCP. I = wonder if TLS buys you anything unless the TURN server runs on port 443 - = which would clearly be a firewall. > Not being conscious with policy matters, I'm still puzzled on = > why are we not allowing this. I mean, if I run my RTP over TCP over > TURN (with UDP peers), how is this any different than RTP over TCP, or > RTP over ICE-TCP, from the policy point of view? As far as I know, we currently DO allow this. The two main objections are it being a way to violate the firewall policy, = and = it being difficult or impossible to implement in hardware. I think the firewall objection is bogus - UDP-to-UDP TURN can be used to = work-around some loose firewall policies just as well. I would argue that's= a = bug in the firewall policy, not in TURN, if it works that way. A third objection, would be head-of-line blocking. However, I believe this = is = a non issue for TCP-to-UDP relaying. The relay can just drop incoming UDP = packets from peers if the TCP session to the client is congested. (...) > In own my personal opinion, let TWIST be TWIST and TURN be TURN. Maybe > TURN is not good enough for everyone, maybe it may not be able to run > on certain hardware, I know it would not run on my wrist watch, but > that's good enough for me. And I think it's good enough for most > people who want a working solution for VoIP vs symmetric NATs. And we > need this solution ASAP. > As implementor, I've been waiting for STUN/TURN/ICE trio to be > published since quite long time. Almost exactly a year ago I finished > my implementation and I wrote in my blog [1] how I thought we were > finally getting somewhere with STUN/ICE and that TURN was still > nowhere from stable. With what you're proposing, heck look where we're > at now. :) As implementor, I have been holding back on implementing TURN, because it's = been obvious, for the past 30+ months years I've been following BEHAVE it's = not ready to be implemented. Note however, that the current TURN spec is just plain broken when it comes= to = TCP, especially, TCP-to-TCP, so it's going to have to change anyhow. -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 1 22:51:38 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1EB3A6A0E; Tue, 1 Apr 2008 22:51:38 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37B783A6A99 for ; Tue, 1 Apr 2008 22:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=3.978, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgx3pfxGTv8k for ; Tue, 1 Apr 2008 22:51:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 29B8F3A69E2 for ; Tue, 1 Apr 2008 22:51:36 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2008 22:51:36 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m325pY9K031048; Tue, 1 Apr 2008 22:51:34 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.13.8/8.13.8) with SMTP id m325pYrY003214; Wed, 2 Apr 2008 05:51:34 GMT From: Cullen Jennings To: Philip Matthews In-Reply-To: <724EB65E-E362-4789-BE5B-10B1C4A1A00F@magma.ca> Impp: xmpp:cullenfluffyjennings@jabber.org References: <5AE36F39-B800-45FD-A4CF-261EEE6BD191@cisco.com> <6CA00DCC-A48A-47DA-8CD3-9BB47C891068@magma.ca> <38F521F6-E706-40F5-B1C7-08A2CCAC7EA0@cisco.com> <9B9EE332-F142-4A2A-9985-D771D1A276CB@magma.ca> <1879720d0803250458t3389ed38j8db079c9b08b7e64@mail.gmail.com> <724EB65E-E362-4789-BE5B-10B1C4A1A00F@magma.ca> Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 1 Apr 2008 22:51:16 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1337; t=1207115494; x=1207979494; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=3A=20Are=20unauthentica ted=20indications=20and=20ChannelData=20msgs=20a=20problem? |Sender:=20; bh=3QOX8Q1o17AkJdUPf+QyB9sXPjUxQ2exACzYQ8stV5M=; b=EvFTTc54RPGnvGaschcIulGypy/UFWeIl9gs7SbTirSGXMDySMOou0LYs6 jU9lm9k5lsLApwiKNifYZ7NBW7JX8Pis+nanra89g0r93LqoO0Tk/P97TmP0 IZC+Gw+Xoe; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Behave WG Subject: Re: [BEHAVE] TURN: Are unauthenticated indications and ChannelData msgs a problem? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org It's seems that one possible solution to these would be "only authenticated requests can create, update, or remove a permission". Cullen On Mar 25, 2008, at 7:26 AM, Philip Matthews wrote: > > On Tue, 25-Mar-08, at 07:58 , Benny Prijono wrote: >> On 3/24/08, Philip Matthews wrote: >>> What are the consequences of not authenticating indications and >>> ChannelData messages? I see two: >>> 1) An attacker can inject fake data packets to the server or the >>> client. >>> 2) At attacker can refresh permissions and channels. >>> >> >> What about: >> 3) Attacker can create new permission to arbitrary peer to send rogue >> data to client >> 4) Attacker can DOS the server by tricking it into creating so >> many permissions >> >> If he can fake source IP address/port, then he just sends a Send >> Indication with arbitrary peer address to create a new permission, >> no? > > Good point! These are indeed attacks that I had not previously > considered. > > I think these are lightly more serious than my attack (2), but I > still don't see why someone would bother with these attacks. > > - Philip > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 02:50:23 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5632D3A6975; Wed, 2 Apr 2008 02:50:23 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60A393A6DC0 for ; Wed, 2 Apr 2008 02:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYnxJ2c9dYAP for ; Wed, 2 Apr 2008 02:50:18 -0700 (PDT) Received: from s200aog10.obsmtp.com (s200aog10.obsmtp.com [207.126.144.124]) by core3.amsl.com (Postfix) with SMTP id 903973A6B98 for ; Wed, 2 Apr 2008 02:50:17 -0700 (PDT) Received: from source ([209.85.198.190]) by eu1sys200aob010.postini.com ([207.126.147.11]) with SMTP; Wed, 02 Apr 2008 09:50:16 UTC Received: by rv-out-0910.google.com with SMTP id b22so1264520rvf.21 for ; Wed, 02 Apr 2008 02:50:16 -0700 (PDT) Received: by 10.141.189.4 with SMTP id r4mr4857904rvp.98.1207129816575; Wed, 02 Apr 2008 02:50:16 -0700 (PDT) Received: by 10.141.186.2 with HTTP; Wed, 2 Apr 2008 02:50:16 -0700 (PDT) Message-ID: <1879720d0804020250k22ed23b5h1ba95fdb2e5245ca@mail.gmail.com> Date: Wed, 2 Apr 2008 10:50:16 +0100 From: "Benny Prijono" To: "Hadriel Kaplan" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> X-Google-Sender-Auth: bc91840ac15935b0 Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Wed, Apr 2, 2008 at 5:08 AM, Hadriel Kaplan wrote: > Hi Benny, > Comments inline... > > > As implementer working on client side, my holy grail is to have a > > client that will "just work", and the TCP/TLS connection helps me a > > lot here as I don't have to implement more complex protocol like > > ICE-TCP. > > > I am not sure what you mean by not having to do ICE-TCP - you mean not doing RFC4571 framing? Or you mean not using ICE connectivity checks and SIP/SDP pieces? In other words you mean you plan to just use the TURN relay addresses, period? > I'm using TURN with ICE, and all I need to do is to advertise the relay address in the ICE candidate list. The fact that the connection to the TURN server uses TCP is oblivious to the remote endpoint, and the remote endpoint doesn't need to support TCP at all. Alternatively, if I want my media to reach Internet with TCP, I will have to implement ICE-TCP, and RFC 3571, and probably RFC 4145. Maybe I'm wrong since I haven't even read any of these considering that I'm not ready to do major modification in my software to support TCP based media. > I'm no expert on that either - I personally only keep up with the network provider side of life. From what I'm told by folks in my company who do deal with enterprises, though, firewall policies are not a fixed well-defined rule-set, and vary for a bunch of reasons. > > Regardless, there is a "difference" between running RTP/TURN/TCP and RTP/TCP. For the former, it allows multiple RTP sessions (like audio+video) to run over a single TCP connection, or for example both RTP and RTCP over the single TURN-TCP connection, or MSRP file transfer and RTP over the same TURN-TCP connection, or Bitorrent and MP3 streams over the same connection, ad infinitum. It is going I don't think that's accurate, CMIIW. One TURN UDP allocation/relay address is only used for one type of media, regardless of whether the connection to the TURN server uses UDP or TCP. So that means application needs to allocate different TURN address for each SDP m= line, including one allocation for RTP and another for RTCP. Sure people can mux all of these in a single UDP allocation, by just advertising the same transport address for all of them. But the same can be done with plain RTP/UDP too, so TURN doesn't make the situation any worse IMO. > down a slippery-slope of firewall avoidance, such that the natural conclusion is not just to use TURN, but to use it on port 80 or 443. That *will* "just work" for you. It is what some p2p apps resort to, to get their apps to work. It is also something the ietf has avoided, afaik. Obviously there is some middle-ground. I'm just not sure what it is personally. Well whether I run my TURN on port 80 or 443 will be up to me, and to be fair to the TURN draft, there's nothing there that says that either. Maybe if TCP connection is disallowed I will run my TURN on port 53, and then what, are we going to disallow TURN UDP too? ;-) > RTP/TCP (RFC4571) is a single TCP connection for a single m-line stream, including one for RTP and one for RTCP. Furthermore, RFC4571 does not define a general application use-case - it is for RTP/RTCP and RTP/RTCP only, signaled in SDP. TURN is not media specific, nor SIP specific, nor anything specific. And given the interest lately to use TURN for any protocol, that raises the stakes. > With TURN application will also have to use one TURN allocation for each m-line, and including one for RTP and one for RTCP. > There are though issues that have nothing to do with firewall policies. Worse than UDP, TCP as a transport presents a number of issues with multiplexing different application streams in the same connection (e.g., HOL blocking, congestion avoidance backoff, flow shaping or RED in routers). > I believe you're talking about TURN TCP allocation, that will be a different issue (which is being discussed on separate thread I believe). Cheers Benny > -hadriel > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 03:23:10 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 829A53A69AC; Wed, 2 Apr 2008 03:23:10 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF7E28C4D1 for ; Wed, 2 Apr 2008 03:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnKTuPt2zp+5 for ; Wed, 2 Apr 2008 03:23:02 -0700 (PDT) Received: from s200aog13.obsmtp.com (s200aog13.obsmtp.com [207.126.144.127]) by core3.amsl.com (Postfix) with SMTP id 4A75328C581 for ; Wed, 2 Apr 2008 03:22:19 -0700 (PDT) Received: from source ([209.85.198.191]) by eu1sys200aob013.postini.com ([207.126.147.11]) with SMTP; Wed, 02 Apr 2008 10:22:18 UTC Received: by rv-out-0910.google.com with SMTP id b22so1269324rvf.21 for ; Wed, 02 Apr 2008 03:22:18 -0700 (PDT) Received: by 10.141.116.16 with SMTP id t16mr4871128rvm.60.1207131738593; Wed, 02 Apr 2008 03:22:18 -0700 (PDT) Received: by 10.141.186.2 with HTTP; Wed, 2 Apr 2008 03:22:18 -0700 (PDT) Message-ID: <1879720d0804020322l1d647f28rdd9d5ccb234cea90@mail.gmail.com> Date: Wed, 2 Apr 2008 11:22:18 +0100 From: "Benny Prijono" To: "=?ISO-8859-1?Q?R=E9mi_Denis-Courmont?=" In-Reply-To: <200804020742.52873.remi.denis-courmont@nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> <200804020742.52873.remi.denis-courmont@nokia.com> X-Google-Sender-Auth: 6fd2176d50697548 Cc: behave@ietf.org, Philip Matthews Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Wed, Apr 2, 2008 at 5:42 AM, R=E9mi Denis-Courmont wrote: > Le Wednesday 02 April 2008 01:45:07 ext Benny Prijono, vous avez =E9crit : > > > As implementer working on client side, my holy grail is to have a > > client that will "just work", and the TCP/TLS connection helps me a > > lot here as I don't have to implement more complex protocol like > > ICE-TCP. > > I know TCP could help in some cases: braindead UDP support in the NAT, > braindead firewall configuration that blocks UDP but lets outgoing TCP. I > wonder if TLS buys you anything unless the TURN server runs on port 443 - > which would clearly be a firewall. > The good thing with using TURN with ICE is, we don't care which one will work. Just put everything in the candidate list and let ICE machinery do its job. > > Not being conscious with policy matters, I'm still puzzled on > > why are we not allowing this. I mean, if I run my RTP over TCP over > > TURN (with UDP peers), how is this any different than RTP over TCP, or > > RTP over ICE-TCP, from the policy point of view? > > As far as I know, we currently DO allow this. Yep, and I'm trying to vote for it to stay. > The two main objections are it being a way to violate the firewall polic= y, and > it being difficult or impossible to implement in hardware. I can sympathize with the hardware problem. But just as Hadriel said he doesn't care if TWIST is not implementable in client since he doesn't write client, I also don't care if TURN is not implementable in a certain chip since I don't write chips. :) > I think the firewall objection is bogus - UDP-to-UDP TURN can be used to > work-around some loose firewall policies just as well. I would argue tha= t's a > bug in the firewall policy, not in TURN, if it works that way. Maybe, can't really comment on that since I've no clue on policies matter. But so far I've yet to hear why it's so bad to perform UDP allocation using TCP connection to TURN server (what's the shorthand name for this btw?), while I can do TCP media using other (non-TURN) means without anybody complaining that I'm breaking somekind of firewall policy. > A third objection, would be head-of-line blocking. However, I believe th= is is > a non issue for TCP-to-UDP relaying. The relay can just drop incoming UDP > packets from peers if the TCP session to the client is congested. > Exactly. > > As implementor, I have been holding back on implementing TURN, because i= t's > been obvious, for the past 30+ months years I've been following BEHAVE i= t's > not ready to be implemented. Well I thought we're finally getting somewhere with TURN-07, and I know at least one other implementor who thought the same. > Note however, that the current TURN spec is just plain broken when it co= mes to > TCP, especially, TCP-to-TCP, so it's going to have to change anyhow. > Yep. I've been lurking here all along to see the latest discussions. Cheers Benny _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 05:13:25 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4D033A6EEB; Wed, 2 Apr 2008 05:13:25 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD583A6914 for ; Wed, 2 Apr 2008 05:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3l3UY8E8psmU for ; Wed, 2 Apr 2008 05:13:17 -0700 (PDT) Received: from s200aog16.obsmtp.com (s200aog16.obsmtp.com [207.126.144.130]) by core3.amsl.com (Postfix) with SMTP id 6D3D43A6E63 for ; Wed, 2 Apr 2008 05:13:16 -0700 (PDT) Received: from source ([209.85.198.188]) by eu1sys200aob016.postini.com ([207.126.147.11]) with SMTP; Wed, 02 Apr 2008 12:13:15 UTC Received: by rv-out-0910.google.com with SMTP id b22so1287166rvf.21 for ; Wed, 02 Apr 2008 05:13:15 -0700 (PDT) Received: by 10.141.156.19 with SMTP id i19mr4896973rvo.25.1207138395525; Wed, 02 Apr 2008 05:13:15 -0700 (PDT) Received: by 10.141.186.2 with HTTP; Wed, 2 Apr 2008 05:13:15 -0700 (PDT) Message-ID: <1879720d0804020513t368824cdhaef7af940fb6cf4a@mail.gmail.com> Date: Wed, 2 Apr 2008 13:13:15 +0100 From: "Benny Prijono" To: "Cullen Jennings" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <5AE36F39-B800-45FD-A4CF-261EEE6BD191@cisco.com> <6CA00DCC-A48A-47DA-8CD3-9BB47C891068@magma.ca> <38F521F6-E706-40F5-B1C7-08A2CCAC7EA0@cisco.com> <9B9EE332-F142-4A2A-9985-D771D1A276CB@magma.ca> <1879720d0803250458t3389ed38j8db079c9b08b7e64@mail.gmail.com> <724EB65E-E362-4789-BE5B-10B1C4A1A00F@magma.ca> X-Google-Sender-Auth: 39b9c0d88f3acf6b Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] TURN: Are unauthenticated indications and ChannelData msgs a problem? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Wed, Apr 2, 2008 at 6:51 AM, Cullen Jennings wrote: > > It's seems that one possible solution to these would be "only authenticated > requests can create, update, or remove a permission". Just to be clear with the proposal, I imagine that we will allow zero or more PEER-ADDRESS attribute(s) to appear in Allocate and Refresh requests, and the server will use these attributes to create or refresh permissions. One of the interesting thing with this is that there will be multiple instances of the same attribute to appear in a STUN message. I don't think this is disallowed by STUN, but I don't think there is existing usages that use this either, so it'll be interesting to hear if it breaks implementations. For me I'm fine with this. There are variants to this proposal which I think are less optimized: - use new request/method to refresh permission. I think this is not necessary since I presume client will want to refresh allocation when it refreshes permission, so why not allow Refresh to refresh permission too (with appropriate attribute to indicate which permissions to refresh). - use separate requests to refresh individual permission. I think this is too chatty. For the proposal, I imagine the use case with ICE will be something like this: - caller sends Allocate with no PEER-ADDRESS (since it doesn't know which permission to create yet). It then sends INVITE with SDP. - callee receives INVITE with SDP, it inspects caller's candidates and sends Allocate (or Refresh if it's already got an allocation) with one or more PEER-ADDRESS attributes, one for each candidate. It then sends 18x/2xx with SDP. - when caller receives SDP, it'll send Refresh with one or more PEER-ADDRESS attributes (one for each remote candidate) to create permissions in the server. It may delay sending Send Indication to perform connectivity check via the the TURN candidate until the Refresh transaction completes, or it may send it immediately after the Refresh in the best hope that the Refresh request will not get lost. It doesn't matter for client since the Send Indication will be retransmitted on the next ICE check retransmissions. - once ICE negotiation completes, and if TURN candidate is used, client issues ChannelBind to "lock on" the permission, and the permission refresh is taken over by ChannelBind refresh mechanism. I think that could work, and it looks doable. It doesn't look too complicated, and it may even simplify the timeout mechanism a bit since now refresh is done more explicitly (no need to refresh permission every time Send Indication or ChannelData is received). The only complication that I can think of is if ICE negotiation is happening for duration that is longer than the permission duration, which in this case client has to remember to refresh the permissions. But considering that permission lives for 5 minutes I don't think this is an issue, ICE negotiation should complete by then. So clients only need to create the permission once up front, and refresh only the one that has been negotiated (via ChannelBind above for example). And with this there is no objection to maintain Send indication either, since it's no longer able to create permissions. So while I'm not too keen to have yet another major modification, I think I can accept the proposal if that makes TURN more acceptable. The other choice is of course to ignore and just document this in Security Consideration section, which I'm fine too. Cheers Benny > Cullen > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 07:13:08 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079D83A6ABB; Wed, 2 Apr 2008 07:13:08 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6830E3A68A3 for ; Wed, 2 Apr 2008 07:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UAKl4UsAJZs for ; Wed, 2 Apr 2008 07:13:03 -0700 (PDT) Received: from mail-02.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 2BFD53A6ABB for ; Wed, 2 Apr 2008 07:13:03 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Jh3i1-0005Ys-37; Wed, 02 Apr 2008 10:13:03 -0400 Message-Id: <6A8E8386-22C4-4D8D-ABA4-47BFBFB5AAEC@magma.ca> From: Philip Matthews To: Behave WG , =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= In-Reply-To: <200804011639.10034.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 10:13:01 -0400 References: <9567300E-395B-4EDF-BD70-B35907F824EB@magma.ca> <200804011639.10034.remi.denis-courmont@nokia.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Subject: Re: [BEHAVE] TURN: Proposed conf call X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Folks: I suggest we confine our discussion to draft-ietf-behave-turn ("TURN- = UDP"). This draft supports only UDP allocations and does not have any = head-of-line blocking problems or MSRP-like multiplexing problems (as = far as I am aware). However, it does allow TCP or TLS over TCP = connections between the client and the server. Bringing in TURN-TCP is just confusing the issue. The authors split = TURN-TCP from TURN because it did have some of these problems, and = even though we had some ideas how to fix them, we didn't have time to = work through the details. The TURN-TCP document has not been updated = since November 2007, is no longer consistent with the current TURN = draft, and should probably be considered just a placeholder. - Philip On Tue, 1-Apr-08, at 09:39 , R=E9mi Denis-Courmont wrote: > Le Friday 28 March 2008 20:23:59 ext Philip Matthews, vous avez = > =E9crit : >> There has been some discussion recently on the encapsulations used >> between the client and the server in TURN. Specifically, Hadriel has >> questioned the use of TCP transport for a UDP allocation, and has >> proposed an alternative encapsulation in his TWIST proposal. > > I believe, TWIST would be is very complicated to implement without = > special > privileges. In theory, it is do-able: it would be a slimmed-down = > userland > TCP/IP stack. This applies to both TURN client and TURN relay, and is > somewhat similar to what slirp[1] does. Alternatively, some kind of = > raw > packets or tunneling API could be used. > This seems to be fit fairly well for hardware relays, but not quite = > anything > else (client, or soft relays). > > [1] http://slirp.sourceforge.net/ > > Nevertheless, this proposal would address the congestion issues = > involving > multiple TCP session over a single TURN allocation. It does not = > solve the > TCP-to-UDP problem - it just does not allow this case to happen, as = > the > client must use UDP to the relay, independent of the relay-to-peer = > transport. > > > > The current TURN proposal does not address head-of-line blocking and = > MSRP-like > multiplexing problems. IMHO, this is a serious flaw. TCP-to-UDP = > however works > (if UDP packets are allowed to be dropped), though that can be = > difficult if > not impossible for hardware relays to implement. > > The "obvious" way to fix the congestion issues is the way SSH does = > (I think): > have some congestion control protocol on top of TCP. Complicated = > however. > > > > The N:N TCP connection proposal solves the congestion issues. It is = > extremely > easy to implement in software (both client and relay). In fact, = > client can > almost use the TCP sockets as usual - as they do with SOCKS. = > Software relays > can terminate the TCP sessions toward both client and peer and = > forward data > across. I believe, it would also be easy to implement in hardware or = > kernel: > TCP packets can simply be translated much like a double-sided NAT - = > in this > case congestion control (and retransmission) are done end-to-end > (client-to-peer). > > For TCP-to-UDP, this would be pretty much the same as the current = > TURN. In > fact, in this case using multiple TCP connections is not so = > interesting. > > > So, as far as I am concerned (you're free to disagree): > > TWIST TURN N:N > ---------------------------------------------- > TCP-UDP HW relay No Hard Hard > TCP-UDP SW relay No Easy Easy > TCP-TCP HW relay Easy Medium? Easy > TCP-TCP SW relay Hard Medium Easy > TCP-TCP Normal client Hard Medium Easy > TCP-TCP "Root" client Medium Medium? Easy > Number of flows N+1 N+1 2N+1 > > -- = > R=E9mi Denis-Courmont > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 07:20:47 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C50628C4E8; Wed, 2 Apr 2008 07:20:47 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88ACE3A6A57 for ; Wed, 2 Apr 2008 07:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WHXXKCUiG2J for ; Wed, 2 Apr 2008 07:20:42 -0700 (PDT) Received: from mail-05.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id D376728C1ED for ; Wed, 2 Apr 2008 07:20:36 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Jh3oK-000541-2p; Wed, 02 Apr 2008 10:19:33 -0400 Message-Id: From: Philip Matthews To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 10:20:36 -0400 References: <9567300E-395B-4EDF-BD70-B35907F824EB@magma.ca> <200804011639.10034.remi.denis-courmont@nokia.com> <20080401152908.46A1D5081A@romeo.rtfm.com> <20080401164304.CCBD150850@romeo.rtfm.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: "behave@ietf.org" Subject: Re: [BEHAVE] TURN: Proposed conf call X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Tue, 1-Apr-08, at 16:07 , Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Eric Rescorla [mailto:ekr@networkresonance.com] >> >> Hadriel Kaplan wrote: >>> >>> Because a client as currently defined in TURN and TURN-tcp can use >>> TURN to create a long-lived, publicly reachable TURN relay listen >>> port for server-type services to itself. Although there is some >>> wording in TURN security section saying it cannot be run as such, I >>> don't see any such restriction in the protocol itself - for example >>> the permissions section as defined does not prevent a willing client >>> app and/or TURN server from doing so. (though I could be wrong) >> >> I'm not sure what you mean by "in the protocol"? It's explicitly >> forbidden by the permission mechanism. Obviously, the server could >> be noncompliant, but how is this a TURN issue? > > I meant afaict the permission mechanism didn't stop a normal TURN > client from allocating a relay address and a normal TURN server from > sending it a DATA indication of receiving something for that relay > address, if a permission was not in effect. But I think I was > wrong. After reading it again carefully, I think what it's saying > is a UDP permission is only created when a TURN client sends > something to that peer first, and a TCP listen request must have a > peer address for a permission, and TURN server silently discards any > inbound messages on its relay side not matching a permission? If > so, then it's good. There is no "TCP listen request" in draft-ietf-behave-turn. And please ignore draft-ietf-behave-turn-tcp for now. And yes, a permission is created only by an explicit action by the client (either sending a packet to the peer, binding a channel, or an sending an empty Send indication). - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 07:52:29 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBAE93A6DD7; Wed, 2 Apr 2008 07:52:29 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370613A6D66 for ; Wed, 2 Apr 2008 07:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTUeHr0na9Ro for ; Wed, 2 Apr 2008 07:52:28 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 59CB03A6CC3 for ; Wed, 2 Apr 2008 07:52:28 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 2 Apr 2008 10:52:02 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 2 Apr 2008 10:52:02 -0400 From: Hadriel Kaplan To: Philip Matthews Date: Wed, 2 Apr 2008 10:52:02 -0400 Thread-Topic: [BEHAVE] TURN: Proposed conf call Thread-Index: AciUzKsRCYjf4LWQQ6mJNodM6Km3NwAAzR0g Message-ID: References: <9567300E-395B-4EDF-BD70-B35907F824EB@magma.ca> <200804011639.10034.remi.denis-courmont@nokia.com> <20080401152908.46A1D5081A@romeo.rtfm.com> <20080401164304.CCBD150850@romeo.rtfm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] TURN: Proposed conf call X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > > There is no "TCP listen request" in draft-ietf-behave-turn. And > please ignore draft-ietf-behave-turn-tcp for now. OK, I will ignore TURN-tcp for now. With regards to draft-ietf-behave-turn, when using a TCP or TLS connection for the client-TURN portion, is there something in draft-ietf-behave-turn that says one TCP connection is used for one UDP peer connection? I was under the impression it allowed/supported many peer UDP connections to be multiplexed in one TCP or TLS TURN connection. -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 08:18:56 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C18923A6EB6; Wed, 2 Apr 2008 08:18:56 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20F443A6EB6 for ; Wed, 2 Apr 2008 08:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNAKLUO5+63D for ; Wed, 2 Apr 2008 08:18:55 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2AA293A6A4B for ; Wed, 2 Apr 2008 08:18:55 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 2 Apr 2008 11:18:29 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 2 Apr 2008 11:18:30 -0400 From: Hadriel Kaplan To: Benny Prijono , =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= Date: Wed, 2 Apr 2008 11:18:29 -0400 Thread-Topic: [BEHAVE] Goals for the proposed conf call on TURN encapsulations Thread-Index: AciUq39XKBFenskCRmS6avW1ekfV9wAJln2Q Message-ID: References: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> <200804020742.52873.remi.denis-courmont@nokia.com> <1879720d0804020322l1d647f28rdd9d5ccb234cea90@mail.gmail.com> In-Reply-To: <1879720d0804020322l1d647f28rdd9d5ccb234cea90@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "behave@ietf.org" , Philip Matthews Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Benny Prijono > > > The two main objections are it being a way to violate the firewall > policy, and > > it being difficult or impossible to implement in hardware. > > I can sympathize with the hardware problem. But just as Hadriel said > he doesn't care if TWIST is not implementable in client since he > doesn't write client, I also don't care if TURN is not implementable > in a certain chip since I don't write chips. :) I *never* said I don't care if TWIST is implementable in a client. I said I don't care *how* it works in a client - i.e., I don't personally care about the implementation details of shims vs. stacks vs. whatever. I most certainly *do* care that clients be able to implement it, and obviously the more easily/simpler the better. BUT, you and others are implying the client should be easy and it doesn't matter how hard the server relay is. I think it should be the other way around completely. I think the clients should do absolutely everything in their power to off-load any burden from relays, and if that takes re-writing the existing client code or installing special-privilege shims to do so then so be it. The reason I think that is not because I'm lazy, but because I think the client desperately wants there to be a relay to begin with, and so it should make the bar for relays as low as possible. My $0.02 anyway (which, given the value of the $, is a lot less than $0.02 used to be). -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 08:26:12 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1AD28C56F; Wed, 2 Apr 2008 08:26:12 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C4028C502 for ; Wed, 2 Apr 2008 08:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obx2irHmC78u for ; Wed, 2 Apr 2008 08:26:09 -0700 (PDT) Received: from mail-05.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id D5F5228C25D for ; Wed, 2 Apr 2008 08:26:08 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Jh4pk-0008Vn-2l; Wed, 02 Apr 2008 11:25:05 -0400 Message-Id: <6D4E88C6-D37E-44BF-87B2-AA7E91639A04@magma.ca> From: Philip Matthews To: Hadriel Kaplan , Benny Prijono In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 11:26:06 -0400 References: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: Behave WG Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org First of all, thanks for having a mailing list discussion on all this. I am following the mailing list closely, and will make sure that any comments made on the list are carefully considered when deciding what to do with TURN. Regarding finishing TURN. Indeed, TURN has been very unstable for a long time, so it has not been a very good candidate for stable trial implementations. However, the authors are working hard to try to finish TURN as fast as possible, since it is the last piece holding back ICE from publication as an RFC. I am still hoping to have a WGLC on TURN before the Dublin meeting. However, even though changing encapsulations is a major change, there is no point going forward with a document that is just going to be ignored. So I want to make sure the question of encapsulations is properly considered. More comments on Hadriel's message below On Wed, 2-Apr-08, at 00:08 , Hadriel Kaplan wrote: > Hi Benny, > Comments inline... > >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf >> Of Benny Prijono >> >> As implementer working on client side, my holy grail is to have a >> client that will "just work", and the TCP/TLS connection helps me a >> lot here as I don't have to implement more complex protocol like >> ICE-TCP. > > I am not sure what you mean by not having to do ICE-TCP - you mean > not doing RFC4571 framing? Or you mean not using ICE connectivity > checks and SIP/SDP pieces? In other words you mean you plan to just > use the TURN relay addresses, period? > > >> Not being conscious with policy matters, I'm still puzzled on >> why are we not allowing this. I mean, if I run my RTP over TCP over >> TURN (with UDP peers), how is this any different than RTP over TCP, >> or >> RTP over ICE-TCP, from the policy point of view? > > I'm no expert on that either - I personally only keep up with the > network provider side of life. From what I'm told by folks in my > company who do deal with enterprises, though, firewall policies are > not a fixed well-defined rule-set, and vary for a bunch of reasons. > > Regardless, there is a "difference" between running RTP/TURN/TCP and > RTP/TCP. For the former, it allows multiple RTP sessions (like audio > +video) to run over a single TCP connection, or for example both RTP > and RTCP over the single TURN-TCP connection, or MSRP file transfer > and RTP over the same TURN-TCP connection, or Bitorrent and MP3 > streams over the same connection, ad infinitum. It is going down a > slippery-slope of firewall avoidance, such that the natural > conclusion is not just to use TURN, but to use it on port 80 or > 443. That *will* "just work" for you. It is what some p2p apps > resort to, to get their apps to work. It is also something the ietf > has avoided, afaik. Obviously there is some middle-ground. I'm > just not sure what it is personally. What precisely are you objecting to here? Is it the multiplexing, or the use of TCP? For example, if the client used a UDP connection to the server, then are you still concerned. Someone told me privately that one reason people are interested in using TCP between a client and the server is because firewall vendors don't like UDP because there is no explicit connection termination. With TCP, there is a handshake to connect and another handshake to disconnect, and this makes everything much more explicit. In my own company (Avaya), there is a firewall that monitors outgoing traffic (as well as incoming traffic), and it blocks various types of outgoing traffic. Though I don't know for sure, I think that the firewall is set to block all outgoing traffic (either TCP or UDP) unless an explicit permission has been inserted for the destination port. So this means that TURN will not work unless the IT department allows it. Thus I don't think allowing TCP connections between the client and the server will violate corporate security policy here. > > > RTP/TCP (RFC4571) is a single TCP connection for a single m-line > stream, including one for RTP and one for RTCP. Furthermore, > RFC4571 does not define a general application use-case - it is for > RTP/RTCP and RTP/RTCP only, signaled in SDP. TURN is not media > specific, nor SIP specific, nor anything specific. And given the > interest lately to use TURN for any protocol, that raises the stakes. > > There are though issues that have nothing to do with firewall > policies. Worse than UDP, TCP as a transport presents a number of > issues with multiplexing different application streams in the same > connection (e.g., HOL blocking, congestion avoidance backoff, flow > shaping or RED in routers). I don't think any of these problems apply in the situations allowed for by draft-ietf-behave-turn-07. If you believe otherwise, can you point out why? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 08:48:58 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E760828C538; Wed, 2 Apr 2008 08:48:58 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391BA28C50E for ; Wed, 2 Apr 2008 08:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9EVkNp8wFu5 for ; Wed, 2 Apr 2008 08:48:57 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4CE9A28C477 for ; Wed, 2 Apr 2008 08:48:57 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 2 Apr 2008 11:48:31 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 2 Apr 2008 11:48:29 -0400 From: Hadriel Kaplan To: Benny Prijono Date: Wed, 2 Apr 2008 11:48:18 -0400 Thread-Topic: [BEHAVE] Goals for the proposed conf call on TURN encapsulations Thread-Index: AciUpubdNYmNgPabRUWA9+eG1xyySQALe6DA Message-ID: References: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> <1879720d0804020250k22ed23b5h1ba95fdb2e5245ca@mail.gmail.com> In-Reply-To: <1879720d0804020250k22ed23b5h1ba95fdb2e5245ca@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: bennylp@pjsip.com [mailto:bennylp@pjsip.com] On Behalf Of Benny > Prijono > > Well whether I run my TURN on port 80 or 443 will be up to me, and to > be fair to the TURN draft, there's nothing there that says that > either. Maybe if TCP connection is disallowed I will run my TURN on > port 53, and then what, are we going to disallow TURN UDP too? ;-) No, you're not following what I mean. You can of course run TURN on port 80, or SIP on port 80, or whatever, and no the IETF is not the protocol police. However, what I'm talking about is about a question I asked a while ago. The question I asked is "Why do we need TCP/TLS as a transport for the TURN connection when the peer connection is UDP?" The answer from several people was (paraphrasing): "So we can get UDP-based applications to work across firewalls, and have something that works as well as Skype or other p2p apps." *That* is a slippery-slope. Because using TCP/TLS TURN will NOT be sufficient to accomplish that goal. Sending on port 80/443 will be necessary. Implementing FEP (RFC3093) is probably ultimately necessary. If one of the goals/requirements for TURN (and I have never actually seen any written goals/requirements for TURN) is "make applications of any type work across firewalls of any type", then to accomplish that goal it would have to specify more than just "use TCP". And that is where the IETF would/should have concerns. They should not be specifying FEP as anything but an April 1st RFC, imho. That's not to say people don't/can't do that - we're only talking about what the IETF should officially advocate - not what people can do. I'm not saying this means TCP/TLS use of TURN-udp should be removed. Maybe it is the appropriate point of "firewall avoidance" we should get to. I dunno. -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 09:04:44 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE593A6F42; Wed, 2 Apr 2008 09:04:44 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 050493A6F31 for ; Wed, 2 Apr 2008 09:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7KIh5B2q3A3 for ; Wed, 2 Apr 2008 09:04:39 -0700 (PDT) Received: from mail-05.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 1368E3A6EB6 for ; Wed, 2 Apr 2008 09:04:38 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Jh5R1-0002pS-1o; Wed, 02 Apr 2008 12:03:35 -0400 Message-Id: From: Philip Matthews To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 12:04:37 -0400 References: <9567300E-395B-4EDF-BD70-B35907F824EB@magma.ca> <200804011639.10034.remi.denis-courmont@nokia.com> <20080401152908.46A1D5081A@romeo.rtfm.com> <20080401164304.CCBD150850@romeo.rtfm.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: "behave@ietf.org" Subject: Re: [BEHAVE] TURN: Proposed conf call X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Wed, 2-Apr-08, at 10:52 , Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: Philip Matthews [mailto:philip_matthews@magma.ca] >> >> There is no "TCP listen request" in draft-ietf-behave-turn. And >> please ignore draft-ietf-behave-turn-tcp for now. > > OK, I will ignore TURN-tcp for now. > > With regards to draft-ietf-behave-turn, when using a TCP or TLS > connection for the client-TURN portion, is there something in draft- > ietf-behave-turn that says one TCP connection is used for one UDP > peer connection? I was under the impression it allowed/supported > many peer UDP connections to be multiplexed in one TCP or TLS TURN > connection. draft-ietf-behave-turn-07 allows a client to communicate with multiple peers using a single (UDP) allocation. This is true regardless of whether UDP, TCP, or TLS over TCP is used for the connection between the client and the server. This is illustrated in figure 1 in the draft. There are a number of reasons for allowing this: 1) If the call forks, and multiple endpoints answer the call, then this means that ICE just works, and there is no need to provide each endpoint with a different relayed transport address. 2) Some people want a client to use a single relayed transport address for ALL communication between the client and peers. For example, some people implementing NAT traversal for HIP are thinking of doing this. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 09:13:23 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A5F428C57E; Wed, 2 Apr 2008 09:13:23 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25F623A6949 for ; Wed, 2 Apr 2008 09:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsZqfrotVMsV for ; Wed, 2 Apr 2008 09:13:19 -0700 (PDT) Received: from mail-05.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 1F3B23A6F46 for ; Wed, 2 Apr 2008 09:11:18 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Jh5XS-0007QE-32; Wed, 02 Apr 2008 12:10:15 -0400 Message-Id: <5E1059C0-64E2-4A21-B121-446DEB62E080@magma.ca> From: Philip Matthews To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 12:11:17 -0400 References: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> <1879720d0804020250k22ed23b5h1ba95fdb2e5245ca@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: Behave WG Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Wed, 2-Apr-08, at 11:48 , Hadriel Kaplan wrote: > If one of the goals/requirements for TURN (and I have never > actually seen any written goals/requirements for TURN) is "make > applications of any type work across firewalls of any type", then to > accomplish that goal it would have to specify more than just "use > TCP". The goal of TURN is to allow an client to work behind a NAT of any type (and specifically, behind NATs which are not BEHAVE-compliant) that implements only very simple filtering properties. It is _NOT_ a goal to try to work around firewall policies. In other words, if you go out a buy a NAT that is not have the Endpoint-Independent mapping property, then TURN should allow you to work through that NAT. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 09:27:18 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273F428C462; Wed, 2 Apr 2008 09:27:18 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8B628C462 for ; Wed, 2 Apr 2008 09:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.866 X-Spam-Level: X-Spam-Status: No, score=-100.866 tagged_above=-999 required=5 tests=[AWL=1.399, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqi7fta0HnsN for ; Wed, 2 Apr 2008 09:27:17 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 14C8428C2AB for ; Wed, 2 Apr 2008 09:27:17 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 03486D9D4264; Wed, 2 Apr 2008 16:27:18 +0000 (UTC) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id C3FAFD9D4262; Wed, 2 Apr 2008 16:27:14 +0000 (UTC) Message-ID: <47F3B3E1.6080607@acm.org> Date: Wed, 02 Apr 2008 09:27:13 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: Philip Matthews References: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> <6D4E88C6-D37E-44BF-87B2-AA7E91639A04@magma.ca> In-Reply-To: <6D4E88C6-D37E-44BF-87B2-AA7E91639A04@magma.ca> Cc: Behave WG Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Philip Matthews wrote: > First of all, thanks for having a mailing list discussion on all this. > I am following the mailing list closely, and will make sure that any > comments made on the list are carefully considered when deciding what > to do with TURN. > > Regarding finishing TURN. Indeed, TURN has been very unstable for a > long time, so it has not been a very good candidate for stable trial > implementations. How a protocol can be proposed as a standard track RFC without implementations is a mystery for me. I know that it is mandatory to have independent implementations only when a standard is promoted to Draft Standard, but as nobody seems to worry to promote standards anymore, I think that the burden of the two implementations should be moved to the Proposed Standard. Anyway even if everybody seems to have given up on TURN implementations, I did not. On request I can provide an access to our TURN servers (turn-05 and rfc3489bis-15 currently, working on upgrading to turn-07). I can also provide a WIP patch for Wireshark. We are also working on implementing STUN and TURN in Zap[1], but it will take 2 or 3 more months to release the code. [1] http://www.croczilla.com/zap > However, the authors are working hard to try to > finish TURN as fast as possible, since it is the last piece holding > back ICE from publication as an RFC. I am still hoping to have a WGLC > on TURN before the Dublin meeting. However, even though changing > encapsulations is a major change, there is no point going forward with > a document that is just going to be ignored. So I want to make sure > the question of encapsulations is properly considered. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 09:42:04 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85A5928C403; Wed, 2 Apr 2008 09:42:04 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB1A28C403 for ; Wed, 2 Apr 2008 09:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0C3vXW2MM-oW for ; Wed, 2 Apr 2008 09:42:03 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1FDBA28C2B7 for ; Wed, 2 Apr 2008 09:42:02 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 2 Apr 2008 12:41:37 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 2 Apr 2008 12:41:38 -0400 From: Hadriel Kaplan To: Benny Prijono Date: Wed, 2 Apr 2008 12:41:36 -0400 Thread-Topic: [BEHAVE] Goals for the proposed conf call on TURN encapsulations Thread-Index: AciUpubdNYmNgPabRUWA9+eG1xyySQANGgjQ Message-ID: References: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> <1879720d0804020250k22ed23b5h1ba95fdb2e5245ca@mail.gmail.com> In-Reply-To: <1879720d0804020250k22ed23b5h1ba95fdb2e5245ca@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: bennylp@pjsip.com [mailto:bennylp@pjsip.com] On Behalf Of Benny > Prijono > > On Wed, Apr 2, 2008 at 5:08 AM, Hadriel Kaplan > wrote: > > > > Regardless, there is a "difference" between running RTP/TURN/TCP and > RTP/TCP. For the former, it allows multiple RTP sessions (like > audio+video) to run over a single TCP connection, or for example both RTP > and RTCP over the single TURN-TCP connection, or MSRP file transfer and > RTP over the same TURN-TCP connection, or Bitorrent and MP3 streams over > the same connection, ad infinitum. It is going > > I don't think that's accurate, CMIIW. One TURN UDP allocation/relay > address is only used for one type of media, regardless of whether the > connection to the TURN server uses UDP or TCP. So that means > application needs to allocate different TURN address for each SDP m= > line, including one allocation for RTP and another for RTCP. > > Sure people can mux all of these in a single UDP allocation, by just > advertising the same transport address for all of them. But the same > can be done with plain RTP/UDP too, so TURN doesn't make the situation > any worse IMO. Nope - afaik, when you advertise multiple RFC4571 connections, each TCP connection handles exactly one RTP m-line stream, or one RTCP stream. The mechanism follows Dr. Spengler's advice of "Don't cross the streams." :) With TURN, one TURN TCP connection, from client to TURN server, can handle numerous peer UDP connections. (For TURN-TCP, it could handle numerous peer TCP connections, but I'll ignore TURN-tcp) In other words, the relay address you give out in SDP may well be unique per stream, but the data for them all can come in and go out on one TCP connection between you and the relay. > > There are though issues that have nothing to do with firewall policies. > Worse than UDP, TCP as a transport presents a number of issues with > multiplexing different application streams in the same connection (e.g., > HOL blocking, congestion avoidance backoff, flow shaping or RED in > routers). > > > > I believe you're talking about TURN TCP allocation, that will be a > different issue (which is being discussed on separate thread I > believe). Nope, I'm talking draft-ietf-behave-turn, using TCP or TLS for the client-relay connection and UDP from relay to peers. -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 10:25:50 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426643A699C; Wed, 2 Apr 2008 10:25:50 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E87DC28C3B3 for ; Wed, 2 Apr 2008 10:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.357 X-Spam-Level: X-Spam-Status: No, score=-1.357 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ1jaoJ-75WQ for ; Wed, 2 Apr 2008 10:25:48 -0700 (PDT) Received: from s200aog16.obsmtp.com (s200aog16.obsmtp.com [207.126.144.130]) by core3.amsl.com (Postfix) with SMTP id 226AC28C42E for ; Wed, 2 Apr 2008 10:25:00 -0700 (PDT) Received: from source ([64.233.184.228]) by eu1sys200aob016.postini.com ([207.126.147.11]) with SMTP; Wed, 02 Apr 2008 17:25:01 UTC Received: by wr-out-0506.google.com with SMTP id c55so1982688wra.0 for ; Wed, 02 Apr 2008 10:25:01 -0700 (PDT) Received: by 10.140.207.3 with SMTP id e3mr5133927rvg.194.1207157100235; Wed, 02 Apr 2008 10:25:00 -0700 (PDT) Received: by 10.141.186.2 with HTTP; Wed, 2 Apr 2008 10:25:00 -0700 (PDT) Message-ID: <1879720d0804021025o312d0087geceff36d6ba10e99@mail.gmail.com> Date: Wed, 2 Apr 2008 18:25:00 +0100 From: "Benny Prijono" To: "Hadriel Kaplan" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> <1879720d0804020250k22ed23b5h1ba95fdb2e5245ca@mail.gmail.com> X-Google-Sender-Auth: dc34441bcd26d7dc Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Wed, Apr 2, 2008 at 5:41 PM, Hadriel Kaplan wrote: > > Sure people can mux all of these in a single UDP allocation, by just > > advertising the same transport address for all of them. But the same > > can be done with plain RTP/UDP too, so TURN doesn't make the situation > > any worse IMO. > > Nope - afaik, when you advertise multiple RFC4571 connections, each TCP connection handles exactly one RTP m-line stream, or one RTCP stream. The mechanism follows Dr. Spengler's advice of "Don't cross the streams." :) > > With TURN, one TURN TCP connection, from client to TURN server, can handle numerous peer UDP connections. (For TURN-TCP, it could handle numerous peer TCP connections, but I'll ignore TURN-tcp) In other words, the relay address you give out in SDP may well be unique per stream, but the data for them all can come in and go out on one TCP connection between you and the relay. > I don't think that's true. One TCP connection between client and TURN server can only be used to serve *exactly one* TURN allocation. But it looks like this is not explicitly mentioned in the draft, the closest thing that I can find that implies this is from this text in page 8: While the terminology used in this document refers to 5-tuples, the TURN server can store whatever identifier it likes that yields identical results. Specifically, many implementations use a file- descriptor in place of a 5-tuple to represent a TCP connection. The last sentence that says a (TCP) file descriptor may be used in place of 5-tuple implies that a TCP client connection can only be used to serve one allocation, since the 5-tuple uniquely identifies an Allocation in the server. Cheers Benny _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 10:27:28 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0E53A6ED2; Wed, 2 Apr 2008 10:27:28 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3040C3A6DED for ; Wed, 2 Apr 2008 10:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihzI35pDT2lo for ; Wed, 2 Apr 2008 10:27:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 558F03A6966 for ; Wed, 2 Apr 2008 10:27:25 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 2 Apr 2008 13:27:00 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 2 Apr 2008 13:27:00 -0400 From: Hadriel Kaplan To: Philip Matthews , Benny Prijono Date: Wed, 2 Apr 2008 13:26:47 -0400 Thread-Topic: [BEHAVE] Goals for the proposed conf call on TURN encapsulations Thread-Index: AciU1dLzimev13+KSvWwVFOS4cPh+AAC/8yg Message-ID: References: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> <6D4E88C6-D37E-44BF-87B2-AA7E91639A04@magma.ca> In-Reply-To: <6D4E88C6-D37E-44BF-87B2-AA7E91639A04@magma.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Behave WG Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Wednesday, April 02, 2008 11:26 AM > > Regarding finishing TURN. Indeed, TURN has been very unstable for a > long time, so it has not been a very good candidate for stable trial > implementations. However, the authors are working hard to try to > finish TURN as fast as possible, since it is the last piece holding > back ICE from publication as an RFC. Whoah. Why is draft-ietf-behave-turn delaying ICE??? I mean I see it in the normative section, and I see it riddled throughout the ICE doc. Hmm. Too bad ICE wasn't written to describe just using a relayed address gotten through some relay means, a possible one being TURN, and leave it at that. :( Ugh. This is not good. -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 11:29:44 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3513A6F12; Wed, 2 Apr 2008 11:29:44 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CB253A6EF6 for ; Wed, 2 Apr 2008 11:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.804 X-Spam-Level: X-Spam-Status: No, score=-100.804 tagged_above=-999 required=5 tests=[AWL=1.161, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFYTnZt9IXwh for ; Wed, 2 Apr 2008 11:29:42 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 3BABC3A6A4B for ; Wed, 2 Apr 2008 11:29:42 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 8284DD9D4264; Wed, 2 Apr 2008 18:29:43 +0000 (UTC) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id 4D92AD9D4262; Wed, 2 Apr 2008 18:29:41 +0000 (UTC) Message-ID: <47F3D094.5060607@acm.org> Date: Wed, 02 Apr 2008 11:29:40 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: =?ISO-8859-1?Q?P=E5l-Erik_Martinsen?= References: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> <6D4E88C6-D37E-44BF-87B2-AA7E91639A04@magma.ca> <47F3B3E1.6080607@acm.org> <47F3BB1F.5080100@tandberg.com> In-Reply-To: <47F3BB1F.5080100@tandberg.com> Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org P=E5l-Erik Martinsen wrote: > inline > = > = > Marc Petit-Huguenin wrote: > = >> Philip Matthews wrote: >> = >>> First of all, thanks for having a mailing list discussion on all this. = >>> I am following the mailing list closely, and will make sure that any = >>> comments made on the list are carefully considered when deciding what = >>> to do with TURN. >>> >>> Regarding finishing TURN. Indeed, TURN has been very unstable for a = >>> long time, so it has not been a very good candidate for stable trial = >>> implementations. = >>> = >> How a protocol can be proposed as a standard track RFC without >> implementations is a mystery for me. I know that it is mandatory to >> have independent implementations only when a standard is promoted to >> Draft Standard, but as nobody seems to worry to promote standards >> anymore, I think that the burden of the two implementations should be >> moved to the Proposed Standard. >> >> Anyway even if everybody seems to have given up on TURN implementations, >> I did not. On request I can provide an access to our TURN servers >> (turn-05 and rfc3489bis-15 currently, working on upgrading to turn-07). >> I can also provide a WIP patch for Wireshark. We are also working on >> implementing STUN and TURN in Zap[1], but it will take 2 or 3 more >> months to release the code. >> >> [1] http://www.croczilla.com/zap >> >> = > I have not given up! > Just finished a TURN-07 client implementation. > = > I have not implemented the REQUESTED-PROPS attribute. Further down the > road ICE will need explicit rtcp-port signalling in the SDP anyway. Isn't what RFC 3605 do? > = > I would be very interested in the Wireshark patch. Getting tired of just > seeing STUN2 packets with unknown attributes. Sent in private email. > = > Please let me know when your servers are upgraded to 07. I would love to > do a quick test. > = -- = Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 13:32:27 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7514028C19C; Wed, 2 Apr 2008 13:32:27 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E7D43A6B82 for ; Wed, 2 Apr 2008 13:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo+trI5E2iQL for ; Wed, 2 Apr 2008 13:32:24 -0700 (PDT) Received: from mail-07.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 020EE28C3D0 for ; Wed, 2 Apr 2008 13:32:23 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Jh9d6-0000uo-0s; Wed, 02 Apr 2008 16:32:20 -0400 Message-Id: From: Philip Matthews To: Benny Prijono , Hadriel Kaplan In-Reply-To: <1879720d0804021025o312d0087geceff36d6ba10e99@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 16:32:22 -0400 References: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> <1879720d0804020250k22ed23b5h1ba95fdb2e5245ca@mail.gmail.com> <1879720d0804021025o312d0087geceff36d6ba10e99@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: Behave WG Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Wed, 2-Apr-08, at 13:25 , Benny Prijono wrote: > On Wed, Apr 2, 2008 at 5:41 PM, Hadriel Kaplan > wrote: >>> Sure people can mux all of these in a single UDP allocation, by just >>> advertising the same transport address for all of them. But the same >>> can be done with plain RTP/UDP too, so TURN doesn't make the >>> situation >>> any worse IMO. >> >> Nope - afaik, when you advertise multiple RFC4571 connections, each >> TCP connection handles exactly one RTP m-line stream, or one RTCP >> stream. The mechanism follows Dr. Spengler's advice of "Don't >> cross the streams." :) >> >> With TURN, one TURN TCP connection, from client to TURN server, can >> handle numerous peer UDP connections. (For TURN-TCP, it could >> handle numerous peer TCP connections, but I'll ignore TURN-tcp) In >> other words, the relay address you give out in SDP may well be >> unique per stream, but the data for them all can come in and go out >> on one TCP connection between you and the relay. >> >> > > I don't think that's true. One TCP connection between client and TURN > server can only be used to serve *exactly one* TURN allocation. But it > looks like this is not explicitly mentioned in the draft, the closest > thing that I can find that implies this is from this text in page 8: > > While the terminology used in this document refers to 5-tuples, > the TURN server can store whatever identifier it likes that > yields > identical results. Specifically, many implementations use a > file- > descriptor in place of a 5-tuple to represent a TCP connection. > > The last sentence that says a (TCP) file descriptor may be used in > place of 5-tuple implies that a TCP client connection can only be used > to serve one allocation, since the 5-tuple uniquely identifies an > Allocation in the server. An allocation is uniquely identified by the 5-tuple (source IP address, source port, dest IP address, dest port, protocol) of the connection between the client and the server. Thus a TCP connection between the client and the server can only be used for one allocation. However, multiple peers can talk to the client over that allocation, where "peer" is a unique (IP address, port) combination. Thus it would be possible for a client to put the same relayed transport address for multiple streams in the SDP, provided the client could figure out what to send to each of the remote (IP address, port) combinations. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 13:59:35 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 870D33A6BE0; Wed, 2 Apr 2008 13:59:35 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47D223A6BE0 for ; Wed, 2 Apr 2008 13:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPj5CycK9lIR for ; Wed, 2 Apr 2008 13:59:33 -0700 (PDT) Received: from mail-02.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 95AB73A6B82 for ; Wed, 2 Apr 2008 13:59:33 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JhA3T-00059f-0E for behave@ietf.org; Wed, 02 Apr 2008 16:59:35 -0400 Message-Id: From: Philip Matthews To: Behave WG Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 16:59:33 -0400 X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Subject: [BEHAVE] Conf call on TURN encapsulations will be held on Tuesday X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org The conference call on TURN encapsulations will be held on Tuesday, 8 April 2007 at the following time 9 - 11 Pacific / 12 - 14 Eastern / 18 - 20 CET / 19 - 21 EET Please send me an e-mail if you want to join this call, and I will send you the bridge information. (Those who have already responded need not reply again). - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 14:27:17 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C7D63A6C81; Wed, 2 Apr 2008 14:27:17 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 891233A69B3 for ; Wed, 2 Apr 2008 14:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.722 X-Spam-Level: X-Spam-Status: No, score=-99.722 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eRJ-HtJjX2k for ; Wed, 2 Apr 2008 14:27:15 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id D947A3A6961 for ; Wed, 2 Apr 2008 14:27:15 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 60E8EDA4C090; Wed, 2 Apr 2008 21:27:17 +0000 (UTC) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id C7D41DA4C08E for ; Wed, 2 Apr 2008 21:27:12 +0000 (UTC) Message-ID: <47F3FA30.2060403@acm.org> Date: Wed, 02 Apr 2008 14:27:12 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: Behave WG Subject: [BEHAVE] IPv4/IPv6 relayed address allocation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I think that I found a contradiction between turn-07 and turn-ipv6-04: In turn-07 section 6.2, "When allocating a relayed transport address for the allocation, the server MUST allocate an IP address of the same family (e.g, IPv4 vs. IPv6) as the server's transport address." In turn-ipv6 section 5.1, "If the REQUESTED-ADDRESS-TYPE attribute is absent, the server MUST allocate a IPv4 transport address to the TURN client." My understanding before trying to implement turn-07 was that TURN without turn-ipv6 always allocates an IPv4 relayed transport address - in other words that a REQUESTED-ADDRESS-TYPE with a family value equals to 0x01 is equivalent to no REQUESTED-ADDRESS-TYPE. Who's right? -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 14:58:55 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 716CB28C278; Wed, 2 Apr 2008 14:58:55 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B62028C278 for ; Wed, 2 Apr 2008 14:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KiM7zXN+SFl for ; Wed, 2 Apr 2008 14:58:53 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0342B3A6B9A for ; Wed, 2 Apr 2008 14:58:53 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 02 Apr 2008 14:58:55 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m32LwsLD029732 for ; Wed, 2 Apr 2008 14:58:54 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m32LwsWE012533 for ; Wed, 2 Apr 2008 21:58:54 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 17:58:54 -0400 Received: from [10.82.250.46] ([10.82.250.46]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 17:58:54 -0400 Message-ID: <47F401A1.2080204@cisco.com> Date: Wed, 02 Apr 2008 17:58:57 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Behave WG X-OriginalArrivalTime: 02 Apr 2008 21:58:54.0077 (UTC) FILETIME=[BE0DA2D0:01C8950C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4189; t=1207173534; x=1208037534; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20TURN=20and=20TWIST |Sender:=20; bh=ivM/qHOIomSJZo2vO92kkP30XldPQaw0IvfK/XQvQQc=; b=yP5gHXs6nwMmClpUct75V7oi0kt+zvRMAf350CCoRf2LTkkhNjilQT5Pbi nIpbp8t/ti12b+nTlmy4C4S+d+qIp5WXbThiOtU7wbaUm5bQLyLhKtoE7JLm JcpWfPnf9/; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [BEHAVE] TURN and TWIST X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I read Hadriel's TWIST draft and as you can imagine I have lots of comments. Firstly, despite Hadriel's comments on the list otherwise, my reading of this document is that it is positioned as an alternative proposal to TURN, obviously one coming extremely late in a process that has already taken a very long. The abstract says: This is similar to TURN, but defines an alternative mechanism which is more scalable, cheaper to deploy, and is thus more likely to succeed in achieving wide- spread use. TWIST is not meant to replace TURN, but rather to provide an alternative. The first and second sentences are clear contradictions to each other, since the argumentative language in the first sentence (and indeed throughout the document) position it as "lets boot turn and do this instead since its better". Though Hadriel of course has the right to author whatever drafts he likes, I find this approach at this late stage to be disruptive and not helpful. Secondly, I disagree entirely with this approach. All along from day one, it has been an objective of TURN to provide a mechanism that was optimized for relaying of real time media and thus low overhead. Both the tunnel and transport modes in this document (and especially tunnel) bring huge overhead for no clear advantage. Thus, this draft doesn't even come close to meeting the needs which drove us towards the TURN design. Next, the draft makes claims of more efficient hardware implementation. I find little real evidence for this; merely some hand-waving at similarity to existing VPN hardware products. However, TWIST is different than VPN and it is far from obvious to me that in reality this would be faster. To be frank this was a lot of FUD. Architecturally, I find the mechansism is an odd hybrid between VPN (layer 3 relay) and transport (layer 4 relay). TURN is very much a transport layer relay and therefore IMHO a cleaner solution. The draft also claims its simpler by only allowing one remote peer per allocation. This capability in TURN is not a bug, its a feature. It is there to make TURN work with SIPs forking feature. If you remove this capability in TWIST then TWIST will not work with SIP. The transport mode in the draft appears to be broken; there is no way for a client to listen on a socket and then send a packet to a particular remote peer. The inner UDP packet only specifies the remote peer's destination port and not the destination IP. This is necessary for ICE to function. Therefore I do not believe transport mode works with ICE. The latching behavior for listen connections is also broken. This used to be in TURN too - and was called lockdown. AN attacker can send a faked UDP packet with no credentials and cause the legitimate peer to be blocked. We discarded this approach years ago for this reason. I believe the demultiplexing is broken. The draft says that, after an allocation is done, STUN and app data are demuxed by sending STUN within the native encapsulation, but using the default TWIST port. This is broken for two reasons. Firstly, it doesn't work if you want to communicate with the peer on its twist port. Second and more importantly, there can still be retransmissions of the original UNENCAPSULATED stun packets. This means the relay needs to demux STUN and UDP, which cannot be reliably done. Thus my opinion is that we should set this draft aside and continue to work on TURN as we have been doing. If Hadriel or anyone else has suggestions on improvements or changes to be made in TURN let us of course hear them. But entertaining a completely new approach that doesn't work, provides no clear improvement over the current approach, and doesn't meet the needs that drove turn, is not beneficial for the group at this point. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 18:57:03 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CCA028C569; Wed, 2 Apr 2008 18:57:03 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C38F3A6D12 for ; Wed, 2 Apr 2008 18:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHk80flW+FFx for ; Wed, 2 Apr 2008 18:57:01 -0700 (PDT) Received: from mail-01.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 821343A6A91 for ; Wed, 2 Apr 2008 18:57:01 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JhEhL-0004w5-1S for behave@ietf.org; Wed, 02 Apr 2008 21:57:03 -0400 Message-Id: From: Philip Matthews To: Behave WG In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 21:57:02 -0400 References: X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Subject: Re: [BEHAVE] Conf call on TURN encapsulations will be held on Tuesday X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I will send out bridge information for the call by Monday. Right now, I have a bridge with a US dial-in number, but I am trying to find one that also has international dial-in numbers. - Philip On Wed, 2-Apr-08, at 16:59 , Philip Matthews wrote: > The conference call on TURN encapsulations will be held on Tuesday, 8 > April 2007 at the following time > 9 - 11 Pacific / 12 - 14 Eastern / 18 - 20 CET / 19 - 21 EET > > Please send me an e-mail if you want to join this call, and I will > send you the bridge information. (Those who have already responded > need not reply again). > > - Philip > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 19:19:21 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90BE28C344; Wed, 2 Apr 2008 19:19:21 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29573A6A41 for ; Wed, 2 Apr 2008 19:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZihOVBiNiQTN for ; Wed, 2 Apr 2008 19:19:19 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4F4ED3A6CC0 for ; Wed, 2 Apr 2008 19:19:19 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 2 Apr 2008 22:18:55 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 2 Apr 2008 22:18:55 -0400 From: Hadriel Kaplan To: Jonathan Rosenberg , Behave WG Date: Wed, 2 Apr 2008 22:18:52 -0400 Thread-Topic: [BEHAVE] TURN and TWIST Thread-Index: AciVDLmtmxlMyuh1S56lbGBaddS6xwAGaV9g Message-ID: References: <47F401A1.2080204@cisco.com> In-Reply-To: <47F401A1.2080204@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [BEHAVE] TURN and TWIST X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Ah, I was wondering when you'd get time for this. :) Thanks for responding. Comments inline... > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Jonathan Rosenberg > > Firstly, despite Hadriel's comments on the list otherwise, my reading of > this document is that it is positioned as an alternative proposal to > TURN, obviously one coming extremely late in a process that has already > taken a very long. The abstract says: > The first and second sentences are clear contradictions to each other, > since the argumentative language in the first sentence (and indeed > throughout the document) position it as "lets boot turn and do this > instead since its better". Though Hadriel of course has the right to > author whatever drafts he likes, I find this approach at this late stage > to be disruptive and not helpful. Although I did not email it to the list, I did email to you and others that my intention was NOT to disrupt TURN with TWIST, and that it's NOT a replacement. I am not, for example, suggesting that ICE be held up for it or even discuss TWIST. I also noted several times to people off-line (though maybe not to you) that I was very sorry for being late with questions about TURN and though I tried to go through previous emails on the reflector archive but there just too many hits to go through, and that if the consensus was "we're way past that - go away" then I'd shut up about TURN. The response from people off-line was "we're well past TURN with udp as the transport, but not Turn with tcp". IF you and others on the list feel the turn-udp draft is well past the TCP or TLS transport issues, I will shut up about them. I am keenly aware I am late to this process and do not want to put up roadblocks to it. I was, for example, surprised to learn ICE had a normative dependency on the TURN-udp draft and that alone makes me regret raising issues on TURN-udp. Again, I apologize sincerely for this. :( > Secondly, I disagree entirely with this approach. All along from day > one, it has been an objective of TURN to provide a mechanism that was > optimized for relaying of real time media and thus low overhead. Both > the tunnel and transport modes in this document (and especially tunnel) > bring huge overhead for no clear advantage. Thus, this draft doesn't > even come close to meeting the needs which drove us towards the TURN > design. The "transport" mode, as noted in the TWIST draft, for udp could be made to *be* TURN's encapsulation. You say "real time media", but using TCP transport for real-time media is a contradiction in itself. The reason it's kosher, maybe, is it makes things work through certain firewalls and thus be "more successful". In a similar vein, the "tunnel" encapsulation format is there simply to make things be "more successful", by letting more server relay types exist. I.e., letting more things *be* TWIST relays. Specifically I am thinking of firewalls, vpn switches, and router services blades. That is the advantage for that format. I am not personally tied to that format myself, though I do think it has other advantages if one were to actually encrypt using it. > Next, the draft makes claims of more efficient hardware implementation. > I find little real evidence for this; merely some hand-waving at > similarity to existing VPN hardware products. However, TWIST is > different than VPN and it is far from obvious to me that in reality this > would be faster. To be frank this was a lot of FUD. Don't take my word for it - talk to your company's hardware folks. When you have to terminate TCP it's not free, and there aren't as many of your products that can do it. There are ASICs that can do it in certain products, and there are at least 3 relatively new off-the-shelf chip vendors I know of that can do it in scale, where by scale I mean in the multi-gig and 100K-1M+ connections, one of whom your company uses in a couple of your products I believe. For those 3 chips, terminating TCP or TLS is still more overhead than either of the encap formats in TWIST, with less resulting throughput and/or fewer flows. I only "know" that because we have one of those too, and like any hardware vendor we're exposed to most if not all of their sales pitches and docs. My goal for TWIST was to not only make those chips scale better, but to make it scale better on already deployed products which don't have those chips. The reason for that desire is again to simply increase the probability of relays existing as much as possible, because I think that is a goal we should strive for. "Cheap" is obviously a subjective concept, and for your company certainly pricing is different that for others. For cases where people's PC's are being used as the TURN relays (ie, for p2p apps or models) it may even seem free to you. I am not arguing against that, though there is an argument against it. What I am referring to is "cheapness" in hardware. Whether you agree with that or not should not actually matter to you, I think, because I am NOT proposing TWIST to replace TURN, and the market has a darn good way of figuring it out for us. :) I am in a sense arguing to let the market do that. I find the IETF is absolutely atrocious at trying to mandate market forces. I'm not claiming to be any better at it, fwiw. > Architecturally, I find the mechansism is an odd hybrid between VPN > (layer 3 relay) and transport (layer 4 relay). TURN is very much a > transport layer relay and therefore IMHO a cleaner solution. TURN is NOT a pure "transport layer relay", imho. Not when it terminates TCP on one side and creates UDP on the other (for TURN-udp), or both sides (for TURN-tcp). It is a hybrid of an application-layer relay, if anything. It is muxing a control channel (STUN) and application channel inside a transport. It is effectively creating a relay for a layer between app and transport. > The draft also claims its simpler by only allowing one remote peer per > allocation. This capability in TURN is not a bug, its a feature. It is > there to make TURN work with SIPs forking feature. If you remove this > capability in TWIST then TWIST will not work with SIP. I don't dispute this. I indicate right in the TWIST draft muxing of relayed streams is possible with TWIST, just not defined in this first draft. I think this muxing need is a unique property of SIP, but you're not proposing TURN be a SIP-specific-use relay mechanism anymore. I left it as a TBD for TWIST, if we think it's important. Your other comments I'll respond to separately, as they're in a different vein methinks. -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 19:22:26 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417693A6A41; Wed, 2 Apr 2008 19:22:26 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEFF33A67A5 for ; Wed, 2 Apr 2008 19:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NugKKwdrJ6LL for ; Wed, 2 Apr 2008 19:22:24 -0700 (PDT) Received: from mail-06.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 10E3D3A6A25 for ; Wed, 2 Apr 2008 19:22:24 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JhF5u-0004ds-0r; Wed, 02 Apr 2008 22:22:26 -0400 Message-Id: From: Philip Matthews To: Behave WG Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 22:22:24 -0400 X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: Mark Townsley , David R Oran , David Ward Subject: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At the last BEHAVE meeting, it was suggested that one use of ALTERNATE- SERVER was to support anycast discovery of TURN servers. I have been doing some inquiries, and it seems that there might be a problem with this idea. The way I had been thinking this would work is that a client would send an Allocate request to an anycast address, and would receive an error response back with an error code of 300 Try Alternative and an ALTERNATE-SERVER attribute giving the unicast address of the server to contact. The problem is that it seems there is no guarantee that two consecutive packets will be delivered to the same anycast server. The only thing that is guaranteed is a single round-trip exchange[1]. This means that the above idea does not work because: a) It is not possible to contact an anycast TURN server using TCP or TLS over TCP, since the handshake will not necessarily complete with the same server. b) It is also not possible to contact an anycast TURN server using UDP, since STUN says that an ALTERNATE-SERVER reply must be authenticated, and authentication in TURN requires a 4-packet exchange. So this straight-forward method of doing anycast lookup in TURN does not seem to work. There are probably ways to fix this by changing how ALTENATE-SERVER works in TURN, but I am currently inclined to forget about anycast for TURN right now, and let someone add it later. Comments? - Philip [1] Private info received from David Oran. I have asked for a public reference. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 19:35:42 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 884B73A6A68; Wed, 2 Apr 2008 19:35:42 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729753A6A68 for ; Wed, 2 Apr 2008 19:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKWdt353CgSG for ; Wed, 2 Apr 2008 19:35:39 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 86FF93A6A09 for ; Wed, 2 Apr 2008 19:35:39 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 2 Apr 2008 22:35:15 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 2 Apr 2008 22:35:15 -0400 From: Hadriel Kaplan To: Jonathan Rosenberg , Behave WG Date: Wed, 2 Apr 2008 22:35:14 -0400 Thread-Topic: [BEHAVE] TURN and TWIST Thread-Index: AciVDLmtmxlMyuh1S56lbGBaddS6xwAI3+Sw Message-ID: References: <47F401A1.2080204@cisco.com> In-Reply-To: <47F401A1.2080204@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [BEHAVE] TURN and TWIST X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org With regards to the comments below, I have a general response: the TWIST draft is a straw-man. It is not a fully defined draft. It said that right in the abstract ("This document is a straw-man proposal, to stimulate discussion, not a fully defined draft"), but I realize I should have repeated that again (multiple times). Some similar comments were made by others in other emails on this list, though you added some new ones as well, and I will attempt to resolve them in a revision. Thank you for reviewing it and providing them, and I apologize for not having them covered already and for raising things you have already hashed out in the past. I tried to grep through previous TURN-related emails on this list's archive, but quickly realized I would not be able to do so in reasonable human lifetime, and I did not see rationales in the current turn drafts for such decisions. -hadriel > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Jonathan Rosenberg > > The transport mode in the draft appears to be broken; there is no way > for a client to listen on a socket and then send a packet to a > particular remote peer. The inner UDP packet only specifies the remote > peer's destination port and not the destination IP. This is necessary > for ICE to function. Therefore I do not believe transport mode works > with ICE. > > The latching behavior for listen connections is also broken. This used > to be in TURN too - and was called lockdown. AN attacker can send a > faked UDP packet with no credentials and cause the legitimate peer to be > blocked. We discarded this approach years ago for this reason. > > I believe the demultiplexing is broken. The draft says that, after an > allocation is done, STUN and app data are demuxed by sending STUN within > the native encapsulation, but using the default TWIST port. This is > broken for two reasons. Firstly, it doesn't work if you want to > communicate with the peer on its twist port. Second and more > importantly, there can still be retransmissions of the original > UNENCAPSULATED stun packets. This means the relay needs to demux STUN > and UDP, which cannot be reliably done. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 20:36:44 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3390228C4E3; Wed, 2 Apr 2008 20:36:44 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C5928C492 for ; Wed, 2 Apr 2008 20:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mq-XGDDkpuXW for ; Wed, 2 Apr 2008 20:36:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 9C66228C4D9 for ; Wed, 2 Apr 2008 20:35:08 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 2 Apr 2008 23:34:44 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 2 Apr 2008 23:34:44 -0400 From: Hadriel Kaplan To: Philip Matthews , Behave WG Date: Wed, 2 Apr 2008 23:34:43 -0400 Thread-Topic: [BEHAVE] ALTERNATE-SERVER and anycast Thread-Index: AciVMYHbByxQ8dCMTXSIrR6iJ2UUAQAARI0g Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Mark Townsley , David R Oran , Ward , David@core3.amsl.com Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I am in still in favor of it, specifically for anycast support. Can you describe the cases it won't be delivered to the same instance that you've been told of? In my experience (which was many years in the L3 routing world, fwiw, but nowhere near as much as either of the Dave's left pinkies), anycasting fails to deliver a packet to the same server "instance" for one of two reasons I can think of off the top of my head: 1) The network topology changes, for example the routing cost to an instance's prefix changes, or an L3 protection mechanism kicked in and temporarily selected a higher-cost path, or whatever. 2) A router or some middle-box is doing some form of load-balancing. For (1), it is either a transient rare event (from our use-case timescale perspective) which stabilizes, which won't matter for this use-case; or it is due to a route flap event, and route flaps take enough time to flap again, in 99% of the cases, that for this use-case timescale it won't matter. Just as long as the mechanism is resilient to the event occurring once in its full handshake - in other words, so long as the second-trip can fail to reach the same server instance but that just triggers another round-trip restart, then (1) isn't an issue for a massive probability. I think that is the case for ALT-SERVER use, right? That it survives such a thing happening gracefully? For (2), all such modern equipment I know of performs hashing or some form of keeping the same "flows" going to the same specific L3 next-hops, and do so using at least IP-dest in their decision, or IP-dest+source, or more, such that any flows to the same anycast dest address will get to the same instance virtually all of the time. Having said that, there have been some (rather infamous) cases of ECMP or L3 load-balancing in routers which did NOT follow that model, and forwarded packets in a round-robin fashion, but I was under the impression they got "called-out" and all their hardware has since been upgraded to fix it years ago. And when I say "anycast", I mean an IPv4 unicast address/prefix that happens to be a virtual shared address for multiple hosts, and advertised into the routing topology from multiple physical locations - I do not mean IPv6 true anycasting, and I have no idea what the modern equipment does for that or if it matters. (I've been out of routing for several years) Regardless, I think all we need is a graceful way for the client to detect a pathological condition, should the worst happen. (ie, a way for it to give up re-tries and use an alternate server altogether) No? -hadriel > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Philip Matthews > Sent: Wednesday, April 02, 2008 10:22 PM > To: Behave WG > Cc: Mark Townsley; David R Oran; David Ward > Subject: [BEHAVE] ALTERNATE-SERVER and anycast > > At the last BEHAVE meeting, it was suggested that one use of ALTERNATE- > SERVER was to support anycast discovery of TURN servers. I have been > doing some inquiries, and it seems that there might be a problem with > this idea. > > The way I had been thinking this would work is that a client would > send an Allocate request to an anycast address, and would receive an > error response back with an error code of 300 Try Alternative and an > ALTERNATE-SERVER attribute giving the unicast address of the server to > contact. > > The problem is that it seems there is no guarantee that two > consecutive packets will be delivered to the same anycast server. The > only thing that is guaranteed is a single round-trip exchange[1]. This > means that the above idea does not work because: > a) It is not possible to contact an anycast TURN server using TCP or > TLS over TCP, since the handshake will not necessarily complete with > the same server. > b) It is also not possible to contact an anycast TURN server using > UDP, since STUN says that an ALTERNATE-SERVER reply must be > authenticated, and authentication in TURN requires a 4-packet exchange. > > So this straight-forward method of doing anycast lookup in TURN does > not seem to work. > > There are probably ways to fix this by changing how ALTENATE-SERVER > works in TURN, but I am currently inclined to forget about anycast for > TURN right now, and let someone add it later. > > Comments? > > - Philip > > [1] Private info received from David Oran. I have asked for a public > reference. > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 21:21:50 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63C1A3A69AE; Wed, 2 Apr 2008 21:21:50 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB97E3A69AE for ; Wed, 2 Apr 2008 21:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.554 X-Spam-Level: X-Spam-Status: No, score=-4.554 tagged_above=-999 required=5 tests=[AWL=1.745, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EG-jBPiBwxq for ; Wed, 2 Apr 2008 21:21:48 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id CE4633A6768 for ; Wed, 2 Apr 2008 21:21:47 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m334Lhqt015182; Thu, 3 Apr 2008 07:21:44 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 07:21:37 +0300 Received: from esdhcp04036.research.nokia.com ([172.21.40.36]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 07:21:36 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia Devices R&D To: "ext Hadriel Kaplan" Date: Thu, 3 Apr 2008 07:22:10 +0300 User-Agent: KMail/1.9.9 References: <1879720d0804020322l1d647f28rdd9d5ccb234cea90@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804030722.10456.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 03 Apr 2008 04:21:36.0842 (UTC) FILETIME=[34ED82A0:01C89542] X-Nokia-AV: Clean Cc: "behave@ietf.org" , Philip Matthews Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Wednesday 02 April 2008 18:18:29 ext Hadriel Kaplan, vous avez =E9crit= =A0: > I *never* said I don't care if TWIST is implementable in a client. I said > I don't care *how* it works in a client - i.e., I don't personally care > about the implementation details of shims vs. stacks vs. whatever. I most > certainly *do* care that clients be able to implement it, and obviously t= he > more easily/simpler the better. I understand. But I am concerned that TWIST would become to TURN, what IPsec has become t= o = TLS. Both are "implementable" and provide the same feature (relaying resp. = authentication+confidentiality). But one is difficult for software vendors = to = integrate due to not stacking up nicely with the existing APIs, while the = other one is easy. Guess which one is being used... I think we need to make a tradeoff, or better yet, try to make the protocol = simple and scalable on both sides. That's one of the reason I like the N:N = idea for TCP relaying. -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 21:23:30 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF4E28C4C8; Wed, 2 Apr 2008 21:23:30 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F1B28C492 for ; Wed, 2 Apr 2008 21:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkatReswhvtm for ; Wed, 2 Apr 2008 21:23:28 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 8D30928C4D9 for ; Wed, 2 Apr 2008 21:23:28 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m334N1xc008039; Thu, 3 Apr 2008 07:23:26 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 07:23:26 +0300 Received: from esdhcp04036.research.nokia.com ([172.21.40.36]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 07:23:25 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia Devices R&D To: "ext Hadriel Kaplan" Date: Thu, 3 Apr 2008 07:23:59 +0300 User-Agent: KMail/1.9.9 References: <6D4E88C6-D37E-44BF-87B2-AA7E91639A04@magma.ca> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804030723.59496.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 03 Apr 2008 04:23:25.0887 (UTC) FILETIME=[75EC74F0:01C89542] X-Nokia-AV: Clean Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Wednesday 02 April 2008 20:26:47 ext Hadriel Kaplan, vous avez =E9crit= =A0: > > -----Original Message----- > > From: Philip Matthews [mailto:philip_matthews@magma.ca] > > Sent: Wednesday, April 02, 2008 11:26 AM > > > > Regarding finishing TURN. Indeed, TURN has been very unstable for a > > long time, so it has not been a very good candidate for stable trial > > implementations. However, the authors are working hard to try to > > finish TURN as fast as possible, since it is the last piece holding > > back ICE from publication as an RFC. > > Whoah. Why is draft-ietf-behave-turn delaying ICE??? I mean I see it in > the normative section, and I see it riddled throughout the ICE doc. Hmm. = > Too bad ICE wasn't written to describe just using a relayed address gotten > through some relay means, a possible one being TURN, and leave it at that. > :( I had been complaining about this a while ago. The answer was that there needs to be at least one normative relay protocol = for the "relay" candidates to make sense (not_ that I was convinced by this = argument). -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 21:32:03 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29DA83A69A6; Wed, 2 Apr 2008 21:32:03 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF4C63A69A6 for ; Wed, 2 Apr 2008 21:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.822 X-Spam-Level: X-Spam-Status: No, score=-4.822 tagged_above=-999 required=5 tests=[AWL=1.477, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xL+qXNiTYUzW for ; Wed, 2 Apr 2008 21:32:00 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 798B43A67EE for ; Wed, 2 Apr 2008 21:32:00 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m334VYAt015217; Thu, 3 Apr 2008 07:31:56 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 07:31:50 +0300 Received: from esdhcp04036.research.nokia.com ([172.21.40.36]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 07:31:50 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia Devices R&D To: behave@ietf.org Date: Thu, 3 Apr 2008 07:32:23 +0300 User-Agent: KMail/1.9.9 References: <47F3FA30.2060403@acm.org> In-Reply-To: <47F3FA30.2060403@acm.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804030732.23763.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 03 Apr 2008 04:31:50.0100 (UTC) FILETIME=[A2754140:01C89543] X-Nokia-AV: Clean Subject: Re: [BEHAVE] IPv4/IPv6 relayed address allocation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Thursday 03 April 2008 00:27:12 ext Marc Petit-Huguenin, vous avez =E9cr= it=A0: > I think that I found a contradiction between turn-07 and turn-ipv6-04: > > In turn-07 section 6.2, "When allocating a relayed transport address for > the allocation, the server MUST allocate an IP address of the same > family (e.g, IPv4 vs. IPv6) as the server's transport address." > > In turn-ipv6 section 5.1, "If the REQUESTED-ADDRESS-TYPE attribute is > absent, the server MUST allocate a IPv4 transport address to the TURN > client." > > My understanding before trying to implement turn-07 was that TURN > without turn-ipv6 always allocates an IPv4 relayed transport address - > in other words that a REQUESTED-ADDRESS-TYPE with a family value equals > to 0x01 is equivalent to no REQUESTED-ADDRESS-TYPE. > > Who's right? IMHO, I think TURN-07 is wrong and TURN-IPv6 is right. The relay cannot know if there was a protocol translator in the middle, so = that would be the only way to obtain sane defaults. So either the client must always explicitly specify the address family, or = the = default should be independent of the relay-reflexive address of the client. My 2 yens (almost 2 cents, right) -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 21:59:25 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5EDB3A6BAF; Wed, 2 Apr 2008 21:59:25 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB0D73A6BAF for ; Wed, 2 Apr 2008 21:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukVAXzwkSnrl for ; Wed, 2 Apr 2008 21:59:23 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C26913A68F6 for ; Wed, 2 Apr 2008 21:59:23 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 3 Apr 2008 00:58:59 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 3 Apr 2008 00:58:57 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= Date: Thu, 3 Apr 2008 00:58:57 -0400 Thread-Topic: [BEHAVE] Goals for the proposed conf call on TURN encapsulations Thread-Index: AciVQizx0KrGA1/FTJ+OveLCgHpsWwAAyXqw Message-ID: References: <1879720d0804020322l1d647f28rdd9d5ccb234cea90@mail.gmail.com> <200804030722.10456.remi.denis-courmont@nokia.com> In-Reply-To: <200804030722.10456.remi.denis-courmont@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "behave@ietf.org" , Philip Matthews Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com] > > But I am concerned that TWIST would become to TURN, what IPsec has become > to > TLS. Both are "implementable" and provide the same feature (relaying resp. > authentication+confidentiality). But one is difficult for software vendors > to > integrate due to not stacking up nicely with the existing APIs, while the > other one is easy. > > Guess which one is being used... Ummm... BOTH!?! They have different market use cases, and both are WILDLY = successful. Are you claiming IPSEC is not??? (and we're talking here VPN = technologies I assume, not HTTP/application protection technologies, for wh= ich IPSEC does not even apply usually) As an aside, do you ever wonder why 3GPP is so fixated on IPSEC as its favo= rite encryption mechanism, even for SIP? Hint: It's not because they don't= know about TLS, or think it's easy for the client, afaik. -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 22:10:59 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737E928C137; Wed, 2 Apr 2008 22:10:59 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C133A6831 for ; Wed, 2 Apr 2008 22:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.928 X-Spam-Level: X-Spam-Status: No, score=-4.928 tagged_above=-999 required=5 tests=[AWL=1.371, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldx54dhBN8vT for ; Wed, 2 Apr 2008 22:10:57 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id BB0EC28C3F6 for ; Wed, 2 Apr 2008 22:10:12 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m335CH4c002947; Thu, 3 Apr 2008 00:12:22 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 08:09:56 +0300 Received: from esdhcp04036.research.nokia.com ([172.21.40.36]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 08:09:56 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia Devices R&D To: "ext Hadriel Kaplan" Date: Thu, 3 Apr 2008 08:10:29 +0300 User-Agent: KMail/1.9.9 References: <200804030722.10456.remi.denis-courmont@nokia.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804030810.30115.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 03 Apr 2008 05:09:56.0258 (UTC) FILETIME=[F51D4820:01C89548] X-Nokia-AV: Clean Cc: "behave@ietf.org" , Philip Matthews Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Thursday 03 April 2008 07:58:57 ext Hadriel Kaplan, vous avez =E9crit=A0: > As an aside, do you ever wonder why 3GPP is so fixated on IPSEC as its > favorite encryption mechanism, even for SIP? Hint: It's not because they > don't know about TLS, or think it's easy for the client, afaik. Because they hold for a fact that TCP does not scale, so they have to use U= DP, = so no TLS. -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 2 22:13:47 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 964ED3A6845; Wed, 2 Apr 2008 22:13:47 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1013A6F31 for ; Wed, 2 Apr 2008 22:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVxIImXtLFqa for ; Wed, 2 Apr 2008 22:13:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CAA403A6831 for ; Wed, 2 Apr 2008 22:13:45 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 3 Apr 2008 01:13:21 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 3 Apr 2008 01:13:21 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= Date: Thu, 3 Apr 2008 01:13:21 -0400 Thread-Topic: [BEHAVE] Goals for the proposed conf call on TURN encapsulations Thread-Index: AciVSPEnUpNTe2roTe+4mto9gQiWugAAKjtQ Message-ID: References: <200804030722.10456.remi.denis-courmont@nokia.com> <200804030810.30115.remi.denis-courmont@nokia.com> In-Reply-To: <200804030810.30115.remi.denis-courmont@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "behave@ietf.org" , Philip Matthews Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com] > > Le Thursday 03 April 2008 07:58:57 ext Hadriel Kaplan, vous avez =E9crit : > > As an aside, do you ever wonder why 3GPP is so fixated on IPSEC as its > > favorite encryption mechanism, even for SIP? Hint: It's not because > they > > don't know about TLS, or think it's easy for the client, afaik. > > Because they hold for a fact that TCP does not scale, so they have to use > UDP, > so no TLS. Yup. -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 03:09:42 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3037B28C344; Thu, 3 Apr 2008 03:09:42 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B45628C569 for ; Thu, 3 Apr 2008 03:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siiVgeYEw6cT for ; Thu, 3 Apr 2008 03:09:32 -0700 (PDT) Received: from oslproxyp1.tandberg.com (oslproxyp1.tandberg.com [194.0.215.2]) by core3.amsl.com (Postfix) with ESMTP id 2C81B28C1DE for ; Thu, 3 Apr 2008 03:09:31 -0700 (PDT) Received: from OSLEXCP11.eu.tandberg.int (oslexcp11.eu.tandberg.int [10.47.136.43]) by oslproxyp1.tandberg.com (8.13.1/8.13.1) with ESMTP id m33A7qdq006843; Thu, 3 Apr 2008 12:08:01 +0200 Received: from oslexcp9.eu.tandberg.int ([194.0.215.7]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 12:06:55 +0200 Received: from [10.47.5.172] ([10.47.5.172]) by oslexcp9.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 12:06:54 +0200 Message-ID: <47F4AC3E.7080107@tandberg.com> Date: Thu, 03 Apr 2008 12:06:54 +0200 From: =?ISO-8859-1?Q?P=E5l-Erik_Martinsen?= User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Marc Petit-Huguenin References: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> <6D4E88C6-D37E-44BF-87B2-AA7E91639A04@magma.ca> <47F3B3E1.6080607@acm.org> <47F3BB1F.5080100@tandberg.com> <47F3D094.5060607@acm.org> In-Reply-To: <47F3D094.5060607@acm.org> X-OriginalArrivalTime: 03 Apr 2008 10:06:54.0764 (UTC) FILETIME=[71C586C0:01C89572] X-Scanned-By: MIMEDefang 2.62 on 194.0.215.2 Cc: Behave WG Subject: Re: [BEHAVE] Goals for the proposed conf call on TURN encapsulations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Marc Petit-Huguenin wrote: [snip] > P=E5l-Erik Martinsen wrote: > = >> >> I have not given up! >> Just finished a TURN-07 client implementation. >> >> I have not implemented the REQUESTED-PROPS attribute. Further down the >> road ICE will need explicit rtcp-port signalling in the SDP anyway. >> = > > Isn't what RFC 3605 do? > > = Yes, you are right. So to be more precise; I did not consider supporting a call from my endpoint through a TURN relay to an endpoint on a public IP not supporting RFC3605 as something I need to support in my first release. If it turn out otherwise I will add it. .-. P=E5l-Erik _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 03:52:32 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDAE43A6BC9; Thu, 3 Apr 2008 03:52:32 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB75D28C5E0 for ; Thu, 3 Apr 2008 03:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.018 X-Spam-Level: X-Spam-Status: No, score=-3.018 tagged_above=-999 required=5 tests=[AWL=3.581, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Q3U4Ccnnl72 for ; Thu, 3 Apr 2008 03:52:27 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 5C7903A6ACA for ; Thu, 3 Apr 2008 03:52:27 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 03 Apr 2008 03:52:30 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m33AqUIf018236; Thu, 3 Apr 2008 03:52:30 -0700 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.13.8/8.13.8) with SMTP id m33AqUXZ005273; Thu, 3 Apr 2008 10:52:30 GMT Message-Id: <0C580D3D-27FD-4E56-9450-0AE3286E2037@cisco.com> From: Cullen Jennings To: Philip Matthews In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 03:54:18 -0700 References: X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3840; t=1207219950; x=1208083950; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20ALTERNATE-SERVER=20and=20anycast |Sender:=20; bh=Eu90AiatdSesR3qF+jNw4bWsn4u3kHBPM3Pgll9gPcU=; b=j0vVcRvu4pvTQkJ3GxlkZzswG6+ROeUS4eFJCOthUBctII6TL+EiokJn4Q myVbXEi1i1IWGdI/8fVNFhyeWtaNRAnHpAcBvCnamA+mXCQud1Rp+pkKfBu8 d3fAlK5uZ2ThrwAb3XfJfrljMrYBWfUGffniu8Z/20w5DSRlyFl8g=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "Dave Oran \(oran\)" , Behave WG , David Ward , "Mark Townsley \(townsley\)" Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Apr 2, 2008, at 7:22 PM, Philip Matthews wrote: > At the last BEHAVE meeting, it was suggested that one use of > ALTERNATE- > SERVER was to support anycast discovery of TURN servers. I have been > doing some inquiries, and it seems that there might be a problem with > this idea. > > The way I had been thinking this would work is that a client would > send an Allocate request to an anycast address, and would receive an > error response back with an error code of 300 Try Alternative and an > ALTERNATE-SERVER attribute giving the unicast address of the server to > contact. > > The problem is that it seems there is no guarantee that two > consecutive packets will be delivered to the same anycast server. The > only thing that is guaranteed is a single round-trip exchange[1]. This > means that the above idea does not work because: > a) It is not possible to contact an anycast TURN server using TCP or > TLS over TCP, since the handshake will not necessarily complete with > the same server. > b) It is also not possible to contact an anycast TURN server using > UDP, since STUN says that an ALTERNATE-SERVER reply must be > authenticated, and authentication in TURN requires a 4-packet > exchange. > > So this straight-forward method of doing anycast lookup in TURN does > not seem to work. > > There are probably ways to fix this by changing how ALTENATE-SERVER > works in TURN, but I am currently inclined to forget about anycast for > TURN right now, and let someone add it later. > > Comments? > Sure, what you are proposing here won't work for the reasons you point out. I don't know when the WG decided the ALTERNATIVE-ERVER reply MUST be authenticated but that seems like it is not going to work for anycast. There are more than a few things wrong with this - for one I suspect the authentication you are talking about is for the server to authenticate the client not for the client to authenticate the server. As an alternative you might want to consider is something like what I had previously email you - I'm sure lots of other ways would work too and I don't really care which way we do it. No doubt the thing I emailed has some issues that would need to be worked out but I think it is closer to working. On Apr 2, 2008, at 3:41 PM, Cullen Jennings wrote: > > > 1) client is configured with TURN server of turn.example.com > > 2) client does an SRV lookup and finds there is no TCP service but > there is a UDP service at 1.1.1.1 > > 3) client sends an UDP packet to 1.1.1.1 which happens to be an > anycast IP. > > 4) Some server gets this and responds with a redirect to 2.2.2.2 > along with info to use TLS. The address 2.2.2.2 is not an anycast > address but goes to a single machine with a TURN server > > 5) client does TLS to 2.2.2.2. Server presents certificate with name > turn.example.com > > 6) client check certificate matches the name that it has in it's > config. > > This approach is susceptible to being DOSed by a well timed response > to the UDP request to 1.1.1.1 but seemed like a risk we were willing > to live with. Presumably some secret material would be copied from > request in step 3 to the response in step 4 to force the attacker to > be on-path. If the client doesn't care about server authentication, then it can ignore TLS and do much the same with just UDP. It's going to be very difficult to add something like this in later so I would argue we should deal with having at least enough placeholders in the base draft that we can add it later - to do this we will likely need to figure it out well enough that we should just add it to the base draft instead of trying to do it as an extension. Cullen _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 06:21:29 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8083028C44D; Thu, 3 Apr 2008 06:21:29 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C595F28C1B6 for ; Thu, 3 Apr 2008 06:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jia1DVD9fBwV for ; Thu, 3 Apr 2008 06:21:23 -0700 (PDT) Received: from mail-08.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 1B2E628C15E for ; Thu, 3 Apr 2008 06:21:22 -0700 (PDT) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JhPNc-0008Sy-22; Thu, 03 Apr 2008 09:21:25 -0400 Message-Id: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> From: Philip Matthews To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 09:21:23 -0400 References: X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Cc: Mark Townsley , Behave WG , David Ward , David R Oran Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I am still trying to dig into the reasons the experts think that multi- packet exchanges won't work. My initial reaction is exactly the same as yours. However, I also wondering how keen people are to have anycast support in TURN? I have heard that there is a draft in preparation that will discuss anycast discovery of servers, but it won't be out for a month or so, and after that there will presumably be some debate on the details. So this may turn out to be an area where there is not yet IETF consensus. If this is the case, are people willing to delay the TURN draft while we sort out the anycast details? - Philip On Wed, 2-Apr-08, at 23:34 , Hadriel Kaplan wrote: > > I am in still in favor of it, specifically for anycast support. > > Can you describe the cases it won't be delivered to the same > instance that you've been told of? In my experience (which was many > years in the L3 routing world, fwiw, but nowhere near as much as > either of the Dave's left pinkies), anycasting fails to deliver a > packet to the same server "instance" for one of two reasons I can > think of off the top of my head: > 1) The network topology changes, for example the routing cost > to an instance's prefix changes, or an L3 protection mechanism > kicked in and temporarily selected a higher-cost path, or whatever. > 2) A router or some middle-box is doing some form of load- > balancing. > > For (1), it is either a transient rare event (from our use-case > timescale perspective) which stabilizes, which won't matter for this > use-case; or it is due to a route flap event, and route flaps take > enough time to flap again, in 99% of the cases, that for this use- > case timescale it won't matter. Just as long as the mechanism is > resilient to the event occurring once in its full handshake - in > other words, so long as the second-trip can fail to reach the same > server instance but that just triggers another round-trip restart, > then (1) isn't an issue for a massive probability. I think that is > the case for ALT-SERVER use, right? That it survives such a thing > happening gracefully? > > For (2), all such modern equipment I know of performs hashing or > some form of keeping the same "flows" going to the same specific L3 > next-hops, and do so using at least IP-dest in their decision, or IP- > dest+source, or more, such that any flows to the same anycast dest > address will get to the same instance virtually all of the time. > Having said that, there have been some (rather infamous) cases of > ECMP or L3 load-balancing in routers which did NOT follow that > model, and forwarded packets in a round-robin fashion, but I was > under the impression they got "called-out" and all their hardware > has since been upgraded to fix it years ago. And when I say > "anycast", I mean an IPv4 unicast address/prefix that happens to be > a virtual shared address for multiple hosts, and advertised into the > routing topology from multiple physical locations - I do not mean > IPv6 true anycasting, and I have no idea what the modern equipment > does for that or if it matters. (I've been out of routing for > several years) > > Regardless, I think all we need is a graceful way for the client to > detect a pathological condition, should the worst happen. (ie, a way > for it to give up re-tries and use an alternate server altogether) > No? > > -hadriel > >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf >> Of Philip Matthews >> Sent: Wednesday, April 02, 2008 10:22 PM >> To: Behave WG >> Cc: Mark Townsley; David R Oran; David Ward >> Subject: [BEHAVE] ALTERNATE-SERVER and anycast >> >> At the last BEHAVE meeting, it was suggested that one use of >> ALTERNATE- >> SERVER was to support anycast discovery of TURN servers. I have been >> doing some inquiries, and it seems that there might be a problem with >> this idea. >> >> The way I had been thinking this would work is that a client would >> send an Allocate request to an anycast address, and would receive an >> error response back with an error code of 300 Try Alternative and an >> ALTERNATE-SERVER attribute giving the unicast address of the server >> to >> contact. >> >> The problem is that it seems there is no guarantee that two >> consecutive packets will be delivered to the same anycast server. The >> only thing that is guaranteed is a single round-trip exchange[1]. >> This >> means that the above idea does not work because: >> a) It is not possible to contact an anycast TURN server using TCP or >> TLS over TCP, since the handshake will not necessarily complete with >> the same server. >> b) It is also not possible to contact an anycast TURN server using >> UDP, since STUN says that an ALTERNATE-SERVER reply must be >> authenticated, and authentication in TURN requires a 4-packet >> exchange. >> >> So this straight-forward method of doing anycast lookup in TURN does >> not seem to work. >> >> There are probably ways to fix this by changing how ALTENATE-SERVER >> works in TURN, but I am currently inclined to forget about anycast >> for >> TURN right now, and let someone add it later. >> >> Comments? >> >> - Philip >> >> [1] Private info received from David Oran. I have asked for a public >> reference. >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 06:43:14 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468AE28C678; Thu, 3 Apr 2008 06:43:14 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE7A28C0E8 for ; Thu, 3 Apr 2008 06:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=0.844, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8B-SjBObB3EP for ; Thu, 3 Apr 2008 06:43:08 -0700 (PDT) Received: from mail-08.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id B48DE28C686 for ; Thu, 3 Apr 2008 06:43:07 -0700 (PDT) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JhPig-0001yH-2P; Thu, 03 Apr 2008 09:43:11 -0400 Message-Id: From: Philip Matthews To: Cullen Jennings In-Reply-To: <0C580D3D-27FD-4E56-9450-0AE3286E2037@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 09:43:09 -0400 References: <0C580D3D-27FD-4E56-9450-0AE3286E2037@cisco.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Cc: "Dave Oran \(oran\)" , Behave WG , David Ward , "Mark Townsley \(townsley\)" Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Thu, 3-Apr-08, at 06:54 , Cullen Jennings wrote: > > On Apr 2, 2008, at 7:22 PM, Philip Matthews wrote: >> At the last BEHAVE meeting, it was suggested that one use of >> ALTERNATE- >> SERVER was to support anycast discovery of TURN servers. I have been >> doing some inquiries, and it seems that there might be a problem with >> this idea. >> >> The way I had been thinking this would work is that a client would >> send an Allocate request to an anycast address, and would receive an >> error response back with an error code of 300 Try Alternative and an >> ALTERNATE-SERVER attribute giving the unicast address of the server >> to >> contact. >> >> The problem is that it seems there is no guarantee that two >> consecutive packets will be delivered to the same anycast server. The >> only thing that is guaranteed is a single round-trip exchange[1]. >> This >> means that the above idea does not work because: >> a) It is not possible to contact an anycast TURN server using TCP or >> TLS over TCP, since the handshake will not necessarily complete with >> the same server. >> b) It is also not possible to contact an anycast TURN server using >> UDP, since STUN says that an ALTERNATE-SERVER reply must be >> authenticated, and authentication in TURN requires a 4-packet >> exchange. >> >> So this straight-forward method of doing anycast lookup in TURN does >> not seem to work. >> >> There are probably ways to fix this by changing how ALTENATE-SERVER >> works in TURN, but I am currently inclined to forget about anycast >> for >> TURN right now, and let someone add it later. >> >> Comments? >> > Sure, what you are proposing here won't work for the reasons you > point out. I don't know when the WG decided the ALTERNATIVE-ERVER > reply MUST be authenticated but that seems like it is not going to > work for anycast. Sorry. I should have provided a reference. draft-ietf- behave-3489bis-15, section 11 says: 11. ALTERNATE-SERVER Mechanism This section describes a mechanism in STUN that allows a server to redirect a client to another server. This extension is optional, and a usage must define if and when this extension is used. To prevent denial-of-service attacks, this extension MUST only be used in situations where the client and server are using an authentication and message-integrity mechanism. A server using this extension redirects a client to another server by replying to a request message with an error response message with an error code of 300 (Try Alternate). The server MUST include a ALTERNATE-SERVER attribute in the error response. The error response message MUST be authenticated, which in practice means the request message must have passed the authentication checks. [Rest of section omitted] > There are more than a few things wrong with this - for one I suspect > the authentication you are talking about is for the server to > authenticate the client not for the client to authenticate the > server. As an alternative you might want to consider is something > like what I had previously email you - I'm sure lots of other ways > would work too and I don't really care which way we do it. No doubt > the thing I emailed has some issues that would need to be worked out > but I think it is closer to working. > > On Apr 2, 2008, at 3:41 PM, Cullen Jennings wrote: >> >> >> 1) client is configured with TURN server of turn.example.com >> >> 2) client does an SRV lookup and finds there is no TCP service but >> there is a UDP service at 1.1.1.1 >> >> 3) client sends an UDP packet to 1.1.1.1 which happens to be an >> anycast IP. >> >> 4) Some server gets this and responds with a redirect to 2.2.2.2 >> along with info to use TLS. The address 2.2.2.2 is not an anycast >> address but goes to a single machine with a TURN server >> >> 5) client does TLS to 2.2.2.2. Server presents certificate with >> name turn.example.com >> >> 6) client check certificate matches the name that it has in it's >> config. >> >> This approach is susceptible to being DOSed by a well timed >> response to the UDP request to 1.1.1.1 but seemed like a risk we >> were willing to live with. Presumably some secret material would be >> copied from request in step 3 to the response in step 4 to force >> the attacker to be on-path. > > > If the client doesn't care about server authentication, then it can > ignore TLS and do much the same with just UDP. > > It's going to be very difficult to add something like this in later > so I would argue we should deal with having at least enough > placeholders in the base draft that we can add it later - to do this > we will likely need to figure it out well enough that we should just > add it to the base draft instead of trying to do it as an extension. > > Cullen This works if the client can contact the server using both UDP and TCP. As you know, we are separately discussing the case of a client that can only contact TURN servers using TCP -- this is the proposed justification for TCP transport for a UDP allocation. If we decide to keep TCP transport for a UDP allocation (and right now, I am seeing more support for keeping it than dropping it -- but we will discuss this next week on the conf call), then I have a problem with something like this as the proposed anycast solution. I will note that there are a couple of ways to achieve something very similar to this without using anycast. The first option is that 1.1.1.1 is not an anycast address, but is a unicast address of a TURN server that doesn't actually accept allocations, but always redirects clients to other servers (using ALTERNATE-SERVER). The second is to use DNS to direct the client to a closer or otherwise appropriate server. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 07:22:35 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0B9728C64F; Thu, 3 Apr 2008 07:22:35 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD41328C64B for ; Thu, 3 Apr 2008 07:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.615 X-Spam-Level: X-Spam-Status: No, score=-3.615 tagged_above=-999 required=5 tests=[AWL=2.984, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPqyMZrz1WOR for ; Thu, 3 Apr 2008 07:22:33 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 659D628C226 for ; Thu, 3 Apr 2008 07:22:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,599,1199692800"; d="scan'208";a="10154191" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 03 Apr 2008 07:22:36 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m33EMZjF015176; Thu, 3 Apr 2008 07:22:35 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.13.8/8.13.8) with SMTP id m33EMZ2U022636; Thu, 3 Apr 2008 14:22:35 GMT From: Cullen Jennings To: Philip Matthews In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: <0C580D3D-27FD-4E56-9450-0AE3286E2037@cisco.com> Message-Id: <4E07EE1A-330E-4457-9F5C-16E5A265E0E5@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 07:22:16 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6769; t=1207232555; x=1208096555; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20ALTERNATE-SERVER=20and=20anycast |Sender:=20; bh=gfQhEHbUQhFVp/OtMDMB3OjMHgYEBMkVAczCogm0Wfs=; b=M1jY9vzW1VZBX9zPsop5P6DytXputECkDPV9NLCKv3/tDdZbW/Nz+ThyrW YW/84EhZtnyEiOycSgFnxPT4la5QhAC4ItKFx3NZHWpaADsyzfKzIASc7Vef EVhCXBMFzG; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "Dave Oran \(oran\)" , Behave WG , David Ward , "Mark Townsley \(townsley\)" Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Apr 3, 2008, at 6:43 AM, Philip Matthews wrote: > > On Thu, 3-Apr-08, at 06:54 , Cullen Jennings wrote: > > > > On Apr 2, 2008, at 7:22 PM, Philip Matthews wrote: > >> At the last BEHAVE meeting, it was suggested that one use of > >> ALTERNATE- > >> SERVER was to support anycast discovery of TURN servers. I have > been > >> doing some inquiries, and it seems that there might be a problem > with > >> this idea. > >> > >> The way I had been thinking this would work is that a client would > >> send an Allocate request to an anycast address, and would receive > an > >> error response back with an error code of 300 Try Alternative and > an > >> ALTERNATE-SERVER attribute giving the unicast address of the server > >> to > >> contact. > >> > >> The problem is that it seems there is no guarantee that two > >> consecutive packets will be delivered to the same anycast server. > The > >> only thing that is guaranteed is a single round-trip exchange[1]. > >> This > >> means that the above idea does not work because: > >> a) It is not possible to contact an anycast TURN server using TCP > or > >> TLS over TCP, since the handshake will not necessarily complete > with > >> the same server. > >> b) It is also not possible to contact an anycast TURN server using > >> UDP, since STUN says that an ALTERNATE-SERVER reply must be > >> authenticated, and authentication in TURN requires a 4-packet > >> exchange. > >> > >> So this straight-forward method of doing anycast lookup in TURN > does > >> not seem to work. > >> > >> There are probably ways to fix this by changing how ALTENATE-SERVER > >> works in TURN, but I am currently inclined to forget about anycast > >> for > >> TURN right now, and let someone add it later. > >> > >> Comments? > >> > > Sure, what you are proposing here won't work for the reasons you > > point out. I don't know when the WG decided the ALTERNATIVE-ERVER > > reply MUST be authenticated but that seems like it is not going to > > work for anycast. > > Sorry. I should have provided a reference. draft-ietf- > behave-3489bis-15, section 11 says: > > 11. ALTERNATE-SERVER Mechanism > > This section describes a mechanism in STUN that allows a server to > redirect a client to another server. This extension is optional, > and > a usage must define if and when this extension is used. To > prevent > denial-of-service attacks, this extension MUST only be used in > situations where the client and server are using an authentication > and message-integrity mechanism. > > A server using this extension redirects a client to another server > by > replying to a request message with an error response message > with an > error code of 300 (Try Alternate). The server MUST include a > ALTERNATE-SERVER attribute in the error response. The error > response > message MUST be authenticated, which in practice means the request > message must have passed the authentication checks. > > [Rest of section omitted] > > right - thanks > > There are more than a few things wrong with this - for one I suspect > > the authentication you are talking about is for the server to > > authenticate the client not for the client to authenticate the > > server. As an alternative you might want to consider is something > > like what I had previously email you - I'm sure lots of other ways > > would work too and I don't really care which way we do it. No doubt > > the thing I emailed has some issues that would need to be worked out > > but I think it is closer to working. > > > > On Apr 2, 2008, at 3:41 PM, Cullen Jennings wrote: > >> > >> > >> 1) client is configured with TURN server of turn.example.com > >> > >> 2) client does an SRV lookup and finds there is no TCP service but > >> there is a UDP service at 1.1.1.1 > >> > >> 3) client sends an UDP packet to 1.1.1.1 which happens to be an > >> anycast IP. > >> > >> 4) Some server gets this and responds with a redirect to 2.2.2.2 > >> along with info to use TLS. The address 2.2.2.2 is not an anycast > >> address but goes to a single machine with a TURN server > >> > >> 5) client does TLS to 2.2.2.2. Server presents certificate with > >> name turn.example.com > >> > >> 6) client check certificate matches the name that it has in it's > >> config. > >> > >> This approach is susceptible to being DOSed by a well timed > >> response to the UDP request to 1.1.1.1 but seemed like a risk we > >> were willing to live with. Presumably some secret material would be > >> copied from request in step 3 to the response in step 4 to force > >> the attacker to be on-path. > > > > > > If the client doesn't care about server authentication, then it can > > ignore TLS and do much the same with just UDP. > > > > It's going to be very difficult to add something like this in later > > so I would argue we should deal with having at least enough > > placeholders in the base draft that we can add it later - to do this > > we will likely need to figure it out well enough that we should just > > add it to the base draft instead of trying to do it as an extension. > > > > Cullen > > This works if the client can contact the server using both UDP and > TCP. As you know, we are separately discussing the case of a client > that can only contact TURN servers using TCP -- this is the proposed > justification for TCP transport for a UDP allocation. If we decide to > keep TCP transport for a UDP allocation (and right now, I am seeing > more support for keeping it than dropping it -- but we will discuss > this next week on the conf call), then I have a problem with something > like this as the proposed anycast solution. > > I will note that there are a couple of ways to achieve something very > similar to this without using anycast. The first option is that > 1.1.1.1 is not an anycast address, but is a unicast address of a TURN > server that doesn't actually accept allocations, but always redirects > clients to other servers (using ALTERNATE-SERVER). The second is to > use DNS to direct the client to a closer or otherwise appropriate > server. > The point of the anycast is not to just spread stuff over multiple servers - a DNS A record could do that. The point is to solve in some way the "close" problem where the client ends up using a TURN server that is topologically close to the client. Anycast is a one appealing way to address that. What you are proposing does not seem to address the issues of getting to a TURN server that is topologically close to the client. > > > - Philip > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 07:23:54 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966543A6C28; Thu, 3 Apr 2008 07:23:54 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD613A6C28 for ; Thu, 3 Apr 2008 07:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.845 X-Spam-Level: X-Spam-Status: No, score=-3.845 tagged_above=-999 required=5 tests=[AWL=2.754, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nAcEH+4-AdF for ; Thu, 3 Apr 2008 07:23:52 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 6F7BC3A6BF7 for ; Thu, 3 Apr 2008 07:23:52 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 03 Apr 2008 07:23:56 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m33ENuGw003674; Thu, 3 Apr 2008 07:23:56 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.13.8/8.13.8) with SMTP id m33ENtih023706; Thu, 3 Apr 2008 14:23:55 GMT From: Cullen Jennings To: Philip Matthews In-Reply-To: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> Impp: xmpp:cullenfluffyjennings@jabber.org References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> Message-Id: <3DD057A7-0458-48E2-BEBE-61DBEA1758DF@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 07:23:37 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=481; t=1207232636; x=1208096636; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20ALTERNATE-SERVER=20and=20any cast |Sender:=20; bh=vUjwytpiOGP6OqCZBWoUnDAn6482EH3ZUo8No986CNg=; b=b4dA0XIyms99p5EEaZohEaHi4CKkzJgUoYYGr3X3W9rvi2hAGsaeKkRup8 efJHOMusxiadVjUtQhNTmzRP1SGnuGUGMytogEHN4X5owfjMeZ6bjpS4PDUi 7dRTi449WqiSkoCaYC3wEPoyXHUUw+qZkNkovJMcmUDhb6Hzjt3OI=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Behave WG Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Apr 3, 2008, at 6:21 AM, Philip Matthews wrote: > However, I also wondering how keen people are to have anycast support > in TURN? I have not gone back and listened to the meeting recording from last ietf meeting but my vague recollection was the room wanted to keep ALTERNATVE-SERVER in to support anycast. At this point I think it will just be faster to go do it than argue about if we really want it or not. Cullen _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 07:28:45 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00E033A6CF2; Thu, 3 Apr 2008 07:28:45 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7853A6CD0 for ; Thu, 3 Apr 2008 07:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yC2a-oEj3-Yt for ; Thu, 3 Apr 2008 07:28:42 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 508973A6C88 for ; Thu, 3 Apr 2008 07:28:42 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 7006250854; Thu, 3 Apr 2008 07:30:33 -0700 (PDT) Date: Thu, 03 Apr 2008 07:30:33 -0700 From: Eric Rescorla To: Philip Matthews In-Reply-To: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080403143033.7006250854@romeo.rtfm.com> Cc: Mark Townsley , David R Oran , Behave WG , David Ward Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Thu, 3 Apr 2008 09:21:23 -0400, Philip Matthews wrote: > > I am still trying to dig into the reasons the experts think that multi- > packet exchanges won't work. My initial reaction is exactly the same > as yours. There's nothing complicated here: The Internet routing system does not guarantee that two packets sent to the same anycast address from the same source address will be delivered to the same destination. To the extent to which it's currently the case that that usually happens, that's an artifact of today's routing systems. It's bad practice to design new systems such that they depend on this behavior, because we may wish to change it in the future. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 07:31:51 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008E43A6BC9; Thu, 3 Apr 2008 07:31:51 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6FBB3A683A for ; Thu, 3 Apr 2008 07:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aibYgAW3wNdP for ; Thu, 3 Apr 2008 07:31:48 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id C61413A6D0D for ; Thu, 3 Apr 2008 07:31:47 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 086E650854; Thu, 3 Apr 2008 07:33:39 -0700 (PDT) Date: Thu, 03 Apr 2008 07:33:38 -0700 From: Eric Rescorla To: Philip Matthews In-Reply-To: References: <0C580D3D-27FD-4E56-9450-0AE3286E2037@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080403143339.086E650854@romeo.rtfm.com> Cc: Behave WG , "Dave Oran \(oran\)" , David Ward , "Mark Townsley \(townsley\)" Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Thu, 3 Apr 2008 09:43:09 -0400, Philip Matthews wrote: > > > On Thu, 3-Apr-08, at 06:54 , Cullen Jennings wrote: > > > > On Apr 2, 2008, at 7:22 PM, Philip Matthews wrote: > >> At the last BEHAVE meeting, it was suggested that one use of > >> ALTERNATE- > >> SERVER was to support anycast discovery of TURN servers. I have been > >> doing some inquiries, and it seems that there might be a problem with > >> this idea. > >> > >> The way I had been thinking this would work is that a client would > >> send an Allocate request to an anycast address, and would receive an > >> error response back with an error code of 300 Try Alternative and an > >> ALTERNATE-SERVER attribute giving the unicast address of the server > >> to > >> contact. > >> > >> The problem is that it seems there is no guarantee that two > >> consecutive packets will be delivered to the same anycast server. The > >> only thing that is guaranteed is a single round-trip exchange[1]. > >> This > >> means that the above idea does not work because: > >> a) It is not possible to contact an anycast TURN server using TCP or > >> TLS over TCP, since the handshake will not necessarily complete with > >> the same server. > >> b) It is also not possible to contact an anycast TURN server using > >> UDP, since STUN says that an ALTERNATE-SERVER reply must be > >> authenticated, and authentication in TURN requires a 4-packet > >> exchange. > >> > >> So this straight-forward method of doing anycast lookup in TURN does > >> not seem to work. > >> > >> There are probably ways to fix this by changing how ALTENATE-SERVER > >> works in TURN, but I am currently inclined to forget about anycast > >> for > >> TURN right now, and let someone add it later. > >> > >> Comments? > >> > > Sure, what you are proposing here won't work for the reasons you > > point out. I don't know when the WG decided the ALTERNATIVE-ERVER > > reply MUST be authenticated but that seems like it is not going to > > work for anycast. > > Sorry. I should have provided a reference. draft-ietf- > behave-3489bis-15, section 11 says: > > 11. ALTERNATE-SERVER Mechanism > > This section describes a mechanism in STUN that allows a server to > redirect a client to another server. This extension is optional, > and > a usage must define if and when this extension is used. To prevent > denial-of-service attacks, this extension MUST only be used in > situations where the client and server are using an authentication > and message-integrity mechanism. > > A server using this extension redirects a client to another server > by > replying to a request message with an error response message with an > error code of 300 (Try Alternate). The server MUST include a > ALTERNATE-SERVER attribute in the error response. The error > response > message MUST be authenticated, which in practice means the request > message must have passed the authentication checks. Yeah, but this doesn't contain the actual security requirement, which is that the client be able to get data origin authentication from the server. That does not require anti-replay for the client request but only for the server response. I.e., it does not require a challenge from the server. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 08:27:22 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C531D28C6F8; Thu, 3 Apr 2008 08:27:22 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A169628C6FA for ; Thu, 3 Apr 2008 08:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2Knda9JkvYv for ; Thu, 3 Apr 2008 08:27:21 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C859728C6F7 for ; Thu, 3 Apr 2008 08:27:20 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 3 Apr 2008 11:26:58 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 3 Apr 2008 11:26:57 -0400 From: Hadriel Kaplan To: Eric Rescorla , Philip Matthews Date: Thu, 3 Apr 2008 11:26:55 -0400 Thread-Topic: [BEHAVE] ALTERNATE-SERVER and anycast Thread-Index: AciVl3irfNEqCoa3RpOjaTbmRfz59QABgeuA Message-ID: References: <0C580D3D-27FD-4E56-9450-0AE3286E2037@cisco.com> <20080403143339.086E650854@romeo.rtfm.com> In-Reply-To: <20080403143339.086E650854@romeo.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "Mark Townsley (townsley)" , "Dave Oran (oran)" , Behave WG , Ward , David@core3.amsl.com Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Eric Rescorla > > Yeah, but this doesn't contain the actual security requirement, > which is that the client be able to get data origin authentication > from the server. That does not require anti-replay for the client > request but only for the server response. I.e., it does not require > a challenge from the server. Yeah that section confused me. It said "to prevent denial of service attacks", and I wasn't sure if it meant (a) to prevent a malicious device from spoofing a client, in the hopes of getting the server to send responses to that legitimate client(s); or (b) if it meant to prevent a malicious device from spoofing a server and redirecting clients to bogus addresses. For (a), I thought there was already a transaction-id to prevent that, and if it's resource exhaustion we're worried about, challenging is not going to help. For (b), a server challenge won't stop that (right?), and DNS has this same problem already (sans DNSSEC), so I personally think it's a red herring. It ought to be a MAY strength methinks. -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 08:39:54 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE18528C11E; Thu, 3 Apr 2008 08:39:54 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0FDC3A6BC5 for ; Thu, 3 Apr 2008 08:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.802 X-Spam-Level: X-Spam-Status: No, score=-1.802 tagged_above=-999 required=5 tests=[AWL=0.797, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mOQx1TMh8fi for ; Thu, 3 Apr 2008 08:39:51 -0700 (PDT) Received: from mail-02.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 775723A6AEB for ; Thu, 3 Apr 2008 08:39:50 -0700 (PDT) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JhRXd-0006qA-2b for behave@ietf.org; Thu, 03 Apr 2008 11:39:54 -0400 Message-Id: From: Philip Matthews To: Behave WG In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 11:39:52 -0400 References: X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Subject: Re: [BEHAVE] TURN: Cullen's suggestion for setting the DF bit X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Just a reminder that I am still interested in getting feedback on these options. So far, I have only gotten one response. Not doing any of these is also an option, so feel free to say "I am not interested in this idea". - Philip On Thu, 20-Mar-08, at 17:15 , Philip Matthews wrote: > The proposal described in my e-mail message of 12 March (see the > bottom of this message) was discussed in the BEHAVE session to mostly > favorable reception. However, Cullen suggested a modification that I > would like to get input on. > > At presently envisioned, in a partly-compliant allocation, if the > server cannot read the value of the incoming DF bit, then it SHOULD > clear the DF bit on the outgoing packet. This increases the chances > that a large packet will be successfully delivered to the peer (or > the client). However, this also breaks Path MTU Discovery, which > requires the DF bit to be set. > > Cullen is interested in trying to make Path MTU Discovery work even > for partly-compliant allocations. Here are a couple of options for > doing this: > > 1) [Cullen's proposal] Add a way for the client to indicate, on a per- > packet basis, that the server should set the DF bit when forwarding > the user data to the peer. > This would apply ONLY to Send indications, which would include a bit > that specifies the setting of the DF bit. This bit could either be > contained in a new attribute, or could be one of the 8 currently > unused bits in the PEER-ADDRESS attribute. > > 2) Add a way for the client to indicate that the server should set > the DF bit on ALL packets relayed by the server for this allocation. > This might be done when the allocation is created, using a bit in the > REQUESTED-PROPS attribute. > > 3) Similar to option (2), but settable on a per-peer basis via some > new to-be-defined transaction. > > Option (1) allows the setting on a per-packet basis, but only in the > client-->peer direction. Thus the peer could not do Path MTU > Discovery. > > Option (2) allows the peer to do Path MTU Discovery as well, but > reduces somewhat the chances of a large packet getting through if the > peer chooses not do PMTUD. > > Option (3) sets the DF bit on a per-peer basis, which might be useful > if some peers do PMTUD and others do not. However, it is the most > complex to specify, since it requires a new transaction type. > > What do people think of either of these options? Is anyone besides > Cullen interested in this question? > > Personally, I am leaning slightly towards (2), but have no strong > option. If no one but Cullen cares, then I will probably just drop > this idea entirely. > > - Philip > > > > > On Wed, 12-Mar-08, at 10:43 , Philip Matthews wrote: >> Below is a new proposal for how to handle the IP header fields in >> TURN. This proposal was developed in conjunction with Magnus, Lars, >> and Jonathan. I will be discussing this proposal in the BEHAVE >> meeting on Thursday. >> >> - Philip >> >> >> A UDP allocation is "fully compliant with the TURN IP header >> requirements" if the TURN server sets the fields in the outgoing IP >> header as follows. [Note: Need a better term; suggestions welcome.] >> >> For IPv4: >> * The TTL field is set to (incoming TTL - 1). >> * The ECN field is set to the incoming ECN field UNLESS the server is >> doing Active Queue Management, the incoming ECN field is 01 or 10, >> and the server wishes to indicate that congestion has been >> experienced, in which case it sets the outgoing ECN field to 11. >> * The DSCP field is set to the incoming DSCP UNLESS the server, >> though configuration or other means, believes that a different >> setting is more appropriate. >> * Various fragmentation fields (identification, fragment offset, >> last/ >> more fragments) are set as appropriate for a packet originated by the >> server. [Since the incoming UDP datagram must be re-assembled before >> it can be processed]. >> * The DF field is set to the incoming DF field. >> * The options are empty (i.e., not copied). >> >> For IPv6: >> * The Flow Label field is set to the incoming Flow Label field >> * The treatment of IPv6 extension headers is TBD. >> >> In addition, a "fully compliant" implementation will relay ICMP >> messages between the peer and client. >> >> >> A UDP allocation is only "partly compliant" if it does not set one or >> more of the fields as indicated above, or does not relay ICMP >> messages. >> >> Where possible, a "partly compliant" UDP allocation should set each >> field in the outgoing IP header as described above. Where a specific >> field cannot be set as described above, it SHOULD be set as described >> below. >> >> For IPv4: >> * ECN field: set to 00 (ECN not supported). >> * DSCP field: set to best effort >> * DF field: set to fragmentation allowed >> >> For IPv6: >> TBD >> >> A client SHOULD set the fields in the IP header as directed by the >> local application. If no direction is received, then the fields are >> set as described under the "partly compliant" description above. >> >> Bit 8 (currently unused) in the REQUESTED-PROPS attribute is >> redefined. If this bit is set to 1, then the client is requesting >> that the allocation be fully compliant with the TURN IP header >> requirements. If the server cannot provide an allocation that is >> fully compliant, then the server MUST reject the allocation request. >> It is a "Bad Request" error to set this bit when requesting a non-UDP >> allocation. >> >> >> When should a client request a fully-compliant allocation? >> * When the client wishes to use ECN or a specific DSCP along the >> entire path, OR >> * When the client wishes to determine the precise Path MTU (using >> Packetization Layer PMTUD). >> In general, a client can use a partly-compliant allocation over IPv4 >> if the application is happy with best effort service, does not need >> ECN, and sends only small packets (i.e., less than 576 - > overhead of 32 bytes>). If the application sends larger packets, then >> the packets may get fragmented along the way. This may result in the >> packets being dropped along the path; for example, if fragments are >> delivered out-of-order to certain NATs that do not handle out-of- >> order fragments properly. If the client uses the Packetization Layer >> PMTUD algorithm, then it may not discover the true path MTU, since >> the server may not set the DF bit. In these cases, it will instead >> discover the maximum packet size that will be delivered successfully >> to the peer. >> Some clients and applications that send larger packets may be able to >> operate successfully in these situations. Others may not, and thus >> require a fully-compliant allocation. >> [Any other suggestions for what to say here??] >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 08:47:31 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92D6028C671; Thu, 3 Apr 2008 08:47:31 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0AF428C662 for ; Thu, 3 Apr 2008 08:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jK0v6vGWniOg for ; Thu, 3 Apr 2008 08:47:27 -0700 (PDT) Received: from mail-07.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id C5BD928C66B for ; Thu, 3 Apr 2008 08:47:27 -0700 (PDT) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JhRex-0000mU-0G for behave@ietf.org; Thu, 03 Apr 2008 11:47:27 -0400 Message-Id: <0F2185A7-C2BA-4E21-91E9-9D7AA8797866@magma.ca> From: Philip Matthews To: Behave WG In-Reply-To: <14E3C6BB-4F4D-4A3B-930A-1A7318E7E195@magma.ca> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 11:47:30 -0400 References: <0419099C-4BDE-4C21-BA1C-D67879DFE272@magma.ca> <20080313184352.GA16791@laperouse.bortzmeyer.org> <07997914-A9CA-4C56-8FA0-0C8AB169301B@cisco.com> <14E3C6BB-4F4D-4A3B-930A-1A7318E7E195@magma.ca> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Subject: Re: [BEHAVE] TURN: Proposal for the BANDWIDTH attribute X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org So far, there seems to be consensus to remove this from the base TURN document. Unless I hear strong objections to this, I will remove it from the (upcoming) TURN-08. If desired, it can be advanced as an extension in a separate document at a later date. - Philip On Mon, 24-Mar-08, at 11:06 , Philip Matthews wrote: > Anyone else have any comments on this, either for or against? > - Philip > > On Fri, 21-Mar-08, at 15:57 , Cullen Jennings wrote: >> >> On the topic of the parameter that was formerly known as BANDWIDTH, >> I'm in favor of the moving it to a serrate document. >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 08:49:49 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09C2A28C668; Thu, 3 Apr 2008 08:49:49 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CFB428C6EE for ; Thu, 3 Apr 2008 08:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9-mBCce2iYL for ; Thu, 3 Apr 2008 08:49:44 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 07ADD3A6E09 for ; Thu, 3 Apr 2008 08:49:43 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 2E2935081A; Thu, 3 Apr 2008 08:51:35 -0700 (PDT) Date: Thu, 03 Apr 2008 08:51:34 -0700 From: Eric Rescorla To: Hadriel Kaplan In-Reply-To: References: <0C580D3D-27FD-4E56-9450-0AE3286E2037@cisco.com> <20080403143339.086E650854@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080403155135.2E2935081A@romeo.rtfm.com> Cc: Behave WG , "Dave Oran (oran)" , David@core3.amsl.com, Ward , "Mark Townsley (townsley)" , Philip Matthews Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org sAt Thu, 3 Apr 2008 11:26:55 -0400, Hadriel Kaplan wrote: > > > > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > > Of Eric Rescorla > > > > Yeah, but this doesn't contain the actual security requirement, > > which is that the client be able to get data origin authentication > > from the server. That does not require anti-replay for the client > > request but only for the server response. I.e., it does not require > > a challenge from the server. > > Yeah that section confused me. It said "to prevent denial of > service attacks", and I wasn't sure if it meant (a) to prevent a > malicious device from spoofing a client, in the hopes of getting the > server to send responses to that legitimate client(s); or (b) if it > meant to prevent a malicious device from spoofing a server and > redirecting clients to bogus addresses. >> > For (a), I thought there was already a transaction-id to prevent > that, and if it's resource exhaustion we're worried about, > challenging is not going to help. For (b), a server challenge won't > stop that (right?), and DNS has this same problem already (sans > DNSSEC), so I personally think it's a red herring. It ought to be a > MAY strength methinks. I think your security analysis is right. I'll decline to comment on ought :) -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 09:12:32 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F19B228C5B0; Thu, 3 Apr 2008 09:12:31 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EF2928C649 for ; Thu, 3 Apr 2008 09:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6WqJsuNLmsz for ; Thu, 3 Apr 2008 09:12:28 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 56AD928C66A for ; Thu, 3 Apr 2008 09:11:44 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 3 Apr 2008 12:11:21 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 3 Apr 2008 12:11:19 -0400 From: Hadriel Kaplan To: Eric Rescorla , Philip Matthews Date: Thu, 3 Apr 2008 12:11:16 -0400 Thread-Topic: [BEHAVE] ALTERNATE-SERVER and anycast Thread-Index: AciVlvgmU2Ajw8gsQ2eklst9eURY/AACPx9g Message-ID: References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> In-Reply-To: <20080403143033.7006250854@romeo.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Mark Townsley , Behave WG , Ward , David R Oran , David@core3.amsl.com Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > > At Thu, 3 Apr 2008 09:21:23 -0400, > Philip Matthews wrote: > > > > I am still trying to dig into the reasons the experts think that multi- > > packet exchanges won't work. My initial reaction is exactly the same > > as yours. > > There's nothing complicated here: > The Internet routing system does not guarantee that two packets > sent to the same anycast address from the same source address > will be delivered to the same destination. To the extent to which > it's currently the case that that usually happens, that's an > artifact of today's routing systems. It's bad practice to design > new systems such that they depend on this behavior, because we > may wish to change it in the future. I think they will find all kinds of crap breaking if they try to change that behavior (people do far worse with anycasts than what we're proposing), but ok - would graceful detection and avoidance of such a case resolve this? Like if it's using TCP/TLS, then it's possible the connection establishment will fail, or it's possible a sent request will reset the connection, but that is possible regardless of anycast and needs to be handled. If it's using UDP and a challenge, then the challenge-responding request may well get an error response (e.g., 401 or 438?), and currently I _think_ section 10.2.3 of 3489bis-15 would just have the client keep retrying, which could be bad if anycast is broken - really it could be bad for unicast too (we've had this problem in SIP). So maybe we should put in wording in that section to constrain that failure case, such that it moves on to another server found through SRV or configuration or whatever. For example, if more than three 401 or 438 responses are received without a success response, consider the transaction to have failed without a response and follow section 9: When following these procedures, if the STUN transaction times out without receipt of a response, the client SHOULD retry the request to the next server in the ordered defined by RFC 2782. -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 09:21:37 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 133183A6C2F; Thu, 3 Apr 2008 09:21:37 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3650728C5B4 for ; Thu, 3 Apr 2008 09:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.454 X-Spam-Level: X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJDQ2juceDKW for ; Thu, 3 Apr 2008 09:21:33 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 8717828C696 for ; Thu, 3 Apr 2008 09:21:29 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id E34475081A; Thu, 3 Apr 2008 09:23:20 -0700 (PDT) Date: Thu, 03 Apr 2008 09:23:20 -0700 From: Eric Rescorla To: Hadriel Kaplan In-Reply-To: References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080403162320.E34475081A@romeo.rtfm.com> Cc: Behave WG , David R Oran , David@core3.amsl.com, Ward , Mark Townsley , Philip Matthews Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Thu, 3 Apr 2008 12:11:16 -0400, Hadriel Kaplan wrote: > > > > > -----Original Message----- > > From: Eric Rescorla [mailto:ekr@networkresonance.com] > > > > At Thu, 3 Apr 2008 09:21:23 -0400, > > Philip Matthews wrote: > > > > > > I am still trying to dig into the reasons the experts think that multi- > > > packet exchanges won't work. My initial reaction is exactly the same > > > as yours. > > > > There's nothing complicated here: > > The Internet routing system does not guarantee that two packets > > sent to the same anycast address from the same source address > > will be delivered to the same destination. To the extent to which > > it's currently the case that that usually happens, that's an > > artifact of today's routing systems. It's bad practice to design > > new systems such that they depend on this behavior, because we > > may wish to change it in the future. > > I think they will find all kinds of crap breaking if they try to > change that behavior (people do far worse with anycasts than what > we're proposing), Yes, but at their own risk. That's different from us encouraging it. > but ok - would graceful detection and avoidance of > such a case resolve this? > > Like if it's using TCP/TLS, then it's possible the connection > establishment will fail, or it's possible a sent request will reset > the connection, but that is possible regardless of anycast and needs > to be handled. Right, but it's possible that this will *never* work. Consider a load balancing system that has two paths and uses a packet hash to determine which path it will take. If the SYN and the SYN/ACK end up on different paths, then anycast will totally break the system. You'll not be able to form a TCP connection at all. Maybe I'm missing something, but why use anycast at this layer at all. Wouldn't it be easier to have the TURN servers be unicast and use anycast (or just load balanced) DNS resolution instead, with different servers giving different responses? -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 09:51:45 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFDAC3A6CCF; Thu, 3 Apr 2008 09:51:45 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2A903A6DB6 for ; Thu, 3 Apr 2008 09:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zocPhLqSKAH for ; Thu, 3 Apr 2008 09:51:43 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EC6763A6F73 for ; Thu, 3 Apr 2008 09:51:19 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 3 Apr 2008 12:50:57 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 3 Apr 2008 12:50:57 -0400 From: Hadriel Kaplan To: Eric Rescorla Date: Thu, 3 Apr 2008 12:50:55 -0400 Thread-Topic: [BEHAVE] ALTERNATE-SERVER and anycast Thread-Index: AciVprnkyeX691HHSyaCA6jZY6kb6QAAYj6A Message-ID: References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> In-Reply-To: <20080403162320.E34475081A@romeo.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Mark Townsley , Behave WG , Philip Matthews , David R Oran , David Ward Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > > At Thu, 3 Apr 2008 12:11:16 -0400, > Hadriel Kaplan wrote: > > > > I think they will find all kinds of crap breaking if they try to > > change that behavior (people do far worse with anycasts than what > > we're proposing), > > Yes, but at their own risk. That's different from us encouraging it. Yup, I concur. :) > Consider a load balancing system that has two paths and uses a packet > hash to determine which path it will take. If the SYN and the SYN/ACK > end up on different paths, then anycast will totally break the system. > You'll not be able to form a TCP connection at all. Right, and it's possible you'll never be able to create a TCP or TLS connection to a unicast server you want to, period. Section 9 deals with that by having it try to another server I think (because the STUN transaction would fail). I don't disagree that an anycast would need a unicast alternate, and unicasts need unicast alternates. Maybe we could just mandate that there be one for an anycast use model, with an explanation of why? > Maybe I'm missing something, but why use anycast at this layer at > all. Wouldn't it be easier to have the TURN servers be unicast and use > anycast (or just load balanced) DNS resolution instead, with different > servers giving different responses? It's not really just load balancing and availability, it's about distance locality (routing topology distance). DNS gives you the former, but not the latter unless either your DNS has topological knowledge, or you deploy DNS everywhere you deploy STUN/TURN servers, and you don't do recursive queries. I don't believe those are really tenable, but IANAE. Regardless, all that would do is replace the ALT-SERV mechanism with DNS, and if that's kosher, then so should doing ALT-SERV without a challenge and over UDP. -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 10:16:34 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38A9B28C1EC; Thu, 3 Apr 2008 10:16:34 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F29928C289 for ; Thu, 3 Apr 2008 10:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cbagmgwyGlt for ; Thu, 3 Apr 2008 10:16:26 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 2F37C28C6EF for ; Thu, 3 Apr 2008 10:15:54 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id C40525081A; Thu, 3 Apr 2008 10:17:45 -0700 (PDT) Date: Thu, 03 Apr 2008 10:17:45 -0700 From: Eric Rescorla To: Hadriel Kaplan In-Reply-To: References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080403171745.C40525081A@romeo.rtfm.com> Cc: Behave WG , David R Oran , David Ward , Mark Townsley , Philip Matthews Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Thu, 3 Apr 2008 12:50:55 -0400, Hadriel Kaplan wrote: > > > > > -----Original Message----- > > From: Eric Rescorla [mailto:ekr@networkresonance.com] > > > > At Thu, 3 Apr 2008 12:11:16 -0400, > > Hadriel Kaplan wrote: > > > > > > I think they will find all kinds of crap breaking if they try to > > > change that behavior (people do far worse with anycasts than what > > > we're proposing), > > > > Yes, but at their own risk. That's different from us encouraging it. > > Yup, I concur. :) > > > > Consider a load balancing system that has two paths and uses a packet > > hash to determine which path it will take. If the SYN and the SYN/ACK > > end up on different paths, then anycast will totally break the system. > > You'll not be able to form a TCP connection at all. > > Right, and it's possible you'll never be able to create a TCP or TLS > connection to a unicast server you want to, period. Yes, but not because of the network being actually completely functional, just not in a way you expect. > Section 9 deals > with that by having it try to another server I think (because the > STUN transaction would fail). I don't disagree that an anycast > would need a unicast alternate, and unicasts need unicast > alternates. Maybe we could just mandate that there be one for an > anycast use model, with an explanation of why? Again, I think this encourages a dangerous practice. > > Maybe I'm missing something, but why use anycast at this layer at > > all. Wouldn't it be easier to have the TURN servers be unicast and use > > anycast (or just load balanced) DNS resolution instead, with different > > servers giving different responses? > > It's not really just load balancing and availability, it's about > distance locality (routing topology distance). DNS gives you the > former, but not the latter unless either your DNS has topological > knowledge, or you deploy DNS everywhere you deploy STUN/TURN > servers, and you don't do recursive queries. I don't believe those > are really tenable, but IANAE. Regardless, all that would do is > replace the ALT-SERV mechanism with DNS, and if that's kosher, then > so should doing ALT-SERV without a challenge and over UDP. Pace DNSSEC. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 12:22:23 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD91328C392; Thu, 3 Apr 2008 12:22:23 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A42F28C33D for ; Thu, 3 Apr 2008 12:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[AWL=0.718, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zm84e0qwu4Op for ; Thu, 3 Apr 2008 12:22:21 -0700 (PDT) Received: from mail-05.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 5AB4628C391 for ; Thu, 3 Apr 2008 12:20:23 -0700 (PDT) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JhUy1-0000YV-2u; Thu, 03 Apr 2008 15:19:22 -0400 Message-Id: <020167B5-CB15-4BAE-AE0E-5D1DF3EE4D26@magma.ca> From: Philip Matthews To: Benny Prijono , Cullen Jennings In-Reply-To: <1879720d0804020513t368824cdhaef7af940fb6cf4a@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 15:20:25 -0400 References: <5AE36F39-B800-45FD-A4CF-261EEE6BD191@cisco.com> <6CA00DCC-A48A-47DA-8CD3-9BB47C891068@magma.ca> <38F521F6-E706-40F5-B1C7-08A2CCAC7EA0@cisco.com> <9B9EE332-F142-4A2A-9985-D771D1A276CB@magma.ca> <1879720d0803250458t3389ed38j8db079c9b08b7e64@mail.gmail.com> <724EB65E-E362-4789-BE5B-10B1C4A1A00F@magma.ca> <1879720d0804020513t368824cdhaef7af940fb6cf4a@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Cc: Behave WG Subject: Re: [BEHAVE] TURN: Are unauthenticated indications and ChannelData msgs a problem? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Wed, 2-Apr-08, at 08:13 , Benny Prijono wrote: > On Wed, Apr 2, 2008 at 6:51 AM, Cullen Jennings > wrote: >> >> It's seems that one possible solution to these would be "only >> authenticated >> requests can create, update, or remove a permission". This is one option. I call this "option C". For other options, see my e-mail of 24 March. >> > > Just to be clear with the proposal, I imagine that we will allow zero > or more PEER-ADDRESS attribute(s) to appear in Allocate and Refresh > requests, and the server will use these attributes to create or > refresh permissions. My personal preference would be to _not_ mix this up with Allocate and Refresh processing. I would instead define a new transaction for refreshing permissions. My reasons are: a) I think that the Allocate transaction is already complex enough; b) We only need a mechanism for peers that have no channels bound to them or where there are no channels bound to the same address but different port (since rebinding a channel also refreshes the corresponding permission). Since I think most clients will use channels for long-term communication, the bandwidth savings from doing this with the Allocate and Refresh transactions is low. One alternative that has some attraction is to generalize the Send method to also support request/response transactions (in the same way that Binding can be either request/response or indication). The Send request could then carry the USERNAME, REALM, NONCE, and MESSAGE- INTEGRITY attributes. It would also be allowed to specify either (a) a PEER-ADDRESS or (b) a CHANNEL-NUMBER. The semantics of the latter would be to send data on that channel and refresh the channel binding and the corresponding permission. This would allow a single packet to both carry the ICE keep-alive and refresh the TURN channel and/or permission. This packet would be an ICE keep-alive (= a STUN Binding indication) wrapped inside a TURN Send request. [NOTE: Some may be thinking "Why do I need an ICE keep-alive if I am sending packets to refresh the TURN channel and permission?". There are two reasons: (1) Most NATs today need to be refreshed much faster than 5 minutes, and (2) if there is a NAT _beyond_ the TURN server with its private side facing the server, then a refresh transaction with the TURN server will not refresh the bindings on that NAT. Case (2) can arise in, for example, when a TURN server is located on a node behind a NAT, which is being considered in P2PSIP situations.] > One of the interesting thing with this is that > there will be multiple instances of the same attribute to appear in a > STUN message. I don't think this is disallowed by STUN, but I don't > think there is existing usages that use this either, so it'll be > interesting to hear if it breaks implementations. For me I'm fine with > this. Section 15 of the STUN spec says: Any attribute type MAY appear more than once in a STUN message. Unless specified otherwise, the order of appearance is significant: only the first occurance needs to be processed by a receiver, and any duplicates MAY be ignored by a receiver. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 16:00:30 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 577F628C24C; Thu, 3 Apr 2008 16:00:30 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07EB3A6B48 for ; Thu, 3 Apr 2008 16:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOFfUMLRwzKv for ; Thu, 3 Apr 2008 16:00:28 -0700 (PDT) Received: from mail-08.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 441E928C29C for ; Thu, 3 Apr 2008 16:00:18 -0700 (PDT) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JhYPt-0000wV-1B for behave@ietf.org; Thu, 03 Apr 2008 19:00:22 -0400 Message-Id: <8211A849-5BA2-46C2-A4E2-92F18783A872@magma.ca> From: Philip Matthews To: Behave WG In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 19:00:20 -0400 References: X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Subject: Re: [BEHAVE] Conf call on TURN encapsulations will be held on Tuesday X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Bridge info is now available. If you wish to attend, please contact me, and I will send it to you. Those I already know about should have already received it. The call is open to everyone who wishes to attend. - Philip PS. Thanks to Dan Wing and Cisco for providing a bridge with international dial-in numbers. On Wed, 2-Apr-08, at 21:57 , Philip Matthews wrote: > I will send out bridge information for the call by Monday. > Right now, I have a bridge with a US dial-in number, but I am trying > to find one that also has international dial-in numbers. > > - Philip > > On Wed, 2-Apr-08, at 16:59 , Philip Matthews wrote: >> The conference call on TURN encapsulations will be held on Tuesday, 8 >> April 2007 at the following time >> 9 - 11 Pacific / 12 - 14 Eastern / 18 - 20 CET / 19 - 21 EET >> >> Please send me an e-mail if you want to join this call, and I will >> send you the bridge information. (Those who have already responded >> need not reply again). >> >> - Philip >> >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 21:27:16 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C42F13A6DE0; Thu, 3 Apr 2008 21:27:16 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA23F3A6DE7 for ; Thu, 3 Apr 2008 21:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.019 X-Spam-Level: X-Spam-Status: No, score=-5.019 tagged_above=-999 required=5 tests=[AWL=1.280, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YtzRdwec5pK for ; Thu, 3 Apr 2008 21:27:15 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C702F3A6DE0 for ; Thu, 3 Apr 2008 21:27:13 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m344RAj3001323; Fri, 4 Apr 2008 07:27:15 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 07:26:32 +0300 Received: from esdhcp04036.research.nokia.com ([172.21.40.36]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 07:26:32 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia Devices R&D To: behave@ietf.org Date: Fri, 4 Apr 2008 07:27:07 +0300 User-Agent: KMail/1.9.9 References: <0419099C-4BDE-4C21-BA1C-D67879DFE272@magma.ca> <14E3C6BB-4F4D-4A3B-930A-1A7318E7E195@magma.ca> <0F2185A7-C2BA-4E21-91E9-9D7AA8797866@magma.ca> In-Reply-To: <0F2185A7-C2BA-4E21-91E9-9D7AA8797866@magma.ca> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804040727.07863.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 04 Apr 2008 04:26:32.0143 (UTC) FILETIME=[0F5A9DF0:01C8960C] X-Nokia-AV: Clean Cc: ext Philip Matthews Subject: Re: [BEHAVE] TURN: Proposal for the BANDWIDTH attribute X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Thursday 03 April 2008 18:47:30 ext Philip Matthews, vous avez =E9crit= =A0: > So far, there seems to be consensus to remove this from the base TURN > document. Unless I hear strong objections to this, I will remove it > from the (upcoming) TURN-08. Ok with me. -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 21:33:46 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CFB23A696D; Thu, 3 Apr 2008 21:33:46 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE503A6916 for ; Thu, 3 Apr 2008 21:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5knFGCW14r4 for ; Thu, 3 Apr 2008 21:33:44 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id CEFAE3A67AC for ; Thu, 3 Apr 2008 21:33:44 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m344Yu6E012252; Thu, 3 Apr 2008 23:36:00 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 07:32:50 +0300 Received: from esdhcp04036.research.nokia.com ([172.21.40.36]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 07:32:50 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia Devices R&D To: behave@ietf.org Date: Fri, 4 Apr 2008 07:33:26 +0300 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804040733.26362.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 04 Apr 2008 04:32:50.0654 (UTC) FILETIME=[F0F6CFE0:01C8960C] X-Nokia-AV: Clean Cc: ext Philip Matthews Subject: Re: [BEHAVE] TURN: Cullen's suggestion for setting the DF bit X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Thursday 03 April 2008 18:39:52 ext Philip Matthews, vous avez =E9crit= =A0: > Just a reminder that I am still interested in getting feedback on > these options. So far, I have only gotten one response. Not doing any > of these is also an option, so feel free to say "I am not interested > in this idea". I am fine with the proposal, but I am confused as to whether/how this is = supposed to solve the "unprivileged" server problem. I know Linux supports both RFC1191 and RFC4821 path MTU discovery (look for = IP_MTU_DISCOVER at ip(7)) without privileges, but that seemed like the = exception rather than the norm. -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 3 21:57:43 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B3DC3A6C89; Thu, 3 Apr 2008 21:57:43 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1983A67AC for ; Thu, 3 Apr 2008 21:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hl+bkgnIsW2F for ; Thu, 3 Apr 2008 21:57:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CD9533A692C for ; Thu, 3 Apr 2008 21:57:40 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 4 Apr 2008 00:57:19 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 4 Apr 2008 00:57:17 -0400 From: Hadriel Kaplan To: Philip Matthews , Behave WG Date: Fri, 4 Apr 2008 00:56:25 -0400 Thread-Topic: [BEHAVE] TURN: Cullen's suggestion for setting the DF bit Thread-Index: AciVoOtm5Vmk4pUISOmhgQh/J2SeTgAbpMMg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [BEHAVE] TURN: Cullen's suggestion for setting the DF bit X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I am (probably predictably) for the KISS principle, where the last S is for Server, so I would prefer option 4: not interested. -hadriel "PITA" kaplan > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Philip Matthews > Sent: Thursday, April 03, 2008 11:40 AM > To: Behave WG > Subject: Re: [BEHAVE] TURN: Cullen's suggestion for setting the DF bit > > Just a reminder that I am still interested in getting feedback on > these options. So far, I have only gotten one response. Not doing any > of these is also an option, so feel free to say "I am not interested > in this idea". > - Philip > > On Thu, 20-Mar-08, at 17:15 , Philip Matthews wrote: > > The proposal described in my e-mail message of 12 March (see the > > bottom of this message) was discussed in the BEHAVE session to mostly > > favorable reception. However, Cullen suggested a modification that I > > would like to get input on. > > > > At presently envisioned, in a partly-compliant allocation, if the > > server cannot read the value of the incoming DF bit, then it SHOULD > > clear the DF bit on the outgoing packet. This increases the chances > > that a large packet will be successfully delivered to the peer (or > > the client). However, this also breaks Path MTU Discovery, which > > requires the DF bit to be set. > > > > Cullen is interested in trying to make Path MTU Discovery work even > > for partly-compliant allocations. Here are a couple of options for > > doing this: > > > > 1) [Cullen's proposal] Add a way for the client to indicate, on a per- > > packet basis, that the server should set the DF bit when forwarding > > the user data to the peer. > > This would apply ONLY to Send indications, which would include a bit > > that specifies the setting of the DF bit. This bit could either be > > contained in a new attribute, or could be one of the 8 currently > > unused bits in the PEER-ADDRESS attribute. > > > > 2) Add a way for the client to indicate that the server should set > > the DF bit on ALL packets relayed by the server for this allocation. > > This might be done when the allocation is created, using a bit in the > > REQUESTED-PROPS attribute. > > > > 3) Similar to option (2), but settable on a per-peer basis via some > > new to-be-defined transaction. > > > > Option (1) allows the setting on a per-packet basis, but only in the > > client-->peer direction. Thus the peer could not do Path MTU > > Discovery. > > > > Option (2) allows the peer to do Path MTU Discovery as well, but > > reduces somewhat the chances of a large packet getting through if the > > peer chooses not do PMTUD. > > > > Option (3) sets the DF bit on a per-peer basis, which might be useful > > if some peers do PMTUD and others do not. However, it is the most > > complex to specify, since it requires a new transaction type. > > > > What do people think of either of these options? Is anyone besides > > Cullen interested in this question? > > > > Personally, I am leaning slightly towards (2), but have no strong > > option. If no one but Cullen cares, then I will probably just drop > > this idea entirely. > > > > - Philip > > > > > > > > > > On Wed, 12-Mar-08, at 10:43 , Philip Matthews wrote: > >> Below is a new proposal for how to handle the IP header fields in > >> TURN. This proposal was developed in conjunction with Magnus, Lars, > >> and Jonathan. I will be discussing this proposal in the BEHAVE > >> meeting on Thursday. > >> > >> - Philip > >> > >> > >> A UDP allocation is "fully compliant with the TURN IP header > >> requirements" if the TURN server sets the fields in the outgoing IP > >> header as follows. [Note: Need a better term; suggestions welcome.] > >> > >> For IPv4: > >> * The TTL field is set to (incoming TTL - 1). > >> * The ECN field is set to the incoming ECN field UNLESS the server is > >> doing Active Queue Management, the incoming ECN field is 01 or 10, > >> and the server wishes to indicate that congestion has been > >> experienced, in which case it sets the outgoing ECN field to 11. > >> * The DSCP field is set to the incoming DSCP UNLESS the server, > >> though configuration or other means, believes that a different > >> setting is more appropriate. > >> * Various fragmentation fields (identification, fragment offset, > >> last/ > >> more fragments) are set as appropriate for a packet originated by the > >> server. [Since the incoming UDP datagram must be re-assembled before > >> it can be processed]. > >> * The DF field is set to the incoming DF field. > >> * The options are empty (i.e., not copied). > >> > >> For IPv6: > >> * The Flow Label field is set to the incoming Flow Label field > >> * The treatment of IPv6 extension headers is TBD. > >> > >> In addition, a "fully compliant" implementation will relay ICMP > >> messages between the peer and client. > >> > >> > >> A UDP allocation is only "partly compliant" if it does not set one or > >> more of the fields as indicated above, or does not relay ICMP > >> messages. > >> > >> Where possible, a "partly compliant" UDP allocation should set each > >> field in the outgoing IP header as described above. Where a specific > >> field cannot be set as described above, it SHOULD be set as described > >> below. > >> > >> For IPv4: > >> * ECN field: set to 00 (ECN not supported). > >> * DSCP field: set to best effort > >> * DF field: set to fragmentation allowed > >> > >> For IPv6: > >> TBD > >> > >> A client SHOULD set the fields in the IP header as directed by the > >> local application. If no direction is received, then the fields are > >> set as described under the "partly compliant" description above. > >> > >> Bit 8 (currently unused) in the REQUESTED-PROPS attribute is > >> redefined. If this bit is set to 1, then the client is requesting > >> that the allocation be fully compliant with the TURN IP header > >> requirements. If the server cannot provide an allocation that is > >> fully compliant, then the server MUST reject the allocation request. > >> It is a "Bad Request" error to set this bit when requesting a non-UDP > >> allocation. > >> > >> > >> When should a client request a fully-compliant allocation? > >> * When the client wishes to use ECN or a specific DSCP along the > >> entire path, OR > >> * When the client wishes to determine the precise Path MTU (using > >> Packetization Layer PMTUD). > >> In general, a client can use a partly-compliant allocation over IPv4 > >> if the application is happy with best effort service, does not need > >> ECN, and sends only small packets (i.e., less than 576 - >> overhead of 32 bytes>). If the application sends larger packets, then > >> the packets may get fragmented along the way. This may result in the > >> packets being dropped along the path; for example, if fragments are > >> delivered out-of-order to certain NATs that do not handle out-of- > >> order fragments properly. If the client uses the Packetization Layer > >> PMTUD algorithm, then it may not discover the true path MTU, since > >> the server may not set the DF bit. In these cases, it will instead > >> discover the maximum packet size that will be delivered successfully > >> to the peer. > >> Some clients and applications that send larger packets may be able to > >> operate successfully in these situations. Others may not, and thus > >> require a fully-compliant allocation. > >> [Any other suggestions for what to say here??] > >> > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > >> > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 4 03:28:47 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760923A6CC2; Fri, 4 Apr 2008 03:28:47 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672F83A6866 for ; Fri, 4 Apr 2008 03:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUDUTEUtiRKZ for ; Fri, 4 Apr 2008 03:28:41 -0700 (PDT) Received: from s200aog13.obsmtp.com (s200aog13.obsmtp.com [207.126.144.127]) by core3.amsl.com (Postfix) with SMTP id 1EE923A6CAA for ; Fri, 4 Apr 2008 03:28:39 -0700 (PDT) Received: from source ([66.249.82.236]) by eu1sys200aob013.postini.com ([207.126.147.11]) with SMTP; Fri, 04 Apr 2008 10:28:44 UTC Received: by wx-out-0506.google.com with SMTP id h27so4257048wxd.3 for ; Fri, 04 Apr 2008 03:28:44 -0700 (PDT) Received: by 10.140.193.16 with SMTP id q16mr344496rvf.109.1207304923484; Fri, 04 Apr 2008 03:28:43 -0700 (PDT) Received: by 10.141.186.2 with HTTP; Fri, 4 Apr 2008 03:28:43 -0700 (PDT) Message-ID: <1879720d0804040328m4d9164a3l2d9e9f5655ecb43d@mail.gmail.com> Date: Fri, 4 Apr 2008 11:28:43 +0100 From: "Benny Prijono" To: "Philip Matthews" In-Reply-To: <020167B5-CB15-4BAE-AE0E-5D1DF3EE4D26@magma.ca> MIME-Version: 1.0 Content-Disposition: inline References: <5AE36F39-B800-45FD-A4CF-261EEE6BD191@cisco.com> <6CA00DCC-A48A-47DA-8CD3-9BB47C891068@magma.ca> <38F521F6-E706-40F5-B1C7-08A2CCAC7EA0@cisco.com> <9B9EE332-F142-4A2A-9985-D771D1A276CB@magma.ca> <1879720d0803250458t3389ed38j8db079c9b08b7e64@mail.gmail.com> <724EB65E-E362-4789-BE5B-10B1C4A1A00F@magma.ca> <1879720d0804020513t368824cdhaef7af940fb6cf4a@mail.gmail.com> <020167B5-CB15-4BAE-AE0E-5D1DF3EE4D26@magma.ca> X-Google-Sender-Auth: a87f7883909db911 Cc: Behave WG Subject: Re: [BEHAVE] TURN: Are unauthenticated indications and ChannelData msgs a problem? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Thu, Apr 3, 2008 at 8:20 PM, Philip Matthews wrote: > > Just to be clear with the proposal, I imagine that we will allow zero > > or more PEER-ADDRESS attribute(s) to appear in Allocate and Refresh > > requests, and the server will use these attributes to create or > > refresh permissions. > > My personal preference would be to _not_ mix this up with Allocate and > Refresh processing. I would instead define a new transaction for refreshing > permissions. My reasons are: > a) I think that the Allocate transaction is already complex enough; I think it won't, since it doesn't add more allocation specification. This would be something that the server does after it creates the allocation, so it shouldn't add to the complexity of the Allocate request (by too much that is). > b) We only need a mechanism for peers that have no channels bound to them > or where there are no channels bound to the same address but different port > (since rebinding a channel also refreshes the corresponding permission). > Since I think most clients will use channels for long-term communication, > the bandwidth savings from doing this with the Allocate and Refresh > transactions is low. > Once the communication has been established, yes. In fact probably most clients won't use this permission refresh mechanism at all once communication has been established if it binds the peer it wants to communicate to with a channel, since it will refresh the channel and the corresponding permission using ChannelBind instead. What I was referring to as chattiness is during initial ICE negotiation. Since client doesn't know which remote candidate will reach it's TURN candidate, basically it has to open a permission to each of the remote candidate (probably three at minimum), and this would mean individual requests to open permission for each candidate. And multiply that with the number of components. Considering that many things are happening during ICE negotiation (lots of packets get sent), this may be something we need to consider. > > One alternative that has some attraction is to generalize the Send method > to also support request/response transactions (in the same way that Binding > can be either request/response or indication). The Send request could then > carry the USERNAME, REALM, NONCE, and MESSAGE-INTEGRITY attributes. It would > also be allowed to specify either (a) a PEER-ADDRESS or (b) a > CHANNEL-NUMBER. The semantics of the latter would be to send data on that > channel and refresh the channel binding and the corresponding permission. > > This would allow a single packet to both carry the ICE keep-alive and > refresh the TURN channel and/or permission. This packet would be an ICE > keep-alive (= a STUN Binding indication) wrapped inside a TURN Send request. For me, the concept of sending a data with a request is not too appealing considering the size of the payload that potentially needs to be retransmitted, and retransmission may cause the payload to arrive out of order in the peer. The later probably is not too much of a concern, but the former is. An ICE Binding request is about 100 bytes in length, and add that to about 100 bytes of typical long-term authenticated TURN request. And considering that a long term request may get challenged (e.g. expired NONCE), the figure starts to get worrying. Also IMO, sending ICE inside Send request looks complicated. First, the ICE keep-alive and TURN permission timer run independently, so I imagine each will be sent independently from one another. And second, one needs to be careful with using Send request with ICE in general, since the Send payload maybe a STUN request in itself (say a Binding request), which will be retransmitted independently from the Send request. A buggy client may end up creating a Send request for every Binding request (the payload of Send request) retransmissions. So with this, what most client do probably is to send a blank Send request (containing no DATA) just to open/refresh the permission, then use Send Indication as usual to send data. Which negates the motivation of having Send request in the first place. Perhaps there are other uses for this. But IMO probably it's better to invent an explicit method to refresh permission. That's your option C I believe. Or as a variant of option C, we also have an option to not provide any mechanism to refresh permission and instead force everyone to use channels. In some way this may be simpler since now there is only one mechanism to refresh permission/channel, but it may cause concern for long term allocation with the limited number of channel number space. I was one of the people who argued about using long term allocation, and in the end I decided that this was not a good idea, so this option sounds quite feasible. So to put all the new options on the table (in addition to your previous mail in this thread): - Option F: allow Allocate and Refresh with multiple PEER-ADDRESS attributes to create/refresh permissions - Option G: not to provide mechanism to refresh permission alone, and instead force everyone to use channels (variant of option C) - Option H: use Send request > [NOTE: Some may be thinking "Why do I need an ICE keep-alive if I am > sending packets to refresh the TURN channel and permission?". There are two > reasons: (1) Most NATs today need to be refreshed much faster than 5 > minutes, and (2) if there is a NAT _beyond_ the TURN server with its private > side facing the server, then a refresh transaction with the TURN server will > not refresh the bindings on that NAT. Case (2) can arise in, for example, > when a TURN server is located on a node behind a NAT, which is being > considered in P2PSIP situations.] > > > > > One of the interesting thing with this is that > > there will be multiple instances of the same attribute to appear in a > > STUN message. I don't think this is disallowed by STUN, but I don't > > think there is existing usages that use this either, so it'll be > > interesting to hear if it breaks implementations. For me I'm fine with > > this. > > > Section 15 of the STUN spec says: > Any attribute type MAY appear more than once in a STUN message. > Unless specified otherwise, the order of appearance is significant: > only the first occurance needs to be processed by a receiver, and any > duplicates MAY be ignored by a receiver. Yeah, but it says "Unless specified otherwise". Cheers Benny > - Philip > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 4 07:32:11 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445BC3A6E22; Fri, 4 Apr 2008 07:32:11 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E007D28C385 for ; Fri, 4 Apr 2008 07:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.652, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scJKziXecJuW for ; Fri, 4 Apr 2008 07:32:09 -0700 (PDT) Received: from mail-09.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id CDFA03A6DA3 for ; Fri, 4 Apr 2008 07:32:09 -0700 (PDT) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Jhmxi-0000DW-2Z for behave@ietf.org; Fri, 04 Apr 2008 10:32:15 -0400 Message-Id: <9A96C37D-30F4-42A1-A4D9-E652918EB1BE@magma.ca> From: Philip Matthews To: Behave WG In-Reply-To: <8211A849-5BA2-46C2-A4E2-92F18783A872@magma.ca> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 10:32:11 -0400 References: <8211A849-5BA2-46C2-A4E2-92F18783A872@magma.ca> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Subject: Re: [BEHAVE] Conf call on TURN encapsulations will be held on Tuesday X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Just a further note on this call. The focus will be on TURN encapsulations as previously described, and I will allow this discussion to go as long as necessary (up to 2 hours). However, if there is time left after discussing encapsulations, then I will bring up some of the other open issues in TURN that we have been discussing on the mailing list (e.g., ALTERNATE-SERVER, anycast, setting the DF bit, refreshing permissions). As usual, a summary of the call will be posted to the list afterwards. - Philip On Thu, 3-Apr-08, at 19:00 , Philip Matthews wrote: > Bridge info is now available. If you wish to attend, please contact > me, and I will send it to you. Those I already know about should have > already received it. > > The call is open to everyone who wishes to attend. > > - Philip > > PS. Thanks to Dan Wing and Cisco for providing a bridge with > international dial-in numbers. > > On Wed, 2-Apr-08, at 21:57 , Philip Matthews wrote: >> I will send out bridge information for the call by Monday. >> Right now, I have a bridge with a US dial-in number, but I am trying >> to find one that also has international dial-in numbers. >> >> - Philip >> >> On Wed, 2-Apr-08, at 16:59 , Philip Matthews wrote: >>> The conference call on TURN encapsulations will be held on >>> Tuesday, 8 >>> April 2007 at the following time >>> 9 - 11 Pacific / 12 - 14 Eastern / 18 - 20 CET / 19 - 21 EET >>> >>> Please send me an e-mail if you want to join this call, and I will >>> send you the bridge information. (Those who have already responded >>> need not reply again). >>> >>> - Philip >>> >>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 4 17:36:46 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CED33A6D87; Fri, 4 Apr 2008 17:36:46 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A96528C680 for ; Thu, 3 Apr 2008 06:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[AWL=1.403, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1o9nPpXf1bD for ; Thu, 3 Apr 2008 06:29:14 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B52F728C68B for ; Thu, 3 Apr 2008 06:29:14 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 03 Apr 2008 06:29:18 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m33DTHSj012900; Thu, 3 Apr 2008 06:29:17 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m33DTGfw007841; Thu, 3 Apr 2008 13:29:17 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 09:29:16 -0400 Received: from rtp-townsley-vpn3.cisco.com ([10.83.1.100]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 09:29:14 -0400 Message-ID: <47F4DB9F.6030205@cisco.com> Date: Thu, 03 Apr 2008 15:29:03 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Philip Matthews References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> In-Reply-To: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> X-OriginalArrivalTime: 03 Apr 2008 13:29:15.0260 (UTC) FILETIME=[B61233C0:01C8958E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6037; t=1207229357; x=1208093357; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20[BEHAVE]=20ALTERNATE-SERVER=20and=20any cast |Sender:=20; bh=ZS9tOELZLJxtPgH8KvgA1MBGQSja9nrF2VvKzINQquQ=; b=RHntLgcVUyhODV6Ihkj2NqSVVnUkBDx757QdygtrYQQib5+/tlhaGdvHRl a3ED4k6lC3LqmDwxXItBpbKBVa7gMHpRrvfoYbIN+Qbz7K69V6S01Kmf4vI1 mQ8B+Ycceg; Authentication-Results: sj-dkim-4; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Mailman-Approved-At: Fri, 04 Apr 2008 17:36:46 -0700 Cc: David R Oran , Behave WG , David Ward Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Philip Matthews wrote: > I am still trying to dig into the reasons the experts think that > multi-packet exchanges won't work. My initial reaction is exactly the > same as yours. > > However, I also wondering how keen people are to have anycast support > in TURN? I have heard that there is a draft in preparation that will > discuss anycast discovery of servers, but it won't be out for a month > or so, and after that there will presumably be some debate on the > details. So this may turn out to be an area where there is not yet > IETF consensus. If this is the case, are people willing to delay the > TURN draft while we sort out the anycast details? I can say for certain that autodiscovery, is something that in many cases we have functionally separated out. There is often more than one way to skin that particular cat, there are various tradeoffs, and lots of opinions on what those are. Consensus is sometimes difficult to reach, unfortunately. - Mark > > - Philip > > On Wed, 2-Apr-08, at 23:34 , Hadriel Kaplan wrote: >> >> I am in still in favor of it, specifically for anycast support. >> >> Can you describe the cases it won't be delivered to the same instance >> that you've been told of? In my experience (which was many years in >> the L3 routing world, fwiw, but nowhere near as much as either of the >> Dave's left pinkies), anycasting fails to deliver a packet to the >> same server "instance" for one of two reasons I can think of off the >> top of my head: >> 1) The network topology changes, for example the routing cost >> to an instance's prefix changes, or an L3 protection mechanism kicked >> in and temporarily selected a higher-cost path, or whatever. >> 2) A router or some middle-box is doing some form of >> load-balancing. >> >> For (1), it is either a transient rare event (from our use-case >> timescale perspective) which stabilizes, which won't matter for this >> use-case; or it is due to a route flap event, and route flaps take >> enough time to flap again, in 99% of the cases, that for this >> use-case timescale it won't matter. Just as long as the mechanism is >> resilient to the event occurring once in its full handshake - in >> other words, so long as the second-trip can fail to reach the same >> server instance but that just triggers another round-trip restart, >> then (1) isn't an issue for a massive probability. I think that is >> the case for ALT-SERVER use, right? That it survives such a thing >> happening gracefully? >> >> For (2), all such modern equipment I know of performs hashing or some >> form of keeping the same "flows" going to the same specific L3 >> next-hops, and do so using at least IP-dest in their decision, or >> IP-dest+source, or more, such that any flows to the same anycast dest >> address will get to the same instance virtually all of the time. >> Having said that, there have been some (rather infamous) cases of >> ECMP or L3 load-balancing in routers which did NOT follow that model, >> and forwarded packets in a round-robin fashion, but I was under the >> impression they got "called-out" and all their hardware has since >> been upgraded to fix it years ago. And when I say "anycast", I mean >> an IPv4 unicast address/prefix that happens to be a virtual shared >> address for multiple hosts, and advertised into the routing topology >> from multiple physical locations - I do not mean IPv6 true >> anycasting, and I have no idea what the modern equipment does for >> that or if it matters. (I've been out of routing for several years) >> >> Regardless, I think all we need is a graceful way for the client to >> detect a pathological condition, should the worst happen. (ie, a way >> for it to give up re-tries and use an alternate server altogether) No? >> >> -hadriel >> >>> -----Original Message----- >>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>> Behalf >>> Of Philip Matthews >>> Sent: Wednesday, April 02, 2008 10:22 PM >>> To: Behave WG >>> Cc: Mark Townsley; David R Oran; David Ward >>> Subject: [BEHAVE] ALTERNATE-SERVER and anycast >>> >>> At the last BEHAVE meeting, it was suggested that one use of ALTERNATE- >>> SERVER was to support anycast discovery of TURN servers. I have been >>> doing some inquiries, and it seems that there might be a problem with >>> this idea. >>> >>> The way I had been thinking this would work is that a client would >>> send an Allocate request to an anycast address, and would receive an >>> error response back with an error code of 300 Try Alternative and an >>> ALTERNATE-SERVER attribute giving the unicast address of the server to >>> contact. >>> >>> The problem is that it seems there is no guarantee that two >>> consecutive packets will be delivered to the same anycast server. The >>> only thing that is guaranteed is a single round-trip exchange[1]. This >>> means that the above idea does not work because: >>> a) It is not possible to contact an anycast TURN server using TCP or >>> TLS over TCP, since the handshake will not necessarily complete with >>> the same server. >>> b) It is also not possible to contact an anycast TURN server using >>> UDP, since STUN says that an ALTERNATE-SERVER reply must be >>> authenticated, and authentication in TURN requires a 4-packet exchange. >>> >>> So this straight-forward method of doing anycast lookup in TURN does >>> not seem to work. >>> >>> There are probably ways to fix this by changing how ALTENATE-SERVER >>> works in TURN, but I am currently inclined to forget about anycast for >>> TURN right now, and let someone add it later. >>> >>> Comments? >>> >>> - Philip >>> >>> [1] Private info received from David Oran. I have asked for a public >>> reference. >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >> > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 4 17:36:46 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A390528C1E9; Fri, 4 Apr 2008 17:36:46 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73C833A6B4A for ; Fri, 4 Apr 2008 10:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 509KKMQJozlD for ; Fri, 4 Apr 2008 10:36:02 -0700 (PDT) Received: from where.matthew.at (unknown [IPv6:2001:5a8:4:39d1:201:3ff:fed1:d4f5]) by core3.amsl.com (Postfix) with ESMTP id B00D828C4C2 for ; Fri, 4 Apr 2008 10:35:52 -0700 (PDT) Received: from [10.10.155.2] (matthew-desk.braemoor.net [10.10.155.2] (may be forged)) by where.matthew.at (8.11.3/8.11.3) with ESMTP id m34HZgL90610; Fri, 4 Apr 2008 10:35:42 -0700 (PDT) (envelope-from matthew@matthew.at) Message-ID: <47F666EE.8080004@matthew.at> Date: Fri, 04 Apr 2008 10:35:42 -0700 From: Matthew Kaufman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: jdrosen@cisco.com, rohan@ekabal.com, philip_matthews@magma.ca X-Mailman-Approved-At: Fri, 04 Apr 2008 17:36:45 -0700 Cc: behave@ietf.org Subject: [BEHAVE] TURN as enterprise proxy mechanism X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: matthew@matthew.at List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org We are developing an application which we expect to be (very) widely deployed that makes client-server and peer-to-peer connections over a UDP-based protocol. Enterprise customers that wish to block all UDP traffic at their firewall have asked for a way to enable the use of this application using some sort of proxy. TURN appears to provide the most convenient UDP-UDP proxy mechanism that we've seen specs for, though this application is somewhat different than "TURN server on public Internet", and thus assumptions and requirements are different than that case. A handful of questions: 1. Should we be looking at something else instead? (Not SOCKS, as it doesn't appear to act as a UDP-UDP proxy and appears to require a fixed destination address, both incompatible with our requirements) 2. Has there been any thought given to an advisory "User Agent" parameter during association? Enterprises may wish to operate an unauthenticated TURN proxy for their employees, but have at least some guess as to what is using it. (Note that this is also a good reason for continuing to allow an unauthenticated mode of operation for TURN) 3. Has there been any thought given to a DHCP option for providing clients with the address of a local TURN server? (This may seem exactly backwards from the STUN goal of having the server independent of the enterprise network so that the "outside" address may be derived, but would help our application and also could support enterprise policy about which STUN/TURN server they'd like their VoIP phones using) Matthew Kaufman matthew@matthew.at _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 4 17:51:04 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BE4A3A6957; Fri, 4 Apr 2008 17:51:04 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26C453A68B3 for ; Fri, 4 Apr 2008 17:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.891 X-Spam-Level: X-Spam-Status: No, score=-4.891 tagged_above=-999 required=5 tests=[AWL=1.708, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMa7TP0yWXSB for ; Fri, 4 Apr 2008 17:51:00 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7ADCD3A6CA7 for ; Fri, 4 Apr 2008 17:50:00 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 04 Apr 2008 17:50:07 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m350o7HV019359; Fri, 4 Apr 2008 17:50:07 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m350o6dr028333; Sat, 5 Apr 2008 00:50:07 GMT From: "Dan Wing" To: References: <47F666EE.8080004@matthew.at> Date: Fri, 4 Apr 2008 17:50:06 -0700 Message-ID: <15af01c896b6$fe4e0780$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47F666EE.8080004@matthew.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciWtS7jBbxS39hGSgGABS7Gv57W6gAAGjBg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2996; t=1207356607; x=1208220607; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20TURN=20as=20enterprise=20pro xy=20mechanism |Sender:=20; bh=6L5LffCHaisDi42uTK1SYQgBTzdLI4muI+9dMkOm/mw=; b=ZBRuwzi1StGZRdHjmw7iXLAQr7gMJ+grLbJoGK9ynY9MmZO6tGsjBZ7Y07 8WDcVQkjR9TNxpzssAYMXMp9ZsbIeDvsoLTdK2Kb7w/0fbGXn2fT5GLh2v2/ P6OlKsh4RQ; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: rohan@ekabal.com, behave@ietf.org, philip_matthews@magma.ca Subject: Re: [BEHAVE] TURN as enterprise proxy mechanism X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Matthew Kaufman > Sent: Friday, April 04, 2008 10:36 AM > To: jdrosen@cisco.com; rohan@ekabal.com; philip_matthews@magma.ca > Cc: behave@ietf.org > Subject: [BEHAVE] TURN as enterprise proxy mechanism > > We are developing an application which we expect to be (very) widely > deployed that makes client-server and peer-to-peer connections over a > UDP-based protocol. > > Enterprise customers that wish to block all UDP traffic at their > firewall have asked for a way to enable the use of this application > using some sort of proxy. > > TURN appears to provide the most convenient UDP-UDP proxy > mechanism that > we've seen specs for, though this application is somewhat > different than > "TURN server on public Internet", and thus assumptions and > requirements > are different than that case. > > A handful of questions: > > 1. Should we be looking at something else instead? (Not SOCKS, as it > doesn't appear to act as a UDP-UDP proxy and appears to > require a fixed > destination address, both incompatible with our requirements) http://www1.cs.columbia.edu/~lennox/udptunnel also uses fixed addresses, but might be useful for you. For example, you could run a CGI on your proxy which called udptunnel with the necessary UDPtunnel parameters. > 2. Has there been any thought given to an advisory "User Agent" > parameter during association? Enterprises may wish to operate an > unauthenticated TURN proxy for their employees, but have at > least some > guess as to what is using it. (Note that this is also a good > reason for > continuing to allow an unauthenticated mode of operation for TURN) A new STUN attribute could be defined for that. But of course there wouldn't be any good way to authenticate its contents -- once someone learns that 'udp-chat-1.0' and 'quake' are both acceptable for using the TURN server, they'll configure other TURN-aware applications to put those strings into that attribute. But if the applications and the users are more-or-less trusted (which is often the case with enterprises -- they can fire employees that subvert company policy), it could be helpful for traffic statistics. > 3. Has there been any thought given to a DHCP option for providing > clients with the address of a local TURN server? (This may > seem exactly > backwards from the STUN goal of having the server independent of the > enterprise network so that the "outside" address may be derived, but > would help our application and also could support enterprise policy > about which STUN/TURN server they'd like their VoIP phones using) Nobody is working on that, but it seems reasonable to me -- it is more reasonable than doing a DNS SRV query to find your TURN server. A drawback with DHCP options is the years it takes to get into OSs and into DHCP servers. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 6 11:16:23 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06DFF3A6CC1; Sun, 6 Apr 2008 11:16:23 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DCCB3A6CC1 for ; Sun, 6 Apr 2008 11:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkKA0bSgDIwF for ; Sun, 6 Apr 2008 11:16:21 -0700 (PDT) Received: from figas.ekabal.com (figas.ekabal.com [204.61.215.10]) by core3.amsl.com (Postfix) with ESMTP id 7F1233A6B23 for ; Sun, 6 Apr 2008 11:16:21 -0700 (PDT) Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id m36IG9a25520; Sun, 6 Apr 2008 11:16:09 -0700 In-Reply-To: <47F666EE.8080004@matthew.at> References: <47F666EE.8080004@matthew.at> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Rohan Mahy Date: Sun, 6 Apr 2008 11:16:10 -0700 To: matthew@matthew.at X-Mailer: Apple Mail (2.753) Cc: Rohan Mahy , behave@ietf.org, philip_matthews@magma.ca Subject: Re: [BEHAVE] TURN as enterprise proxy mechanism X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi Mathew, I think TURN is perfectly reasonable for your application. While you could define a new USER-AGENT or CLIENT attribute. I definitely recommend against making any application unauthenticated in an enterprise. The enterprise certainly has a username/password directory (possibly more than one). I would suggest just using that same directory. Why is DNS not working well for you? In my experience it is far easier to configure and deploy a new SRV record than a new DHCP option. You have to add the DHCP option on a per-scope (subnet) basis whereas the SRV record is done once per zone (domain name). Any information you can provide here would be useful. thanks, -rohan On Apr 4, 2008, at 10:35 AM, Matthew Kaufman wrote: > We are developing an application which we expect to be (very) > widely deployed that makes client-server and peer-to-peer > connections over a UDP-based protocol. > > Enterprise customers that wish to block all UDP traffic at their > firewall have asked for a way to enable the use of this application > using some sort of proxy. > > TURN appears to provide the most convenient UDP-UDP proxy mechanism > that we've seen specs for, though this application is somewhat > different than "TURN server on public Internet", and thus > assumptions and requirements are different than that case. > > A handful of questions: > > 1. Should we be looking at something else instead? (Not SOCKS, as > it doesn't appear to act as a UDP-UDP proxy and appears to require > a fixed destination address, both incompatible with our requirements) > > 2. Has there been any thought given to an advisory "User Agent" > parameter during association? Enterprises may wish to operate an > unauthenticated TURN proxy for their employees, but have at least > some guess as to what is using it. (Note that this is also a good > reason for continuing to allow an unauthenticated mode of operation > for TURN) > > 3. Has there been any thought given to a DHCP option for providing > clients with the address of a local TURN server? (This may seem > exactly backwards from the STUN goal of having the server > independent of the enterprise network so that the "outside" address > may be derived, but would help our application and also could > support enterprise policy about which STUN/TURN server they'd like > their VoIP phones using) > > Matthew Kaufman > matthew@matthew.at _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 6 13:59:02 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C1F03A6D35; Sun, 6 Apr 2008 13:59:02 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62DF43A6D35 for ; Sun, 6 Apr 2008 13:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a99T-iQ3AxhO for ; Sun, 6 Apr 2008 13:59:00 -0700 (PDT) Received: from where.matthew.at (unknown [IPv6:2001:5a8:4:39d1:201:3ff:fed1:d4f5]) by core3.amsl.com (Postfix) with ESMTP id C24EA3A6A88 for ; Sun, 6 Apr 2008 13:58:59 -0700 (PDT) Received: from [10.10.155.2] (matthew-desk.braemoor.net [10.10.155.2] (may be forged)) by where.matthew.at (8.11.3/8.11.3) with ESMTP id m36Kx0L26685; Sun, 6 Apr 2008 13:59:00 -0700 (PDT) (envelope-from matthew@matthew.at) Message-ID: <47F93994.8050005@matthew.at> Date: Sun, 06 Apr 2008 13:59:00 -0700 From: Matthew Kaufman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dan Wing References: <47F666EE.8080004@matthew.at> <15af01c896b6$fe4e0780$c5f0200a@cisco.com> In-Reply-To: <15af01c896b6$fe4e0780$c5f0200a@cisco.com> Cc: rohan@ekabal.com, behave@ietf.org, philip_matthews@magma.ca Subject: Re: [BEHAVE] TURN as enterprise proxy mechanism X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: matthew@matthew.at List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Dan Wing wrote: > http://www1.cs.columbia.edu/~lennox/udptunnel also uses fixed addresses, but > might be useful for you. For example, you could run a CGI on your proxy which > called udptunnel with the necessary UDPtunnel parameters. > > Appears to also suffer from the same "one allocation talks to one far host/port" problem. Our application requires that a single local (or proxied-local) UDP port be able to talk to multiple far UDP host/port. > A new STUN attribute could be defined for that. But of course there > wouldn't be any good way to authenticate its contents -- once someone > learns that 'udp-chat-1.0' and 'quake' are both acceptable for using > the TURN server, they'll configure other TURN-aware applications to > put those strings into that attribute. But if the applications and > the users are more-or-less trusted (which is often the case with > enterprises -- they can fire employees that subvert company policy), > it could be helpful for traffic statistics. > > That would be the utility, exactly. It could be used in enterprises where employees are entirely trusted for enabling/disabling certain applications, and in enterprises where employees are mostly trusted for logging (but not access control). >> 3. Has there been any thought given to a DHCP option for providing >> clients with the address of a local TURN server? > Nobody is working on that, but it seems reasonable to me -- it is > more reasonable than doing a DNS SRV query to find your TURN server. > > A drawback with DHCP options is the years it takes to get into > OSs and into DHCP servers. > Our application can make the DHCP query itself, and even my home firewall has the ability to set new custom DHCP options (unfortunately only top-level options, not ones that use the vendor class mechanism) Matthew Kaufman matthew@matthew.at _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 6 14:09:28 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA223A6D07; Sun, 6 Apr 2008 14:09:28 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E413A6A81 for ; Sun, 6 Apr 2008 14:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Se2k0F2p4Yw for ; Sun, 6 Apr 2008 14:09:26 -0700 (PDT) Received: from where.matthew.at (unknown [IPv6:2001:5a8:4:39d1:201:3ff:fed1:d4f5]) by core3.amsl.com (Postfix) with ESMTP id 0A25C3A6DE6 for ; Sun, 6 Apr 2008 14:09:25 -0700 (PDT) Received: from [10.10.155.2] (matthew-desk.braemoor.net [10.10.155.2] (may be forged)) by where.matthew.at (8.11.3/8.11.3) with ESMTP id m36L9TL26807; Sun, 6 Apr 2008 14:09:29 -0700 (PDT) (envelope-from matthew@matthew.at) Message-ID: <47F93C09.7090905@matthew.at> Date: Sun, 06 Apr 2008 14:09:29 -0700 From: Matthew Kaufman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Rohan Mahy References: <47F666EE.8080004@matthew.at> In-Reply-To: Cc: behave@ietf.org, philip_matthews@magma.ca Subject: Re: [BEHAVE] TURN as enterprise proxy mechanism X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: matthew@matthew.at List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Rohan Mahy wrote: > Hi Mathew, > > I think TURN is perfectly reasonable for your application. Thanks for the vote in favor... that gives me additional confidence that we're going down the right path. > > While you could define a new USER-AGENT or CLIENT attribute. I > definitely recommend against making any application unauthenticated in > an enterprise. The enterprise certainly has a username/password > directory (possibly more than one). I would suggest just using that > same directory. Some enterprises will want per-user authentication, others don't need it. Just as some enterprises require click-throughs or logins to use their outbound web proxy, and others allow all users access to the web. And like the web proxy, the reason TURN is even appropriate here is because some enterprises we've talked to feel it is more secure to funnel all UDP traffic for a particular application through a proxy that can do things like log usage than it is to just open up outbound UDP company-wide on the firewall. > > Why is DNS not working well for you? In my experience it is far easier > to configure and deploy a new SRV record than a new DHCP option. You > have to add the DHCP option on a per-scope (subnet) basis whereas the > SRV record is done once per zone (domain name). Any information you > can provide here would be useful. > We're trying to solve the same problem as WPAD (finding a proxy server for our client application), and DNS has the same (security) issues for us that it has for WPAD-using-DNS. Unless you're suggesting an SRV record in .local or something like that. Whether strange entries in a .local domain or new DHCP options is more likely to be accepted by an enterprise is an open question, though one could argue that at some multi-site organizations, having proxies per DHCP scope is more appropriate than proxies per scope-of-company-provided-DNS-resolver. We also need this application to "do the right thing" when it is installed in an environment other than an enterprise that has made the special configurations necessary to use it, which is to say not do things that would annoy consumer ISPs or expose the user to bad things. (DNS queries to .local probably fails the first, DNS queries up the chain of names as WPAD tried to do certainly fails the second) The alternative is for users in environments that need the traffic to pass through a TURN bottleneck to have to ues a settings dialog and/or edit a configuration file... we're just trying to avoid that, and thought that DHCP or similar auto-discovery might have already been explored for STUN/TURN. Matthew Kaufman matthew@matthew.at _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 7 06:24:56 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B08E83A6C5E; Mon, 7 Apr 2008 06:24:56 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B8023A6E90 for ; Mon, 7 Apr 2008 06:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XADuHzwJi77 for ; Mon, 7 Apr 2008 06:24:51 -0700 (PDT) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by core3.amsl.com (Postfix) with ESMTP id 66AE63A6C5E for ; Mon, 7 Apr 2008 06:24:51 -0700 (PDT) Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id CDF663EA0F2; Mon, 7 Apr 2008 15:25:03 +0200 (CEST) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 88C363EA158; Mon, 7 Apr 2008 15:24:50 +0200 (CEST) Message-ID: <47FA20BA.3090804@free.fr> Date: Mon, 07 Apr 2008 15:25:14 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: behave@ietf.org Cc: Brian Carpenter Subject: [BEHAVE] A Transition approach whereby NAT64s are not neeeded X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org The following draft has just been posted. http://www.ietf.org/internet-drafts/draft-despres-v6ops-apbp-00.txt It presents an approach whereby the IPv4-to-IPv6 transition period needs no NAT64s (only NAT44s, plus an address-port-borrowing protocol similar to that presented by Brian Carpenter in SHANTI). IMU, it concerns v6ops first, but has a relationship with some of the concerns of the Behave WG. Regards. R=E9mi _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 7 09:36:49 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24A5A28C383; Mon, 7 Apr 2008 09:36:49 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97D5428C383 for ; Mon, 7 Apr 2008 09:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.993 X-Spam-Level: X-Spam-Status: No, score=-4.993 tagged_above=-999 required=5 tests=[AWL=1.006, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnY4GM7DOug3 for ; Mon, 7 Apr 2008 09:36:47 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B5E683A6BF7 for ; Mon, 7 Apr 2008 09:36:47 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2008 09:37:01 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m37Gb1bh021558 for ; Mon, 7 Apr 2008 09:37:01 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m37Gb1Qg012058 for ; Mon, 7 Apr 2008 16:37:01 GMT From: "Dan Wing" To: Date: Mon, 7 Apr 2008 09:37:01 -0700 Message-ID: <1eda01c898cd$9b5362b0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciYwPROz17954BhSZ+HdQlLJVIHNwADJ3sA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2191; t=1207586221; x=1208450221; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20FW=3A=20TSVWG=20last=20call=20on=20=22UDP=20Usa ge=20Guidelines=20for=20Application=20Designers=22to=20BCP |Sender:=20; bh=Ghzg0sCOjMVhlSv5ejRDMKAOpZfvrl71mfvO80R1VGk=; b=ihCfM+XcHjoFTNGFKIIH43JTmMz77wyjoV2BqtoOPZ2u9lohvy7pw7i1hw DRwCxwXVJAiecZYbzT6jFkmECvu3z8dWc1c9RSa5zgBTtxteX4+ejMsV+WWB YxDg1bB5iU; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [BEHAVE] FW: TSVWG last call on "UDP Usage Guidelines for Application Designers"to BCP X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org = -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Magnus Westerlund Sent: Monday, April 07, 2008 8:06 AM To: discuss@apps.ietf.org Subject: TSVWG last call on "UDP Usage Guidelines for Application Designers= "to BCP Hi, I would like to inform that currently TSVWG has started the WG last call on "UDP Usage Guidelines for Application Designers" (draft-ietf-tsvwg-udp-guidelines-06) with the intended status of BCP. It runs until the 21st of April. If you like to provide any comments please send them to the TSVWG mailing list (tsvwg@ietf.org). Abstract: The User Datagram Protocol (UDP) provides a minimal, message-passing transport that has no inherent congestion control mechanisms. Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and establish some degree of fairness with concurrent traffic. This document provides guidelines on the use of UDP for the designers of such applications and upper-layer protocols. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums and middlebox traversal. http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-guidelines-06.txt Best Regards Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 7 11:27:24 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCB263A6EBE; Mon, 7 Apr 2008 11:27:24 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CAAC3A6C29 for ; Mon, 7 Apr 2008 11:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcA-Dy1zJc8z for ; Mon, 7 Apr 2008 11:27:23 -0700 (PDT) Received: from mail-05.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id E251528C376 for ; Mon, 7 Apr 2008 11:27:22 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Jiw34-00009f-2N for behave@ietf.org; Mon, 07 Apr 2008 14:26:30 -0400 Message-Id: <96609F5F-C1E9-405B-89E5-408C688429BE@magma.ca> From: Philip Matthews To: Behave WG Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 7 Apr 2008 14:27:33 -0400 X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Subject: [BEHAVE] TURN conf call Tuesday X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Just a last-minute reminder for anyone who has not already contacted me that the TURN conf call will take place tomorrow. Everyone who has contacted me should already have bridge information. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 7 14:08:05 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BCC63A69DE; Mon, 7 Apr 2008 14:08:05 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F0F3A681D for ; Mon, 7 Apr 2008 14:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gg43-VA0mEZW for ; Mon, 7 Apr 2008 14:08:03 -0700 (PDT) Received: from mail-07.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id C8BBF3A688C for ; Mon, 7 Apr 2008 14:08:03 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JiyZY-0003zs-1f; Mon, 07 Apr 2008 17:08:12 -0400 Message-Id: <1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca> From: Philip Matthews To: Behave WG In-Reply-To: <20080403171745.C40525081A@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 7 Apr 2008 17:08:15 -0400 References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <20080403171745.C40525081A@romeo.rtfm.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: David R Oran Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org After some off-line discussions, it seems the following anycast = procedure might work: 1. The TURN client uses ordinary TURN Allocate procedures to contact a = server at address X which, unbeknownst to it, is an anycast address. = The client can use UDP, TCP, or TLS transport. When replying, the = server uses anycast address X as the source address of its packets = (otherwise, this won't work through NATs). 2. The server uses ALTERNATE-SERVER to redirect the client to its own = unicast address. 3. The client doesn=92t know this is an anycast redirection, but just = follows ALTERNATE-SERVER rules to contact new server. Step 1 requires that the client be able to complete a multi-packet = exchange with the same server. In other words, this requires that all = the packets from the client get delivered to the same server (and not = two different servers). It seems that, for the short packet exchange = required, this is likely but not guaranteed. However, the client can easily detect when there is a problem. = Specifically: * If UDP transport is used, then a correct transaction is: send = Allocate with no credentials, gets back a 401 Unauthorized, resend = with correct credentials, get back Allocate response. However, if the = second Allocate is delivered to a different server, then the second = server will reject with a 401 Unauthorized (or perhaps a 438 Stale = Nonce). * If TCP or TLS over TCP transport is used, then the TCP connection = will eventually reset because the new server will not have any = connection state and will either reply with a TCP reset or just ignore = the packets. In either of these cases, if the client simply retries the request = from scratch, then it will be highly likely to succeed the second time. So with some simple rules for ALTERNATE-SERVER processing, plus a = little tweak to the rules for when to retry an Allocate request, it = seems that we may be able to get anycast to work. Comments? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 7 14:49:34 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FD613A6ED7; Mon, 7 Apr 2008 14:49:34 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A603A6ED5 for ; Mon, 7 Apr 2008 14:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXx6RFNaGpe8 for ; Mon, 7 Apr 2008 14:49:32 -0700 (PDT) Received: from mail-09.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 188E13A6EDB for ; Mon, 7 Apr 2008 14:49:32 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JizDm-0003tK-0Y for behave@ietf.org; Mon, 07 Apr 2008 17:49:46 -0400 Message-Id: <2F4AABB5-84E3-40EB-A081-BB051A413052@magma.ca> From: Philip Matthews To: Behave WG In-Reply-To: <1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 7 Apr 2008 17:49:45 -0400 References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <20080403171745.C40525081A@romeo.rtfm.com> <1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org A few more comments about ALTERNATE-SERVER. If anycast and redirection to a geographically-closer server are our intended uses for ALTERNATE- SERVER, then I think the more complex rules introduced in TURN-07 for ALTERNATE-SERVER are no longer required. Specifically, TURN-07 proposed that ALTERNATE-SERVER could appear alongside any error code (not just 300 Try Alternate), which conflicts with draft-ietf-behave- rfc3489bis. This allowed the client to see the error code and decide if it wanted to retry with a modified request to the same server, rather than contacting the alternate server. This was appropriate when we were thinking of ALTERNATE-SERVER as a way to find a server within a cluster that could handle a particular feature (e.g., a particularly large BANDWIDTH allocation). However, with the new view, this now seems less appropriate. So I am now thinking that TURN should revert to using ALTERNATE-SERVER only with 300 Try Alternate, which will simplify the error processing rules somewhat. The new rules would be: * A server redirects by using error code 300 (Try Alternate) and including an ALTERNATE-SERVER attribute. * The client SHOULD re-attempt the Allocate request with the alternate server, rather than trying the next server in the SRV list. * That alternate server MAY redirect to a second alternate, etc, however the client MUST NOT try the same server twice within a 5 minute period. * If the chain of redirections ultimately fails, the client MAY resume processing the SRV list. Comments? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 7 15:02:04 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CB823A68EA; Mon, 7 Apr 2008 15:02:04 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A92893A6A1C for ; Mon, 7 Apr 2008 15:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iw9Jd0J1OgvH for ; Mon, 7 Apr 2008 15:02:01 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id C017A3A683D for ; Mon, 7 Apr 2008 15:02:01 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 1A1855081A; Mon, 7 Apr 2008 15:04:05 -0700 (PDT) Date: Mon, 07 Apr 2008 15:04:05 -0700 From: Eric Rescorla To: Philip Matthews In-Reply-To: <1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca> References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <20080403171745.C40525081A@romeo.rtfm.com> <1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080407220405.1A1855081A@romeo.rtfm.com> Cc: David R Oran , Behave WG Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Mon, 7 Apr 2008 17:08:15 -0400, Philip Matthews wrote: > = > After some off-line discussions, it seems the following anycast = > procedure might work: > = > 1. The TURN client uses ordinary TURN Allocate procedures to contact a = > server at address X which, unbeknownst to it, is an anycast address. = > The client can use UDP, TCP, or TLS transport. When replying, the = > server uses anycast address X as the source address of its packets = > (otherwise, this won't work through NATs). > = > 2. The server uses ALTERNATE-SERVER to redirect the client to its own = > unicast address. > = > 3. The client doesn=92t know this is an anycast redirection, but just = > follows ALTERNATE-SERVER rules to contact new server. > = > Step 1 requires that the client be able to complete a multi-packet = > exchange with the same server. In other words, this requires that all = > the packets from the client get delivered to the same server (and not = > two different servers). It seems that, for the short packet exchange = > required, this is likely but not guaranteed. > = > However, the client can easily detect when there is a problem. = > Specifically: > * If UDP transport is used, then a correct transaction is: send = > Allocate with no credentials, gets back a 401 Unauthorized, resend = > with correct credentials, get back Allocate response. However, if the = > second Allocate is delivered to a different server, then the second = > server will reject with a 401 Unauthorized (or perhaps a 438 Stale = > Nonce). > * If TCP or TLS over TCP transport is used, then the TCP connection = > will eventually reset because the new server will not have any = > connection state and will either reply with a TCP reset or just ignore = > the packets. > = > In either of these cases, if the client simply retries the request = > from scratch, then it will be highly likely to succeed the second time. As I said in my comments to Hadriel, this is not guaranteed to work if the first and third packets of the TCP handshake go to different places (e.g., because of hash-based PPLB). > So with some simple rules for ALTERNATE-SERVER processing, plus a = > little tweak to the rules for when to retry an Allocate request, it = > seems that we may be able to get anycast to work. > = > Comments? Yes. Stop trying to fix this. If it turns out we actually need this we can do something new later. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 7 15:28:26 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72CA3A6D64; Mon, 7 Apr 2008 15:28:26 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A3603A6D64 for ; Mon, 7 Apr 2008 15:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdeBG5p+x0YY for ; Mon, 7 Apr 2008 15:28:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2E0653A6785 for ; Mon, 7 Apr 2008 15:28:25 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 7 Apr 2008 18:28:11 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 7 Apr 2008 18:28:11 -0400 From: Hadriel Kaplan To: Philip Matthews , Behave WG Date: Mon, 7 Apr 2008 18:27:33 -0400 Thread-Topic: [BEHAVE] ALTERNATE-SERVER and anycast Thread-Index: AciY83CMJRkxxRxyTKOsFGUTTuhxFQACutQg Message-ID: References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <20080403171745.C40525081A@romeo.rtfm.com> <1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca> In-Reply-To: <1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: David R Oran Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org This is an excellent idea, and a good compromise. -hadriel > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Monday, April 07, 2008 5:08 PM > To: Behave WG > Cc: Hadriel Kaplan; David R Oran; Eric Rescorla; Cullen Jennings > Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast > > After some off-line discussions, it seems the following anycast > procedure might work: > > 1. The TURN client uses ordinary TURN Allocate procedures to contact a > server at address X which, unbeknownst to it, is an anycast address. > The client can use UDP, TCP, or TLS transport. When replying, the > server uses anycast address X as the source address of its packets > (otherwise, this won't work through NATs). > > 2. The server uses ALTERNATE-SERVER to redirect the client to its own > unicast address. > > 3. The client doesn't know this is an anycast redirection, but just > follows ALTERNATE-SERVER rules to contact new server. > > Step 1 requires that the client be able to complete a multi-packet > exchange with the same server. In other words, this requires that all > the packets from the client get delivered to the same server (and not > two different servers). It seems that, for the short packet exchange > required, this is likely but not guaranteed. > > However, the client can easily detect when there is a problem. > Specifically: > * If UDP transport is used, then a correct transaction is: send > Allocate with no credentials, gets back a 401 Unauthorized, resend > with correct credentials, get back Allocate response. However, if the > second Allocate is delivered to a different server, then the second > server will reject with a 401 Unauthorized (or perhaps a 438 Stale > Nonce). > * If TCP or TLS over TCP transport is used, then the TCP connection > will eventually reset because the new server will not have any > connection state and will either reply with a TCP reset or just ignore > the packets. > > In either of these cases, if the client simply retries the request > from scratch, then it will be highly likely to succeed the second time. > > So with some simple rules for ALTERNATE-SERVER processing, plus a > little tweak to the rules for when to retry an Allocate request, it > seems that we may be able to get anycast to work. > > Comments? > > - Philip > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 7 15:46:04 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8073A6B44; Mon, 7 Apr 2008 15:46:04 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD6C3A6ABE for ; Mon, 7 Apr 2008 15:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmtPc7EIn11B for ; Mon, 7 Apr 2008 15:45:59 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id AE71F3A6BBE for ; Mon, 7 Apr 2008 15:45:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,619,1199692800"; d="scan'208";a="20359622" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 07 Apr 2008 15:45:23 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m37MjNn0029365; Mon, 7 Apr 2008 15:45:23 -0700 Received: from dwingwxp01 (dhcp-128-107-163-46.cisco.com [128.107.163.46]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m37MjN01011998; Mon, 7 Apr 2008 22:45:23 GMT From: "Dan Wing" To: "'Eric Rescorla'" , "'Philip Matthews'" References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca><20080403143033.7006250854@romeo.rtfm.com><20080403162320.E34475081A@romeo.rtfm.com><20080403171745.C40525081A@romeo.rtfm.com><1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca> <20080407220405.1A1855081A@romeo.rtfm.com> Date: Mon, 7 Apr 2008 15:45:23 -0700 Message-ID: <30fe01c89901$109b2840$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080407220405.1A1855081A@romeo.rtfm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciY+w8+IPSRqK84Qn6ZJV7oLOPkjwABZXFQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1135; t=1207608323; x=1208472323; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20ALTERNATE-SERVER=20and=20any cast |Sender:=20; bh=Nn47AOUX1bIzvukdaPUDUhg6XfaCCJjnV5/LyqXIMvI=; b=cAKtQPNrJdhH8xiF83Hl2t5oIJntrAwApm6Cj+SFTytwu93J9WxqsgZVGQ Rw/xHV2XfW/TFNVyhq8NOuDwMplBUUPgWryI8KMPrUq4nMKzjOmEHlCGE93b U//a1B/xHw; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'Behave WG' , 'David R Oran' Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > > In either of these cases, if the client simply retries the request > > from scratch, then it will be highly likely to succeed the > > second time. > > As I said in my comments to Hadriel, this is not guaranteed to work > if the first and third packets of the TCP handshake go to different > places (e.g., because of hash-based PPLB). PPLB = per packet load balancing, I presume. Can you point at a per-packet load balancer that would purposefully or accidentally (through misconfiguration) send packets with the same 5-tuple to different servers? > > So with some simple rules for ALTERNATE-SERVER processing, plus a > > little tweak to the rules for when to retry an Allocate > > request, it > > seems that we may be able to get anycast to work. > > > > Comments? > > Yes. Stop trying to fix this. If it turns out we actually need this > we can do something new later. It has been brought up that we won't be able to introduce Alternate-Server later if existing clients would ignore it. We could only, at that later date, use DNS to steer TURN clients to certain TURN servers. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 7 15:53:20 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD6323A684B; Mon, 7 Apr 2008 15:53:20 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9E463A6862 for ; Mon, 7 Apr 2008 15:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLkl9AuPrRZF for ; Mon, 7 Apr 2008 15:53:19 -0700 (PDT) Received: from mail-01.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 088A53A684B for ; Mon, 7 Apr 2008 15:53:18 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Jj0DU-0001ZP-0O; Mon, 07 Apr 2008 18:53:32 -0400 Message-Id: <3B6C8481-9BA3-49A4-90B0-B3DCC7CD5E3C@magma.ca> From: Philip Matthews To: Benny Prijono In-Reply-To: <1879720d0804040328m4d9164a3l2d9e9f5655ecb43d@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 7 Apr 2008 18:53:31 -0400 References: <5AE36F39-B800-45FD-A4CF-261EEE6BD191@cisco.com> <6CA00DCC-A48A-47DA-8CD3-9BB47C891068@magma.ca> <38F521F6-E706-40F5-B1C7-08A2CCAC7EA0@cisco.com> <9B9EE332-F142-4A2A-9985-D771D1A276CB@magma.ca> <1879720d0803250458t3389ed38j8db079c9b08b7e64@mail.gmail.com> <724EB65E-E362-4789-BE5B-10B1C4A1A00F@magma.ca> <1879720d0804020513t368824cdhaef7af940fb6cf4a@mail.gmail.com> <020167B5-CB15-4BAE-AE0E-5D1DF3EE4D26@magma.ca> <1879720d0804040328m4d9164a3l2d9e9f5655ecb43d@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: Behave WG Subject: Re: [BEHAVE] TURN: Are unauthenticated indications and ChannelData msgs a problem? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Fri, 4-Apr-08, at 06:28 , Benny Prijono wrote: > > > So to put all the new options on the table (in addition to your > previous mail in this thread): > - Option F: allow Allocate and Refresh with multiple PEER-ADDRESS > attributes to create/refresh permissions > - Option G: not to provide mechanism to refresh permission alone, and > instead force everyone to use channels (variant of option C) Hmmm. This option has some appeal, especially since it would suggest that we should remove Send indications at the same time, since their usefulness would go down a lot. This option would solve the problem AND simplify the protocol. The only drawback would be the larger number of channels allocated (presumably some just temporarily while doing ICE connectivity checks) but is this really bad? > > - Option H: use Send request - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 7 16:23:09 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886D13A6BDD; Mon, 7 Apr 2008 16:23:09 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB69C3A6BDD for ; Mon, 7 Apr 2008 16:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgS+zpF245SK for ; Mon, 7 Apr 2008 16:23:08 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id F38813A6904 for ; Mon, 7 Apr 2008 16:23:07 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id C21AA5081A; Mon, 7 Apr 2008 16:25:11 -0700 (PDT) Date: Mon, 07 Apr 2008 16:25:11 -0700 From: Eric Rescorla To: "Dan Wing" In-Reply-To: <30fe01c89901$109b2840$c5f0200a@cisco.com> References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <20080403171745.C40525081A@romeo.rtfm.com> <1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca> <20080407220405.1A1855081A@romeo.rtfm.com> <30fe01c89901$109b2840$c5f0200a@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080407232511.C21AA5081A@romeo.rtfm.com> Cc: 'Behave WG' , 'David R Oran' , 'Philip Matthews' Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Mon, 7 Apr 2008 15:45:23 -0700, Dan Wing wrote: > > > > > In either of these cases, if the client simply retries the request > > > from scratch, then it will be highly likely to succeed the > > > second time. > > > > As I said in my comments to Hadriel, this is not guaranteed to work > > if the first and third packets of the TCP handshake go to different > > places (e.g., because of hash-based PPLB). > > PPLB = per packet load balancing, I presume. > > Can you point at a per-packet load balancer that would purposefully > or accidentally (through misconfiguration) send packets with the same > 5-tuple to different servers? Why is that relevant? As I noted earlier, the issue isn't what the current network does but rather that there is no guarantee that a future network will not do this in the future. Designing a system that relies on a property of the network that is not one of its architectural invariants is bad, because it sticks people in the future with the choice of breaking the system or retaining the invariant even if it's no longer a good idea. > > > So with some simple rules for ALTERNATE-SERVER processing, plus a > > > little tweak to the rules for when to retry an Allocate > > > request, it > > > seems that we may be able to get anycast to work. > > > > > > Comments? > > > > Yes. Stop trying to fix this. If it turns out we actually need this > > we can do something new later. > > It has been brought up that we won't be able to introduce > Alternate-Server later if existing clients would ignore > it. We could only, at that later date, use DNS to steer > TURN clients to certain TURN servers. I didn't say anything about introducing alternate server. What I said was that if anycast was needed in the future, we could add that. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 7 16:28:31 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 019B03A6904; Mon, 7 Apr 2008 16:28:31 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B95C83A6904 for ; Mon, 7 Apr 2008 16:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUEHUpmSVe85 for ; Mon, 7 Apr 2008 16:28:29 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id AD3BF3A6851 for ; Mon, 7 Apr 2008 16:28:29 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 7 Apr 2008 19:28:16 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 7 Apr 2008 19:28:16 -0400 From: Hadriel Kaplan To: Dan Wing , 'Eric Rescorla' , 'Philip Matthews' Date: Mon, 7 Apr 2008 19:27:38 -0400 Thread-Topic: [BEHAVE] ALTERNATE-SERVER and anycast Thread-Index: AciY+w8+IPSRqK84Qn6ZJV7oLOPkjwABZXFQAAD0JUA= Message-ID: References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca><20080403143033.7006250854@romeo.rtfm.com><20080403162320.E34475081A@romeo.rtfm.com><20080403171745.C40525081A@romeo.rtfm.com><1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca> <20080407220405.1A1855081A@romeo.rtfm.com> <30fe01c89901$109b2840$c5f0200a@cisco.com> In-Reply-To: <30fe01c89901$109b2840$c5f0200a@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: 'David R Oran' , 'Behave WG' Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Dan Wing > > It has been brought up that we won't be able to introduce > Alternate-Server later if existing clients would ignore > it. We could only, at that later date, use DNS to steer > TURN clients to certain TURN servers. Yes it will be much easier to know when to stop servers from doing it if the Internet routing model changes, than to know when to start doing it when it doesn't. ;) But anyway this is whole argument is a non sequitur against ALTERNATE-SERVER. There are other reasons for having it, regardless of anycasting. For example: 1) Wanting to gracefully shed load temporarily from a server, and use a local alternate backup; for example to avoid service outages for a planned maintenance. (DNS caching issues would make that very difficult) 2) Having a couple load-balancers redirect clients to one of possibly hundreds of servers, without having to change DNS every time a new server is added. (e.g., think "Google") 3) Doing anycasting to servers in a physically or virtually constrained network topology; for example a 3G or 4G access provider, or a broadband provider, which can offer TURN servers to their customers while also controlling their network routing equipment. 4) Having an intelligent redirector which redirects clients based on their user/realm, or type of allocations, or whatever. For example, if the server can do IPv4-IPv4 relaying but has a twin server which does IPv4/v6. -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 7 16:36:48 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8376028C119; Mon, 7 Apr 2008 16:36:48 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF4028C119 for ; Mon, 7 Apr 2008 16:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuyb6DnbjbHr for ; Mon, 7 Apr 2008 16:36:46 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id B41383A67DF for ; Mon, 7 Apr 2008 16:36:46 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 681F25081A; Mon, 7 Apr 2008 16:38:50 -0700 (PDT) Date: Mon, 07 Apr 2008 16:38:50 -0700 From: Eric Rescorla To: Hadriel Kaplan In-Reply-To: References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <20080403171745.C40525081A@romeo.rtfm.com> <1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca> <20080407220405.1A1855081A@romeo.rtfm.com> <30fe01c89901$109b2840$c5f0200a@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080407233850.681F25081A@romeo.rtfm.com> Cc: 'David R Oran' , 'Behave WG' , Dan Wing , 'Philip Matthews' Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Mon, 7 Apr 2008 19:27:38 -0400, Hadriel Kaplan wrote: > > > > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > > Of Dan Wing > > > > It has been brought up that we won't be able to introduce > > Alternate-Server later if existing clients would ignore > > it. We could only, at that later date, use DNS to steer > > TURN clients to certain TURN servers. > > Yes it will be much easier to know when to stop servers from doing it if the Internet routing model changes, than to know when to start doing it when it doesn't. ;) > > But anyway this is whole argument is a non sequitur against ALTERNATE-SERVER. There are other reasons for having it, regardless of anycasting. > > For example: > 1) Wanting to gracefully shed load temporarily from a server, and use a local alternate backup; for example to avoid service outages for a planned maintenance. (DNS caching issues would make that very difficult) As several people have noted, this creates the possibility of loops. Moreover, there are standard procedures here, namely load balancers. > 2) Having a couple load-balancers redirect clients to one of possibly hundreds of servers, without having to change DNS every time a new server is added. (e.g., think "Google") But of course this is not how Google works. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 7 16:49:25 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515C73A6CAE; Mon, 7 Apr 2008 16:49:25 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71D433A6C1F for ; Mon, 7 Apr 2008 16:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.328 X-Spam-Level: X-Spam-Status: No, score=-5.328 tagged_above=-999 required=5 tests=[AWL=1.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYr9ZKX8wZZb for ; Mon, 7 Apr 2008 16:49:23 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 295D428C16F for ; Mon, 7 Apr 2008 16:49:23 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 07 Apr 2008 16:49:37 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m37NnbZb022948; Mon, 7 Apr 2008 16:49:37 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m37NnaTn004981; Mon, 7 Apr 2008 23:49:36 GMT From: "Dan Wing" To: "'Eric Rescorla'" References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca><20080403143033.7006250854@romeo.rtfm.com><20080403162320.E34475081A@romeo.rtfm.com><20080403171745.C40525081A@romeo.rtfm.com><1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca><20080407220405.1A1855081A@romeo.rtfm.com><30fe01c89901$109b2840$c5f0200a@cisco.com> <20080407232511.C21AA5081A@romeo.rtfm.com> Date: Mon, 7 Apr 2008 16:49:36 -0700 Message-ID: <318901c8990a$09e8e600$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080407232511.C21AA5081A@romeo.rtfm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciZBmCfstVxqb46RAKM6ZiWiWMN6wAAf+hg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2753; t=1207612177; x=1208476177; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20ALTERNATE-SERVER=20and=20any cast |Sender:=20; bh=FgROY/wR7Sua2IkenWPmNRMiyEC77l264RWT7/ajIZE=; b=dJigJq8VVAvrJ4W5yyEWZuVOzg315qt2tiZto3vGLJuZsXqLpf9NKzgrjR n6u6ae4xkphPlYsxfOXTrG2hgLJRqN4GTLhkS4O+/WvI9o5iGQW8rvLwm4iz V7ARfdGYH+; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'David R Oran' , 'Behave WG' , 'Philip Matthews' Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Eric Rescorla > Sent: Monday, April 07, 2008 4:25 PM > To: Dan Wing > Cc: 'Behave WG'; 'David R Oran'; 'Philip Matthews' > Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast > > At Mon, 7 Apr 2008 15:45:23 -0700, > Dan Wing wrote: > > > > > > > > In either of these cases, if the client simply retries > the request > > > > from scratch, then it will be highly likely to succeed the > > > > second time. > > > > > > As I said in my comments to Hadriel, this is not > guaranteed to work > > > if the first and third packets of the TCP handshake go to > different > > > places (e.g., because of hash-based PPLB). > > > > PPLB = per packet load balancing, I presume. > > > > Can you point at a per-packet load balancer that would purposefully > > or accidentally (through misconfiguration) send packets > with the same > > 5-tuple to different servers? > > Why is that relevant? > > As I noted earlier, the issue isn't what the current network > does but rather that there is no guarantee that a future network > will not do this in the future. Designing a system that relies > on a property of the network that is not one of its architectural > invariants is bad, because it sticks people in the future with > the choice of breaking the system or retaining the invariant > even if it's no longer a good idea. ALTERNATE-SERVER does not require the TURN servers to use anycast. If, in some future where anycasting works differently, that anycasted TURN server can avoid using ALTERNATE-SERVER and can do something new and fancy. Today, there appears to be at least one company that has found anycast with TCP works: http://www.nanog.org/mtg-0606/pdf/matt.levine.pdf > > > > So with some simple rules for ALTERNATE-SERVER > > > > processing, plus a > > > > little tweak to the rules for when to retry an Allocate > > > > request, it > > > > seems that we may be able to get anycast to work. > > > > > > > > Comments? > > > > > > Yes. Stop trying to fix this. If it turns out we actually > > > need this > > > we can do something new later. > > > > It has been brought up that we won't be able to introduce > > Alternate-Server later if existing clients would ignore > > it. We could only, at that later date, use DNS to steer > > TURN clients to certain TURN servers. > > I didn't say anything about introducing alternate server. What I > said was that if anycast was needed in the future, we could add > that. So you're saying we should use something other than anycast to justify inclusion of the ALTERNATE-SERVER attribute ? -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 7 20:27:21 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426F43A6AC3; Mon, 7 Apr 2008 20:27:21 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 541683A6AC3 for ; Mon, 7 Apr 2008 20:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRFfSLR0O35S for ; Mon, 7 Apr 2008 20:27:19 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 80CF13A6A56 for ; Mon, 7 Apr 2008 20:27:19 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 7 Apr 2008 23:27:06 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 7 Apr 2008 23:27:06 -0400 From: Hadriel Kaplan To: Eric Rescorla Date: Mon, 7 Apr 2008 23:24:58 -0400 Thread-Topic: [BEHAVE] ALTERNATE-SERVER and anycast Thread-Index: AciZCDgpceCZQG8oSGi3dy4AWdYjQAAHlHHg Message-ID: References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <20080403171745.C40525081A@romeo.rtfm.com> <1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca> <20080407220405.1A1855081A@romeo.rtfm.com> <30fe01c89901$109b2840$c5f0200a@cisco.com> <20080407233850.681F25081A@romeo.rtfm.com> In-Reply-To: <20080407233850.681F25081A@romeo.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: 'David R Oran' , 'Behave WG' , 'Philip Matthews' , Dan Wing Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > > > For example: > > 1) Wanting to gracefully shed load temporarily from a server, and use a > local alternate backup; for example to avoid service outages for a planned > maintenance. (DNS caching issues would make that very difficult) > > As several people have noted, this creates the possibility of loops. > Moreover, there are > standard procedures here, namely load balancers. But I thought your argument against anycast was load-balancers could screw up how they load-balance! (just kidding!:) Anyway, no, load-balancers don't always work for this, if you mean of the inline variety. They can - they just restrict things topologically. I think you're thinking central data centers, and I'm thinking distributed PoP's/CO's, where inline load-balancers aren't always reasonably worth it. > > 2) Having a couple load-balancers redirect clients to one of possibly > hundreds of servers, without having to change DNS every time a new server > is added. (e.g., think "Google") > > But of course this is not how Google works. Oh I have no idea how Google works for TURN servers, and didn't mean they did. (I realize they don't work that way for HTTP servers) I just meant one *could* do it that way. -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 7 21:43:06 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1D73A6E0A; Mon, 7 Apr 2008 21:43:06 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A03D53A6E14 for ; Mon, 7 Apr 2008 21:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lj0XgvEHpaAm for ; Mon, 7 Apr 2008 21:42:59 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id ECC0D3A6DBD for ; Mon, 7 Apr 2008 21:42:58 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 417045081A; Mon, 7 Apr 2008 21:45:03 -0700 (PDT) Date: Mon, 07 Apr 2008 21:45:03 -0700 From: Eric Rescorla To: "Dan Wing" In-Reply-To: <318901c8990a$09e8e600$c5f0200a@cisco.com> References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <20080403171745.C40525081A@romeo.rtfm.com> <1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca> <20080407220405.1A1855081A@romeo.rtfm.com> <30fe01c89901$109b2840$c5f0200a@cisco.com> <20080407232511.C21AA5081A@romeo.rtfm.com> <318901c8990a$09e8e600$c5f0200a@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080408044503.417045081A@romeo.rtfm.com> Cc: 'David R Oran' , 'Behave WG' , 'Philip Matthews' Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Mon, 7 Apr 2008 16:49:36 -0700, Dan Wing wrote: > > > > > -----Original Message----- > > From: behave-bounces@ietf.org > > [mailto:behave-bounces@ietf.org] On Behalf Of Eric Rescorla > > Sent: Monday, April 07, 2008 4:25 PM > > To: Dan Wing > > Cc: 'Behave WG'; 'David R Oran'; 'Philip Matthews' > > Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast > > > > At Mon, 7 Apr 2008 15:45:23 -0700, > > Dan Wing wrote: > > > > > > > > > > > In either of these cases, if the client simply retries > > the request > > > > > from scratch, then it will be highly likely to succeed the > > > > > second time. > > > > > > > > As I said in my comments to Hadriel, this is not > > guaranteed to work > > > > if the first and third packets of the TCP handshake go to > > different > > > > places (e.g., because of hash-based PPLB). > > > > > > PPLB = per packet load balancing, I presume. > > > > > > Can you point at a per-packet load balancer that would purposefully > > > or accidentally (through misconfiguration) send packets > > with the same > > > 5-tuple to different servers? > > > > Why is that relevant? > > > > As I noted earlier, the issue isn't what the current network > > does but rather that there is no guarantee that a future network > > will not do this in the future. Designing a system that relies > > on a property of the network that is not one of its architectural > > invariants is bad, because it sticks people in the future with > > the choice of breaking the system or retaining the invariant > > even if it's no longer a good idea. > > ALTERNATE-SERVER does not require the TURN servers to use > anycast. If, in some future where anycasting works > differently, that anycasted TURN server can avoid using > ALTERNATE-SERVER and can do something new and fancy. > > Today, there appears to be at least one company > that has found anycast with TCP works: > http://www.nanog.org/mtg-0606/pdf/matt.levine.pdf For the third time, now: the issue is not what currently works but what the architecture of the Internet guarantees. > > I didn't say anything about introducing alternate server. What I > > said was that if anycast was needed in the future, we could add > > that. > > So you're saying we should use something other than anycast > to justify inclusion of the ALTERNATE-SERVER attribute ? Uh, no. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 8 07:05:39 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EE0928C3C8; Tue, 8 Apr 2008 07:05:39 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F12063A6E64 for ; Tue, 8 Apr 2008 07:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPIbhDytp8X4 for ; Tue, 8 Apr 2008 07:05:31 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D934028C3DA for ; Tue, 8 Apr 2008 07:05:26 -0700 (PDT) Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 08 Apr 2008 07:05:42 -0700 Received: from stealth-10-32-245-152.cisco.com ([10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m38Dnbvw014709; Tue, 8 Apr 2008 06:49:38 -0700 Message-Id: <624FDF7B-22A6-49AD-8665-C439618F6034@cisco.com> From: David R Oran To: Philip Matthews In-Reply-To: <1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 8 Apr 2008 10:05:38 -0400 References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <20080403171745.C40525081A@romeo.rtfm.com> <1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca> X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2785; t=1207662578; x=1208526578; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[BEHAVE]=20ALTERNATE-SERVER=20and=20any cast |Sender:=20 |To:=20Philip=20Matthews=20; bh=kMmyF1WCPlCLVsWzXymbm026LYBul9sXeBCMhMFsk6E=; b=Z2oS/D+pGLkH8iSXKh7QQTMFBch8S6ZqvcQY3ZEdAWTmfPBCJMZWzc9uvc SoOGFDzSigpIR21W+9vla5V+pvKL5h+GTWkmKPHCMbBN8i5MatG7UBiPB4QD WtZrDq96O5; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: Behave WG Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Apr 7, 2008, at 5:08 PM, Philip Matthews wrote: > After some off-line discussions, it seems the following anycast = > procedure might work: > > 1. The TURN client uses ordinary TURN Allocate procedures to contact = > a server at address X which, unbeknownst to it, is an anycast = > address. The client can use UDP, TCP, or TLS transport. When = > replying, the server uses anycast address X as the source address of = > its packets (otherwise, this won't work through NATs). > > 2. The server uses ALTERNATE-SERVER to redirect the client to its = > own unicast address. > > 3. The client doesn=92t know this is an anycast redirection, but just = > follows ALTERNATE-SERVER rules to contact new server. > > Step 1 requires that the client be able to complete a multi-packet = > exchange with the same server. In other words, this requires that = > all the packets from the client get delivered to the same server = > (and not two different servers). It seems that, for the short packet = > exchange required, this is likely but not guaranteed. > > However, the client can easily detect when there is a problem. = > Specifically: > * If UDP transport is used, then a correct transaction is: send = > Allocate with no credentials, gets back a 401 Unauthorized, resend = > with correct credentials, get back Allocate response. However, if = > the second Allocate is delivered to a different server, then the = > second server will reject with a 401 Unauthorized (or perhaps a 438 = > Stale Nonce). > * If TCP or TLS over TCP transport is used, then the TCP connection = > will eventually reset because the new server will not have any = > connection state and will either reply with a TCP reset or just = > ignore the packets. > > In either of these cases, if the client simply retries the request = > from scratch, then it will be highly likely to succeed the second = > time. > > So with some simple rules for ALTERNATE-SERVER processing, plus a = > little tweak to the rules for when to retry an Allocate request, it = > seems that we may be able to get anycast to work. > > Comments? > I'd far prefer a completely separate discovery exchange with UDP. If = the only reason we're doing this is to not delay publication of TURN, = I think it's a sub-optimal tradeoff. As a counter-proposal, how about = not supporting anycast until we have a TURN protocol enhancement = defined to do TURN server detection with anycast. Once we go down this = path I suspect the "right thing" will never happen and we'll have yet = another application protocol that has tight dependency on current = routing behavior. DaveO. > - Philip > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 8 08:01:53 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E133A6CFB; Tue, 8 Apr 2008 08:01:53 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258433A6CD4 for ; Tue, 8 Apr 2008 08:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.593 X-Spam-Level: X-Spam-Status: No, score=-4.593 tagged_above=-999 required=5 tests=[AWL=2.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGHO8528ZyOT for ; Tue, 8 Apr 2008 08:01:51 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EF2DD3A6A67 for ; Tue, 8 Apr 2008 08:01:50 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 08 Apr 2008 08:02:07 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m38F27bf012050; Tue, 8 Apr 2008 08:02:07 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.13.8/8.13.8) with SMTP id m38F26Eo003814; Tue, 8 Apr 2008 15:02:06 GMT From: Cullen Jennings To: Philip Matthews In-Reply-To: <1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca> Impp: xmpp:cullenfluffyjennings@jabber.org References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <20080403171745.C40525081A@romeo.rtfm.com> <1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca> Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 8 Apr 2008 08:01:53 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3405; t=1207666927; x=1208530927; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20ALTERNATE-SERVER=20and=20any cast |Sender:=20; bh=X3RMiwdNuFX4j9Z7g6/mayUZZU/Or5DKTaVsNccxBag=; b=QYBRBwNQR2zNBOfOCeXlX6xQ0XeC/+jDO6Lj0ltr8Zfa7r8H4bGi/ENyGJ VCZGsCioOVuPzYjQX3vLDbR74kBsbK0z3kHaRo9LleR5rhyIiECidxMlR6QC XPKg05cLvH; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: David R Oran , Behave WG Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org One comment. This is not a good way to do anycast for reasons = previously given. However, I would be very interested in understanding if anyone sees = problems with On Apr 2, 2008, at 3:41 PM, Cullen Jennings wrote: > > > 1) client is configured with TURN server of turn.example.com > > 2) client does an SRV lookup and finds there is no TCP service but > there is a UDP service at 1.1.1.1 > > 3) client sends an UDP packet to 1.1.1.1 which happens to be an > anycast IP. > > 4) Some server gets this and responds with a redirect to 2.2.2.2 > along with info to use TLS. The address 2.2.2.2 is not an anycast > address but goes to a single machine with a TURN server > > 5) client does TLS to 2.2.2.2. Server presents certificate with name > turn.example.com > > 6) client check certificate matches the name that it has in it's > config. > > This approach is susceptible to being DOSed by a well timed response > to the UDP request to 1.1.1.1 but seemed like a risk we were willing > to live with. Presumably some secret material would be copied from > request in step 3 to the response in step 4 to force the attacker to > be on-path. On Apr 7, 2008, at 2:08 PM, Philip Matthews wrote: > After some off-line discussions, it seems the following anycast = > procedure might work: > > 1. The TURN client uses ordinary TURN Allocate procedures to contact = > a server at address X which, unbeknownst to it, is an anycast = > address. The client can use UDP, TCP, or TLS transport. When = > replying, the server uses anycast address X as the source address of = > its packets (otherwise, this won't work through NATs). > > 2. The server uses ALTERNATE-SERVER to redirect the client to its = > own unicast address. > > 3. The client doesn=92t know this is an anycast redirection, but just = > follows ALTERNATE-SERVER rules to contact new server. > > Step 1 requires that the client be able to complete a multi-packet = > exchange with the same server. In other words, this requires that = > all the packets from the client get delivered to the same server = > (and not two different servers). It seems that, for the short packet = > exchange required, this is likely but not guaranteed. > > However, the client can easily detect when there is a problem. = > Specifically: > * If UDP transport is used, then a correct transaction is: send = > Allocate with no credentials, gets back a 401 Unauthorized, resend = > with correct credentials, get back Allocate response. However, if = > the second Allocate is delivered to a different server, then the = > second server will reject with a 401 Unauthorized (or perhaps a 438 = > Stale Nonce). > * If TCP or TLS over TCP transport is used, then the TCP connection = > will eventually reset because the new server will not have any = > connection state and will either reply with a TCP reset or just = > ignore the packets. > > In either of these cases, if the client simply retries the request = > from scratch, then it will be highly likely to succeed the second = > time. > > So with some simple rules for ALTERNATE-SERVER processing, plus a = > little tweak to the rules for when to retry an Allocate request, it = > seems that we may be able to get anycast to work. > > Comments? > > - Philip > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 8 08:03:44 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBBB83A6C0A; Tue, 8 Apr 2008 08:03:44 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 885383A6C0A for ; Tue, 8 Apr 2008 08:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAzCsapbRQ+L for ; Tue, 8 Apr 2008 08:03:42 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1DDC73A6CD4 for ; Tue, 8 Apr 2008 08:03:42 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 08 Apr 2008 08:03:58 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m38F3ww8014778; Tue, 8 Apr 2008 08:03:58 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.13.8/8.13.8) with SMTP id m38F3wU8013349; Tue, 8 Apr 2008 15:03:58 GMT From: Cullen Jennings To: Dan Wing In-Reply-To: <1ab601c88469$44427e20$bd4f150a@cisco.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <1ab601c88469$44427e20$bd4f150a@cisco.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 8 Apr 2008 08:03:44 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=795; t=1207667038; x=1208531038; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20Jabber=20for=20upcoming=20Be have=20meeting |Sender:=20; bh=lX4AcwFqqx7W4EMbjidi82mt3iLimUVZz/RWF7OerP0=; b=sdhSwZLdwXFcGQdlQOohBRR+b3vC4LBoel5ab8xGLO3WNQpoQP6uhJ/G6j 1J0hg2Ht0Gm64QR1Rpx7+LDjszcjlt2dise7DZT16YGJ5akCrhEOE1KHAdDW S9MEKAJwlB; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'Behave WG' Subject: Re: [BEHAVE] Jabber for upcoming Behave meeting X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I'm confused - you mean he is going to participate via jabber but can't be bothered to dial in to the phone call? If the issues is long distance charges you can dial out to him and bill it to Cisco. On Mar 12, 2008, at 10:48 AM, Dan Wing wrote: > Marc Petit-Huguenin (and perhaps other people) is participating > remotely, and > jabber would be a good way to allow him to raise points during the > meeting. I > would like a volunteer or two that will be at the BEHAVE meeting to > also be in > the Jabber room. If possible, some Jabber note-taking would be > helpful, but > not absolutely necessary. > > Thanks, > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 8 08:04:59 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADB583A6CFB; Tue, 8 Apr 2008 08:04:59 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45D753A6D64 for ; Tue, 8 Apr 2008 08:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpsaTj3RVxIR for ; Tue, 8 Apr 2008 08:04:57 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5C42B3A69F2 for ; Tue, 8 Apr 2008 08:04:56 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 08 Apr 2008 08:05:12 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m38F5CCT015746; Tue, 8 Apr 2008 08:05:12 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.13.8/8.13.8) with SMTP id m38F5CYk014284; Tue, 8 Apr 2008 15:05:12 GMT From: Cullen Jennings To: Dan Wing In-Reply-To: <1ab601c88469$44427e20$bd4f150a@cisco.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <1ab601c88469$44427e20$bd4f150a@cisco.com> Message-Id: <7DD3C6DE-C95E-4B49-A6C9-1899B06EDD3D@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 8 Apr 2008 08:04:59 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=752; t=1207667112; x=1208531112; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20Jabber=20for=20upcoming=20Be have=20meeting |Sender:=20; bh=fBy9PWXLWkgPzamyeyiD4D8v4GNSlT/W1VEk2306mNw=; b=m6LFvBboCG7SEvvaYV69l3SDctTRd99pRqtavzE+8sqtAGFQ3vCm/iTr0A MvLUp6cL49e+X48Cu5NdUSwADuRNSL61lF5F6QqjfUlwYSOUgA6cY775Gwaw L2xbn7YVzA; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Behave WG' Subject: Re: [BEHAVE] Jabber for upcoming Behave meeting X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org never mind last email - I had the wrong date for this - I thought it was about todays meeting due to my email server marking all behave email as from today. On Mar 12, 2008, at 10:48 AM, Dan Wing wrote: > Marc Petit-Huguenin (and perhaps other people) is participating > remotely, and > jabber would be a good way to allow him to raise points during the > meeting. I > would like a volunteer or two that will be at the BEHAVE meeting to > also be in > the Jabber room. If possible, some Jabber note-taking would be > helpful, but > not absolutely necessary. > > Thanks, > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 8 08:08:53 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6ADC3A69F2; Tue, 8 Apr 2008 08:08:53 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EAB53A69F2 for ; Tue, 8 Apr 2008 08:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWVPmC740Paj for ; Tue, 8 Apr 2008 08:08:49 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id A29083A6900 for ; Tue, 8 Apr 2008 08:08:49 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 58073D9D4262; Tue, 8 Apr 2008 15:09:05 +0000 (UTC) Received: from [192.168.1.3] (c-67-161-24-129.hsd1.ca.comcast.net [67.161.24.129]) by server.implementers.org (Postfix) with ESMTP id 22421D9D4246; Tue, 8 Apr 2008 15:09:00 +0000 (UTC) Message-ID: <47FB8A8B.40000@acm.org> Date: Tue, 08 Apr 2008 08:08:59 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.12 (X11/20080405) MIME-Version: 1.0 To: Cullen Jennings References: <1ab601c88469$44427e20$bd4f150a@cisco.com> In-Reply-To: Cc: 'Behave WG' , Dan Wing Subject: Re: [BEHAVE] Jabber for upcoming Behave meeting X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Cullen Jennings wrote: > I'm confused - you mean he is going to participate via jabber but > can't be bothered to dial in to the phone call? If the issues is long > distance charges you can dial out to him and bill it to Cisco. What are you talking about? This was for the IETF meeting, not the conference call. > > On Mar 12, 2008, at 10:48 AM, Dan Wing wrote: >> Marc Petit-Huguenin (and perhaps other people) is participating >> remotely, and >> jabber would be a good way to allow him to raise points during the >> meeting. I >> would like a volunteer or two that will be at the BEHAVE meeting to >> also be in >> the Jabber room. If possible, some Jabber note-taking would be >> helpful, but >> not absolutely necessary. >> >> Thanks, >> -d -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 8 08:11:42 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BC583A6A99; Tue, 8 Apr 2008 08:11:42 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 347213A69F2 for ; Tue, 8 Apr 2008 08:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=1.900, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsUZJjIze4g9 for ; Tue, 8 Apr 2008 08:11:37 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id EC0B03A6A99 for ; Tue, 8 Apr 2008 08:11:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,624,1199692800"; d="scan'208";a="10497018" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 08 Apr 2008 08:11:53 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m38FBrO4003333; Tue, 8 Apr 2008 08:11:53 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.13.8/8.13.8) with SMTP id m38FBqvf010258; Tue, 8 Apr 2008 15:11:52 GMT From: Cullen Jennings To: Philip Matthews In-Reply-To: <3B6C8481-9BA3-49A4-90B0-B3DCC7CD5E3C@magma.ca> Impp: xmpp:cullenfluffyjennings@jabber.org References: <5AE36F39-B800-45FD-A4CF-261EEE6BD191@cisco.com> <6CA00DCC-A48A-47DA-8CD3-9BB47C891068@magma.ca> <38F521F6-E706-40F5-B1C7-08A2CCAC7EA0@cisco.com> <9B9EE332-F142-4A2A-9985-D771D1A276CB@magma.ca> <1879720d0803250458t3389ed38j8db079c9b08b7e64@mail.gmail.com> <724EB65E-E362-4789-BE5B-10B1C4A1A00F@magma.ca> <1879720d0804020513t368824cdhaef7af940fb6cf4a@mail.gmail.com> <020167B5-CB15-4BAE-AE0E-5D1DF3EE4D26@magma.ca> <1879720d0804040328m4d9164a3l2d9e9f5655ecb43d@mail.gmail.com> <3B6C8481-9BA3-49A4-90B0-B3DCC7CD5E3C@magma.ca> Message-Id: <065C993A-5D81-4D3A-81FB-18F574D824CF@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 8 Apr 2008 08:11:39 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1216; t=1207667513; x=1208531513; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=3A=20Are=20unauthentica ted=20indications=20and=20ChannelData=20msgs=20a=20problem? |Sender:=20; bh=4Ksjpt/WgiU9ElBSZ5u+NrNQIF/81ZI71nYl7ypCH7o=; b=Z1MDotseju1a0Q8TqlmmYEZW7kdYXk9UljfB9PCYN1WOqvBUSiec3C/LOq U3obUPQ1zYE1wMSWtzLNhpw7ox8h4xXvZnnwJa+gYCWnNNtdCFAhkdOhf6mq MzscDJl2po; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Behave WG Subject: Re: [BEHAVE] TURN: Are unauthenticated indications and ChannelData msgs a problem? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I think I would need to seem more details on some of these before I could figure out which one looked like the best path. On Apr 7, 2008, at 3:53 PM, Philip Matthews wrote: > > On Fri, 4-Apr-08, at 06:28 , Benny Prijono wrote: >> >> >> So to put all the new options on the table (in addition to your >> previous mail in this thread): >> - Option F: allow Allocate and Refresh with multiple PEER-ADDRESS >> attributes to create/refresh permissions >> - Option G: not to provide mechanism to refresh permission alone, and >> instead force everyone to use channels (variant of option C) > > Hmmm. This option has some appeal, especially since it would suggest > that we should remove Send indications at the same time, since their > usefulness would go down a lot. This option would solve the problem > AND simplify the protocol. The only drawback would be the larger > number of channels allocated (presumably some just temporarily while > doing ICE connectivity checks) but is this really bad? > >> >> - Option H: use Send request > > - Philip > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 8 08:16:30 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55DF33A6E1C; Tue, 8 Apr 2008 08:16:30 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A98E3A6E20 for ; Tue, 8 Apr 2008 08:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[AWL=1.805, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uu69J-UjhyGQ for ; Tue, 8 Apr 2008 08:16:27 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A52EA3A6DA3 for ; Tue, 8 Apr 2008 08:16:27 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 08 Apr 2008 08:16:43 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m38FGhcP007073; Tue, 8 Apr 2008 08:16:43 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.13.8/8.13.8) with SMTP id m38FGgWG013335; Tue, 8 Apr 2008 15:16:42 GMT From: Cullen Jennings To: Hadriel Kaplan In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 8 Apr 2008 08:16:14 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8559; t=1207667803; x=1208531803; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=3A=20Cullen's=20suggest ion=20for=20setting=20the=20DF=20bit |Sender:=20; bh=Y/JMeXWSuyigCB9ExbbCJk/Lahy3pi4LeE9mKes/Q9w=; b=lbycO+YfVU4cVVrpc+ekklZsTZNOnU4JZ4oqifbAL9sn4ZWCvjIkvxpvnS JKhrVbAQCDoPwoF+mlZb8bwPzT7VuDJKXsByco3Ssg/TBzG4K6vbiKvD2gmS TgiAEjSsdi; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] TURN: Cullen's suggestion for setting the DF bit X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I'd like to discuss the implications of doing nothing on the call today if we can. On Apr 3, 2008, at 9:56 PM, Hadriel Kaplan wrote: > > I am (probably predictably) for the KISS principle, where the last S > is for Server, so I would prefer option 4: not interested. > > -hadriel "PITA" kaplan > > >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf >> Of Philip Matthews >> Sent: Thursday, April 03, 2008 11:40 AM >> To: Behave WG >> Subject: Re: [BEHAVE] TURN: Cullen's suggestion for setting the DF >> bit >> >> Just a reminder that I am still interested in getting feedback on >> these options. So far, I have only gotten one response. Not doing any >> of these is also an option, so feel free to say "I am not interested >> in this idea". >> - Philip >> >> On Thu, 20-Mar-08, at 17:15 , Philip Matthews wrote: >>> The proposal described in my e-mail message of 12 March (see the >>> bottom of this message) was discussed in the BEHAVE session to >>> mostly >>> favorable reception. However, Cullen suggested a modification that I >>> would like to get input on. >>> >>> At presently envisioned, in a partly-compliant allocation, if the >>> server cannot read the value of the incoming DF bit, then it SHOULD >>> clear the DF bit on the outgoing packet. This increases the chances >>> that a large packet will be successfully delivered to the peer (or >>> the client). However, this also breaks Path MTU Discovery, which >>> requires the DF bit to be set. >>> >>> Cullen is interested in trying to make Path MTU Discovery work even >>> for partly-compliant allocations. Here are a couple of options for >>> doing this: >>> >>> 1) [Cullen's proposal] Add a way for the client to indicate, on a >>> per- >>> packet basis, that the server should set the DF bit when forwarding >>> the user data to the peer. >>> This would apply ONLY to Send indications, which would include a bit >>> that specifies the setting of the DF bit. This bit could either be >>> contained in a new attribute, or could be one of the 8 currently >>> unused bits in the PEER-ADDRESS attribute. >>> >>> 2) Add a way for the client to indicate that the server should set >>> the DF bit on ALL packets relayed by the server for this allocation. >>> This might be done when the allocation is created, using a bit in >>> the >>> REQUESTED-PROPS attribute. >>> >>> 3) Similar to option (2), but settable on a per-peer basis via some >>> new to-be-defined transaction. >>> >>> Option (1) allows the setting on a per-packet basis, but only in the >>> client-->peer direction. Thus the peer could not do Path MTU >>> Discovery. >>> >>> Option (2) allows the peer to do Path MTU Discovery as well, but >>> reduces somewhat the chances of a large packet getting through if >>> the >>> peer chooses not do PMTUD. >>> >>> Option (3) sets the DF bit on a per-peer basis, which might be >>> useful >>> if some peers do PMTUD and others do not. However, it is the most >>> complex to specify, since it requires a new transaction type. >>> >>> What do people think of either of these options? Is anyone besides >>> Cullen interested in this question? >>> >>> Personally, I am leaning slightly towards (2), but have no strong >>> option. If no one but Cullen cares, then I will probably just drop >>> this idea entirely. >>> >>> - Philip >>> >>> >>> >>> >>> On Wed, 12-Mar-08, at 10:43 , Philip Matthews wrote: >>>> Below is a new proposal for how to handle the IP header fields in >>>> TURN. This proposal was developed in conjunction with Magnus, Lars, >>>> and Jonathan. I will be discussing this proposal in the BEHAVE >>>> meeting on Thursday. >>>> >>>> - Philip >>>> >>>> >>>> A UDP allocation is "fully compliant with the TURN IP header >>>> requirements" if the TURN server sets the fields in the outgoing IP >>>> header as follows. [Note: Need a better term; suggestions welcome.] >>>> >>>> For IPv4: >>>> * The TTL field is set to (incoming TTL - 1). >>>> * The ECN field is set to the incoming ECN field UNLESS the >>>> server is >>>> doing Active Queue Management, the incoming ECN field is 01 or 10, >>>> and the server wishes to indicate that congestion has been >>>> experienced, in which case it sets the outgoing ECN field to 11. >>>> * The DSCP field is set to the incoming DSCP UNLESS the server, >>>> though configuration or other means, believes that a different >>>> setting is more appropriate. >>>> * Various fragmentation fields (identification, fragment offset, >>>> last/ >>>> more fragments) are set as appropriate for a packet originated by >>>> the >>>> server. [Since the incoming UDP datagram must be re-assembled >>>> before >>>> it can be processed]. >>>> * The DF field is set to the incoming DF field. >>>> * The options are empty (i.e., not copied). >>>> >>>> For IPv6: >>>> * The Flow Label field is set to the incoming Flow Label field >>>> * The treatment of IPv6 extension headers is TBD. >>>> >>>> In addition, a "fully compliant" implementation will relay ICMP >>>> messages between the peer and client. >>>> >>>> >>>> A UDP allocation is only "partly compliant" if it does not set >>>> one or >>>> more of the fields as indicated above, or does not relay ICMP >>>> messages. >>>> >>>> Where possible, a "partly compliant" UDP allocation should set each >>>> field in the outgoing IP header as described above. Where a >>>> specific >>>> field cannot be set as described above, it SHOULD be set as >>>> described >>>> below. >>>> >>>> For IPv4: >>>> * ECN field: set to 00 (ECN not supported). >>>> * DSCP field: set to best effort >>>> * DF field: set to fragmentation allowed >>>> >>>> For IPv6: >>>> TBD >>>> >>>> A client SHOULD set the fields in the IP header as directed by the >>>> local application. If no direction is received, then the fields are >>>> set as described under the "partly compliant" description above. >>>> >>>> Bit 8 (currently unused) in the REQUESTED-PROPS attribute is >>>> redefined. If this bit is set to 1, then the client is requesting >>>> that the allocation be fully compliant with the TURN IP header >>>> requirements. If the server cannot provide an allocation that is >>>> fully compliant, then the server MUST reject the allocation >>>> request. >>>> It is a "Bad Request" error to set this bit when requesting a non- >>>> UDP >>>> allocation. >>>> >>>> >>>> When should a client request a fully-compliant allocation? >>>> * When the client wishes to use ECN or a specific DSCP along the >>>> entire path, OR >>>> * When the client wishes to determine the precise Path MTU (using >>>> Packetization Layer PMTUD). >>>> In general, a client can use a partly-compliant allocation over >>>> IPv4 >>>> if the application is happy with best effort service, does not need >>>> ECN, and sends only small packets (i.e., less than 576 - >>> overhead of 32 bytes>). If the application sends larger packets, >>>> then >>>> the packets may get fragmented along the way. This may result in >>>> the >>>> packets being dropped along the path; for example, if fragments are >>>> delivered out-of-order to certain NATs that do not handle out-of- >>>> order fragments properly. If the client uses the Packetization >>>> Layer >>>> PMTUD algorithm, then it may not discover the true path MTU, since >>>> the server may not set the DF bit. In these cases, it will instead >>>> discover the maximum packet size that will be delivered >>>> successfully >>>> to the peer. >>>> Some clients and applications that send larger packets may be >>>> able to >>>> operate successfully in these situations. Others may not, and thus >>>> require a fully-compliant allocation. >>>> [Any other suggestions for what to say here??] >>>> >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 8 08:17:53 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 603EF3A6E1C; Tue, 8 Apr 2008 08:17:53 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F2593A6DEF for ; Tue, 8 Apr 2008 08:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZyQ6efilXid for ; Tue, 8 Apr 2008 08:17:51 -0700 (PDT) Received: from s200aog17.obsmtp.com (s200aog17.obsmtp.com [207.126.144.131]) by core3.amsl.com (Postfix) with SMTP id 144D53A6E1C for ; Tue, 8 Apr 2008 08:17:46 -0700 (PDT) Received: from source ([64.233.184.229]) by eu1sys200aob017.postini.com ([207.126.147.11]) with SMTP; Tue, 08 Apr 2008 15:17:20 UTC Received: by wr-out-0506.google.com with SMTP id c55so1747838wra.0 for ; Tue, 08 Apr 2008 08:18:02 -0700 (PDT) Received: by 10.141.195.5 with SMTP id x5mr2050085rvp.263.1207667881907; Tue, 08 Apr 2008 08:18:01 -0700 (PDT) Received: by 10.141.186.2 with HTTP; Tue, 8 Apr 2008 08:18:01 -0700 (PDT) Message-ID: <1879720d0804080818y367a8a5am263e14ab908567d3@mail.gmail.com> Date: Tue, 8 Apr 2008 16:18:01 +0100 From: "Benny Prijono" To: "Philip Matthews" In-Reply-To: <3B6C8481-9BA3-49A4-90B0-B3DCC7CD5E3C@magma.ca> MIME-Version: 1.0 Content-Disposition: inline References: <5AE36F39-B800-45FD-A4CF-261EEE6BD191@cisco.com> <38F521F6-E706-40F5-B1C7-08A2CCAC7EA0@cisco.com> <9B9EE332-F142-4A2A-9985-D771D1A276CB@magma.ca> <1879720d0803250458t3389ed38j8db079c9b08b7e64@mail.gmail.com> <724EB65E-E362-4789-BE5B-10B1C4A1A00F@magma.ca> <1879720d0804020513t368824cdhaef7af940fb6cf4a@mail.gmail.com> <020167B5-CB15-4BAE-AE0E-5D1DF3EE4D26@magma.ca> <1879720d0804040328m4d9164a3l2d9e9f5655ecb43d@mail.gmail.com> <3B6C8481-9BA3-49A4-90B0-B3DCC7CD5E3C@magma.ca> X-Google-Sender-Auth: 4dc25bcd4a9c323d Cc: Behave WG Subject: Re: [BEHAVE] TURN: Are unauthenticated indications and ChannelData msgs a problem? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Mon, Apr 7, 2008 at 11:53 PM, Philip Matthews wrote: > > - Option G: not to provide mechanism to refresh permission alone, and > > instead force everyone to use channels (variant of option C) > > Hmmm. This option has some appeal, especially since it would suggest that > we should remove Send indications at the same time, since their usefulness > would go down a lot. This option would solve the problem AND simplify the > protocol. The only drawback would be the larger number of channels > allocated (presumably some just temporarily while doing ICE connectivity > checks) but is this really bad? I guess probably no, even for long term allocation. I don't suppose people will use all the available channels simultaneously, and the 10 minutes channel life time should allow expired channels to be reused. While this simplifies the protocol, this would make client implementation slightly more complicated though. Cheers Benny _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 8 08:23:14 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068553A6959; Tue, 8 Apr 2008 08:23:14 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 709F73A6959 for ; Tue, 8 Apr 2008 08:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKdtcZQWUAmX for ; Tue, 8 Apr 2008 08:23:11 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B77103A68D7 for ; Tue, 8 Apr 2008 08:23:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,624,1199692800"; d="scan'208";a="20486142" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 08 Apr 2008 08:23:27 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m38FNRYw026130; Tue, 8 Apr 2008 08:23:27 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.13.8/8.13.8) with SMTP id m38FNRhV008861; Tue, 8 Apr 2008 15:23:27 GMT From: Cullen Jennings To: "Marc Petit-Huguenin" In-Reply-To: <47FB8A8B.40000@acm.org> Impp: xmpp:cullenfluffyjennings@jabber.org References: <1ab601c88469$44427e20$bd4f150a@cisco.com> <47FB8A8B.40000@acm.org> Message-Id: <43ACE18C-961E-4B27-ACD5-46CA1446B5AF@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 8 Apr 2008 08:23:14 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=448; t=1207668208; x=1208532208; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20Jabber=20for=20upcoming=20Be have=20meeting |Sender:=20; bh=txGYUIBNfxmbPtnOWVpmneQpaeTtXsbJDvMKMglcX+I=; b=KeQttcU1MarPOeTa9/ShwX0Trbz8HK4QbOaJp7PRM0PmgTHK4w2E1463GL uLqry+kQ4qDvhQXD5s+NF07C2wKAs817xlMqvK7NYqDKpsArSM99OTxNPA2V Jf7xahLELE; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Behave WG , "Dan Wing \(dwing\)" Subject: Re: [BEHAVE] Jabber for upcoming Behave meeting X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Apr 8, 2008, at 8:08 AM, Marc Petit-Huguenin wrote: > Cullen Jennings wrote: > > I'm confused - you mean he is going to participate via jabber but > > can't be bothered to dial in to the phone call? If the issues is > long > > distance charges you can dial out to him and bill it to Cisco. > > What are you talking about? This was for the IETF meeting, not the > conference call. > sorry - temporary (at least I hope) insanity _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 8 08:23:40 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F63D3A6D64; Tue, 8 Apr 2008 08:23:40 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF053A6DA3 for ; Tue, 8 Apr 2008 08:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVJPx9JHM+uY for ; Tue, 8 Apr 2008 08:23:37 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 63B6B3A68D7 for ; Tue, 8 Apr 2008 08:23:37 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 8 Apr 2008 11:23:25 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 8 Apr 2008 11:23:25 -0400 From: Hadriel Kaplan To: Cullen Jennings Date: Tue, 8 Apr 2008 11:21:17 -0400 Thread-Topic: [BEHAVE] TURN: Cullen's suggestion for setting the DF bit Thread-Index: AciZi4fwHykPqPAcSOS++E38ohGaaQAAGgLA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] TURN: Cullen's suggestion for setting the DF bit X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Yes, I'm sure we could do nothing on the call today, without any implications. ;) > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > > I'd like to discuss the implications of doing nothing on the call > today if we can. > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 8 12:18:26 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C4123A6DD1; Tue, 8 Apr 2008 12:18:26 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA4528C3D2 for ; Tue, 8 Apr 2008 12:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uetoWkSw1XNw for ; Tue, 8 Apr 2008 12:18:19 -0700 (PDT) Received: from mail-01.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 587F43A6DA1 for ; Tue, 8 Apr 2008 12:18:19 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JjJL1-0002mg-0q; Tue, 08 Apr 2008 15:18:35 -0400 Message-Id: <5D6CBCA2-3703-4567-A789-2B6251F7E336@magma.ca> From: Philip Matthews To: Benny Prijono In-Reply-To: <1879720d0804080818y367a8a5am263e14ab908567d3@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 8 Apr 2008 15:18:34 -0400 References: <5AE36F39-B800-45FD-A4CF-261EEE6BD191@cisco.com> <38F521F6-E706-40F5-B1C7-08A2CCAC7EA0@cisco.com> <9B9EE332-F142-4A2A-9985-D771D1A276CB@magma.ca> <1879720d0803250458t3389ed38j8db079c9b08b7e64@mail.gmail.com> <724EB65E-E362-4789-BE5B-10B1C4A1A00F@magma.ca> <1879720d0804020513t368824cdhaef7af940fb6cf4a@mail.gmail.com> <020167B5-CB15-4BAE-AE0E-5D1DF3EE4D26@magma.ca> <1879720d0804040328m4d9164a3l2d9e9f5655ecb43d@mail.gmail.com> <3B6C8481-9BA3-49A4-90B0-B3DCC7CD5E3C@magma.ca> <1879720d0804080818y367a8a5am263e14ab908567d3@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: Behave WG Subject: Re: [BEHAVE] TURN: Are unauthenticated indications and ChannelData msgs a problem? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Tue, 8-Apr-08, at 11:18 , Benny Prijono wrote: > On Mon, Apr 7, 2008 at 11:53 PM, Philip Matthews > wrote: >>> - Option G: not to provide mechanism to refresh permission alone, >>> and >>> instead force everyone to use channels (variant of option C) >> >> Hmmm. This option has some appeal, especially since it would >> suggest that >> we should remove Send indications at the same time, since their >> usefulness >> would go down a lot. This option would solve the problem AND >> simplify the >> protocol. The only drawback would be the larger number of channels >> allocated (presumably some just temporarily while doing ICE >> connectivity >> checks) but is this really bad? > > I guess probably no, even for long term allocation. I don't suppose > people will use all the available channels simultaneously, and the 10 > minutes channel life time should allow expired channels to be reused. > While this simplifies the protocol, this would make client > implementation slightly more complicated though. Why would the client be more complicated, and do you think this is serious? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 8 13:05:51 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 810383A6C2B; Tue, 8 Apr 2008 13:05:51 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E3D28C395 for ; Tue, 8 Apr 2008 13:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVezoqnzPfet for ; Tue, 8 Apr 2008 13:05:45 -0700 (PDT) Received: from mail-06.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 9C58F3A6C8D for ; Tue, 8 Apr 2008 13:05:44 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JjK4u-00080t-2o for behave@ietf.org; Tue, 08 Apr 2008 16:06:01 -0400 Message-Id: From: Philip Matthews To: Behave WG Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 8 Apr 2008 16:06:00 -0400 X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Subject: [BEHAVE] Minutes of TURN conf call on 8 April 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Below are the preliminary minutes of the TURN conference call of 8 April 2008. If any of the attendees think I did not properly capture some aspect, then please send e-mail to the mailing list. Furthermore, if anyone who was not on the call disagrees with a conclusion, then please send e-mail. By IETF procedures, all decisions must be ratified on the mailing list. - Philip Minutes of TURN conference call of 8 April 2008 =============================================== Attendees: Cullen Jennings Hadriel Kaplan Feng Liu Rohan Mahy Philip Matthews Mariano O'Kon Benny Prijono Eric Rescorla Jonathan Rosenberg Magnus Westerlund Dan Wing 1. TWIST Hadriel gave a presentation of his TWIST proposal, followed by a discussion. The conclusion was that, while TWIST may be interesting, it doesn't fit the requirements of TURN. In particular, TWIST has high encapsulation overhead (although in the meeting Hadriel suggested a modification to reduce the overhead) and TWIST cannot be implemented as an unprivileged userland process. These reasons, and the fact that the completion of TURN is holding up ICE, lead everyone on the call to agree that we would continue with the existing TURN direction and not bring in ideas from TWIST. Decision: TWIST is a separate proposal, and is not a TURN replacement. 2. TCP and TLS between the Client and the Server It was agreed that both these transports should be kept in TURN. For TCP, it was agreed that the motivating text will be changed to describe why in some environments TCP is preferred over UDP (e.g., clear indication of end of flow, data exchanged only with peer of 3- way handshake). For TLS, the motivating text should talk about the fact that TLS provides a way for the client to verify that it is talking to the correct server, as well as a way to prevent third parties from reading the TURN messages. Action: Philip to work with Jonathan and Cullen to craft some proposed text that described why these transports are in TURN. 3. Setting the DF bit in "Partly-Compliant" Allocations There was a long discussion about how Path MTU Discovery might be done even if the server cannot read the setting of the DF bit on incoming packets. A number of possible solutions were discussed, and there seemed to be a general conclusion that the problem was harder than it seemed at first glance. However, it was agreed to go with Cullen's proposal that TURN provide a way for the client to indicate, on a per- packet basis, that the DF bit should be set when sending from the server to the peer. It was felt that this was easy to specify and implement, and provided at least part of the total solution. Philip noted that it was probably possible to do this with an existing unused bit for the Send indication. Action: Philip to send a concrete proposal to the mailing list. 4. Anycast and ALTERNATE-SERVER There was another long discussion about anycast and ALTERNATE-SERVER. It was agreed that TURN would not specify all the details about how anycast discovery of a server would work, but just specify some necessary pieces. A full anycast discovery procedure could then be advanced as a separate document (though note that BEHAVE does not have a milestone for such a document). One necessary piece is the specification of the ALTERNATE-SERVER semantics, and the proposal that Philip sent to the mailing list on 7 April 2008 was accepted without comment. A second piece might be a change in the requirement that any response using ALTERNATE- SERVER be authenticated -- it was pointed out that TURN authentication currently authenticates the client, not the server. However, the participants were unable to agree on a way to fix this, and more discussion is required. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 8 15:52:39 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEC93A6E75; Tue, 8 Apr 2008 15:52:39 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE75D3A6C06 for ; Tue, 8 Apr 2008 15:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9FCOSj2ynhL for ; Tue, 8 Apr 2008 15:52:36 -0700 (PDT) Received: from s200aog14.obsmtp.com (s200aog14.obsmtp.com [207.126.144.128]) by core3.amsl.com (Postfix) with SMTP id 04A703A68D1 for ; Tue, 8 Apr 2008 15:52:35 -0700 (PDT) Received: from source ([209.85.198.229]) by eu1sys200aob014.postini.com ([207.126.147.11]) with SMTP; Tue, 08 Apr 2008 22:52:51 UTC Received: by rv-out-0506.google.com with SMTP id g37so17830rvb.21 for ; Tue, 08 Apr 2008 15:52:51 -0700 (PDT) Received: by 10.141.68.5 with SMTP id v5mr2304303rvk.179.1207695171239; Tue, 08 Apr 2008 15:52:51 -0700 (PDT) Received: by 10.141.186.2 with HTTP; Tue, 8 Apr 2008 15:52:51 -0700 (PDT) Message-ID: <1879720d0804081552v6c2da245vfe1fa3f75f566f79@mail.gmail.com> Date: Tue, 8 Apr 2008 23:52:51 +0100 From: "Benny Prijono" To: "Philip Matthews" In-Reply-To: <5D6CBCA2-3703-4567-A789-2B6251F7E336@magma.ca> MIME-Version: 1.0 Content-Disposition: inline References: <5AE36F39-B800-45FD-A4CF-261EEE6BD191@cisco.com> <1879720d0803250458t3389ed38j8db079c9b08b7e64@mail.gmail.com> <724EB65E-E362-4789-BE5B-10B1C4A1A00F@magma.ca> <1879720d0804020513t368824cdhaef7af940fb6cf4a@mail.gmail.com> <020167B5-CB15-4BAE-AE0E-5D1DF3EE4D26@magma.ca> <1879720d0804040328m4d9164a3l2d9e9f5655ecb43d@mail.gmail.com> <3B6C8481-9BA3-49A4-90B0-B3DCC7CD5E3C@magma.ca> <1879720d0804080818y367a8a5am263e14ab908567d3@mail.gmail.com> <5D6CBCA2-3703-4567-A789-2B6251F7E336@magma.ca> X-Google-Sender-Auth: d36f9485498edab4 Cc: Behave WG Subject: Re: [BEHAVE] TURN: Are unauthenticated indications and ChannelData msgs a problem? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Tue, Apr 8, 2008 at 8:18 PM, Philip Matthews wrote: > On Tue, 8-Apr-08, at 11:18 , Benny Prijono wrote: > > > On Mon, Apr 7, 2008 at 11:53 PM, Philip Matthews > > wrote: > > > > > > > > > - Option G: not to provide mechanism to refresh permission alone, and > > > > instead force everyone to use channels (variant of option C) > > > > > > > > > > Hmmm. This option has some appeal, especially since it would suggest > that > > > we should remove Send indications at the same time, since their > usefulness > > > would go down a lot. This option would solve the problem AND simplify > the > > > protocol. The only drawback would be the larger number of channels > > > allocated (presumably some just temporarily while doing ICE connectivity > > > checks) but is this really bad? > > > > > > > I guess probably no, even for long term allocation. I don't suppose > > people will use all the available channels simultaneously, and the 10 > > minutes channel life time should allow expired channels to be reused. > > While this simplifies the protocol, this would make client > > implementation slightly more complicated though. > > > > Why would the client be more complicated, and do you think this is serious? > Few questions that I have in mind e.g. - should client ChannelBind to all remote candidates before starting any connectivity checks, or one by one upon sending the first check using the relay so that there's a gap between ChannelBind requests. (I tend to say the later). - If it does the later, should the ICE check be embedded inside ChannelBind (assuming ChannelBind can carry DATA), or in separate ChannelData. (I tend to prefer the later) - If the later, what will happen to the first ChannelData's, would it be wiser to sent them immediately after ChannelBind request, or to drop them until client receives ChannelBind response? (I think i would just send ChannelData right after ChannelBind and hope for the best.) - And what should (an ICE) client do if ChannelBind fails? (I think I'll mark the check as failed.) Not sure how serious that would be, but my feeling is it's implementable. cheers -benny _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 8 16:17:11 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E061A3A6C23; Tue, 8 Apr 2008 16:17:11 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671B63A6C23 for ; Tue, 8 Apr 2008 16:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.77 X-Spam-Level: X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3D+CdGPZRkI4 for ; Tue, 8 Apr 2008 16:17:10 -0700 (PDT) Received: from s200aog12.obsmtp.com (s200aog12.obsmtp.com [207.126.144.126]) by core3.amsl.com (Postfix) with SMTP id 124113A6B85 for ; Tue, 8 Apr 2008 16:17:09 -0700 (PDT) Received: from source ([64.233.184.231]) by eu1sys200aob012.postini.com ([207.126.147.11]) with SMTP; Tue, 08 Apr 2008 23:17:21 UTC Received: by wr-out-0506.google.com with SMTP id c55so1960090wra.0 for ; Tue, 08 Apr 2008 16:17:26 -0700 (PDT) Received: by 10.140.203.9 with SMTP id a9mr2310920rvg.203.1207696645530; Tue, 08 Apr 2008 16:17:25 -0700 (PDT) Received: by 10.141.186.2 with HTTP; Tue, 8 Apr 2008 16:17:25 -0700 (PDT) Message-ID: <1879720d0804081617g825379fk28d5b5c7c8360092@mail.gmail.com> Date: Wed, 9 Apr 2008 00:17:25 +0100 From: "Benny Prijono" To: "Philip Matthews" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: X-Google-Sender-Auth: 6c5f2c20abd4a365 Cc: Behave WG Subject: Re: [BEHAVE] Minutes of TURN conf call on 8 April 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Tue, Apr 8, 2008 at 9:06 PM, Philip Matthews wrote: > 3. Setting the DF bit in "Partly-Compliant" Allocations > There was a long discussion about how Path MTU Discovery might be done > even if the server cannot read the setting of the DF bit on incoming > packets. A number of possible solutions were discussed, and there > seemed to be a general conclusion that the problem was harder than it > seemed at first glance. However, it was agreed to go with Cullen's > proposal that TURN provide a way for the client to indicate, on a per- > packet basis, that the DF bit should be set when sending from the > server to the peer. It was felt that this was easy to specify and > implement, and provided at least part of the total solution. Philip > noted that it was probably possible to do this with an existing unused > bit for the Send indication. > Action: Philip to send a concrete proposal to the mailing list. > Sorry I missed the discussion when people said this would be difficult to implement as extension. I mean why something like these couldn't be made to work?: - clients that require server to do DF extension would include a mandatory REQUIRE-DF attribute in Allocate request. - server that wants to indicate DF extension support would include a non-mandatory SUPPORT-DF in its Allocate response. The benefit of this approach (apart from that it's a separate draft) are server implementors doesn't have to implement this if they don't care, and client will know for sure if server implements it. cheers -benny _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 9 06:24:15 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E043028C506; Wed, 9 Apr 2008 06:24:15 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EA1328C500 for ; Wed, 9 Apr 2008 06:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[AWL=0.624, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2qJHswrb7di for ; Wed, 9 Apr 2008 06:24:14 -0700 (PDT) Received: from mail-08.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 640E328C4B1 for ; Wed, 9 Apr 2008 06:24:14 -0700 (PDT) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JjaHw-0005Vp-1H; Wed, 09 Apr 2008 09:24:32 -0400 Message-Id: <674D2532-D0CF-4EBE-BB36-AF5F9B416CA5@magma.ca> From: Philip Matthews To: Behave WG In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 9 Apr 2008 09:24:32 -0400 References: X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Subject: Re: [BEHAVE] Minutes of TURN conf call on 8 April 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Whoops! I forgot to include Derek MacDonald in the list of attendees. - Philip On Tue, 8-Apr-08, at 16:06 , Philip Matthews wrote: > > Minutes of TURN conference call of 8 April 2008 > =============================================== > > Attendees: > Cullen Jennings > Hadriel Kaplan > Feng Liu > > Rohan Mahy > Philip Matthews > Mariano O'Kon > Benny Prijono > Eric Rescorla > Jonathan Rosenberg > Magnus Westerlund > Dan Wing _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 9 06:33:38 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E635928C472; Wed, 9 Apr 2008 06:33:38 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9013D28C462 for ; Wed, 9 Apr 2008 06:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtrWx+bFYwDQ for ; Wed, 9 Apr 2008 06:33:37 -0700 (PDT) Received: from mail-06.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id A02B228C472 for ; Wed, 9 Apr 2008 06:33:37 -0700 (PDT) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JjaR1-0007V8-25; Wed, 09 Apr 2008 09:33:55 -0400 Message-Id: <690E1AAE-0E76-41EE-8AED-8551E1B134BE@magma.ca> From: Philip Matthews To: Benny Prijono In-Reply-To: <1879720d0804081617g825379fk28d5b5c7c8360092@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 9 Apr 2008 09:33:54 -0400 References: <1879720d0804081617g825379fk28d5b5c7c8360092@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Cc: Behave WG Subject: Re: [BEHAVE] Minutes of TURN conf call on 8 April 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Tue, 8-Apr-08, at 19:17 , Benny Prijono wrote: > On Tue, Apr 8, 2008 at 9:06 PM, Philip Matthews > wrote: >> 3. Setting the DF bit in "Partly-Compliant" Allocations >> There was a long discussion about how Path MTU Discovery might be >> done >> even if the server cannot read the setting of the DF bit on incoming >> packets. A number of possible solutions were discussed, and there >> seemed to be a general conclusion that the problem was harder than it >> seemed at first glance. However, it was agreed to go with Cullen's >> proposal that TURN provide a way for the client to indicate, on a >> per- >> packet basis, that the DF bit should be set when sending from the >> server to the peer. It was felt that this was easy to specify and >> implement, and provided at least part of the total solution. Philip >> noted that it was probably possible to do this with an existing >> unused >> bit for the Send indication. >> Action: Philip to send a concrete proposal to the mailing list. >> > > Sorry I missed the discussion when people said this would be difficult > to implement as extension. I mean why something like these couldn't be > made to work?: > - clients that require server to do DF extension would include a > mandatory REQUIRE-DF attribute in Allocate request. > - server that wants to indicate DF extension support would include a > non-mandatory SUPPORT-DF in its Allocate response. > > The benefit of this approach (apart from that it's a separate draft) > are server implementors doesn't have to implement this if they don't > care, and client will know for sure if server implements it. We could do this. There is already a REQUESTED-PROPS attribute which I would suggest using rather than a new REQUIRE-DF attribute. However, I think the sense of the call was that a flag requesting the DF bit be sent on sending would be easy to implement, much easier than adding a "REQUIRE-DF" mechanism. The sense of the call is almost every OS provides an API to set the DF bit. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 9 06:51:41 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB16628C472; Wed, 9 Apr 2008 06:51:41 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4556F28C3B4 for ; Wed, 9 Apr 2008 06:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMHMwKDk0k40 for ; Wed, 9 Apr 2008 06:51:36 -0700 (PDT) Received: from s200aog11.obsmtp.com (s200aog11.obsmtp.com [207.126.144.125]) by core3.amsl.com (Postfix) with SMTP id 2BA503A69ED for ; Wed, 9 Apr 2008 06:51:35 -0700 (PDT) Received: from source ([64.233.184.238]) by eu1sys200aob011.postini.com ([207.126.147.11]) with SMTP; Wed, 09 Apr 2008 13:51:52 UTC Received: by wr-out-0506.google.com with SMTP id c55so2230030wra.0 for ; Wed, 09 Apr 2008 06:51:52 -0700 (PDT) Received: by 10.140.142.6 with SMTP id p6mr62481rvd.224.1207749111572; Wed, 09 Apr 2008 06:51:51 -0700 (PDT) Received: by 10.141.186.2 with HTTP; Wed, 9 Apr 2008 06:51:51 -0700 (PDT) Message-ID: <1879720d0804090651h7945d71dm49158f550d61adf2@mail.gmail.com> Date: Wed, 9 Apr 2008 14:51:51 +0100 From: "Benny Prijono" To: "Philip Matthews" In-Reply-To: <690E1AAE-0E76-41EE-8AED-8551E1B134BE@magma.ca> MIME-Version: 1.0 Content-Disposition: inline References: <1879720d0804081617g825379fk28d5b5c7c8360092@mail.gmail.com> <690E1AAE-0E76-41EE-8AED-8551E1B134BE@magma.ca> X-Google-Sender-Auth: 15fe54fa9f997ae8 Cc: Behave WG Subject: Re: [BEHAVE] Minutes of TURN conf call on 8 April 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Wed, Apr 9, 2008 at 2:33 PM, Philip Matthews wrote: > > Sorry I missed the discussion when people said this would be difficult > > to implement as extension. I mean why something like these couldn't be > > made to work?: > > - clients that require server to do DF extension would include a > > mandatory REQUIRE-DF attribute in Allocate request. > > - server that wants to indicate DF extension support would include a > > non-mandatory SUPPORT-DF in its Allocate response. > > > > The benefit of this approach (apart from that it's a separate draft) > > are server implementors doesn't have to implement this if they don't > > care, and client will know for sure if server implements it. > > > > We could do this. There is already a REQUESTED-PROPS attribute which I > would suggest using rather than a new REQUIRE-DF attribute. Yes if we put this in the main spec. > However, I think the sense of the call was that a flag requesting the DF > bit be sent on sending would be easy to implement, much easier than adding a > "REQUIRE-DF" mechanism. The sense of the call is almost every OS provides an > API to set the DF bit. Okay. I just thought that if this would burden the development of the main spec (you seem to have quite a lot of stuffs to do!) then we have the option to put this as extension. Thanks Benny > - Philip > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 9 06:56:00 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 613D928C4C0; Wed, 9 Apr 2008 06:56:00 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCF9F28C472 for ; Wed, 9 Apr 2008 06:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCq2NcjvotN7 for ; Wed, 9 Apr 2008 06:55:54 -0700 (PDT) Received: from mail-05.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id CB88A28C4B2 for ; Wed, 9 Apr 2008 06:54:59 -0700 (PDT) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Jjakd-0006td-2H; Wed, 09 Apr 2008 09:54:12 -0400 Message-Id: From: Philip Matthews To: Benny Prijono In-Reply-To: <1879720d0804081552v6c2da245vfe1fa3f75f566f79@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 9 Apr 2008 09:55:17 -0400 References: <5AE36F39-B800-45FD-A4CF-261EEE6BD191@cisco.com> <1879720d0803250458t3389ed38j8db079c9b08b7e64@mail.gmail.com> <724EB65E-E362-4789-BE5B-10B1C4A1A00F@magma.ca> <1879720d0804020513t368824cdhaef7af940fb6cf4a@mail.gmail.com> <020167B5-CB15-4BAE-AE0E-5D1DF3EE4D26@magma.ca> <1879720d0804040328m4d9164a3l2d9e9f5655ecb43d@mail.gmail.com> <3B6C8481-9BA3-49A4-90B0-B3DCC7CD5E3C@magma.ca> <1879720d0804080818y367a8a5am263e14ab908567d3@mail.gmail.com> <5D6CBCA2-3703-4567-A789-2B6251F7E336@magma.ca> <1879720d0804081552v6c2da245vfe1fa3f75f566f79@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Cc: Behave WG Subject: Re: [BEHAVE] TURN: Are unauthenticated indications and ChannelData msgs a problem? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Tue, 8-Apr-08, at 18:52 , Benny Prijono wrote: > On Tue, Apr 8, 2008 at 8:18 PM, Philip Matthews > wrote: >> On Tue, 8-Apr-08, at 11:18 , Benny Prijono wrote: >> >>> On Mon, Apr 7, 2008 at 11:53 PM, Philip Matthews >>> wrote: >>> >>>> >>>>> - Option G: not to provide mechanism to refresh permission >>>>> alone, and >>>>> instead force everyone to use channels (variant of option C) >>>>> >>>> >>>> Hmmm. This option has some appeal, especially since it would >>>> suggest >> that >>>> we should remove Send indications at the same time, since their >> usefulness >>>> would go down a lot. This option would solve the problem AND >>>> simplify >> the >>>> protocol. The only drawback would be the larger number of channels >>>> allocated (presumably some just temporarily while doing ICE >>>> connectivity >>>> checks) but is this really bad? >>>> >>> >>> I guess probably no, even for long term allocation. I don't suppose >>> people will use all the available channels simultaneously, and the >>> 10 >>> minutes channel life time should allow expired channels to be >>> reused. >>> While this simplifies the protocol, this would make client >>> implementation slightly more complicated though. >>> >> >> Why would the client be more complicated, and do you think this is >> serious? >> > > Few questions that I have in mind e.g. > - should client ChannelBind to all remote candidates before starting > any connectivity checks, or one by one upon sending the first check > using the relay so that there's a gap between ChannelBind requests. (I > tend to say the later). I would suggest doing the former as it eliminates the concerns in your next two points below. Furthermore, it will make the ICE checks run faster -- one of the things that makes ICE checks slow is waiting for both ends to install the necessary permissions to get connectivity- check packets through. > > - If it does the later, should the ICE check be embedded inside > ChannelBind (assuming ChannelBind can carry DATA), or in separate > ChannelData. (I tend to prefer the later) The latter is what we have today, and with my comment above, I don't currently see any reason to change it. > > - If the later, what will happen to the first ChannelData's, would it > be wiser to sent them immediately after ChannelBind request, or to > drop them until client receives ChannelBind response? (I think i would > just send ChannelData right after ChannelBind and hope for the best.) For a TURN candidate, I might consider binding the channel as part of the candidate gathering process. This ensures the binding is completed before the checks start and eliminates any concern about the binding not being ready when sending a connectivity check packet. > > - And what should (an ICE) client do if ChannelBind fails? (I think > I'll mark the check as failed.) If it fails for anything other than an authentication challenge, then I think you probably want to abort the entire allocation and try again, because this probably means there is something out of sync between the client and the server. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 10 09:01:10 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D313A6A87; Thu, 10 Apr 2008 09:01:10 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86EBF3A6F23 for ; Thu, 10 Apr 2008 09:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cF4oGkVFu4MV for ; Thu, 10 Apr 2008 09:00:58 -0700 (PDT) Received: from where.matthew.at (unknown [IPv6:2001:5a8:4:39d1:201:3ff:fed1:d4f5]) by core3.amsl.com (Postfix) with ESMTP id 065993A6D99 for ; Thu, 10 Apr 2008 09:00:37 -0700 (PDT) Received: from [10.10.155.2] (matthew-desk.braemoor.net [10.10.155.2] (may be forged)) by where.matthew.at (8.11.3/8.11.3) with ESMTP id m3AG0hL87106; Thu, 10 Apr 2008 09:00:44 -0700 (PDT) (envelope-from matthew@matthew.at) Message-ID: <47FE39AB.10404@matthew.at> Date: Thu, 10 Apr 2008 09:00:43 -0700 From: Matthew Kaufman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: bennylp@pjsip.org, phillip_matthews@magma.ca Cc: behave@ietf.org Subject: Re: [BEHAVE] TURN: Are unauthenticated indications and ChannelData msgs a problem? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: matthew@matthew.at List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Phillip: > For a TURN candidate, I might consider binding the channel > as part of the candidate gathering process. This ensures > the binding is completed before the checks start and eliminates > any concern about the binding not being ready when sending a > connectivity check packet. For protocols like the one we have developed (that we're planning on using TURN with) there is no "candidate gathering process", and so the extra round trip required for a channel binding becomes a time penalty on each session establishment. We would recommend against removing the existing send indication mechanism. Matthew Kaufman matthew@matthew.at ps. Does anyone have an implementation of the latest draft that we can test our client against? What we've found so far appears to be at least one draft old. We will have very wide distribution when we ship, so we would prefer to be as close as possible to the final standard. pps. I don't seem to be able to subscribe to the mailing list via the web or email interface,.. is the approver on vacation or am I doing something wrong? _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 10 11:10:37 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C631D3A6E01; Thu, 10 Apr 2008 11:10:37 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9897D3A6D7D for ; Thu, 10 Apr 2008 11:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1m9jipBZdqWm for ; Thu, 10 Apr 2008 11:10:31 -0700 (PDT) Received: from s200aog13.obsmtp.com (s200aog13.obsmtp.com [207.126.144.127]) by core3.amsl.com (Postfix) with SMTP id 11A9C3A6D3F for ; Thu, 10 Apr 2008 11:10:18 -0700 (PDT) Received: from source ([64.233.166.180]) by eu1sys200aob013.postini.com ([207.126.147.11]) with SMTP; Thu, 10 Apr 2008 18:10:39 UTC Received: by py-out-1112.google.com with SMTP id a73so150196pye.2 for ; Thu, 10 Apr 2008 11:10:38 -0700 (PDT) Received: by 10.141.204.16 with SMTP id g16mr945144rvq.275.1207851038524; Thu, 10 Apr 2008 11:10:38 -0700 (PDT) Received: by 10.141.186.2 with HTTP; Thu, 10 Apr 2008 11:10:38 -0700 (PDT) Message-ID: <1879720d0804101110o61362f21yc089096636b66994@mail.gmail.com> Date: Thu, 10 Apr 2008 19:10:38 +0100 From: "Benny Prijono" To: matthew@matthew.at MIME-Version: 1.0 Content-Disposition: inline X-Google-Sender-Auth: 70197483bfb408a0 Cc: behave@ietf.org, phillip_matthews@magma.ca Subject: [BEHAVE] TURN-07 implementation (was Re: TURN: Are unauthenticated indications and ChannelData msgs a problem?) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Thu, Apr 10, 2008 at 5:00 PM, Matthew Kaufman wrote: > ps. Does anyone have an implementation of the latest draft that we can test > our client against? What we've found so far appears to be at least one draft > old. We will have very wide distribution when we ship, so we would prefer to > be as close as possible to the final standard. We have open source implementation of TURN-07 client and server in http://www.pjsip.org. Cheers Benny _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 11 07:30:38 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F5653A6C80; Fri, 11 Apr 2008 07:30:38 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FEB93A6E43 for ; Fri, 11 Apr 2008 07:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.707 X-Spam-Level: X-Spam-Status: No, score=-4.707 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36z6NKFEKO21 for ; Fri, 11 Apr 2008 07:30:27 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7455A3A695C for ; Fri, 11 Apr 2008 07:30:00 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 Apr 2008 07:30:24 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3BEUOk4019881; Fri, 11 Apr 2008 07:30:24 -0700 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.13.8/8.13.8) with SMTP id m3BEUNL3029063; Fri, 11 Apr 2008 14:30:23 GMT Message-Id: <08169E3C-0F02-4476-91B4-4E877DE849DC@cisco.com> From: Cullen Jennings To: Philip Matthews In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 10 Apr 2008 21:06:50 -0600 References: X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=357; t=1207924224; x=1208788224; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20Minutes=20of=20TURN=20conf=2 0call=20on=208=20April=202008 |Sender:=20; bh=nrJXT0yMFIUloEcQr4y3KbIgu9mnHBGkVt5J9BDB9QA=; b=e/l6mdCxmfqDZ1dFDiTKuINDTHanWVPU4e7joithiwqLQ1pUC3vlNpAHvE IdlJwta3n0Ikp3GG+h2wTGZBAYIdViox3lGhR2jfHvR8LETrTJh10Sh22FlS DiQTk/lSSqoriD/OV/azb06YsnaQ/aK7BugN07n4g4lerWcLh2UVM=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Behave WG Subject: Re: [BEHAVE] Minutes of TURN conf call on 8 April 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Apr 8, 2008, at 2:06 PM, Philip Matthews wrote: > One necessary piece is the specification of the ALTERNATE-SERVER > semantics, and the proposal that Philip sent to the mailing > list on 7 April 2008 was accepted without comment. Uhmm - I don't think that proposal specified enough to agree or disagree with. I would not view it as accepted. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 11 07:30:38 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869A63A6E43; Fri, 11 Apr 2008 07:30:38 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF853A6E40 for ; Fri, 11 Apr 2008 07:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.676 X-Spam-Level: X-Spam-Status: No, score=-4.676 tagged_above=-999 required=5 tests=[AWL=0.854, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tml85jEDdLkD for ; Fri, 11 Apr 2008 07:30:27 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0B1AE3A6C80 for ; Fri, 11 Apr 2008 07:30:01 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 11 Apr 2008 07:30:24 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3BEUOM9019905; Fri, 11 Apr 2008 07:30:24 -0700 Received: from [192.168.4.2] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.13.8/8.13.8) with SMTP id m3BEUNL4029063; Fri, 11 Apr 2008 14:30:24 GMT Message-Id: <12A94043-0CC0-4931-AB25-EF7CF7362050@cisco.com> From: Cullen Jennings To: Philip Matthews In-Reply-To: <8355427A-4338-4AE6-A4E5-2862EE5595B6@magma.ca> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 10 Apr 2008 21:10:38 -0600 References: <47DEEF88.9060901@nostrum.com> <8355427A-4338-4AE6-A4E5-2862EE5595B6@magma.ca> X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2784; t=1207924224; x=1208788224; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20TCP=20TURN=20Multiplexing=20 Issue |Sender:=20; bh=RQiRUWNqzNOEeWsf65wb99qjHs1H7LhTcVdbvPS3PSc=; b=m2K/NGGM40leOET7n8st3Le5n7JpsOxtnohvCz+Onbo9GoJ4L9Umr77i79 OBhCV4or/c85CO3y0JU0atr+DlYkedfx0anfATnipJvzMW753DFd7wrump+y YCgvyTSAJxWcOsPWt6SW2mxsiNHhJFCtufi8f0gVr5kPwpP6QyntY=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'Behave WG' Subject: Re: [BEHAVE] TCP TURN Multiplexing Issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Mar 19, 2008, at 8:38 AM, Philip Matthews wrote: > > On Mon, 17-Mar-08, at 18:24 , Adam Roach wrote: > >> I've done a lot of thinking on the "multiple relayed connections >> over a >> single Client-Relay connection" problem over the weekend, and I >> have a >> modest proposal that is, at the very least, easy to implement. >> >> It seems that the problem arises from a fundamental mismatch >> between the >> way that clients interact with relays, and the way that TCP listeners >> generally behave. For example, consider the way the sockets interface >> handles TCP server connections: applications create a socket >> descriptor >> and listen() on it. When a new incoming connection is made, the >> listen() >> call returns a *new* socket descriptor, which the applications then >> performs read() and write() operations on. >> >> Now, what we're really trying to do with TCP TURN is provide remote >> access to this kind of resource model. The problem arises when we >> try to >> take the original socket (the listen() socket) and multiplex its >> information with multiple other sockets (the read() and write() >> sockets) >> on a single TCP connection. >> >> So what I'm proposing is: don't. >> >> In other words: to listen for incoming TCP connections, TURN clients >> would establish a TCP connection to the relay (roughly >> corresponding to >> the listen() socket) that serves as a control channel. When a remote >> peer connects, the Connection Status Indication (ESTABLISHED) would >> include a new attribute, which contains a cookie. The user then >> connects >> to the relay using a new TCP connection, authenticates, and then >> sends >> the cookie in a request of some kind (perhaps we re-use CONNECT for >> this; perhaps we use a new message type). From that point forward, >> this >> new connection is used to ferry information to and from the remote >> peer >> connection. >> >> I recognize that this generally ends up taking twice as many >> connections; I think that there is room for optimization on top of >> the >> basic theme (e.g., dropping the control connection when listening >> is no >> longer necessary), but wanted to know whether there would be any >> support >> for this *kind* of approach before I spent too much time polishing >> the >> corners down. > > The TURN-TCP authors considered this approach. I developed a proposal > similar to the one you are proposing and argued for it. > > As I recall, we dropped this one because it didn't work well with > ICE. The client would end up establishing a lot of temporary TCP > connections to the server that would then be dropped. I'm being dense and don't understand why this doesn't work well with ICE. Can you explain? _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 11 08:28:20 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107573A6F3C; Fri, 11 Apr 2008 08:28:20 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F8723A6F37 for ; Fri, 11 Apr 2008 08:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FE+x4nq+wKq for ; Fri, 11 Apr 2008 08:28:18 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id A658E3A6F38 for ; Fri, 11 Apr 2008 08:28:18 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 03E1F50854; Fri, 11 Apr 2008 08:30:33 -0700 (PDT) Date: Fri, 11 Apr 2008 08:30:32 -0700 From: Eric Rescorla To: Philip Matthews In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080411153033.03E1F50854@romeo.rtfm.com> Cc: Behave WG Subject: Re: [BEHAVE] Minutes of TURN conf call on 8 April 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Tue, 8 Apr 2008 16:06:00 -0400, Philip Matthews wrote: > 4. Anycast and ALTERNATE-SERVER > There was another long discussion about anycast and ALTERNATE-SERVER. > It was agreed that TURN would not specify all the details about how > anycast discovery of a server would work, but just specify some > necessary pieces. A full anycast discovery procedure could then be > advanced as a separate document (though note that BEHAVE does not have > a milestone for such a document). > One necessary piece is the specification of the ALTERNATE-SERVER > semantics, and the proposal that Philip sent to the mailing > list on 7 April 2008 was accepted without comment. I don't recall this, nor does it make sense without the authentication issue being complete. > A second piece > might be a change in the requirement that any response using ALTERNATE- > SERVER be authenticated -- it was pointed out that TURN authentication > currently authenticates the client, not the server. However, the > participants were unable to agree on a way to fix this, and more > discussion is required. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 11 10:55:30 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672083A6BC9; Fri, 11 Apr 2008 10:55:30 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 412783A6825 for ; Fri, 11 Apr 2008 10:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.48 X-Spam-Level: X-Spam-Status: No, score=-5.48 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7Tk9Y8skmB4 for ; Fri, 11 Apr 2008 10:55:28 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1BB223A6C5B for ; Fri, 11 Apr 2008 10:55:22 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 Apr 2008 10:55:46 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3BHtjJu004163; Fri, 11 Apr 2008 10:55:45 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3BHtjt2028350; Fri, 11 Apr 2008 17:55:45 GMT From: "Dan Wing" To: "'Cullen Jennings'" , "'Philip Matthews'" References: <47DEEF88.9060901@nostrum.com><8355427A-4338-4AE6-A4E5-2862EE5595B6@magma.ca> <12A94043-0CC0-4931-AB25-EF7CF7362050@cisco.com> Date: Fri, 11 Apr 2008 10:55:45 -0700 Message-ID: <0c0c01c89bfd$446107e0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <12A94043-0CC0-4931-AB25-EF7CF7362050@cisco.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acib4Lavb3+lIoC7Rx6d6OALlmatNwAGrGaQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4504; t=1207936545; x=1208800545; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20TCP=20TURN=20Multiplexing=20 Issue |Sender:=20; bh=PISZzDy6+4FqLdc1Bt+FzRauLfqwvJtoez0srCG47wc=; b=Gz98ucgqayEr42y1YGfQb5e5vHL5mIlDNJSjYadCXP9f9rv9ZP0HyOFceV BS7P6AGJOJqy0QwODa7Ju5B2+MysPa2JZocW/CtelLEzXXgnKty19jDnSZCn dvh6chnVhdSCkBCknZEpR737midLb1vLI1EjBrV6Ea6r+/+G1jHBs=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'Behave WG' Subject: Re: [BEHAVE] TCP TURN Multiplexing Issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: Thursday, April 10, 2008 8:11 PM > To: Philip Matthews > Cc: 'Behave WG' > Subject: Re: [BEHAVE] TCP TURN Multiplexing Issue > > > On Mar 19, 2008, at 8:38 AM, Philip Matthews wrote: > > > > On Mon, 17-Mar-08, at 18:24 , Adam Roach wrote: > > > >> I've done a lot of thinking on the "multiple relayed connections > >> over a > >> single Client-Relay connection" problem over the weekend, and I > >> have a > >> modest proposal that is, at the very least, easy to implement. > >> > >> It seems that the problem arises from a fundamental mismatch > >> between the > >> way that clients interact with relays, and the way that > TCP listeners > >> generally behave. For example, consider the way the > sockets interface > >> handles TCP server connections: applications create a socket > >> descriptor > >> and listen() on it. When a new incoming connection is made, the > >> listen() > >> call returns a *new* socket descriptor, which the applications then > >> performs read() and write() operations on. > >> > >> Now, what we're really trying to do with TCP TURN is provide remote > >> access to this kind of resource model. The problem arises when we > >> try to > >> take the original socket (the listen() socket) and multiplex its > >> information with multiple other sockets (the read() and write() > >> sockets) > >> on a single TCP connection. > >> > >> So what I'm proposing is: don't. > >> > >> In other words: to listen for incoming TCP connections, > TURN clients > >> would establish a TCP connection to the relay (roughly > >> corresponding to > >> the listen() socket) that serves as a control channel. > When a remote > >> peer connects, the Connection Status Indication (ESTABLISHED) would > >> include a new attribute, which contains a cookie. The user then > >> connects > >> to the relay using a new TCP connection, authenticates, and then > >> sends > >> the cookie in a request of some kind (perhaps we re-use CONNECT for > >> this; perhaps we use a new message type). From that point forward, > >> this > >> new connection is used to ferry information to and from the remote > >> peer > >> connection. > >> > >> I recognize that this generally ends up taking twice as many > >> connections; I think that there is room for optimization > on top of > >> the > >> basic theme (e.g., dropping the control connection when listening > >> is no > >> longer necessary), but wanted to know whether there would be any > >> support > >> for this *kind* of approach before I spent too much time > polishing > >> the > >> corners down. > > > > The TURN-TCP authors considered this approach. I developed > a proposal > > similar to the one you are proposing and argued for it. > > > > As I recall, we dropped this one because it didn't work well with > > ICE. The client would end up establishing a lot of temporary TCP > > connections to the server that would then be dropped. > > I'm being dense and don't understand why this doesn't work well with > ICE. Can you explain? Here is the analysis: Let's say you receive four a=candidate lines from your peer. You prioritize the list of candidates, as specified in ICE. You start doing connectivity checks (basically, the priority is: local candidates, STUN'd candidates, TURN'd candidates). You do those following the pacing rules (to not flood the network). If, as you are doing your connectivity checks, none of them is succeeding so far, you will eventually get so low in your priority list to need to use your TURN server to do the four connectivity checks. Now, the two different designs: * If the design of TURN requires a new TCP connection for each of those four connectivity checks, you have four TCP 3-way handshakes to the TURN server. * If the design of TURN requires only one TCP connection for each of those four connectivity checks, you can send the connectivity checks inside of TCP. I would assume, because you're running over TCP, you are already TCP-friendly so the connectivity checks would not need to be paced. It is certainly worth discussing if establishing the separate TCP connections is 'bad', especially compared to how 'bad' it is to multiplex several TCP connections over one TCP connection. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 11 13:55:37 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F325B3A67A6; Fri, 11 Apr 2008 13:55:36 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BCA13A67A6 for ; Fri, 11 Apr 2008 13:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.812 X-Spam-Level: X-Spam-Status: No, score=-5.812 tagged_above=-999 required=5 tests=[AWL=0.787, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjEOw5g5zu68 for ; Fri, 11 Apr 2008 13:55:34 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 926AF3A67A3 for ; Fri, 11 Apr 2008 13:55:34 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 11 Apr 2008 13:55:58 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3BKtwIa030756 for ; Fri, 11 Apr 2008 13:55:58 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3BKtwYR004301 for ; Fri, 11 Apr 2008 20:55:58 GMT From: "Dan Wing" To: "'Behave WG'" Date: Fri, 11 Apr 2008 13:55:58 -0700 Message-ID: <005f01c89c16$71b41520$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcicE+bEDgfriIkmRPK8BNkMsJHTwAAAUdCA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=311; t=1207947358; x=1208811358; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20Nortel's=20updated=20IPR=20on=20RFC3489=20 |Sender:=20; bh=+d1HegziO3WfyoHMjK/ukW+csN2OBXu9DMX6h0wtIlQ=; b=RA1w4arembYZM56rok+4YIcb3Lo10jQr//HKA9X+J7aRaJa5xJUcwDxMTq akj8q/Eb/sslBlsF0AhnsReZwFmBFkFY3CXmzLthHVQ2FeYf1CcHYJ6b20gX JEr/AqEzH0; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [BEHAVE] Nortel's updated IPR on RFC3489 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org As you may recall, in January Nortel issued IPR declarations for draft-ietf-behave-nat-behavior-discovery and RFC3489, http://www.ietf.org/mail-archive/web/behave/current/msg03150.html I received word that Nortel has updated their license regarding RFC3489, https://datatracker.ietf.org/ipr/937/ -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 14 05:50:26 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29BE3A6E6C; Mon, 14 Apr 2008 05:50:26 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A5DD3A696A for ; Mon, 14 Apr 2008 05:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWThDkLbfAbx for ; Mon, 14 Apr 2008 05:50:24 -0700 (PDT) Received: from mail-02.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 7FC283A67B7 for ; Mon, 14 Apr 2008 05:49:56 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JlO8g-0007Hh-1Y; Mon, 14 Apr 2008 08:50:26 -0400 Message-Id: From: Philip Matthews To: Eric Rescorla , Cullen Jennings In-Reply-To: <20080411153033.03E1F50854@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 14 Apr 2008 08:50:26 -0400 References: <20080411153033.03E1F50854@romeo.rtfm.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: Behave WG Subject: Re: [BEHAVE] Minutes of TURN conf call on 8 April 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Ok, then comment away on the proposal. - Philip On Fri, 11-Apr-08, at 11:30 , Eric Rescorla wrote: > At Tue, 8 Apr 2008 16:06:00 -0400, > Philip Matthews wrote: >> 4. Anycast and ALTERNATE-SERVER >> There was another long discussion about anycast and ALTERNATE-SERVER. >> It was agreed that TURN would not specify all the details about how >> anycast discovery of a server would work, but just specify some >> necessary pieces. A full anycast discovery procedure could then be >> advanced as a separate document (though note that BEHAVE does not >> have >> a milestone for such a document). >> One necessary piece is the specification of the ALTERNATE-SERVER >> semantics, and the proposal that Philip sent to the mailing >> list on 7 April 2008 was accepted without comment. > > I don't recall this, nor does it make sense without the authentication > issue being complete. > >> A second piece >> might be a change in the requirement that any response using >> ALTERNATE- >> SERVER be authenticated -- it was pointed out that TURN >> authentication >> currently authenticates the client, not the server. However, the >> participants were unable to agree on a way to fix this, and more >> discussion is required. > > > -Ekr > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 14 13:13:54 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A3C63A6A2E; Mon, 14 Apr 2008 13:13:54 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 936443A69FE for ; Mon, 14 Apr 2008 13:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4dDN4gwtruO for ; Mon, 14 Apr 2008 13:13:50 -0700 (PDT) Received: from mail-01.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id C242D3A680D for ; Mon, 14 Apr 2008 13:13:50 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JlV4H-0004AT-14; Mon, 14 Apr 2008 16:14:21 -0400 Message-Id: From: Philip Matthews To: Derek MacDonald , Bruce Lowekamp Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 14 Apr 2008 16:14:20 -0400 X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: Behave WG Subject: [BEHAVE] A few minor comments on draft-ietf-behave-nat-behavior-discovery-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I know this comes after WGLC, but here are a few minor comments on this draft. Note that I haven't finished reading the document, but I am sending these out now in case they are helpful. - Philip * The wording of this draft seems to imply that it is an experimental extension to draft-ietf-behave-rfc3489bis (and not, for example, RFC 3489). Perhaps it would be good to make a definite statement about this in the introduction section? * From the draft: 4.2. Determining NAT Mapping Behavior This will require at most three tests. In test I, the client performs the UDP connectivity test. The server will return its alternate address and port in OTHER-ADDRESS in the binding response. If OTHER-ADDRESS is not returned, the server does not support this usage and this test cannot be run. The client examines the XOR- MAPPED-ADDRESS attribute. If this address and port are the same as the local IP address and port of the socket used to send the request, the client knows that it is not NATed and the effective mapping will be Endpoint-Independent. What about the case of cascaded NATs where the address gets reused in a different addressing domain? This will give the wrong result. This failure seems different than some other failures in that it is not the NAT that is "faking out" the test, but rather a consequence of the network topology. * Is section 4 normative or informative? * From the draft: the server. Therefore, a client MUST be prepared for receiving a 420 s/for receiving/to receive/ _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 14 16:20:57 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0353C3A6961; Mon, 14 Apr 2008 16:20:57 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D22653A6961 for ; Mon, 14 Apr 2008 16:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FO8E8XiMeia7 for ; Mon, 14 Apr 2008 16:20:55 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id A88273A686B for ; Mon, 14 Apr 2008 16:20:55 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 14 Apr 2008 16:21:27 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3ENLRNU007466; Mon, 14 Apr 2008 16:21:27 -0700 Received: from dhcp-128-107-100-73.cisco.com (dhcp-128-107-100-73.cisco.com [128.107.100.73]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3ENLRE1018068; Mon, 14 Apr 2008 23:21:27 GMT Message-Id: From: Cullen Jennings To: Dan Wing In-Reply-To: <0c0c01c89bfd$446107e0$c5f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 14 Apr 2008 16:24:36 -0700 References: <47DEEF88.9060901@nostrum.com><8355427A-4338-4AE6-A4E5-2862EE5595B6@magma.ca> <12A94043-0CC0-4931-AB25-EF7CF7362050@cisco.com> <0c0c01c89bfd$446107e0$c5f0200a@cisco.com> X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4853; t=1208215287; x=1209079287; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20TCP=20TURN=20Multiplexing=20 Issue |Sender:=20; bh=PTyX/SLEFJDS+cNAaOGUM+ljusxayzgQwT3uzN9GJts=; b=eWwSevlHTJmON1JTp2/8vm8QNrFoMjxFM0MfUvzeWIZA4SOlmtm4+DTMx5 Zc56u8tdq6lGr41iK7lHg1yv7yMItXBUawlQY404WahIjet/5QCg+GUilRND UdxU5YmE/R; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'Behave WG' , 'Philip Matthews' Subject: Re: [BEHAVE] TCP TURN Multiplexing Issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Apr 11, 2008, at 10:55 AM, Dan Wing wrote: > > >> -----Original Message----- >> From: behave-bounces@ietf.org >> [mailto:behave-bounces@ietf.org] On Behalf Of Cullen Jennings >> Sent: Thursday, April 10, 2008 8:11 PM >> To: Philip Matthews >> Cc: 'Behave WG' >> Subject: Re: [BEHAVE] TCP TURN Multiplexing Issue >> >> >> On Mar 19, 2008, at 8:38 AM, Philip Matthews wrote: >>> >>> On Mon, 17-Mar-08, at 18:24 , Adam Roach wrote: >>> >>>> I've done a lot of thinking on the "multiple relayed connections >>>> over a >>>> single Client-Relay connection" problem over the weekend, and I >>>> have a >>>> modest proposal that is, at the very least, easy to implement. >>>> >>>> It seems that the problem arises from a fundamental mismatch >>>> between the >>>> way that clients interact with relays, and the way that >> TCP listeners >>>> generally behave. For example, consider the way the >> sockets interface >>>> handles TCP server connections: applications create a socket >>>> descriptor >>>> and listen() on it. When a new incoming connection is made, the >>>> listen() >>>> call returns a *new* socket descriptor, which the applications then >>>> performs read() and write() operations on. >>>> >>>> Now, what we're really trying to do with TCP TURN is provide remote >>>> access to this kind of resource model. The problem arises when we >>>> try to >>>> take the original socket (the listen() socket) and multiplex its >>>> information with multiple other sockets (the read() and write() >>>> sockets) >>>> on a single TCP connection. >>>> >>>> So what I'm proposing is: don't. >>>> >>>> In other words: to listen for incoming TCP connections, >> TURN clients >>>> would establish a TCP connection to the relay (roughly >>>> corresponding to >>>> the listen() socket) that serves as a control channel. >> When a remote >>>> peer connects, the Connection Status Indication (ESTABLISHED) would >>>> include a new attribute, which contains a cookie. The user then >>>> connects >>>> to the relay using a new TCP connection, authenticates, and then >>>> sends >>>> the cookie in a request of some kind (perhaps we re-use CONNECT for >>>> this; perhaps we use a new message type). From that point forward, >>>> this >>>> new connection is used to ferry information to and from the remote >>>> peer >>>> connection. >>>> >>>> I recognize that this generally ends up taking twice as many >>>> connections; I think that there is room for optimization >> on top of >>>> the >>>> basic theme (e.g., dropping the control connection when listening >>>> is no >>>> longer necessary), but wanted to know whether there would be any >>>> support >>>> for this *kind* of approach before I spent too much time >> polishing >>>> the >>>> corners down. >>> >>> The TURN-TCP authors considered this approach. I developed >> a proposal >>> similar to the one you are proposing and argued for it. >>> >>> As I recall, we dropped this one because it didn't work well with >>> ICE. The client would end up establishing a lot of temporary TCP >>> connections to the server that would then be dropped. >> >> I'm being dense and don't understand why this doesn't work well with >> ICE. Can you explain? > > Here is the analysis: > > > Let's say you receive four a=candidate lines from your peer. You > prioritize the list of candidates, as specified in ICE. You start > doing connectivity checks (basically, the priority is: local > candidates, STUN'd candidates, TURN'd candidates). You do those > following the pacing rules (to not flood the network). > > If, as you are doing your connectivity checks, none of them is > succeeding so far, you will eventually get so low in your priority > list to need to use your TURN server to do the four connectivity > checks. > > > Now, the two different designs: > > * If the design of TURN requires a new TCP connection for each of > those four connectivity checks, you have four TCP 3-way handshakes > to the TURN server. > > * If the design of TURN requires only one TCP connection for each > of those four connectivity checks, you can send the connectivity > checks inside of TCP. I would assume, because you're running > over TCP, you are already TCP-friendly so the connectivity > checks would not need to be paced. > > > > It is certainly worth discussing if establishing the separate > TCP connections is 'bad', especially compared to how 'bad' it is > to multiplex several TCP connections over one TCP connection. > > -d > Thanks - I see what you are saying. I'm not sure how bad it is. Fundamentally ICE forms a ton of connections that don't get used so not sure how much different I see these than others. Would be ntersting to see more results on this. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 15 14:17:57 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 381FA3A6F4F; Tue, 15 Apr 2008 14:17:57 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522983A6F4F for ; Tue, 15 Apr 2008 14:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anZ2hDLD-GAl for ; Tue, 15 Apr 2008 14:17:54 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 820343A6F19 for ; Tue, 15 Apr 2008 14:17:54 -0700 (PDT) Received: from boris-lab3.nc.tekelec.com (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 37E2B18156A1; Tue, 15 Apr 2008 23:18:27 +0200 (CEST) Message-ID: <48051BE4.4000103@iptel.org> Date: Tue, 15 Apr 2008 23:19:32 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Hadriel Kaplan References: In-Reply-To: Cc: Behave WG , David R Oran , Ward , David@core3.amsl.com, Mark Townsley , Philip Matthews Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hadriel Kaplan wrote: > I am in still in favor of it, specifically for anycast support. Sorry for such a late comment, still I'm hopeful better late than never. I think use of anycast in this context may be useful and we shall not preclude it in any way. There are surveys showing that from the application point of view, instability (affinity) is a marginal issue. See Ballani, Francis, Rtnsasamy: Measurement-based Deployment Proposal for IP Anycast; Sigcomm 2006. I have seen similar observations in other publications, alas I can't recall those right nowl. -jiri _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 15 14:24:21 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 806513A6A70; Tue, 15 Apr 2008 14:24:21 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2F0328C3D8 for ; Tue, 15 Apr 2008 14:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkUxa0FeE6AC for ; Tue, 15 Apr 2008 14:24:18 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 9502F3A6A70 for ; Tue, 15 Apr 2008 14:24:18 -0700 (PDT) Received: from boris-lab3.nc.tekelec.com (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 2AC75181BE50; Tue, 15 Apr 2008 23:24:51 +0200 (CEST) Message-ID: <48051D64.30405@iptel.org> Date: Tue, 15 Apr 2008 23:25:56 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Eric Rescorla References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> In-Reply-To: <20080403162320.E34475081A@romeo.rtfm.com> Cc: Behave WG , David R Oran , Ward , David@core3.amsl.com, Mark Townsley , Philip Matthews Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Eric Rescorla wrote: > At Thu, 3 Apr 2008 12:11:16 -0400, > Hadriel Kaplan wrote: >> >> >>> -----Original Message----- >>> From: Eric Rescorla [mailto:ekr@networkresonance.com] >>> >>> At Thu, 3 Apr 2008 09:21:23 -0400, >>> Philip Matthews wrote: >>>> I am still trying to dig into the reasons the experts think that multi- >>>> packet exchanges won't work. My initial reaction is exactly the same >>>> as yours. >>> There's nothing complicated here: >>> The Internet routing system does not guarantee that two packets >>> sent to the same anycast address from the same source address >>> will be delivered to the same destination. To the extent to which >>> it's currently the case that that usually happens, that's an >>> artifact of today's routing systems. It's bad practice to design >>> new systems such that they depend on this behavior, because we >>> may wish to change it in the future. >> I think they will find all kinds of crap breaking if they try to >> change that behavior (people do far worse with anycasts than what >> we're proposing), > > Yes, but at their own risk. That's different from us encouraging it. > > >> but ok - would graceful detection and avoidance of >> such a case resolve this? >> >> Like if it's using TCP/TLS, then it's possible the connection >> establishment will fail, or it's possible a sent request will reset >> the connection, but that is possible regardless of anycast and needs >> to be handled. > > Right, but it's possible that this will *never* work. > > Consider a load balancing system that has two paths and uses a packet > hash to determine which path it will take. If the SYN and the SYN/ACK > end up on different paths, then anycast will totally break the system. > You'll not be able to form a TCP connection at all. See my previous email -- it is a risk known empirically to be low. I'm inclined to conclude to support it with a "use at your own risk" disclaimer. Those who can benefit of it should be warned but not precluded from using it. > > Maybe I'm missing something, but why use anycast at this layer at > all. Wouldn't it be easier to have the TURN servers be unicast and use > anycast (or just load balanced) DNS resolution instead, with different > servers giving different responses? That's not 100% perfect either as the DNS resolver from TURN server's perspective may or may not be the actual client, whose proximity is sought. Some publications suggest that practically this is mostly fine. (Chen, Lim, Katz, Overton: on the stability of network distance estimation, sigmetric perf. eval. rev. 2002) -jiri > > -Ekr > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 15 14:35:30 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ADFD28C451; Tue, 15 Apr 2008 14:35:30 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF4C53A684F for ; Tue, 15 Apr 2008 14:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4hW+GX0loF9 for ; Tue, 15 Apr 2008 14:35:28 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 9931C3A695D for ; Tue, 15 Apr 2008 14:35:26 -0700 (PDT) Received: from boris-lab3.nc.tekelec.com (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 6CA8F1810C68; Tue, 15 Apr 2008 23:35:59 +0200 (CEST) Message-ID: <48052000.4070202@iptel.org> Date: Tue, 15 Apr 2008 23:37:04 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Eric Rescorla References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <20080403171745.C40525081A@romeo.rtfm.com> <1BE816DD-B162-4431-AF9B-81CE5416AABF@magma.ca> <20080407220405.1A1855081A@romeo.rtfm.com> <30fe01c89901$109b2840$c5f0200a@cisco.com> <20080407232511.C21AA5081A@romeo.rtfm.com> <318901c8990a$09e8e600$c5f0200a@cisco.com> <20080408044503.417045081A@romeo.rtfm.com> In-Reply-To: <20080408044503.417045081A@romeo.rtfm.com> Cc: 'Behave WG' , 'David R Oran' , 'Philip Matthews' , Dan Wing Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Eric Rescorla wrote: > At Mon, 7 Apr 2008 16:49:36 -0700, > Dan Wing wrote: >> >> >>> -----Original Message----- >>> From: behave-bounces@ietf.org >>> [mailto:behave-bounces@ietf.org] On Behalf Of Eric Rescorla >>> Sent: Monday, April 07, 2008 4:25 PM >>> To: Dan Wing >>> Cc: 'Behave WG'; 'David R Oran'; 'Philip Matthews' >>> Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast >>> >>> At Mon, 7 Apr 2008 15:45:23 -0700, >>> Dan Wing wrote: >>>> >>>>>> In either of these cases, if the client simply retries >>> the request >>>>>> from scratch, then it will be highly likely to succeed the >>>>>> second time. >>>>> As I said in my comments to Hadriel, this is not >>> guaranteed to work >>>>> if the first and third packets of the TCP handshake go to >>> different >>>>> places (e.g., because of hash-based PPLB). >>>> PPLB = per packet load balancing, I presume. >>>> >>>> Can you point at a per-packet load balancer that would purposefully >>>> or accidentally (through misconfiguration) send packets >>> with the same >>>> 5-tuple to different servers? >>> Why is that relevant? >>> >>> As I noted earlier, the issue isn't what the current network >>> does but rather that there is no guarantee that a future network >>> will not do this in the future. Designing a system that relies >>> on a property of the network that is not one of its architectural >>> invariants is bad, because it sticks people in the future with >>> the choice of breaking the system or retaining the invariant >>> even if it's no longer a good idea. >> ALTERNATE-SERVER does not require the TURN servers to use >> anycast. If, in some future where anycasting works >> differently, that anycasted TURN server can avoid using >> ALTERNATE-SERVER and can do something new and fancy. >> >> Today, there appears to be at least one company >> that has found anycast with TCP works: >> http://www.nanog.org/mtg-0606/pdf/matt.levine.pdf > > For the third time, now: the issue is not what currently works > but what the architecture of the Internet guarantees. I have made an interesting observation with the Internet: NATs, one of the topics of interest of this working group, have never been part of a guaranteed Internet architecture, they have been always the thing that currently works. I would be worried to underestimate this kind of things. > > >>> I didn't say anything about introducing alternate server. What I >>> said was that if anycast was needed in the future, we could add >>> that. >> So you're saying we should use something other than anycast >> to justify inclusion of the ALTERNATE-SERVER attribute ? > > Uh, no. So what's the actual suggestion? Thanks, -jiri > > -Ekr > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 15 15:02:15 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DF023A6B59; Tue, 15 Apr 2008 15:02:15 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D0F28C3D8 for ; Tue, 15 Apr 2008 15:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLsyHI3kUnLU for ; Tue, 15 Apr 2008 15:02:13 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 780753A6B59 for ; Tue, 15 Apr 2008 15:02:13 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id BC5205081A; Tue, 15 Apr 2008 15:04:39 -0700 (PDT) Date: Tue, 15 Apr 2008 15:04:39 -0700 From: Eric Rescorla To: Jiri Kuthan In-Reply-To: <48051D64.30405@iptel.org> References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <48051D64.30405@iptel.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080415220439.BC5205081A@romeo.rtfm.com> Cc: Behave WG , David R Oran , Ward , David@core3.amsl.com, Mark Townsley , Philip Matthews Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Tue, 15 Apr 2008 23:25:56 +0200, Jiri Kuthan wrote: > > Eric Rescorla wrote: > > At Thu, 3 Apr 2008 12:11:16 -0400, > > Hadriel Kaplan wrote: > >> > >> > >>> -----Original Message----- > >>> From: Eric Rescorla [mailto:ekr@networkresonance.com] > >>> > >>> At Thu, 3 Apr 2008 09:21:23 -0400, > >>> Philip Matthews wrote: > >>>> I am still trying to dig into the reasons the experts think that multi- > >>>> packet exchanges won't work. My initial reaction is exactly the same > >>>> as yours. > >>> There's nothing complicated here: > >>> The Internet routing system does not guarantee that two packets > >>> sent to the same anycast address from the same source address > >>> will be delivered to the same destination. To the extent to which > >>> it's currently the case that that usually happens, that's an > >>> artifact of today's routing systems. It's bad practice to design > >>> new systems such that they depend on this behavior, because we > >>> may wish to change it in the future. > >> I think they will find all kinds of crap breaking if they try to > >> change that behavior (people do far worse with anycasts than what > >> we're proposing), > > > > Yes, but at their own risk. That's different from us encouraging it. > > > > > >> but ok - would graceful detection and avoidance of > >> such a case resolve this? > >> > >> Like if it's using TCP/TLS, then it's possible the connection > >> establishment will fail, or it's possible a sent request will reset > >> the connection, but that is possible regardless of anycast and needs > >> to be handled. > > > > Right, but it's possible that this will *never* work. > > > > Consider a load balancing system that has two paths and uses a packet > > hash to determine which path it will take. If the SYN and the SYN/ACK > > end up on different paths, then anycast will totally break the system. > > You'll not be able to form a TCP connection at all. > > See my previous email -- it is a risk known empirically to be low. > I'm inclined to conclude to support it with a "use at your own risk" > disclaimer. Those who can benefit of it should be warned but not > precluded from using it. Once again, the relevant question isn't whether this works in the current network but whether it's guaranteed to work by the Internet routing architecture. The answer to *that* question is "No", and hence this is architecturally unsound. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 15 23:45:47 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED9428C35C; Tue, 15 Apr 2008 23:45:47 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7B0628C2F9 for ; Tue, 15 Apr 2008 23:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DHjLTum9Fu9 for ; Tue, 15 Apr 2008 23:45:41 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 75F6E28C0F7 for ; Tue, 15 Apr 2008 23:45:36 -0700 (PDT) Received: from boris-lab3.nc.tekelec.com (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 0094D1810C6B; Wed, 16 Apr 2008 08:46:09 +0200 (CEST) Message-ID: <4805A0F2.20605@iptel.org> Date: Wed, 16 Apr 2008 08:47:14 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Eric Rescorla References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <48051D64.30405@iptel.org> <20080415220439.BC5205081A@romeo.rtfm.com> In-Reply-To: <20080415220439.BC5205081A@romeo.rtfm.com> Cc: Behave WG , David R Oran , Ward , David@core3.amsl.com, Mark Townsley , Philip Matthews Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Eric Rescorla wrote: > At Tue, 15 Apr 2008 23:25:56 +0200, > Jiri Kuthan wrote: >> Eric Rescorla wrote: >>> At Thu, 3 Apr 2008 12:11:16 -0400, >>> Hadriel Kaplan wrote: >>>> >>>>> -----Original Message----- >>>>> From: Eric Rescorla [mailto:ekr@networkresonance.com] >>>>> >>>>> At Thu, 3 Apr 2008 09:21:23 -0400, >>>>> Philip Matthews wrote: >>>>>> I am still trying to dig into the reasons the experts think that multi- >>>>>> packet exchanges won't work. My initial reaction is exactly the same >>>>>> as yours. >>>>> There's nothing complicated here: >>>>> The Internet routing system does not guarantee that two packets >>>>> sent to the same anycast address from the same source address >>>>> will be delivered to the same destination. To the extent to which >>>>> it's currently the case that that usually happens, that's an >>>>> artifact of today's routing systems. It's bad practice to design >>>>> new systems such that they depend on this behavior, because we >>>>> may wish to change it in the future. >>>> I think they will find all kinds of crap breaking if they try to >>>> change that behavior (people do far worse with anycasts than what >>>> we're proposing), >>> Yes, but at their own risk. That's different from us encouraging it. >>> >>> >>>> but ok - would graceful detection and avoidance of >>>> such a case resolve this? >>>> >>>> Like if it's using TCP/TLS, then it's possible the connection >>>> establishment will fail, or it's possible a sent request will reset >>>> the connection, but that is possible regardless of anycast and needs >>>> to be handled. >>> Right, but it's possible that this will *never* work. >>> >>> Consider a load balancing system that has two paths and uses a packet >>> hash to determine which path it will take. If the SYN and the SYN/ACK >>> end up on different paths, then anycast will totally break the system. >>> You'll not be able to form a TCP connection at all. >> See my previous email -- it is a risk known empirically to be low. >> I'm inclined to conclude to support it with a "use at your own risk" >> disclaimer. Those who can benefit of it should be warned but not >> precluded from using it. > > Once again, the relevant question isn't whether this works in the > current network but whether it's guaranteed to work by the Internet > routing architecture. The answer to *that* question is "No", and > hence this is architecturally unsound. I respectfully disagree this argument makes a case (or even as many cases as many times it is repeated :-) ... I really read your point.). The Internet is what it is and not what it is thought to be. The NAT story, where IETF for the "guaranteed Internet architecture" reasons chose to ignore NATs, to find later they form the Internet more than an "architecture" may be a great eye-opening experience for anyone. Particularly with respect to the VoIP area, skype actually began to be the Internet application with running code whereas SIP began to be kind of architectural stuff. I think empirical grounded publications, of which you have been given two references, show best what the Internet really is. In particular, they show that what is believed to be architectural problem doesn't occur with running code. I personally consider this research a very sound foundation for protocol design, and I don't think it can be challenged on the grounds of some routing architectures. -jiri > > -Ekr > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 16 07:25:25 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76B5F3A6AA3; Wed, 16 Apr 2008 07:25:25 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C063A6AEB for ; Wed, 16 Apr 2008 07:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrzmLVdkFB2n for ; Wed, 16 Apr 2008 07:25:22 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 497053A6864 for ; Wed, 16 Apr 2008 07:24:56 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 03216222473; Wed, 16 Apr 2008 07:25:30 -0700 (PDT) Date: Wed, 16 Apr 2008 07:25:30 -0700 From: Eric Rescorla To: Jiri Kuthan In-Reply-To: <4805A0F2.20605@iptel.org> References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <48051D64.30405@iptel.org> <20080415220439.BC5205081A@romeo.rtfm.com> <4805A0F2.20605@iptel.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080416142531.03216222473@kilo.rtfm.com> Cc: Behave WG , David R Oran , Ward , David@core3.amsl.com, Mark Townsley , Philip Matthews Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Wed, 16 Apr 2008 08:47:14 +0200, Jiri Kuthan wrote: > > Eric Rescorla wrote: > > Once again, the relevant question isn't whether this works in the > > current network but whether it's guaranteed to work by the Internet > > routing architecture. The answer to *that* question is "No", and > > hence this is architecturally unsound. > > I respectfully disagree this argument makes a case (or even as many > cases as many times it is repeated :-) ... I really read your point.). You're entitled to your opinion, but since you're just repeating your point again, there's no reason why I should expect it to be convincing. > The Internet is what it is and not what it is thought to be. > The NAT story, where IETF for the "guaranteed Internet architecture" > reasons chose to ignore NATs, to find later they form the Internet more > than an "architecture" may be a great eye-opening experience for anyone. Yes, strangely as a long-time participant, I'm quite aware of NATs. I don't think that invalidates my point. > I think empirical grounded publications, of which you have been given > two references, show best what the Internet really is. In particular, > they show that what is believed to be architectural problem doesn't > occur with running code. You claim you read my point, but you don't seem to understand it. The architectural point isn't that it happens with the current code, but that if we assume that this is the only behavior that can happen, we create a new invariant that will then constrain all future Internet routing system design. Go sell the routing area that that's cool and then we'll talk. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 16 07:26:17 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2982B3A6AFA; Wed, 16 Apr 2008 07:26:17 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7FEB3A694E for ; Wed, 16 Apr 2008 07:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.844 X-Spam-Level: X-Spam-Status: No, score=-0.844 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o83jGYhHIC+k for ; Wed, 16 Apr 2008 07:26:15 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id E466D3A67F3 for ; Wed, 16 Apr 2008 07:26:14 -0700 (PDT) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1Jm8b23kD0-0007qS; Wed, 16 Apr 2008 10:26:50 -0400 Message-ID: <02f401c89fcd$c7a7bcb0$ad600240@china.huawei.com> From: "Spencer Dawkins" To: "Behave WG" References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <48051D64.30405@iptel.org><20080415220439.BC5205081A@romeo.rtfm.com> <4805A0F2.20605@iptel.org> Date: Wed, 16 Apr 2008 09:25:51 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX1+g475knjz06TYwK7kaVSua5Y9DhgsHmzTyWdA dQafzbXqvrqrxlrAtuP8ku+ZNzX0pWvIql4PQ6VghrKUU7xeK1 bkl3CgXbh7lNN5VKoHy4tYae0sYBU3JwCRxI5xiaQw= Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I THINK I understand what's being said in this thread. Just to up-level one notch, is there any reason that we have to mention TCP anycast at all in this specification? Thanks, Spencer _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 16 08:24:18 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7204D28C218; Wed, 16 Apr 2008 08:24:18 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2375828C237 for ; Wed, 16 Apr 2008 08:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yP+AWyFA3QN for ; Wed, 16 Apr 2008 08:24:11 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 2D6AF28C226 for ; Wed, 16 Apr 2008 08:24:11 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-3.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 6B1C71817EE9; Wed, 16 Apr 2008 17:24:45 +0200 (CEST) Message-ID: <48061A7D.3030003@iptel.org> Date: Wed, 16 Apr 2008 17:25:49 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Eric Rescorla References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <48051D64.30405@iptel.org> <20080415220439.BC5205081A@romeo.rtfm.com> <4805A0F2.20605@iptel.org> <20080416142531.03216222473@kilo.rtfm.com> In-Reply-To: <20080416142531.03216222473@kilo.rtfm.com> Cc: Behave WG , woody@pch.net, David R Oran , Ward , David@core3.amsl.com, Mark Townsley , Philip Matthews Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Eric Rescorla wrote: > At Wed, 16 Apr 2008 08:47:14 +0200, > Jiri Kuthan wrote: >> Eric Rescorla wrote: >>> Once again, the relevant question isn't whether this works in the >>> current network but whether it's guaranteed to work by the Internet >>> routing architecture. The answer to *that* question is "No", and >>> hence this is architecturally unsound. >> I respectfully disagree this argument makes a case (or even as many >> cases as many times it is repeated :-) ... I really read your point.). > > You're entitled to your opinion, but since you're just repeating > your point again, there's no reason why I should expect it to > be convincing. > > >> The Internet is what it is and not what it is thought to be. >> The NAT story, where IETF for the "guaranteed Internet architecture" >> reasons chose to ignore NATs, to find later they form the Internet more >> than an "architecture" may be a great eye-opening experience for anyone. > > Yes, strangely as a long-time participant, I'm quite aware of NATs. > I don't think that invalidates my point. > > >> I think empirical grounded publications, of which you have been given >> two references, show best what the Internet really is. In particular, >> they show that what is believed to be architectural problem doesn't >> occur with running code. > > You claim you read my point, but you don't seem to understand it. The > architectural point isn't that it happens with the current code, but > that if we assume that this is the only behavior that can happen, we > create a new invariant that will then constrain all future Internet > routing system design. I don't think I misunderstand your point, I just mean that "architectural" arguments are weak as whole in lieu of running code doing things in a different way and being reserched by founded publications. If running code delivers and its measurement give us a different picture than an "architecture", there is then apparently something wrong in the "architecture". Also, I don't think anyone was mandating here a requirement to do anycast. Instead, the suggestion here was to allow TURN to do it for those who wish to. I'm failing to see how allowing the anycast option in TURN can "constrain all future Internet routing system designs". It would be most helpful if you could elaborate on this. Go sell the routing area that that's cool > and then we'll talk. Really rhetorics is not any helpful. It would be most helpful if you could continue this conversation by providing supporting arguments -jiri _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 16 08:34:55 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21FF328C247; Wed, 16 Apr 2008 08:34:55 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3FA128C247 for ; Wed, 16 Apr 2008 08:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xMUibfSZ-Zu for ; Wed, 16 Apr 2008 08:34:50 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 118CB28C1D1 for ; Wed, 16 Apr 2008 08:34:50 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 334D25081A; Wed, 16 Apr 2008 08:38:52 -0700 (PDT) Date: Wed, 16 Apr 2008 08:38:52 -0700 From: Eric Rescorla To: Jiri Kuthan In-Reply-To: <48061A7D.3030003@iptel.org> References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <48051D64.30405@iptel.org> <20080415220439.BC5205081A@romeo.rtfm.com> <4805A0F2.20605@iptel.org> <20080416142531.03216222473@kilo.rtfm.com> <48061A7D.3030003@iptel.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080416153852.334D25081A@romeo.rtfm.com> Cc: Behave WG , woody@pch.net, David R Oran , Ward , David@core3.amsl.com, Mark Townsley , Philip Matthews Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Wed, 16 Apr 2008 17:25:49 +0200, Jiri Kuthan wrote: > > Eric Rescorla wrote: > > At Wed, 16 Apr 2008 08:47:14 +0200, > > Jiri Kuthan wrote: > >> I think empirical grounded publications, of which you have been given > >> two references, show best what the Internet really is. In particular, > >> they show that what is believed to be architectural problem doesn't > >> occur with running code. > > > > You claim you read my point, but you don't seem to understand it. The > > architectural point isn't that it happens with the current code, but > > that if we assume that this is the only behavior that can happen, we > > create a new invariant that will then constrain all future Internet > > routing system design. > > I don't think I misunderstand your point, I just mean that > "architectural" arguments are weak as whole in lieu of running code > doing things in a different way and being reserched by founded > publications. If running code delivers and its measurement give us a > different picture than an "architecture", there is then apparently > something wrong in the "architecture". I'm sorry, but this is simply not true. There is already existing hardware that breaks the invariants that anycast TCP relies on. Moreover, there are known cases where its useful to deploy such techniques. The fact that those techniques are not currently in wide use does not mean that it's a good idea to design systems that would preclude their use in the future. The fact that you have measurements indicating that this is not a widespread problem with the current designs is, frankly, irrelevant. Using the argument you're advancing, I could as easily argue that it was perfectly fine to build a system that relied on grabbing all of 2/24, since after all nobody is using it right now. An important part of good architecture is thinking about how systems might be used in the future, not just how they are used now. > Also, I don't think anyone was mandating here a requirement to do > anycast. Instead, the suggestion here was to allow TURN to do it for > those who wish to. I'm failing to see how allowing the anycast option in > TURN can "constrain all future Internet routing system designs". It > would be most helpful if you could elaborate on this. I should have thought it would be fairly obvious. If, in the future, we wish to deploy a routing system that breaks the invariants that allows anycast TCP to function, we'll hear from people that "oh, we need anycast TCP to work, so you can't do that". It will have become a new invariant. Given that there are plenty of alternatives that do not have this side effect, designing a system which does is bad architecture. > Really rhetorics is not any helpful. It would be most helpful if you > could continue this conversation by providing supporting arguments It's not rhetoric. This document has to pass IESG review. Have you asked them what they think about using anycast in this way? -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 16 12:53:44 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03DB53A6B07; Wed, 16 Apr 2008 12:53:44 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 724B83A6A54 for ; Wed, 16 Apr 2008 12:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgIGrUiyUocR for ; Wed, 16 Apr 2008 12:53:42 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 145BD3A6939 for ; Wed, 16 Apr 2008 12:51:11 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.263.0; Wed, 16 Apr 2008 15:45:50 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 16 Apr 2008 14:51:16 -0400 From: Hadriel Kaplan To: Behave WG Date: Wed, 16 Apr 2008 14:52:33 -0400 Thread-Topic: ALTERNATE-SERVER inclusion Thread-Index: Acif12+6XWSQIBAZQFCP4IGor/DIGAAFVuOA Message-ID: References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <48051D64.30405@iptel.org> <20080415220439.BC5205081A@romeo.rtfm.com> <4805A0F2.20605@iptel.org> <20080416142531.03216222473@kilo.rtfm.com> <48061A7D.3030003@iptel.org> <20080416153852.334D25081A@romeo.rtfm.com> In-Reply-To: <20080416153852.334D25081A@romeo.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "woody@pch.net" , David R Oran , Mark@core3.amsl.com, Ward , "David@core3.amsl.com" , Townsley Subject: [BEHAVE] ALTERNATE-SERVER inclusion X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I think we can ignore and avoid any debate about what ALTERNATE_SERVER may be used for if, as Spencer suggested and I thought as we talked about on the last call, we only discuss its anycast-specific use for UDP. The Alt-server response may also be used for TCP, for other reasons, but we would discourage Anycasting-use of TCP in particular in the RFC. With regards to using it for anycast, I know we debated it on the call, but I don't know why a simple UDP query-response without extraneous authentication isn't sufficient. Yes, the server can be spoofed by a malicious attacker, such that the client goes somewhere it shouldn't. Seems to me we have that with DNS too. Oh well. It's up to the client if it wants to accept it or not. We can always define a DNSSEC-style mechanism for TURN in the future; for example the server responds with some signature over the Alt-server address, so it can keep the signature statically without recomputing it every query, and the client can verify the signature by pulling a cert through TURN or HTTP from somewhere, etc., etc. We don't need to do that for this TURN draft though, imho. Would that be acceptable? -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 16 12:57:23 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 607A43A6939; Wed, 16 Apr 2008 12:57:23 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2503A68BD for ; Wed, 16 Apr 2008 12:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzYyd79Aw9jB for ; Wed, 16 Apr 2008 12:57:20 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 332D13A6939 for ; Wed, 16 Apr 2008 12:57:20 -0700 (PDT) Received: from boris-lab3.nc.tekelec.com (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id C8EE91812DA9; Wed, 16 Apr 2008 21:57:54 +0200 (CEST) Message-ID: <48065A82.9050009@iptel.org> Date: Wed, 16 Apr 2008 21:58:58 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Eric Rescorla References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <48051D64.30405@iptel.org> <20080415220439.BC5205081A@romeo.rtfm.com> <4805A0F2.20605@iptel.org> <20080416142531.03216222473@kilo.rtfm.com> <48061A7D.3030003@iptel.org> <20080416153852.334D25081A@romeo.rtfm.com> In-Reply-To: <20080416153852.334D25081A@romeo.rtfm.com> Cc: Behave WG , woody@pch.net, David R Oran , Ward , David@core3.amsl.com, Mark Townsley , Philip Matthews Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Eric Rescorla wrote: > At Wed, 16 Apr 2008 17:25:49 +0200, > Jiri Kuthan wrote: >> Eric Rescorla wrote: >>> At Wed, 16 Apr 2008 08:47:14 +0200, >>> Jiri Kuthan wrote: >>>> I think empirical grounded publications, of which you have been given >>>> two references, show best what the Internet really is. In particular, >>>> they show that what is believed to be architectural problem doesn't >>>> occur with running code. >>> You claim you read my point, but you don't seem to understand it. The >>> architectural point isn't that it happens with the current code, but >>> that if we assume that this is the only behavior that can happen, we >>> create a new invariant that will then constrain all future Internet >>> routing system design. >> I don't think I misunderstand your point, I just mean that >> "architectural" arguments are weak as whole in lieu of running code >> doing things in a different way and being reserched by founded >> publications. If running code delivers and its measurement give us a >> different picture than an "architecture", there is then apparently >> something wrong in the "architecture". > > I'm sorry, but this is simply not true. > > There is already existing hardware that breaks the invariants that > anycast TCP relies on. Moreover, there are known cases where its > useful to deploy such techniques. The fact that those techniques are > not currently in wide use does not mean that it's a good idea to > design systems that would preclude their use in the future. Would you mind being more specific? It would be helpful to learn what type of equipment gets broken or breaks something else here. I mean some DNS root servers do anycast for a good reason and with good success. (This is really not 2/24 -- this is quite well understood *running code*.) Personally, if I was to choose between putting effort into supporting a case that is known and an unknown one and these two were for sure mutually exclusive, I would obviously prefer the former. > The fact that you have measurements indicating that this is not a > widespread problem with the current designs is, frankly, > irrelevant. Using the argument you're advancing, I could as easily > argue that it was perfectly fine to build a system that relied on > grabbing all of 2/24, since after all nobody is using it right now. > An important part of good architecture is thinking about how > systems might be used in the future, not just how they are > used now. Admittedly, future-proof design is good-to-have. However, I'm still not understanding how allowing for anycast in TURN would break (whatever ought to stand for) in the future. IMO, at worst, it can break itself, i.e., the TURN uses that chose to use anycast (even though I doubt that failure rate would be concerning based on the DNS/anycast reports). It would be different if for example someone suggested that to accomodate anycast-based use-cases the Internet must have a new invariant, which is stable delivery of anycast traffic to a single destination. I don't think such a weak suggestion or similar has been made. In the field, all known anycast uses have taken this into account, limit themselves to shortly-lived transactions with minimum context, and can cope with errors. In fact, I believe that there are more applications than DNS that can benefit of anycast. anycast-powered TURN is particularly appealing to ASPs who are seeking to move RTP relays (or SBCs if you wish to) close to at least one of SIP call parties. (I guess that was the case Hadriel had in his mind; at least I do.) > > >> Also, I don't think anyone was mandating here a requirement to do >> anycast. Instead, the suggestion here was to allow TURN to do it for >> those who wish to. I'm failing to see how allowing the anycast option in >> TURN can "constrain all future Internet routing system designs". It >> would be most helpful if you could elaborate on this. > > I should have thought it would be fairly obvious. If, in > the future, we wish to deploy a routing system that breaks > the invariants that allows anycast TCP to function, we'll > hear from people that "oh, we need anycast TCP to work, so > you can't do that". It will have become a new invariant. Possibly we might have found the disconnect. It is very agreeable that it makes little or actually no sense to demand TCP to function over anycast as good as over unicast. I don't think anyone is demanding this though. The residual risk with routing instability indeed remains there, it has proven marginal, and is to be traded off and entered at one's own risk for those who are willing to do so. Concerns about some suggesting something like a "fixed anycast routing" are IMO of educational nature, and if considered important, may be well addressed by IP-tutorials and other educational material documenting possible risks. Which appears to be out-of-scope of this debate for me. > Given that there are plenty of alternatives that do not have > this side effect, designing a system which does is bad architecture. Actually I don't think the other alternative are equal. One of the key motivations for use of TURN with anycast is getting a service close-to-client (or at least not-getting-a-service-far-from-client). A survey of such may be found for example in "Freedman LAsksminarayanan, Mazieres: OASIS, Anycast for Any Service" (OASIS itself is based on anycast). Many of them typically rely on creating a "map of the Internet" (which has its own cans of worms), or rely on specialized clients (which may be in fact architecturally sounder, but quite hard to deploy with widely available clients). > > >> Really rhetorics is not any helpful. It would be most helpful if you >> could continue this conversation by providing supporting arguments > > It's not rhetoric. This document has to pass IESG review. Have > you asked them what they think about using anycast in this way? It would be a surprise to me if participants of the IESG review were not on this mailing list. -jiri > > -Ekr > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 16 15:14:55 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0EB128C38C; Wed, 16 Apr 2008 15:14:55 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279B43A67D7 for ; Wed, 16 Apr 2008 15:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.944 X-Spam-Level: X-Spam-Status: No, score=-5.944 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqBXLIQvkWQn for ; Wed, 16 Apr 2008 15:14:54 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 34A8C28C38C for ; Wed, 16 Apr 2008 15:14:54 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 16 Apr 2008 15:15:31 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3GMFUKa025639; Wed, 16 Apr 2008 15:15:30 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3GMFTqI000908; Wed, 16 Apr 2008 22:15:30 GMT From: "Dan Wing" To: "'Hadriel Kaplan'" , "'Behave WG'" References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca><20080403143033.7006250854@romeo.rtfm.com><20080403162320.E34475081A@romeo.rtfm.com> <48051D64.30405@iptel.org><20080415220439.BC5205081A@romeo.rtfm.com> <4805A0F2.20605@iptel.org><20080416142531.03216222473@kilo.rtfm.com> <48061A7D.3030003@iptel.org><20080416153852.334D25081A@romeo.rtfm.com> Date: Wed, 16 Apr 2008 15:15:29 -0700 Message-ID: <091701c8a00f$61d4d1b0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acif12+6XWSQIBAZQFCP4IGor/DIGAAFVuOAAAhXV6A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2473; t=1208384130; x=1209248130; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20ALTERNATE-SERVER=20inclusion |Sender:=20; bh=BJMRkLxASl4fpigoqxuyC7n6LnO4RlVUB1neHkEeS4o=; b=UAHc75K+PZGruoDOECvfvYCiqtS5ZJJOLwgzSCv2CXiEkY4yNQRnw5c+Lc T41a478puYzPicVv/weIBTMglHzXTQN+4Ini6rDVmy4AG/tIaSaBrHno9KlB 4ZIZ2ZcneO; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: woody@pch.net, 'David R Oran' , 'Ward' , David@core3.amsl.com, 'Townsley' , Mark@core3.amsl.com Subject: Re: [BEHAVE] ALTERNATE-SERVER inclusion X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: Wednesday, April 16, 2008 11:53 AM > To: Behave WG > Cc: woody@pch.net; David R Oran; Mark@core3.amsl.com; Ward; > David@core3.amsl.com; Townsley > Subject: [BEHAVE] ALTERNATE-SERVER inclusion > > I think we can ignore and avoid any debate about what > ALTERNATE_SERVER may be used for if, as Spencer suggested and > I thought as we talked about on the last call, we only > discuss its anycast-specific use for UDP. The Alt-server > response may also be used for TCP, for other reasons, but we > would discourage Anycasting-use of TCP in particular in the RFC. > > With regards to using it for anycast, I know we debated it on > the call, but I don't know why a simple UDP query-response > without extraneous authentication isn't sufficient. Yes, the > server can be spoofed by a malicious attacker, such that the > client goes somewhere it shouldn't. Such an attacker would have to know (or guess) the 96-bit transaction id and know the client's source UDP port. > Seems to me we have that with DNS too. Oh well. It's up to > the client if it wants to accept it or not. Works for me. And in the future if/when DNSSEC is deployed and TURN needs stronger authentication (on par with DNSSEC), stronger authentication of Alternate-Server could be added to TURN. For example, in this DNSSEC future, one mechanism would be for the TURN server to return a new attribute which signs (part or all of) the STUN response with the TURN server's private key. The TURN client could obtain the TURN server's public key via a (DNSSEC-signed) DNS record. That would allow the DNS server and the TURN server to remain idempotent, and allow anycast to continue to be used. -d > We can always define a DNSSEC-style mechanism for TURN in the > future; for example the server responds with some signature > over the Alt-server address, so it can keep the signature > statically without recomputing it every query, and the client > can verify the signature by pulling a cert through TURN or > HTTP from somewhere, etc., etc. We don't need to do that for > this TURN draft though, imho. > > Would that be acceptable? > > -hadriel > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 16 15:16:03 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF6028C3E3; Wed, 16 Apr 2008 15:16:03 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C50A28C383 for ; Wed, 16 Apr 2008 15:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uByxILSPzVYR for ; Wed, 16 Apr 2008 15:16:00 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 3E8CD28C1DE for ; Wed, 16 Apr 2008 15:16:00 -0700 (PDT) Received: from boris-lab3.nc.tekelec.com (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 5EEE81810C55; Thu, 17 Apr 2008 00:16:35 +0200 (CEST) Message-ID: <48067B02.6000002@iptel.org> Date: Thu, 17 Apr 2008 00:17:38 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Hadriel Kaplan References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <48051D64.30405@iptel.org> <20080415220439.BC5205081A@romeo.rtfm.com> <4805A0F2.20605@iptel.org> <20080416142531.03216222473@kilo.rtfm.com> <48061A7D.3030003@iptel.org> <20080416153852.334D25081A@romeo.rtfm.com> In-Reply-To: Cc: Behave WG , "woody@pch.net" , David R Oran , Ward , "David@core3.amsl.com" , Townsley , Mark@core3.amsl.com Subject: Re: [BEHAVE] ALTERNATE-SERVER inclusion X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hadriel Kaplan wrote: > I think we can ignore and avoid any debate about what ALTERNATE_SERVER may be used for if, as Spencer suggested and I thought as we talked about on the last call, we only discuss its anycast-specific use for UDP. The Alt-server response may also be used for TCP, for other reasons, but we would discourage Anycasting-use of TCP in particular in the RFC. > > With regards to using it for anycast, I know we debated it on the call, but I don't know why a simple UDP query-response without extraneous authentication isn't sufficient. Yes, the server can be spoofed by a malicious attacker, such that the client goes somewhere it shouldn't. Seems to me we have that with DNS too. Oh well. It's up to the client if it wants to accept it or not. > > We can always define a DNSSEC-style mechanism for TURN in the future; for example the server responds with some signature over the Alt-server address, so it can keep the signature statically without recomputing it every query, and the client can verify the signature by pulling a cert through TURN or HTTP from somewhere, etc., etc. We don't need to do that for this TURN draft though, imho. > > Would that be acceptable? perfectly for me. -jiri > > -hadriel > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 16 15:16:41 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77E0A3A6D43; Wed, 16 Apr 2008 15:16:41 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1892A28C10F for ; Wed, 16 Apr 2008 15:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86mdRm7T73Ma for ; Wed, 16 Apr 2008 15:16:40 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 4FD483A6CB8 for ; Wed, 16 Apr 2008 15:16:40 -0700 (PDT) Received: from boris-lab3.nc.tekelec.com (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 677CE1810C55; Thu, 17 Apr 2008 00:17:16 +0200 (CEST) Message-ID: <48067B2B.9060306@iptel.org> Date: Thu, 17 Apr 2008 00:18:19 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Spencer Dawkins References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <48051D64.30405@iptel.org><20080415220439.BC5205081A@romeo.rtfm.com> <4805A0F2.20605@iptel.org> <02f401c89fcd$c7a7bcb0$ad600240@china.huawei.com> In-Reply-To: <02f401c89fcd$c7a7bcb0$ad600240@china.huawei.com> Cc: Behave WG Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Spencer Dawkins wrote: > I THINK I understand what's being said in this thread. > > Just to up-level one notch, is there any reason that we have to mention TCP > anycast at all in this specification? I don't think so. -jiri > > Thanks, > > Spencer > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 17 10:48:37 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E67AF28C587; Thu, 17 Apr 2008 10:48:37 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5293A6CB9 for ; Thu, 17 Apr 2008 00:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOJu-wMyhImt for ; Thu, 17 Apr 2008 00:23:25 -0700 (PDT) Received: from paixhost.pch.net (unknown [204.61.210.70]) by core3.amsl.com (Postfix) with ESMTP id B4F9D3A6BBB for ; Thu, 17 Apr 2008 00:23:25 -0700 (PDT) Received: from paixhost.pch.net (paixhost.pch.net [204.61.210.70]) by paixhost.pch.net (8.13.8/8.13.8) with ESMTP id m3H7MqwQ021466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Apr 2008 00:22:52 -0700 (PDT) Date: Thu, 17 Apr 2008 00:22:52 -0700 (PDT) From: Bill Woodcock To: Eric Rescorla In-Reply-To: <20080416153852.334D25081A@romeo.rtfm.com> Message-ID: References: <0736FE4C-5E4B-4AB6-BF06-6E9F8239E5DF@magma.ca> <20080403143033.7006250854@romeo.rtfm.com> <20080403162320.E34475081A@romeo.rtfm.com> <48051D64.30405@iptel.org> <20080415220439.BC5205081A@romeo.rtfm.com> <4805A0F2.20605@iptel.org> <20080416142531.03216222473@kilo.rtfm.com> <48061A7D.3030003@iptel.org> <20080416153852.334D25081A@romeo.rtfm.com> MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (paixhost.pch.net [204.61.210.70]); Thu, 17 Apr 2008 00:22:53 -0700 (PDT) X-Mailman-Approved-At: Thu, 17 Apr 2008 10:48:35 -0700 Cc: Behave WG , David R Oran , Ward , David@core3.amsl.com, Mark Townsley , Philip Matthews Subject: Re: [BEHAVE] ALTERNATE-SERVER and anycast X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Wed, 16 Apr 2008, Eric Rescorla wrote: > There is already existing hardware that breaks the invariants that > anycast TCP relies on. Moreover, there are known cases where its > useful to deploy such techniques. The fact that those techniques are > not currently in wide use does not mean that it's a good idea to > design systems that would preclude their use in the future. Eric, could you catch me up on what it is that you guys are arguing about? It may not be obvious, from a developer's perspective, how widely-used anycast is, and has been, since it's transparent to code and middle-of-the-network configuration. Anything that breaks anycast tends to be ejected from the network very quickly, because any users behind it dislike not having, for instance, working root nameservers, or software downloads. So it's not an accident that things that don't work in the real world don't exist much in the real world, it's natural selection. -Bill _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 17 21:02:27 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5AF23A6856; Thu, 17 Apr 2008 21:02:27 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525173A6833 for ; Thu, 17 Apr 2008 21:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eImgeC0i4QKc for ; Thu, 17 Apr 2008 21:02:26 -0700 (PDT) Received: from where.matthew.at (unknown [IPv6:2001:5a8:4:39d1:201:3ff:fed1:d4f5]) by core3.amsl.com (Postfix) with ESMTP id 0BAA23A694A for ; Thu, 17 Apr 2008 21:02:25 -0700 (PDT) Received: from [10.10.155.2] (matthew-desk.braemoor.net [10.10.155.2] (may be forged)) by where.matthew.at (8.11.3/8.11.3) with ESMTP id m3I42OL08516; Thu, 17 Apr 2008 21:02:24 -0700 (PDT) (envelope-from matthew@matthew.at) Message-ID: <48081D50.7010508@matthew.at> Date: Thu, 17 Apr 2008 21:02:24 -0700 From: Matthew Kaufman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: behave@ietf.org Cc: philip_matthews@magma.ca Subject: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: matthew@matthew.at List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org We would like to propose using 0x8030 for "User Agent", with the value as a UTF-8 string which identifies a particular client application. This would be to support logging at the TURN server, and to allow enterprise TURN boxes to allow/block usage by checking this string. (Note that it may easily be forged, but in an enterprise environment applications which forge the User Agent can be banned as a matter of policy, employees terminated for using them, etc.) Comments? Matthew Kaufman _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 18 12:03:13 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E751F28C306; Fri, 18 Apr 2008 12:03:12 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2482328C268 for ; Fri, 18 Apr 2008 12:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuAxm52NNMWI for ; Fri, 18 Apr 2008 12:03:06 -0700 (PDT) Received: from mail-09.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 660FE28C306 for ; Fri, 18 Apr 2008 12:01:04 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Jmvpa-0002Z2-0m; Fri, 18 Apr 2008 15:01:06 -0400 Message-Id: <1E22EB7A-8B33-406C-89D2-ECA42C61C96A@magma.ca> From: Philip Matthews To: matthew@matthew.at In-Reply-To: <48081D50.7010508@matthew.at> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 18 Apr 2008 15:01:04 -0400 References: <48081D50.7010508@matthew.at> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: Behave WG Subject: Re: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org What is the purpose of this attribute? Is it to identify exactly which client has asked for the allocation? What about using the USERNAME attribute for this purpose? That is, require every client to have a unique USERNAME? If every client had a unique username and password, then I think this would give you what you want, and would not be forge-able either. - Philip On Fri, 18-Apr-08, at 00:02 , Matthew Kaufman wrote: > We would like to propose using 0x8030 for "User Agent", with the > value as a UTF-8 string which identifies a particular client > application. This would be to support logging at the TURN server, > and to allow enterprise TURN boxes to allow/block usage by checking > this string. (Note that it may easily be forged, but in an > enterprise environment applications which forge the User Agent can > be banned as a matter of policy, employees terminated for using > them, etc.) > > Comments? > > Matthew Kaufman > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 18 19:56:36 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC6A33A6AB4; Fri, 18 Apr 2008 19:56:36 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B163A68FB for ; Fri, 18 Apr 2008 19:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 894Q6B8yVBT0 for ; Fri, 18 Apr 2008 19:56:35 -0700 (PDT) Received: from where.matthew.at (unknown [IPv6:2001:5a8:4:39d1:201:3ff:fed1:d4f5]) by core3.amsl.com (Postfix) with ESMTP id 809BF3A6A81 for ; Fri, 18 Apr 2008 19:56:04 -0700 (PDT) Received: from [10.10.155.2] (matthew-desk.braemoor.net [10.10.155.2] (may be forged)) by where.matthew.at (8.11.3/8.11.3) with ESMTP id m3J2u2L23801; Fri, 18 Apr 2008 19:56:02 -0700 (PDT) (envelope-from matthew@matthew.at) Message-ID: <48095F42.8070804@matthew.at> Date: Fri, 18 Apr 2008 19:56:02 -0700 From: Matthew Kaufman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Philip Matthews References: <48081D50.7010508@matthew.at> <1E22EB7A-8B33-406C-89D2-ECA42C61C96A@magma.ca> In-Reply-To: <1E22EB7A-8B33-406C-89D2-ECA42C61C96A@magma.ca> Cc: Behave WG Subject: Re: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: matthew@matthew.at List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org User Agent is (like the same field in an HTTP header) independent of the Username and describes the client application (rather than the user or particular instance of that application). For example, I might have a Username of "matthew" but a User Agent of "Acme Softphone 1.0" for one client application I use, and a Username of "matthew" and a different User Agent of "Newco Messenger" for a different client application. This allows for logging of which client applications are using a particular proxy, simplifies debugging if particular client applications have issues not experienced by other client applications, and in closed ecosystems (e.g., enterprise DMZ-based proxies) might be used to allow certain approved client applications. By the way, I am now able to say that the software we are developing that we know will be widely distributed is in fact the next version of the Adobe Flash Player, and we intend to use TURN to allow our new UDP-based network protocol to work in enterprise environments that have UDP blocked but want to enable applications based on the new networking capabilities we are adding. We would be happiest if the subset of TURN we ship to everyone for this purpose ends up matching what is in the final specification of the protocol. Matthew Kaufman Philip Matthews wrote: > What is the purpose of this attribute? Is it to identify exactly which > client has asked for the allocation? > > What about using the USERNAME attribute for this purpose? That is, > require every client to have a unique USERNAME? If every client had a > unique username and password, then I think this would give you what > you want, and would not be forge-able either. > > - Philip > > > On Fri, 18-Apr-08, at 00:02 , Matthew Kaufman wrote: >> We would like to propose using 0x8030 for "User Agent", with the >> value as a UTF-8 string which identifies a particular client >> application. This would be to support logging at the TURN server, and >> to allow enterprise TURN boxes to allow/block usage by checking this >> string. (Note that it may easily be forged, but in an enterprise >> environment applications which forge the User Agent can be banned as >> a matter of policy, employees terminated for using them, etc.) >> >> Comments? >> >> Matthew Kaufman >> >> > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 21 07:09:22 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CF673A6F54; Mon, 21 Apr 2008 07:09:22 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6D53A6D8D for ; Mon, 21 Apr 2008 07:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqbZzC8iGWrS for ; Mon, 21 Apr 2008 07:09:19 -0700 (PDT) Received: from mail-07.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id C22C73A6F60 for ; Mon, 21 Apr 2008 07:07:04 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Jnwfi-0001cx-0v; Mon, 21 Apr 2008 10:07:06 -0400 Message-Id: From: Philip Matthews To: matthew@matthew.at In-Reply-To: <48095F42.8070804@matthew.at> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 21 Apr 2008 10:07:14 -0400 References: <48081D50.7010508@matthew.at> <1E22EB7A-8B33-406C-89D2-ECA42C61C96A@magma.ca> <48095F42.8070804@matthew.at> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: Behave WG Subject: Re: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org From a narrow technical perspective, I can see how your proposed field differs from Username. However, is it not likely that Adobe will set up its own set of TURN servers to support its Flash Player which will differ from the TURN servers set up by Acme for their "Acme Softphone 1.0"? So in practice is there going to be a difference? Note that I could see a difference if Adobe starts shipping multiple different client types and you want to distinguish between them. However, I don't get the sense that this is what you want to do (but perhaps I am wrong). Anyone else have any comments on Matthew's proposal? - Philip BTW, I would be tempted to rename the attribute to "Client", given that the term "User Agent" doesn't exist in TURN. On Fri, 18-Apr-08, at 22:56 , Matthew Kaufman wrote: > User Agent is (like the same field in an HTTP header) independent of > the Username and describes the client application (rather than the > user or particular instance of that application). For example, I > might have a Username of "matthew" but a User Agent of "Acme > Softphone 1.0" for one client application I use, and a Username of > "matthew" and a different User Agent of "Newco Messenger" for a > different client application. > > This allows for logging of which client applications are using a > particular proxy, simplifies debugging if particular client > applications have issues not experienced by other client > applications, and in closed ecosystems (e.g., enterprise DMZ-based > proxies) might be used to allow certain approved client applications. > > By the way, I am now able to say that the software we are developing > that we know will be widely distributed is in fact the next version > of the Adobe Flash Player, and we intend to use TURN to allow our > new UDP-based network protocol to work in enterprise environments > that have UDP blocked but want to enable applications based on the > new networking capabilities we are adding. We would be happiest if > the subset of TURN we ship to everyone for this purpose ends up > matching what is in the final specification of the protocol. > > Matthew Kaufman > > Philip Matthews wrote: >> What is the purpose of this attribute? Is it to identify exactly >> which client has asked for the allocation? >> >> What about using the USERNAME attribute for this purpose? That is, >> require every client to have a unique USERNAME? If every client had >> a unique username and password, then I think this would give you >> what you want, and would not be forge-able either. >> >> - Philip >> >> >> On Fri, 18-Apr-08, at 00:02 , Matthew Kaufman wrote: >>> We would like to propose using 0x8030 for "User Agent", with the >>> value as a UTF-8 string which identifies a particular client >>> application. This would be to support logging at the TURN server, >>> and to allow enterprise TURN boxes to allow/block usage by >>> checking this string. (Note that it may easily be forged, but in >>> an enterprise environment applications which forge the User Agent >>> can be banned as a matter of policy, employees terminated for >>> using them, etc.) >>> >>> Comments? >>> >>> Matthew Kaufman >>> >>> >> > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 21 07:25:27 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE18C28C1C7; Mon, 21 Apr 2008 07:25:27 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F11F28C23A for ; Mon, 21 Apr 2008 07:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WorOxY9h9eoA for ; Mon, 21 Apr 2008 07:25:22 -0700 (PDT) Received: from where.matthew.at (unknown [IPv6:2001:5a8:4:39d1:201:3ff:fed1:d4f5]) by core3.amsl.com (Postfix) with ESMTP id 6ACB928C12A for ; Mon, 21 Apr 2008 07:25:21 -0700 (PDT) Received: from [10.10.155.2] (matthew-desk.braemoor.net [10.10.155.2] (may be forged)) by where.matthew.at (8.11.3/8.11.3) with ESMTP id m3LEP1L68971; Mon, 21 Apr 2008 07:25:01 -0700 (PDT) (envelope-from matthew@matthew.at) Message-ID: <480CA3BD.4010605@matthew.at> Date: Mon, 21 Apr 2008 07:25:01 -0700 From: Matthew Kaufman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Philip Matthews References: <48081D50.7010508@matthew.at> <1E22EB7A-8B33-406C-89D2-ECA42C61C96A@magma.ca> <48095F42.8070804@matthew.at> In-Reply-To: Cc: Behave WG Subject: Re: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: matthew@matthew.at List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Philip Matthews wrote: > From a narrow technical perspective, I can see how your proposed field > differs from Username. However, is it not likely that Adobe will set > up its own set of TURN servers to support its Flash Player which will > differ from the TURN servers set up by Acme for their "Acme Softphone > 1.0"? So in practice is there going to be a difference? > This is a completely different use case of a TURN server, as I've mentioned before. The "Internet" use case, and the one I think everyone thinks of when they think of STUN/TURN is that a telephony service provider would deploy a TURN service on the Internet for use by their clients. They would want to restrict the use of their TURN proxies to their paying customers, and thus want strong username/password authentication. It is also unlikely, as a result, that one service provider's software or firmware would be using the TURN servers of another service provider, until "white-label" service providers become more common. Such providers might in fact want User Agent parameter in order to more clearly differentiate between which software or hardware is using their service. The "enterprise" use case (the one we are targeting) is that an enterprise would deploy one or more TURN servers in their DMZ in order to proxy certain UDP-using applications to the outside of their firewall in a controlled fashion. (This is just like the old days of web proxying, where enterprises weren't comfortable with opening up port 80 directly and didn't have transparent proxy features available from their firewall vendors.) (This is also where my earlier query about locating such an enterprise TURN proxy via DHCP comes from) In the enterprise case, Adobe doesn't set up its own set of TURN servers to support Flash Player... rather, Company XYZ sets up TURN servers to support applications that need to get through the firewall, and allows their employees to use Flash Player (but might not allow them to use some other UDP-using application that also supports TURN, as a matter of policy). Now, it might be the case that an enterprise also uses the Username field along with their LDAP servers to individually authenticate certain employees who are allowed to use the TURN server... but this is different than wanting to log which applications are using the TURN server, or allow/deny based on which application it is. Again, in an enterprise environment, an application could claim to be something it isn't, but employees can get fired for downloading and running such a thing. > Note that I could see a difference if Adobe starts shipping multiple > different client types and you want to distinguish between them. > However, I don't get the sense that this is what you want to do (but > perhaps I am wrong). > No. While we will likely use different variations on the User Agent string for other applications we ship that use our new UDP-based network protocol and which will need a proxy mechanism, it isn't because we will be setting up a globally-accessible service that needs to know... it would just be so that enterprise IT departments can meet their logging requirements. Please remember that we're talking about large organizations who need to do things like get their proxy services signed off by the people doing their Sarbanes-Oxley compliance audits, and that is where the requirement that applications using the proxy be identified for logging purposes comes from. > > BTW, I would be tempted to rename the attribute to "Client", given > that the term "User Agent" doesn't exist in TURN. I think that "Client" is somewhat more ambiguous, but I'm not attached to the name, just making sure we have a place we can send such a value. Matthew Kaufman _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 21 10:16:39 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76A63A6B58; Mon, 21 Apr 2008 10:16:39 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74A853A6B86 for ; Mon, 21 Apr 2008 10:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58McTVwdI+eB for ; Mon, 21 Apr 2008 10:16:37 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id EAB223A6B58 for ; Mon, 21 Apr 2008 10:16:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,690,1199692800"; d="scan'208";a="11469673" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 21 Apr 2008 10:16:43 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3LHGhoK011537; Mon, 21 Apr 2008 10:16:43 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m3LHGgk9023031; Mon, 21 Apr 2008 17:16:42 GMT From: "Dan Wing" To: "'Philip Matthews'" , References: <48081D50.7010508@matthew.at><1E22EB7A-8B33-406C-89D2-ECA42C61C96A@magma.ca><48095F42.8070804@matthew.at> Date: Mon, 21 Apr 2008 10:16:40 -0700 Message-ID: <02c301c8a3d3$78589f80$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AcijuVMwh+e/hdfeRKqLUcqum52CvwAGWGAA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2091; t=1208798203; x=1209662203; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20STUN/TURN=20=22User=20Agent= 22 |Sender:=20; bh=A9R8A0jPlFvKI9WrKzknQ01iBEWd6YhAxgOhFi/8Wow=; b=MH23sY0ss4SRJfzXIAhDr+x5Lsrpbjs7nG2mLQqQoiKN324dNkDxpCamhc BgkGSjIfi87WJhtl5dblihsjnm5XUABPEgAJRn9ER+0xicapmextg0Vw8P9d BFDaUCTV6Z; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Behave WG' Subject: Re: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Philip Matthews > Sent: Monday, April 21, 2008 7:07 AM > To: matthew@matthew.at > Cc: Behave WG > Subject: Re: [BEHAVE] STUN/TURN "User Agent" > > From a narrow technical perspective, I can see how your proposed > field differs from Username. However, is it not likely that > Adobe will > set up its own set of TURN servers to support its Flash Player which > will differ from the TURN servers set up by Acme for their "Acme > Softphone 1.0"? So in practice is there going to be a difference? > > Note that I could see a difference if Adobe starts shipping multiple > different client types and you want to distinguish between them. > However, I don't get the sense that this is what you want to do (but > perhaps I am wrong). > > Anyone else have any comments on Matthew's proposal? > > - Philip > > BTW, I would be tempted to rename the attribute to "Client", given > that the term "User Agent" doesn't exist in TURN. I note that rfc3489bis has a free-form text field called SERVER which serves a purpose very similar to what Matthew wants for the client. reads: 15.10. SERVER The server attribute contains a textual description of the software being used by the server, including manufacturer and version number. The attribute has no impact on operation of the protocol, and serves only as a tool for diagnostic and debugging purposes. The value of SERVER is variable length. It MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 763 bytes). As an individual, I find it reasonable to have a CLIENT attribute with text that is similar to rfc3489bis's SERVER attribute. I would even say such an attribute should have been in the base specification (rfc3489bis) rather than just in TURN, but we are too late for that (rfc3489bis is in IESG review). -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 21 11:08:54 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C698C3A6D1C; Mon, 21 Apr 2008 11:08:54 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16CAA3A6D1C for ; Mon, 21 Apr 2008 11:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zasHy6hcbt8e for ; Mon, 21 Apr 2008 11:08:53 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id C40E93A6D47 for ; Mon, 21 Apr 2008 11:08:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,690,1199682000"; d="scan'208";a="112244118" Received: from unknown (HELO delia.research.avayalabs.com) ([135.10.40.26]) by nj300815-nj-outbound.avaya.com with ESMTP; 21 Apr 2008 14:08:58 -0400 Received: from fliu1dell (fliu1-dell.woods.avayalabs.com [135.10.42.52]) by delia.research.avayalabs.com (8.14.2+Sun/8.14.2) with ESMTP id m3LI8tZv016471; Mon, 21 Apr 2008 14:08:55 -0400 (EDT) From: "Feng Liu" To: , "'Philip Matthews'" References: <48081D50.7010508@matthew.at><1E22EB7A-8B33-406C-89D2-ECA42C61C96A@magma.ca><48095F42.8070804@matthew.at> <480CA3BD.4010605@matthew.at> Date: Mon, 21 Apr 2008 14:08:55 -0400 Organization: Avaya Labs Research, Avaya Inc. Message-ID: <563A459284CB4D8BBC577EAED0A1F0D6@woods.avayalabs.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <480CA3BD.4010605@matthew.at> x-mimeole: Produced By Microsoft MimeOLE V6.00.3790.4133 thread-index: Aciju5CV50SGU+TIQc6LgCOzBS5gTgACIHEg Cc: 'Behave WG' Subject: Re: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi, I am not a TURN expert, but have a few comments regarding this issue. 1) If the purpose of User Agent is for logging purpose, can you use the IP/port to identify the application? Just like the web proxy or reverse proxy for web applications, the application is identified by the URL. This is because, as Matthew pointed out, the User Agent information may or may not be correct, and using this for logging or identifying different applications thus may not be a reliable solution. 2) Is it possible/meaningful to have an extension mechanism that allows different vendors to specify their own extensions such as User Agent? Then vendors may have the ability to develop their own TURN solutions. This is a common practice in web services and XML world. Just my 2 cents, Feng -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Matthew Kaufman Sent: Monday, April 21, 2008 10:25 AM To: Philip Matthews Cc: Behave WG Subject: Re: [BEHAVE] STUN/TURN "User Agent" Philip Matthews wrote: > From a narrow technical perspective, I can see how your proposed field > differs from Username. However, is it not likely that Adobe will set > up its own set of TURN servers to support its Flash Player which will > differ from the TURN servers set up by Acme for their "Acme Softphone > 1.0"? So in practice is there going to be a difference? > This is a completely different use case of a TURN server, as I've mentioned before. The "Internet" use case, and the one I think everyone thinks of when they think of STUN/TURN is that a telephony service provider would deploy a TURN service on the Internet for use by their clients. They would want to restrict the use of their TURN proxies to their paying customers, and thus want strong username/password authentication. It is also unlikely, as a result, that one service provider's software or firmware would be using the TURN servers of another service provider, until "white-label" service providers become more common. Such providers might in fact want User Agent parameter in order to more clearly differentiate between which software or hardware is using their service. The "enterprise" use case (the one we are targeting) is that an enterprise would deploy one or more TURN servers in their DMZ in order to proxy certain UDP-using applications to the outside of their firewall in a controlled fashion. (This is just like the old days of web proxying, where enterprises weren't comfortable with opening up port 80 directly and didn't have transparent proxy features available from their firewall vendors.) (This is also where my earlier query about locating such an enterprise TURN proxy via DHCP comes from) In the enterprise case, Adobe doesn't set up its own set of TURN servers to support Flash Player... rather, Company XYZ sets up TURN servers to support applications that need to get through the firewall, and allows their employees to use Flash Player (but might not allow them to use some other UDP-using application that also supports TURN, as a matter of policy). Now, it might be the case that an enterprise also uses the Username field along with their LDAP servers to individually authenticate certain employees who are allowed to use the TURN server... but this is different than wanting to log which applications are using the TURN server, or allow/deny based on which application it is. Again, in an enterprise environment, an application could claim to be something it isn't, but employees can get fired for downloading and running such a thing. > Note that I could see a difference if Adobe starts shipping multiple > different client types and you want to distinguish between them. > However, I don't get the sense that this is what you want to do (but > perhaps I am wrong). > No. While we will likely use different variations on the User Agent string for other applications we ship that use our new UDP-based network protocol and which will need a proxy mechanism, it isn't because we will be setting up a globally-accessible service that needs to know... it would just be so that enterprise IT departments can meet their logging requirements. Please remember that we're talking about large organizations who need to do things like get their proxy services signed off by the people doing their Sarbanes-Oxley compliance audits, and that is where the requirement that applications using the proxy be identified for logging purposes comes from. > > BTW, I would be tempted to rename the attribute to "Client", given > that the term "User Agent" doesn't exist in TURN. I think that "Client" is somewhat more ambiguous, but I'm not attached to the name, just making sure we have a place we can send such a value. Matthew Kaufman _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 21 12:41:26 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23EA728C10D; Mon, 21 Apr 2008 12:41:26 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A57328C10D for ; Mon, 21 Apr 2008 12:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nRjxjoml5MD for ; Mon, 21 Apr 2008 12:41:20 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 9C85B3A6F53 for ; Mon, 21 Apr 2008 12:41:20 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2008 12:41:27 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3LJfR5K013917; Mon, 21 Apr 2008 12:41:27 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m3LJfQvE018104; Mon, 21 Apr 2008 19:41:26 GMT From: "Dan Wing" To: "'Feng Liu'" , , "'Philip Matthews'" References: <48081D50.7010508@matthew.at><1E22EB7A-8B33-406C-89D2-ECA42C61C96A@magma.ca><48095F42.8070804@matthew.at><480CA3BD.4010605@matthew.at> <563A459284CB4D8BBC577EAED0A1F0D6@woods.avayalabs.com> Date: Mon, 21 Apr 2008 12:41:26 -0700 Message-ID: <042301c8a3e7$b0d808a0$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <563A459284CB4D8BBC577EAED0A1F0D6@woods.avayalabs.com> Thread-Index: Aciju5CV50SGU+TIQc6LgCOzBS5gTgACIHEgAAjJdhA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6425; t=1208806887; x=1209670887; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20STUN/TURN=20=22User=20Agent= 22 |Sender:=20; bh=mtK7ya4fe1eNrfo4LZsQdbgMPYnTi64Y8zhvjJohGJk=; b=PyP+S8nSPbtxmhnJtbt0ZuA5i082vRFp82yYL9kHxXuEiMFC1pUkmyY9I2 OJZPRneqlnmCezhPyRxRuC1d2I5PjfZNrs9wR6l8Do4cvlz/ad8TP65S6RnL vXFzTqdzKGHvNjFclK83HPgURmjJp1k//8Q9qDM/JPNXtB/pKDfnE=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'Behave WG' Subject: Re: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Feng Liu > Sent: Monday, April 21, 2008 11:09 AM > To: matthew@matthew.at; 'Philip Matthews' > Cc: 'Behave WG' > Subject: Re: [BEHAVE] STUN/TURN "User Agent" > > Hi, > > I am not a TURN expert, but have a few comments regarding this issue. > > 1) If the purpose of User Agent is for logging purpose, can > you use the > IP/port to identify the application? Just like the web proxy > or reverse > proxy for web applications, the application is identified by > the URL. This > is because, as Matthew pointed out, the User Agent > information may or may > not be correct, and using this for logging or identifying different > applications thus may not be a reliable solution. A NAT can (and often does) change the port, so even if you managed to always get a certain application to use a fixed port on the host, the TURN server would see different ports. This can happen, for example, if two PCs are behind a NAT and use the same source port -- the NAT cannot give both PCs the same source port. > 2) Is it possible/meaningful to have an extension mechanism > that allows > different vendors to specify their own extensions such as > User Agent? Then > vendors may have the ability to develop their own TURN > solutions. This is a > common practice in web services and XML world. RFC3489bis (also known as 'STUNbis') does have an extension mechanism to add new attributes, see . TURN uses the STUN protocol, so TURN can be extended using vendor-defined STUN attributes. -d > Just my 2 cents, > > Feng > > > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of > Matthew Kaufman > Sent: Monday, April 21, 2008 10:25 AM > To: Philip Matthews > Cc: Behave WG > Subject: Re: [BEHAVE] STUN/TURN "User Agent" > > Philip Matthews wrote: > > From a narrow technical perspective, I can see how your > proposed field > > differs from Username. However, is it not likely that Adobe > will set > > up its own set of TURN servers to support its Flash Player > which will > > differ from the TURN servers set up by Acme for their "Acme > Softphone > > 1.0"? So in practice is there going to be a difference? > > > This is a completely different use case of a TURN server, as I've > mentioned before. The "Internet" use case, and the one I > think everyone > thinks of when they think of STUN/TURN is that a telephony service > provider would deploy a TURN service on the Internet for use by their > clients. They would want to restrict the use of their TURN proxies to > their paying customers, and thus want strong username/password > authentication. It is also unlikely, as a result, that one service > provider's software or firmware would be using the TURN servers of > another service provider, until "white-label" service > providers become > more common. Such providers might in fact want User Agent > parameter in > order to more clearly differentiate between which software or > hardware > is using their service. > > The "enterprise" use case (the one we are targeting) is that an > enterprise would deploy one or more TURN servers in their DMZ > in order > to proxy certain UDP-using applications to the outside of > their firewall > in a controlled fashion. (This is just like the old days of web > proxying, where enterprises weren't comfortable with opening > up port 80 > directly and didn't have transparent proxy features available > from their > firewall vendors.) (This is also where my earlier query about > locating > such an enterprise TURN proxy via DHCP comes from) > > In the enterprise case, Adobe doesn't set up its own set of > TURN servers > to support Flash Player... rather, Company XYZ sets up TURN > servers to > support applications that need to get through the firewall, > and allows > their employees to use Flash Player (but might not allow them to use > some other UDP-using application that also supports TURN, as > a matter of > policy). Now, it might be the case that an enterprise also uses the > Username field along with their LDAP servers to individually > authenticate certain employees who are allowed to use the > TURN server... > but this is different than wanting to log which applications > are using > the TURN server, or allow/deny based on which application it > is. Again, > in an enterprise environment, an application could claim to > be something > it isn't, but employees can get fired for downloading and > running such a > thing. > > > Note that I could see a difference if Adobe starts shipping > multiple > > different client types and you want to distinguish between them. > > However, I don't get the sense that this is what you want > to do (but > > perhaps I am wrong). > > > No. While we will likely use different variations on the User Agent > string for other applications we ship that use our new > UDP-based network > protocol and which will need a proxy mechanism, it isn't > because we will > be setting up a globally-accessible service that needs to know... it > would just be so that enterprise IT departments can meet > their logging > requirements. > > Please remember that we're talking about large organizations > who need to > do things like get their proxy services signed off by the > people doing > their Sarbanes-Oxley compliance audits, and that is where the > requirement that applications using the proxy be identified > for logging > purposes comes from. > > > > BTW, I would be tempted to rename the attribute to "Client", given > > that the term "User Agent" doesn't exist in TURN. > I think that "Client" is somewhat more ambiguous, but I'm not > attached > to the name, just making sure we have a place we can send > such a value. > > Matthew Kaufman > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 21 13:19:45 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7583A6F47; Mon, 21 Apr 2008 13:19:45 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689A03A69E5 for ; Mon, 21 Apr 2008 13:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGSDT-Orgat4 for ; Mon, 21 Apr 2008 13:19:43 -0700 (PDT) Received: from where.matthew.at (unknown [IPv6:2001:5a8:4:39d1:201:3ff:fed1:d4f5]) by core3.amsl.com (Postfix) with ESMTP id CF8B93A68AF for ; Mon, 21 Apr 2008 13:19:42 -0700 (PDT) Received: from [10.10.155.2] (matthew-desk.braemoor.net [10.10.155.2] (may be forged)) by where.matthew.at (8.11.3/8.11.3) with ESMTP id m3LKJeL72813; Mon, 21 Apr 2008 13:19:40 -0700 (PDT) (envelope-from matthew@matthew.at) Message-ID: <480CF6DC.3040105@matthew.at> Date: Mon, 21 Apr 2008 13:19:40 -0700 From: Matthew Kaufman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Feng Liu References: <48081D50.7010508@matthew.at><1E22EB7A-8B33-406C-89D2-ECA42C61C96A@magma.ca><48095F42.8070804@matthew.at> <480CA3BD.4010605@matthew.at> <563A459284CB4D8BBC577EAED0A1F0D6@woods.avayalabs.com> In-Reply-To: <563A459284CB4D8BBC577EAED0A1F0D6@woods.avayalabs.com> Cc: 'Behave WG' , 'Philip Matthews' Subject: Re: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: matthew@matthew.at List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Feng Liu wrote: > Hi, > > I am not a TURN expert, but have a few comments regarding this issue. > > 1) If the purpose of User Agent is for logging purpose, can you use the > IP/port to identify the application? Just like the web proxy or reverse > proxy for web applications, the application is identified by the URL. This > is because, as Matthew pointed out, the User Agent information may or may > not be correct, and using this for logging or identifying different > applications thus may not be a reliable solution. > > The source IP address and port number does not identify the software or firmware that is initiating the TURN session. > 2) Is it possible/meaningful to have an extension mechanism that allows > different vendors to specify their own extensions such as User Agent? Then > vendors may have the ability to develop their own TURN solutions. This is a > common practice in web services and XML world. > > It exists, so that's an option if we can't get agreement around our proposal. Matthew Kaufman _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 21 13:23:24 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF24D3A6F18; Mon, 21 Apr 2008 13:23:24 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9022F3A6F18 for ; Mon, 21 Apr 2008 13:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTIi+HXluOhl for ; Mon, 21 Apr 2008 13:23:22 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by core3.amsl.com (Postfix) with ESMTP id 8FD9B3A6DBC for ; Mon, 21 Apr 2008 13:23:22 -0700 (PDT) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1Jo2Xr27WW-0005js; Mon, 21 Apr 2008 16:23:27 -0400 Message-ID: <039401c8a3ed$c1ec13b0$ad600240@china.huawei.com> From: "Spencer Dawkins" To: "Dan Wing" , "'Philip Matthews'" , References: <48081D50.7010508@matthew.at><1E22EB7A-8B33-406C-89D2-ECA42C61C96A@magma.ca><48095F42.8070804@matthew.at> <02c301c8a3d3$78589f80$c2f0200a@cisco.com> Date: Mon, 21 Apr 2008 15:24:46 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX18Z7BmHSYxlVAofn9n7lW8/iz6CgEcRqtU6KO6 aByWP1H9D6IzLBbh8+y0zwVNFqj6cCGA1/a3sPYt7beTJn+zHa fO3B0piAMBE3oTem0R3gD4bt6mCHWzyY2rMx8EIwuc= Cc: 'Behave WG' Subject: Re: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi, Dan/Philip/Matthew, >> From a narrow technical perspective, I can see how your proposed >> field differs from Username. However, is it not likely that >> Adobe will >> set up its own set of TURN servers to support its Flash Player which >> will differ from the TURN servers set up by Acme for their "Acme >> Softphone 1.0"? So in practice is there going to be a difference? >> >> Note that I could see a difference if Adobe starts shipping multiple >> different client types and you want to distinguish between them. >> However, I don't get the sense that this is what you want to do (but >> perhaps I am wrong). >> >> Anyone else have any comments on Matthew's proposal? >> >> - Philip >> >> BTW, I would be tempted to rename the attribute to "Client", given >> that the term "User Agent" doesn't exist in TURN. > > I note that rfc3489bis has a free-form text field called SERVER which > serves a > purpose very similar to what Matthew wants for the client. > > reads: > > 15.10. SERVER > > The server attribute contains a textual description of the software > being used by the server, including manufacturer and version number. > The attribute has no impact on operation of the protocol, and serves > only as a tool for diagnostic and debugging purposes. The value of > SERVER is variable length. It MUST be a UTF-8 [RFC3629] encoded > sequence of less than 128 characters (which can be as long as 763 > bytes). > > As an individual, I find it reasonable to have a CLIENT attribute with > text > that is similar to rfc3489bis's SERVER attribute. I would even say such > an > attribute should have been in the base specification (rfc3489bis) rather > than > just in TURN, but we are too late for that (rfc3489bis is in IESG review). OK, let's start with the process part, first. If "Someone" was to submit an IETF Last Call comment that says "there's a SERVER attribute that does what we want, but we also need a CLIENT attribute, with the same text and obvious substitutions" - in fact, it would probably look a lot like this: 15.whatever. CLIENT The client attribute contains a textual description of the software being used by the client, including manufacturer and version number. The attribute has no impact on operation of the protocol, and serves only as a tool for diagnostic and debugging purposes. The value of CLIENT is variable length. It MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 763 bytes). I'm not sure why the IESG would freak out. We've done worse, later in the process. Now, for the technical part. Please keep in mind that I'm not a genius of STUN/TURN, and don't have opinions about whether "User-Agent" or "CLIENT" are really going to be useful. When this proposed attribute was called "User-Agent", I expressed offline concerns based on the HTTP User-Agent experience, where everyone claimed to be Mozilla, whether they were Mozilla or not, for a very long time. If CLIENT is documented as "no impact on operation of the protocol", that could be "good enough" to decide this isn't a likely problem for STUN/TURN - SERVER is currently specified with the same language. If there are reasons for endpoints to lie, I would think both CLIENT and SERVER would be problematic (servers could change their behavior based on CLIENT values, but clients could certainly change their behavior based on SERVER values from previous exchanges - so I don't think having CLIENT is any worse than having SERVER, and we have SERVER now). Thanks, Spencer _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 21 16:14:00 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157043A6F86; Mon, 21 Apr 2008 16:14:00 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B0913A6F84 for ; Mon, 21 Apr 2008 16:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LddQ2AjEtV9P for ; Mon, 21 Apr 2008 16:13:57 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9714E3A6F77 for ; Mon, 21 Apr 2008 16:13:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,691,1199692800"; d="scan'208";a="22804440" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 21 Apr 2008 16:14:01 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3LNE2oW012080; Mon, 21 Apr 2008 16:14:02 -0700 Received: from [192.168.16.100] ([10.21.70.169]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m3LNE19W029952; Mon, 21 Apr 2008 23:14:01 GMT Message-Id: <9AD667CD-915D-482D-A998-04A6E0F1C81B@cisco.com> From: Cullen Jennings To: matthew@matthew.at In-Reply-To: <48081D50.7010508@matthew.at> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 21 Apr 2008 19:17:52 -0400 References: <48081D50.7010508@matthew.at> X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1011; t=1208819642; x=1209683642; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20STUN/TURN=20=22User=20Agent= 22 |Sender:=20; bh=Bdva+ZOYAi6GSXL1YJjiOqiNBb/Z1HgESBbPpGCsdPE=; b=JYFrJvanhbcF5M7NSkXBmekhjUy+Ypv0otuakia+5uTfjJ5xZRQ5EI47Pm wMCTuWYVpseNWUWcjY07nVdAuYnWcHlv7kOlahLuVX3MNGIKl4fvtDHPVfNl 9uyFxgo04a; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: behave@ietf.org, philip_matthews@magma.ca Subject: Re: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I think this is a good idea. I know there have been a bunch of times I have been trying to debug what is going on where this would have been really useful. I suspect adding it to 3489bis might be the best place to do it. Cullen On Apr 18, 2008, at 12:02 AM, Matthew Kaufman wrote: > We would like to propose using 0x8030 for "User Agent", with the > value as a UTF-8 string which identifies a particular client > application. This would be to support logging at the TURN server, > and to allow enterprise TURN boxes to allow/block usage by checking > this string. (Note that it may easily be forged, but in an > enterprise environment applications which forge the User Agent can > be banned as a matter of policy, employees terminated for using > them, etc.) > > Comments? > > Matthew Kaufman > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 21 22:41:28 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C7828C44B; Mon, 21 Apr 2008 22:41:28 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7609828C457 for ; Mon, 21 Apr 2008 22:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PP-ZjGS7uR-j for ; Mon, 21 Apr 2008 22:41:26 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 6CF503A67D7 for ; Mon, 21 Apr 2008 22:41:23 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3M5htgk027785 for ; Tue, 22 Apr 2008 00:43:56 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Apr 2008 08:41:23 +0300 Received: from esdhcp04148.research.nokia.com ([172.21.41.48]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Apr 2008 08:41:23 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia Devices R&D To: behave@ietf.org Date: Tue, 22 Apr 2008 08:42:26 +0300 User-Agent: KMail/1.9.9 References: <48081D50.7010508@matthew.at> <9AD667CD-915D-482D-A998-04A6E0F1C81B@cisco.com> In-Reply-To: <9AD667CD-915D-482D-A998-04A6E0F1C81B@cisco.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804220842.27058.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 22 Apr 2008 05:41:23.0426 (UTC) FILETIME=[7FCD8420:01C8A43B] X-Nokia-AV: Clean Subject: Re: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Tuesday 22 April 2008 02:17:52 ext Cullen Jennings, vous avez =E9crit=A0: > I think this is a good idea. I know there have been a bunch of times I > have been trying to debug what is going on where this would have been > really useful. I suspect adding it to 3489bis might be the best place > to do it. Yeah, it may help troubleshooting IOP problems, and collect statistics. -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 22 05:29:48 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE2643A6D48; Tue, 22 Apr 2008 05:29:48 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC7D93A6CF4 for ; Tue, 22 Apr 2008 05:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2d0ydiwaveNN for ; Tue, 22 Apr 2008 05:29:45 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 921B928C1EF for ; Tue, 22 Apr 2008 05:29:45 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 9465729E1486; Tue, 22 Apr 2008 08:29:21 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 8C2DE29E130C for ; Tue, 22 Apr 2008 08:29:21 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: behave@ietf.org Date: Tue, 22 Apr 2008 08:29:18 -0400 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804220829.18682.simon.perreault@viagenie.ca> Subject: [BEHAVE] Transaction lifetime X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org In [draft-ietf-behave-rfc3489bis-15], Section 7.3.1, there is the following text: If the request uses UDP transport and is a retransmission of a request for which the server has already generated a success response within the last 40 seconds, the server MUST retransmit the same success response. One way for a server to do this is to remember all transaction IDs received over UDP and their corresponding responses in the last 10 seconds. So, which one is it? 40 or 10 seconds? _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 22 07:48:19 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB38D3A6B22; Tue, 22 Apr 2008 07:48:19 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B23828C14F for ; Tue, 22 Apr 2008 07:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.776 X-Spam-Level: X-Spam-Status: No, score=-100.776 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPNcH99TUyv0 for ; Tue, 22 Apr 2008 07:48:16 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 49B503A696A for ; Tue, 22 Apr 2008 07:48:16 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id CE52ED9DC0F2; Tue, 22 Apr 2008 14:48:21 +0000 (UTC) Received: from [192.168.1.3] (c-67-161-24-129.hsd1.ca.comcast.net [67.161.24.129]) by server.implementers.org (Postfix) with ESMTP id 02F55D9D4248 for ; Tue, 22 Apr 2008 14:48:20 +0000 (UTC) Message-ID: <480DFAB4.2050207@acm.org> Date: Tue, 22 Apr 2008 07:48:20 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.12 (X11/20080420) MIME-Version: 1.0 To: Behave WG Subject: [BEHAVE] TURN and TURNS URI and resolution mechanism X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I just submitted an I-D that defines URIs and a resolution mechanism to find TURN servers: http://www.ietf.org/internet-drafts/draft-petithuguenin-behave-turn-uri-00.txt Comments appreciated. Thanks. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 22 12:45:27 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB113A6DF9; Tue, 22 Apr 2008 12:45:27 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 048263A684D for ; Tue, 22 Apr 2008 12:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAEaBxB6Bgoa for ; Tue, 22 Apr 2008 12:45:15 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 5ECE83A6DF9 for ; Tue, 22 Apr 2008 12:45:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,696,1199682000"; d="scan'208";a="6019725" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 Apr 2008 15:45:19 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3MJjJ2T019336; Tue, 22 Apr 2008 15:45:19 -0400 Received: from [192.168.1.73] (rtp-vpn2-433.cisco.com [10.82.241.177]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3MJjEe9001308; Tue, 22 Apr 2008 19:45:14 GMT Message-Id: <3B6A8287-122B-4D63-909D-C6377BB24AA4@cisco.com> From: Cullen Jennings To: Marc Petit-Huguenin In-Reply-To: <480DFAB4.2050207@acm.org> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 22 Apr 2008 15:49:10 -0400 References: <480DFAB4.2050207@acm.org> X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1020; t=1208893519; x=1209757519; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20and=20TURNS=20URI=20a nd=20resolution=20mechanism |Sender:=20 |To:=20Marc=20Petit-Huguenin=20; bh=OWqKR7EYDQKyNIl6eJb0GYbZ+0SZq+5xJ40zXliL1hc=; b=KpYTdPPvFvnCog+Pz+ysqx6LYxxCznIckx6J9zAg65udRr7k9SKlivKvSD jhOEyKyscPmv6/u8uM2Wp3neDOcTH2PHs3NP/y5kar1Owu9RIH/68L8wWTA/ E/YHaw1+Sy; Authentication-Results: rtp-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Behave WG Subject: Re: [BEHAVE] TURN and TURNS URI and resolution mechanism X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Most this draft makes sense to me and seems I like it. One thing that I don't understand, what's the need for S-NAPTR in the type of use case we need here. Why not just greatly simplify this and just have SRV (and of course A/AAAA implied by that)? Cullen On Apr 22, 2008, at 10:48 AM, Marc Petit-Huguenin wrote: > I just submitted an I-D that defines URIs and a resolution mechanism > to > find TURN servers: > > http://www.ietf.org/internet-drafts/draft-petithuguenin-behave-turn-uri-00.txt > > Comments appreciated. > > Thanks. > > -- > Marc Petit-Huguenin [ ] > Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] > Work: marc@8x8.com [ ] > [ ] > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 22 13:34:01 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778BC3A6E7A; Tue, 22 Apr 2008 13:34:01 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321DC3A6E96 for ; Tue, 22 Apr 2008 13:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dikKq9NaOZ74 for ; Tue, 22 Apr 2008 13:33:58 -0700 (PDT) Received: from mail-06.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id CBEC128C490 for ; Tue, 22 Apr 2008 13:32:26 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JoPAG-00023E-0I; Tue, 22 Apr 2008 16:32:32 -0400 Message-Id: <3A78C701-8D84-4981-834F-FF674AD0D43E@magma.ca> From: Philip Matthews To: matthew@matthew.at In-Reply-To: <02c301c8a3d3$78589f80$c2f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 22 Apr 2008 16:32:34 -0400 References: <48081D50.7010508@matthew.at><1E22EB7A-8B33-406C-89D2-ECA42C61C96A@magma.ca><48095F42.8070804@matthew.at> <02c301c8a3d3$78589f80$c2f0200a@cisco.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: Behave WG , Dan Wing Subject: Re: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Matthew: Dan's proposal (below) seems a good one to me. Will this meet your needs? If it does, then there seems to be enough support for this idea to include it in the base TURN spec. - Philip On Mon, 21-Apr-08, at 13:16 , Dan Wing wrote: > > >> > > I note that rfc3489bis has a free-form text field called SERVER > which serves a > purpose very similar to what Matthew wants for the client. > > > reads: > > 15.10. SERVER > > The server attribute contains a textual description of the software > being used by the server, including manufacturer and version number. > The attribute has no impact on operation of the protocol, and serves > only as a tool for diagnostic and debugging purposes. The value of > SERVER is variable length. It MUST be a UTF-8 [RFC3629] encoded > sequence of less than 128 characters (which can be as long as 763 > bytes). > > As an individual, I find it reasonable to have a CLIENT attribute > with text > that is similar to rfc3489bis's SERVER attribute. I would even say > such an > attribute should have been in the base specification (rfc3489bis) > rather than > just in TURN, but we are too late for that (rfc3489bis is in IESG > review). > > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 22 13:35:57 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55AF73A6969; Tue, 22 Apr 2008 13:35:57 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0364F3A6969 for ; Tue, 22 Apr 2008 13:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNtPhf1wcrEF for ; Tue, 22 Apr 2008 13:35:55 -0700 (PDT) Received: from where.matthew.at (unknown [IPv6:2001:5a8:4:39d1:201:3ff:fed1:d4f5]) by core3.amsl.com (Postfix) with ESMTP id E5D243A67B2 for ; Tue, 22 Apr 2008 13:35:50 -0700 (PDT) Received: from [10.10.155.2] (matthew-desk.braemoor.net [10.10.155.2] (may be forged)) by where.matthew.at (8.11.3/8.11.3) with ESMTP id m3MKZhL88964; Tue, 22 Apr 2008 13:35:43 -0700 (PDT) (envelope-from matthew@matthew.at) Message-ID: <480E4C1F.6090005@matthew.at> Date: Tue, 22 Apr 2008 13:35:43 -0700 From: Matthew Kaufman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Philip Matthews References: <48081D50.7010508@matthew.at><1E22EB7A-8B33-406C-89D2-ECA42C61C96A@magma.ca><48095F42.8070804@matthew.at> <02c301c8a3d3$78589f80$c2f0200a@cisco.com> <3A78C701-8D84-4981-834F-FF674AD0D43E@magma.ca> In-Reply-To: <3A78C701-8D84-4981-834F-FF674AD0D43E@magma.ca> Cc: Behave WG , Dan Wing Subject: Re: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: matthew@matthew.at List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Philip Matthews wrote: > Matthew: > > Dan's proposal (below) seems a good one to me. Will this meet your needs? > Yes. > If it does, then there seems to be enough support for this idea to > include it in the base TURN spec. > That would be good, and we'll use the code point that gets assigned that way, assuming the number is assigned before we ship. Matthew Kaufman _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 22 13:36:52 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4323A696F; Tue, 22 Apr 2008 13:36:52 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 699E93A6D6D for ; Tue, 22 Apr 2008 13:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1uHQoBG0I9y for ; Tue, 22 Apr 2008 13:36:50 -0700 (PDT) Received: from mail-07.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id A31CA3A696F for ; Tue, 22 Apr 2008 13:36:50 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JoPEQ-000653-1Q; Tue, 22 Apr 2008 16:36:50 -0400 From: Philip Matthews To: Spencer Dawkins In-Reply-To: <039401c8a3ed$c1ec13b0$ad600240@china.huawei.com> X-Priority: 3 References: <48081D50.7010508@matthew.at><1E22EB7A-8B33-406C-89D2-ECA42C61C96A@magma.ca><48095F42.8070804@matthew.at> <02c301c8a3d3$78589f80$c2f0200a@cisco.com> <039401c8a3ed$c1ec13b0$ad600240@china.huawei.com> Message-Id: <67E3B2AF-DC12-41B6-9D00-1D1E167EB4E1@magma.ca> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 22 Apr 2008 16:36:54 -0400 X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: 'Behave WG' , Dan Wing , matthew@matthew.at Subject: Re: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Mon, 21-Apr-08, at 16:24 , Spencer Dawkins wrote: >>> > > Now, for the technical part. Please keep in mind that I'm not a > genius of > STUN/TURN, and don't have opinions about whether "User-Agent" or > "CLIENT" > are really going to be useful. > > When this proposed attribute was called "User-Agent", I expressed > offline > concerns based on the HTTP User-Agent experience, where everyone > claimed to > be Mozilla, whether they were Mozilla or not, for a very long time. If > CLIENT is documented as "no impact on operation of the protocol", > that could > be "good enough" to decide this isn't a likely problem for STUN/TURN - > SERVER is currently specified with the same language. > > If there are reasons for endpoints to lie, I would think both CLIENT > and > SERVER would be problematic (servers could change their behavior > based on > CLIENT values, but clients could certainly change their behavior > based on > SERVER values from previous exchanges - so I don't think having > CLIENT is > any worse than having SERVER, and we have SERVER now). The proposal is to make this a free-form text field with no specified values. Moreover, I would add some text to say that its purpose is for logging and debugging. This will not completely prevent people determined to do this from using it to drive behavior, but I don't see how to do any better than this. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 22 13:50:03 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 943FD3A6D6D; Tue, 22 Apr 2008 13:50:03 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19DEC3A6E3A for ; Tue, 22 Apr 2008 13:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OChdNvh5dbvX for ; Tue, 22 Apr 2008 13:50:01 -0700 (PDT) Received: from mail-01.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 4BF5F3A6D39 for ; Tue, 22 Apr 2008 13:50:01 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JoPRG-0000GH-2y; Tue, 22 Apr 2008 16:50:07 -0400 Message-Id: <2F15E765-DFF3-4F31-A9BD-2701E42A5360@magma.ca> From: Philip Matthews To: Simon Perreault In-Reply-To: <200804220829.18682.simon.perreault@viagenie.ca> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 22 Apr 2008 16:50:08 -0400 References: <200804220829.18682.simon.perreault@viagenie.ca> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: Behave WG Subject: Re: [BEHAVE] Transaction lifetime X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I think the right answer is "40 seconds". In earlier versions of the draft, the last retransmission timer expired in slightly under 10 seconds from the start of the transaction. However, during IESG review, the retransmission timers were lengthened and by default now expire slightly before 40 seconds. - Philip On Tue, 22-Apr-08, at 08:29 , Simon Perreault wrote: > In [draft-ietf-behave-rfc3489bis-15], Section 7.3.1, there is the > following > text: > > If the request uses UDP transport and is a retransmission of a > request for which the server has already generated a success > response > within the last 40 seconds, the server MUST retransmit the same > success response. One way for a server to do this is to remember > all > transaction IDs received over UDP and their corresponding responses > in the last 10 seconds. > > So, which one is it? 40 or 10 seconds? > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 22 13:58:57 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2094828C24D; Tue, 22 Apr 2008 13:58:57 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ADA23A6AF5 for ; Tue, 22 Apr 2008 13:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P09DnJQb8z4D for ; Tue, 22 Apr 2008 13:58:55 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 43A9C3A6A5D for ; Tue, 22 Apr 2008 13:58:55 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 22 Apr 2008 13:59:01 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m3MKx1bu001940; Tue, 22 Apr 2008 13:59:01 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m3MKx0Li004554; Tue, 22 Apr 2008 20:59:01 GMT From: "Dan Wing" To: "'Philip Matthews'" , "'Spencer Dawkins'" References: <48081D50.7010508@matthew.at><1E22EB7A-8B33-406C-89D2-ECA42C61C96A@magma.ca><48095F42.8070804@matthew.at><02c301c8a3d3$78589f80$c2f0200a@cisco.com><039401c8a3ed$c1ec13b0$ad600240@china.huawei.com> <67E3B2AF-DC12-41B6-9D00-1D1E167EB4E1@magma.ca> Date: Tue, 22 Apr 2008 13:59:00 -0700 Message-ID: <004b01c8a4bb$b0ffe8a0$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <67E3B2AF-DC12-41B6-9D00-1D1E167EB4E1@magma.ca> thread-index: AcikuJ59zIpkzXGcQk6scwMdgNdh3wAArFYg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=759; t=1208897941; x=1209761941; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20STUN/TURN=20=22User=20Agent= 22 |Sender:=20; bh=0X2jQzxEiUa1AAggHliIkprpzQUNOcU844QeU5Pw0b8=; b=RXv6VNPgYhj8n8qreEpzSKqmxN2RWw7xYEGxUm80IAUhEHO0nlaCe17l7z 1g/dm8AzNoodD23Kh3JCyVBhB7mbJyXSHT9VTq/7tnDoxSd9ufmlWiZ2r+HS EkqJVoV9qV; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'Behave WG' , matthew@matthew.at Subject: Re: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org (as an individual,) > The proposal is to make this a free-form text field with no > specified values. Moreover, I would add some text to say that > its purpose is for logging and debugging. So you want this only in TURN, and not in the base STUN specification? > This will not completely prevent people determined to do this from > using it to drive behavior, but I don't see how to do any better > than this. Nothing will prevent this; if someone wanted to signal special behavior they could encode a tag into the Username attribute, as you described earlier. Or they could register a proprietary attribute and use that, or have their TURN client and server use non-IANA ports. I'm sure there are another dozen techniques. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 22 15:18:13 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2219C28C43D; Tue, 22 Apr 2008 15:18:13 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 449033A6F91 for ; Tue, 22 Apr 2008 15:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EEzoRLSPvBM for ; Tue, 22 Apr 2008 15:18:10 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 4A5F93A6FF2 for ; Tue, 22 Apr 2008 15:17:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,696,1199682000"; d="scan'208,217";a="113091048" Received: from unknown (HELO delia.research.avayalabs.com) ([135.10.40.26]) by nj300815-nj-outbound.avaya.com with ESMTP; 22 Apr 2008 18:17:25 -0400 Received: from fliu1dell (fliu1-dell.woods.avayalabs.com [135.10.42.52]) by delia.research.avayalabs.com (8.14.2+Sun/8.14.2) with ESMTP id m3MMHOBL020037 for ; Tue, 22 Apr 2008 18:17:25 -0400 (EDT) From: "Feng Liu" To: Date: Tue, 22 Apr 2008 18:17:24 -0400 Organization: Avaya Labs Research, Avaya Inc. Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.3790.4133 thread-index: AcikxqP227McVY/dTlWQS7SNWprVNA== Subject: [BEHAVE] Channel Number X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1954613659==" Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============1954613659== Content-Type: multipart/alternative; boundary="----=_NextPart_000_009C_01C8A4A5.1D982B10" This is a multi-part message in MIME format. ------=_NextPart_000_009C_01C8A4A5.1D982B10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear BEHAVE experts, I have two questions regarding Channel Number in TURN, and would like to get your advice. Assume I have two TURN clients, and each wants to bind a channel to its peer. When TURN clients choose Channel Numbers, it is likely that they pick the same Channel Number (e.g., both clients are from the same vendor and have the same initial value and number selection algorithm). My question is: what is the behavior of the server in this case? Will the server accept one binding request and reject the other? Or it accepts both as two channel bindings are independent of each other? If the server accepts one and rejects another, according to the spec, one client will get a "bad request" response. My second question is: how can the client know the rejection is because the number is taken, as the server can reject the request for different reasons? Thanks, Feng Feng Liu, Ph.D. | Research Scientist, Dialogue System Research Group | Avaya Labs Research | Avaya | 233 Mt. Airy Road| Rm. 2D36 | Basking Ridge, NJ 07920 | Voice/Fax: 908-696-5156 / 908-696-5401 | fliu1@avaya.com ------=_NextPart_000_009C_01C8A4A5.1D982B10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear BEHAVE experts,

 

I have two questions regarding Channel Number in = TURN, and would like to get your advice.

 

Assume I have two TURN clients, and each wants to = bind a channel to its peer. When TURN clients choose Channel Numbers, it is = likely that they pick the same Channel Number (e.g., both clients are from the = same vendor and have the same initial value and number selection algorithm). =

 

My question is: what is the behavior of the server in = this case? Will the server accept one binding request and reject the other? = Or it accepts both as two channel bindings are independent of each = other?

 

If the server accepts one and rejects another, = according to the spec, one client will get a "bad request" response. My = second question is: how can the client know the rejection is because the number = is taken, as the server can reject the request for different = reasons?

 

Thanks,

 

Feng

 

 

 

 

 

Feng Liu, Ph.D.  | Research Scientist, Dialogue System = Research Group | Avaya Labs Research  | = Avaya | = 233 Mt. Airy = Road| Rm. 2D36 | = Basking Ridge, NJ 07920 | Voice/Fax: 908-696-5156 / 908-696-5401 | fliu1@avaya.com

 

 

------=_NextPart_000_009C_01C8A4A5.1D982B10-- --===============1954613659== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave --===============1954613659==-- From behave-bounces@ietf.org Tue Apr 22 16:37:50 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8255328C1DE; Tue, 22 Apr 2008 16:37:50 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D263D28C1D5 for ; Tue, 22 Apr 2008 16:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGkviUp0QiQ0 for ; Tue, 22 Apr 2008 16:37:49 -0700 (PDT) Received: from syd-iport-1.cisco.com (syd-iport-1.cisco.com [64.104.193.196]) by core3.amsl.com (Postfix) with ESMTP id 8816A28C1DE for ; Tue, 22 Apr 2008 16:37:46 -0700 (PDT) Received: from syd-dkim-1.cisco.com ([64.104.193.116]) by syd-iport-1.cisco.com with ESMTP; 23 Apr 2008 09:37:47 +1000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by syd-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3MNbkmI019865; Wed, 23 Apr 2008 09:37:47 +1000 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m3MNbjq2014782; Tue, 22 Apr 2008 23:37:46 GMT From: "Dan Wing" To: "'Feng Liu'" , References: Date: Tue, 22 Apr 2008 16:37:45 -0700 Message-ID: <00ff01c8a4d1$de3fc360$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: thread-index: AcikxqP227McVY/dTlWQS7SNWprVNAACuQcA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1828; t=1208907467; x=1209771467; c=relaxed/simple; s=syddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20=20Channel=20Number |Sender:=20; bh=aotMuqB8PDD5YrArMEMPoSrvQEMANzJNv4/D7CxE26o=; b=NUIwRFldMsaO1alOFQzRHwmsom/Dd8OLOL6AHa42eLaSeDgMy4cCnrPNG8 bjZFV7XxtF9/GPYpmlThaAQH8DG+wlhQrC/57pNqRmZjpRlfjmQyONWXtryu fSdgy+RTWtmYCCXaUY84+PgMNWr5mGyGHJX6CJDzCzErfsrv/jphM=; Authentication-Results: syd-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/syddkim1002 verified; ); Subject: Re: [BEHAVE] Channel Number X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Feng Liu > Sent: Tuesday, April 22, 2008 3:17 PM > To: behave@ietf.org > Subject: [BEHAVE] Channel Number > > Dear BEHAVE experts, > > > > I have two questions regarding Channel Number in TURN, and > would like to get your advice. > > > > Assume I have two TURN clients, and each wants to bind a > channel to its peer. When TURN clients choose Channel > Numbers, it is likely that they pick the same Channel Number > (e.g., both clients are from the same vendor and have the > same initial value and number selection algorithm). > > > > My question is: what is the behavior of the server in this > case? Will the server accept one binding request and reject > the other? Or it accepts both as two channel bindings are > independent of each other? They are independent of each other because they are over different TURN clients (different source IP address+port). The channel number is not unique for the entire TURN server; rather, the channel number is unique for every TURN session with that TURN server. -d > > If the server accepts one and rejects another, according to > the spec, one client will get a "bad request" response. My > second question is: how can the client know the rejection is > because the number is taken, as the server can reject the > request for different reasons? > > > > Thanks, > > > > Feng > > > > > > > > > > > > Feng Liu, Ph.D. | Research Scientist, Dialogue System > Research Group | Avaya Labs Research | Avaya | 233 Mt. Airy > Road| Rm. 2D36 | Basking Ridge, NJ 07920 | Voice/Fax: > 908-696-5156 / 908-696-5401 | fliu1@avaya.com > > > > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 22 16:48:58 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579143A6D4D; Tue, 22 Apr 2008 16:48:58 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003763A6D4D for ; Tue, 22 Apr 2008 16:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.52 X-Spam-Level: X-Spam-Status: No, score=-101.52 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aF23iqiMHbD6 for ; Tue, 22 Apr 2008 16:48:56 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 2A93B3A688C for ; Tue, 22 Apr 2008 16:48:56 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 194BA7F02BC; Tue, 22 Apr 2008 23:49:02 +0000 (UTC) Received: from [192.168.1.3] (c-67-161-24-129.hsd1.ca.comcast.net [67.161.24.129]) by server.implementers.org (Postfix) with ESMTP id 397027F02B8; Tue, 22 Apr 2008 23:48:59 +0000 (UTC) Message-ID: <480E796A.6000200@acm.org> Date: Tue, 22 Apr 2008 16:48:58 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.12 (X11/20080420) MIME-Version: 1.0 To: Cullen Jennings References: <480DFAB4.2050207@acm.org> <3B6A8287-122B-4D63-909D-C6377BB24AA4@cisco.com> In-Reply-To: <3B6A8287-122B-4D63-909D-C6377BB24AA4@cisco.com> Cc: Behave WG Subject: Re: [BEHAVE] TURN and TURNS URI and resolution mechanism X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Cullen Jennings wrote: > > Most this draft makes sense to me and seems I like it. One thing that I > don't understand, what's the need for S-NAPTR in the type of use case we > need here. Why not just greatly simplify this and just have SRV (and of > course A/AAAA implied by that)? My original reason for using the S-NAPTR mechanism was to give a TURN servers administrator a possibility to provision the preferred order to use the different transport protocols between the TURN client and the TURN server (UDP, TCP and TLS as currently defined). This is not really needed when using TURN with ICE because the socket on the TURN client should be able to receive/send with the same protocol that is used on the relayed port, so the preferred transport list used in the resolution mechanism contains only one protocol. But be able to give preference to a transport over another can still be useful for other usages, e.g. an administrator with resources constraints can prefer that the clients use UDP, and another administrator with security constraints can prefer that the clients use TLS (obviously in the cases where both protocols can be used). Another reason could be remote hosting. A VoIP provider can have a contract with a different company that provides only the TURN servers. The provider does not (and cannot) manage the SRV records, as the servers are not under its control, so S-NAPTR can solve this problem: example.com IN NAPTR 100 10 "" "RELAY:turn.udp:turn.tcp" "" other.com. other.com IN NAPTR 100 10 "s" "RELAY:turn.udp" "" _turn._udp.other.com other.com IN NAPTR 200 10 "s" "RELAY:turn.tcp" "" _turn._tcp.other.com _turn._udp.other.com IN SRV 10 10 3478 a.other.com. _turn._udp.other.com IN SRV 10 10 3478 b.other.com. _turn._udp.other.com IN SRV 10 20 3478 c.other.com. _turn._tcp.other.com IN SRV 10 10 3478 a.other.com. _turn._tcp.other.com IN SRV 10 10 3478 b.other.com. _turn._tcp.other.com IN SRV 10 20 3478 c.other.com. Here the company providing the TURN servers does not know (and does not care) if the VoIP provider is using the servers for ICE or another usage. I am even thinking that this mechanism could be used to select a TURN server by its feature set (versus trying all the servers until one responds with the set of features needed). Let take the example of turn-ipv6. Without S-NAPTR one will have to try to allocate an IPv6 address/port on the first SRV RR returned then if it fails try the next server and so on until one return an IPv6 address/port. Now if turn-ipv6 defines an Application Protocol tag named turn.udp+ipv6, a TURN client can directly retrieve the SRV RR pointing to servers that can allocate an IPv6 address. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 22 22:50:13 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22433A6927; Tue, 22 Apr 2008 22:50:13 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 173993A68FB for ; Tue, 22 Apr 2008 22:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWcz6-WVnzeD for ; Tue, 22 Apr 2008 22:49:54 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 2734A3A697B for ; Tue, 22 Apr 2008 22:49:52 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3N5q1Jh027599; Wed, 23 Apr 2008 00:52:23 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Apr 2008 08:49:31 +0300 Received: from esdhcp04158.research.nokia.com ([172.21.41.58]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Apr 2008 08:49:31 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia Devices R&D To: behave@ietf.org Date: Wed, 23 Apr 2008 08:50:36 +0300 User-Agent: KMail/1.9.9 References: <480DFAB4.2050207@acm.org> In-Reply-To: <480DFAB4.2050207@acm.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804230850.37186.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 23 Apr 2008 05:49:31.0228 (UTC) FILETIME=[CCF7F1C0:01C8A505] X-Nokia-AV: Clean Subject: Re: [BEHAVE] TURN and TURNS URI and resolution mechanism X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Tuesday 22 April 2008 17:48:20 ext Marc Petit-Huguenin, vous avez =E9cri= t=A0: > I just submitted an I-D that defines URIs and a resolution mechanism to > find TURN servers: > > http://www.ietf.org/internet-drafts/draft-petithuguenin-behave-turn-uri-0= 0. >txt Should this not: 1/ allow for [username@[password:]], e.g. as HTTP, and, 2/ use UNAPTR rather than NAPTR? -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 23 02:58:16 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABB103A6CCA; Wed, 23 Apr 2008 02:58:16 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1EC3A6A7A for ; Wed, 23 Apr 2008 02:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.743 X-Spam-Level: X-Spam-Status: No, score=-101.743 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqRu6zpmTH5w for ; Wed, 23 Apr 2008 02:58:14 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 99D7F28C45F for ; Wed, 23 Apr 2008 02:57:48 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 5EA87D9D424A; Wed, 23 Apr 2008 09:57:54 +0000 (UTC) Received: from [192.168.1.3] (c-67-161-24-129.hsd1.ca.comcast.net [67.161.24.129]) by server.implementers.org (Postfix) with ESMTP id 85BB0D9D4246; Wed, 23 Apr 2008 09:57:50 +0000 (UTC) Message-ID: <480F081D.5060403@acm.org> Date: Wed, 23 Apr 2008 02:57:49 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.12 (X11/20080420) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= References: <480DFAB4.2050207@acm.org> <200804230850.37186.remi.denis-courmont@nokia.com> In-Reply-To: <200804230850.37186.remi.denis-courmont@nokia.com> Cc: behave@ietf.org Subject: Re: [BEHAVE] TURN and TURNS URI and resolution mechanism X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org R=E9mi Denis-Courmont wrote: > Le Tuesday 22 April 2008 17:48:20 ext Marc Petit-Huguenin, vous avez =E9c= rit : >> I just submitted an I-D that defines URIs and a resolution mechanism to >> find TURN servers: >> >> http://www.ietf.org/internet-drafts/draft-petithuguenin-behave-turn-uri-= 00. >> txt > = > Should this not: > 1/ allow for [username@[password:]], e.g. as HTTP, and, The password in the URI is now deprecated (RFC 3986 section 3.2.1), which is a good thing. I am not sure that be able to provide the username on the URI adds anything useful - in all case the end-user will have to be prompted for the password, so prompting also for the username should not be a problem. There is also the minor security risk that it can be used to confuse the end user (e.g. turn:example.com@208.77.188.166). This said I can add the username component if people think it is important. > 2/ use UNAPTR rather than NAPTR? > = I did not find a use case where a TURN URI needs be converted into another URI, but as it annoys me when authors reject suggestions because then cannot think of a use case to justify it, so let me know if you have a good reason for this. Thanks. I always found this "use case" thing extremely annoying when working with the IETF, and this for two reasons. Firstly I consider top-down design as bad engineering. Secondly there is often use cases that can justify to add something to an RFC, but I cannot talk about because it would give an insight to my competitors on what I am working on - another good reason for bottom-up design. -- = Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 23 04:58:02 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB46F3A6BAE; Wed, 23 Apr 2008 04:58:02 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98E303A6BAE for ; Wed, 23 Apr 2008 04:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4HIYW7dp9ML for ; Wed, 23 Apr 2008 04:58:01 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 89DED3A6A9B for ; Wed, 23 Apr 2008 04:58:01 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4190621739; Wed, 23 Apr 2008 13:56:05 +0200 (CEST) X-AuditID: c1b4fb3e-ae198bb000004ec0-be-480f23d50c29 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 265C721518; Wed, 23 Apr 2008 13:56:05 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Apr 2008 13:56:05 +0200 Received: from [127.0.0.1] ([147.214.183.205]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Apr 2008 13:56:04 +0200 Message-ID: <480F23D4.9040205@ericsson.com> Date: Wed, 23 Apr 2008 13:56:04 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Spencer Dawkins References: <48081D50.7010508@matthew.at><1E22EB7A-8B33-406C-89D2-ECA42C61C96A@magma.ca><48095F42.8070804@matthew.at> <02c301c8a3d3$78589f80$c2f0200a@cisco.com> <039401c8a3ed$c1ec13b0$ad600240@china.huawei.com> In-Reply-To: <039401c8a3ed$c1ec13b0$ad600240@china.huawei.com> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 23 Apr 2008 11:56:04.0936 (UTC) FILETIME=[023D7480:01C8A539] X-Brightmail-Tracker: AAAAAA== Cc: 'Behave WG' , 'Philip Matthews' , Dan Wing , matthew@matthew.at Subject: Re: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Spencer Dawkins skrev: > OK, let's start with the process part, first. > = > If "Someone" was to submit an IETF Last Call comment that says "there's a = > SERVER attribute that does what we want, but we also need a CLIENT = > attribute, with the same text and obvious substitutions" - in fact, it wo= uld = > probably look a lot like this: > = > 15.whatever. CLIENT > = > The client attribute contains a textual description of the software > being used by the client, including manufacturer and version number. > The attribute has no impact on operation of the protocol, and serves > only as a tool for diagnostic and debugging purposes. The value of > CLIENT is variable length. It MUST be a UTF-8 [RFC3629] encoded > sequence of less than 128 characters (which can be as long as 763 > bytes). > = > I'm not sure why the IESG would freak out. We've done worse, later in the = > process. I don't think the IESG will freak out. If the WG likes to add this to = STUNbis I think we have satisfied procedure by having a consensus call = in the WG and if strong consensus exist go forward. The IESG will of = course need to have the possibility to put DISCUSS so probably putting = it back on a call before approving it. If going forward with this idea, I would please remind that you = shouldn't forget the security issues with this header. I think HTTP (RFC = 2616) has some text on the issues with Client (User-Agent in HTTP) = implementation identifiers. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 23 07:00:39 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB1DA28C1D3; Wed, 23 Apr 2008 07:00:39 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C69C3A6B5A for ; Wed, 23 Apr 2008 07:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxcHieX+qzvK for ; Wed, 23 Apr 2008 07:00:35 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 439ED28C1D3 for ; Wed, 23 Apr 2008 07:00:35 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 23 Apr 2008 07:00:41 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3NE0cBb029162; Wed, 23 Apr 2008 07:00:38 -0700 Received: from [192.168.1.73] ([10.21.73.75]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3NDwBCB005062; Wed, 23 Apr 2008 13:58:15 GMT Message-Id: From: Cullen Jennings To: Magnus Westerlund In-Reply-To: <480F23D4.9040205@ericsson.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 23 Apr 2008 10:02:10 -0400 References: <48081D50.7010508@matthew.at><1E22EB7A-8B33-406C-89D2-ECA42C61C96A@magma.ca><48095F42.8070804@matthew.at> <02c301c8a3d3$78589f80$c2f0200a@cisco.com> <039401c8a3ed$c1ec13b0$ad600240@china.huawei.com> <480F23D4.9040205@ericsson.com> X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2582; t=1208959238; x=1209823238; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20STUN/TURN=20=22User=20Agent= 22 |Sender:=20; bh=Vd44uF1/O+3i+70nW0MkAc61/33QPpvNst0pOYUbx/0=; b=bDIZAuccI7DLfBmzOXesGKKDJzKA2jpy7C6H19JBkfpvztayPufGZj3h/q uNzkMkPjQlp9Vak1KW+uS6o5OUcxoox3y1Ir7BANPjNHwTNkPBfwAqNJ0rZy 5RV/ih5NQp; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Behave WG Subject: Re: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org When we moved 3489bis ahead, most folks realized there was a = reasonable chance that small changes might be needed to 3489bis coming = out of the ICE or TURN work. I don't think IESG would have any = heartburn over this if the WG wanted to do it. On Apr 23, 2008, at 7:56 AM, Magnus Westerlund wrote: > Spencer Dawkins skrev: > >> OK, let's start with the process part, first. >> >> If "Someone" was to submit an IETF Last Call comment that says = >> "there's a >> SERVER attribute that does what we want, but we also need a CLIENT >> attribute, with the same text and obvious substitutions" - in fact, = >> it would >> probably look a lot like this: >> >> 15.whatever. CLIENT >> >> The client attribute contains a textual description of the software >> being used by the client, including manufacturer and version = >> number. >> The attribute has no impact on operation of the protocol, and = >> serves >> only as a tool for diagnostic and debugging purposes. The value of >> CLIENT is variable length. It MUST be a UTF-8 [RFC3629] encoded >> sequence of less than 128 characters (which can be as long as 763 >> bytes). >> >> I'm not sure why the IESG would freak out. We've done worse, later = >> in the >> process. > > I don't think the IESG will freak out. If the WG likes to add this to > STUNbis I think we have satisfied procedure by having a consensus call > in the WG and if strong consensus exist go forward. The IESG will of > course need to have the possibility to put DISCUSS so probably putting > it back on a call before approving it. > > If going forward with this idea, I would please remind that you > shouldn't forget the security issues with this header. I think HTTP = > (RFC > 2616) has some text on the issues with Client (User-Agent in HTTP) > implementation identifiers. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > F=E4r=F6gatan 6 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 23 07:05:39 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BE1F3A6A8D; Wed, 23 Apr 2008 07:05:39 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12ED43A6A8D for ; Wed, 23 Apr 2008 07:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNC-cP-+LEiC for ; Wed, 23 Apr 2008 07:05:36 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 4E2593A69D8 for ; Wed, 23 Apr 2008 07:05:36 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id F12F929E1493; Wed, 23 Apr 2008 10:05:11 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id E7C0329E130C for ; Wed, 23 Apr 2008 10:05:11 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: behave@ietf.org Date: Wed, 23 Apr 2008 10:05:11 -0400 User-Agent: KMail/1.9.9 References: <48081D50.7010508@matthew.at> <480F23D4.9040205@ericsson.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804231005.11519.simon.perreault@viagenie.ca> Subject: Re: [BEHAVE] STUN/TURN "User Agent" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Wednesday 23 April 2008 10:02:10 Cullen Jennings wrote: > When we moved 3489bis ahead, most folks realized there was a > reasonable chance that small changes might be needed to 3489bis coming > out of the ICE or TURN work. I don't think IESG would have any > heartburn over this if the WG wanted to do it. I see a lot of "if the WG wanted it"... I, for one, am not an author nor an IESG member, and I want it. Is it OK now? ;) /me hums _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 23 08:58:59 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41AF3A6E2D; Wed, 23 Apr 2008 08:58:59 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B74E83A6B40 for ; Wed, 23 Apr 2008 08:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WKD8uL7YpS1 for ; Wed, 23 Apr 2008 08:58:53 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 296B83A6AAB for ; Wed, 23 Apr 2008 08:58:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,700,1199682000"; d="scan'208";a="103909135" Received: from unknown (HELO delia.research.avayalabs.com) ([135.10.40.26]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Apr 2008 11:58:55 -0400 Received: from fliu1dell (fliu1-dell.woods.avayalabs.com [135.10.42.52]) by delia.research.avayalabs.com (8.14.2+Sun/8.14.2) with ESMTP id m3NFwrE5016133; Wed, 23 Apr 2008 11:58:54 -0400 (EDT) From: "Feng Liu" To: "'Dan Wing'" , References: <00ff01c8a4d1$de3fc360$c2f0200a@cisco.com> Date: Wed, 23 Apr 2008 11:58:53 -0400 Organization: Avaya Labs Research, Avaya Inc. Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <00ff01c8a4d1$de3fc360$c2f0200a@cisco.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.3790.4133 thread-index: AcikxqP227McVY/dTlWQS7SNWprVNAACuQcAACJUGbA= Subject: Re: [BEHAVE] Channel Number X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Thank you for clarifying it! Feng -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com] Sent: Tuesday, April 22, 2008 7:38 PM To: 'Feng Liu'; behave@ietf.org Subject: RE: [BEHAVE] Channel Number > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Feng Liu > Sent: Tuesday, April 22, 2008 3:17 PM > To: behave@ietf.org > Subject: [BEHAVE] Channel Number > > Dear BEHAVE experts, > > > > I have two questions regarding Channel Number in TURN, and > would like to get your advice. > > > > Assume I have two TURN clients, and each wants to bind a > channel to its peer. When TURN clients choose Channel > Numbers, it is likely that they pick the same Channel Number > (e.g., both clients are from the same vendor and have the > same initial value and number selection algorithm). > > > > My question is: what is the behavior of the server in this > case? Will the server accept one binding request and reject > the other? Or it accepts both as two channel bindings are > independent of each other? They are independent of each other because they are over different TURN clients (different source IP address+port). The channel number is not unique for the entire TURN server; rather, the channel number is unique for every TURN session with that TURN server. -d > > If the server accepts one and rejects another, according to > the spec, one client will get a "bad request" response. My > second question is: how can the client know the rejection is > because the number is taken, as the server can reject the > request for different reasons? > > > > Thanks, > > > > Feng > > > > > > > > > > > > Feng Liu, Ph.D. | Research Scientist, Dialogue System > Research Group | Avaya Labs Research | Avaya | 233 Mt. Airy > Road| Rm. 2D36 | Basking Ridge, NJ 07920 | Voice/Fax: > 908-696-5156 / 908-696-5401 | fliu1@avaya.com > > > > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 23 09:31:25 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10EBE28C309; Wed, 23 Apr 2008 09:31:25 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA583A6B84 for ; Wed, 23 Apr 2008 09:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+jLvoeoDN7F for ; Wed, 23 Apr 2008 09:31:17 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E763828C270 for ; Wed, 23 Apr 2008 09:31:00 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 23 Apr 2008 09:31:06 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3NGV6x1002952 for ; Wed, 23 Apr 2008 09:31:06 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3NGV5Tx022111 for ; Wed, 23 Apr 2008 16:31:06 GMT From: "Dan Wing" To: Date: Wed, 23 Apr 2008 09:31:02 -0700 Message-ID: <044801c8a55f$6c255040$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcilX2vGOAk3iGMrSBmFiao/2jM0Cw== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=334; t=1208968266; x=1209832266; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20Nortel's=20updated=20IPR=20on=20draft-ietf-beha ve-nat-behavior-discovery |Sender:=20; bh=Rq4md5jh92dzYQUvVIuoUYJpRQ0BRnvct5fHUQs5Doo=; b=cGEpXjIdhIrRAwRVL10Pxf42m/Ven0MbuBRkCrp8mTwXiCllQYF7E0SHH/ aD88WV8dryOdkehPYl5f4LqPLkAaotJPXncRcA9V4g+gv02NH88uH2H2NEI3 9fpc1R6Xen; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [BEHAVE] Nortel's updated IPR on draft-ietf-behave-nat-behavior-discovery X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org FYI, Nortel has updated their IPR disclosure on draft-ietf-behave-nat-behavior-discovery. A copy of their disclosure can be found here: http://www.ietf.org/ietf/IPR/nortel-ipr-update-draft-ietf-behave-nat-behavior- discovery.txt As a reminder, all IPR disclosures can be found at https://datatracker.ietf.org/ipr/ -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 23 09:42:32 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4DAD3A6D41; Wed, 23 Apr 2008 09:42:32 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B50433A6B55 for ; Wed, 23 Apr 2008 09:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnOviqYxsOnK for ; Wed, 23 Apr 2008 09:42:29 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3E63F3A6BE8 for ; Wed, 23 Apr 2008 09:42:29 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 23 Apr 2008 09:42:35 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3NGgZoG005714; Wed, 23 Apr 2008 09:42:35 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m3NGgYPO024326; Wed, 23 Apr 2008 16:42:34 GMT From: "Dan Wing" To: "'Marc Petit-Huguenin'" , "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" References: <480DFAB4.2050207@acm.org><200804230850.37186.remi.denis-courmont@nokia.com> <480F081D.5060403@acm.org> Date: Wed, 23 Apr 2008 09:42:31 -0700 Message-ID: <046501c8a561$066740e0$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <480F081D.5060403@acm.org> thread-index: AcilKJgmtmg2kUBXQ02iUj6mU1PdEgAN+T/A DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2973; t=1208968955; x=1209832955; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20TURN=20and=20TURNS=20URI=20a nd=20resolution=20mechanism |Sender:=20; bh=fZxTwRuOKuyOn2vh0QsxrGFx1qGQcX6VdqTG7l9zH4U=; b=MqKwwuf49yiiVYx2wfiOEdCfExu05oZUC9206BahO1Shc6u4kbAzaWyBd+ QZLrVN0mS/DqH6yTz37OHB7dCkYOquVHLKFm4A6LvBoeg6wy30Vv/I1llUA9 u9EOaWNCciFX3o/d7SrWANCmhTHOXmuuo78FEfe0TxAeLXvkKcS48=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] TURN and TURNS URI and resolution mechanism X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org = > -----Original Message----- > From: behave-bounces@ietf.org = > [mailto:behave-bounces@ietf.org] On Behalf Of Marc Petit-Huguenin > Sent: Wednesday, April 23, 2008 2:58 AM > To: R=E9mi Denis-Courmont > Cc: behave@ietf.org > Subject: Re: [BEHAVE] TURN and TURNS URI and resolution mechanism > = > R=E9mi Denis-Courmont wrote: > > Le Tuesday 22 April 2008 17:48:20 ext Marc Petit-Huguenin, = > vous avez =E9crit : > >> I just submitted an I-D that defines URIs and a resolution = > mechanism to > >> find TURN servers: > >> > >> = > http://www.ietf.org/internet-drafts/draft-petithuguenin-behave > -turn-uri-00. > >> txt > > = > > Should this not: > > 1/ allow for [username@[password:]], e.g. as HTTP, and, > = > The password in the URI is now deprecated (RFC 3986 section 3.2.1), > which is a good thing. I am not sure that be able to provide the > username on the URI adds anything useful - in all case the = > end-user will > have to be prompted for the password, so prompting also for = > the username > should not be a problem. There is also the minor security = > risk that it > can be used to confuse the end user (e.g. > turn:example.com@208.77.188.166). This said I can add the username > component if people think it is important. Your I-D describes an address resolution mechanism, which is unlike HTTP (or FTP, which can also have username:password) that accesses a resource (a 'document' or 'file'). = The only value that I see with allowing the username in the URI is if we expect someone might want: = turn:dan.wing@turn.example.com turn:joe.sixpack@turn.example.com to resolve to different IP addresses. That doesn't seem likely to me, (for whatever my foresight is worth). -d > > 2/ use UNAPTR rather than NAPTR? > > = > = > I did not find a use case where a TURN URI needs be converted into > another URI, but as it annoys me when authors reject = > suggestions because > then cannot think of a use case to justify it, so let me know if you > have a good reason for this. > = > Thanks. > = > = > I always found this "use case" thing extremely annoying when > working with the IETF, and this for two reasons. Firstly I consider > top-down design as bad engineering. Secondly there is often use cases > that can justify to add something to an RFC, but I cannot talk about > because it would give an insight to my competitors on what I = > am working > on - another good reason for bottom-up design. > = > -- = > Marc Petit-Huguenin [ ] > Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] > Work: marc@8x8.com [ ] > [ ] > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 23 10:30:38 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991BE28C316; Wed, 23 Apr 2008 10:30:38 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEDAE3A6AD0 for ; Wed, 23 Apr 2008 10:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.967 X-Spam-Level: X-Spam-Status: No, score=-101.967 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F52G2WjrbH3c for ; Wed, 23 Apr 2008 10:30:32 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 4E8B228C316 for ; Wed, 23 Apr 2008 10:30:32 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id E4203D9DC0F8; Wed, 23 Apr 2008 17:30:37 +0000 (UTC) Received: from [192.168.1.3] (c-67-161-24-129.hsd1.ca.comcast.net [67.161.24.129]) by server.implementers.org (Postfix) with ESMTP id 606C3D9DC0F2; Wed, 23 Apr 2008 17:30:35 +0000 (UTC) Message-ID: <480F7238.1060302@acm.org> Date: Wed, 23 Apr 2008 10:30:32 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.12 (X11/20080420) MIME-Version: 1.0 To: Dan Wing References: <480DFAB4.2050207@acm.org><200804230850.37186.remi.denis-courmont@nokia.com> <480F081D.5060403@acm.org> <046501c8a561$066740e0$c2f0200a@cisco.com> In-Reply-To: <046501c8a561$066740e0$c2f0200a@cisco.com> Cc: behave@ietf.org Subject: Re: [BEHAVE] TURN and TURNS URI and resolution mechanism X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Dan Wing wrote: > = > = >> -----Original Message----- >> From: behave-bounces@ietf.org = >> [mailto:behave-bounces@ietf.org] On Behalf Of Marc Petit-Huguenin >> Sent: Wednesday, April 23, 2008 2:58 AM >> To: R=E9mi Denis-Courmont >> Cc: behave@ietf.org >> Subject: Re: [BEHAVE] TURN and TURNS URI and resolution mechanism >> >> R=E9mi Denis-Courmont wrote: >>> Le Tuesday 22 April 2008 17:48:20 ext Marc Petit-Huguenin, = >> vous avez =E9crit : >>>> I just submitted an I-D that defines URIs and a resolution = >> mechanism to >>>> find TURN servers: >>>> >>>> >> http://www.ietf.org/internet-drafts/draft-petithuguenin-behave >> -turn-uri-00. >>>> txt >>> Should this not: >>> 1/ allow for [username@[password:]], e.g. as HTTP, and, >> The password in the URI is now deprecated (RFC 3986 section 3.2.1), >> which is a good thing. I am not sure that be able to provide the >> username on the URI adds anything useful - in all case the = >> end-user will >> have to be prompted for the password, so prompting also for = >> the username >> should not be a problem. There is also the minor security = >> risk that it >> can be used to confuse the end user (e.g. >> turn:example.com@208.77.188.166). This said I can add the username >> component if people think it is important. > = > Your I-D describes an address resolution mechanism, which is unlike > HTTP (or FTP, which can also have username:password) that accesses > a resource (a 'document' or 'file'). = > = > The only value that I see with allowing the username in the URI is > if we expect someone might want: > = > turn:dan.wing@turn.example.com > turn:joe.sixpack@turn.example.com > = > to resolve to different IP addresses. = Yes, I like the idea that all components in the URI are exclusively for the purpose of guiding the resolution mechanism. > That doesn't seem likely to > me, (for whatever my foresight is worth). > = Well, one can design a mechanism that would resolve a user component to a SRV/A RR, e.g. with distributed hash tables (a hash is associated to a SRV RR in the DNS, the client calculates a hash for the user component and use the SRV RR with a hash value equal or lower to the user hash value). -- = Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 23 10:44:10 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6365428C321; Wed, 23 Apr 2008 10:44:10 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B2F228C33A for ; Wed, 23 Apr 2008 10:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhPYXRBtsKGB for ; Wed, 23 Apr 2008 10:44:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0401728C321 for ; Wed, 23 Apr 2008 10:44:04 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 23 Apr 2008 10:44:09 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m3NHi9jE031477; Wed, 23 Apr 2008 10:44:09 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3NHi9aO003071; Wed, 23 Apr 2008 17:44:09 GMT From: "Dan Wing" To: "'Marc Petit-Huguenin'" References: <480DFAB4.2050207@acm.org><200804230850.37186.remi.denis-courmont@nokia.com><480F081D.5060403@acm.org><046501c8a561$066740e0$c2f0200a@cisco.com> <480F7238.1060302@acm.org> Date: Wed, 23 Apr 2008 10:44:09 -0700 Message-ID: <052d01c8a569$a284a410$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <480F7238.1060302@acm.org> thread-index: AcilZ8oLUUl4o/CjSiiZphn6tHzJogAAaa1A DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1078; t=1208972649; x=1209836649; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20TURN=20and=20TURNS=20URI=20a nd=20resolution=20mechanism |Sender:=20; bh=tmnnrs7UQeh4H2nI010x2tR9ZgBVDaootryzDo190RU=; b=Vc53hP+pr5iMwYNDvnjE6sZn7uB0NMs/KfJA0R8WzlbXytD4XMCOqJVdZ5 EXw0Lg4sfQ6hWCH558TkTCAaPmvI2Lyzy/5ey9e/W+ENwu8s3Rc+qy1kpKK0 GjnG3JuaGT; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] TURN and TURNS URI and resolution mechanism X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > > The only value that I see with allowing the username in the URI is > > if we expect someone might want: > > > > turn:dan.wing@turn.example.com > > turn:joe.sixpack@turn.example.com > > > > to resolve to different IP addresses. > > Yes, I like the idea that all components in the URI are > exclusively for > the purpose of guiding the resolution mechanism. > > > That doesn't seem likely to > > me, (for whatever my foresight is worth). > > > > Well, one can design a mechanism that would resolve a user > component to > a SRV/A RR, e.g. with distributed hash tables (a hash is > associated to a > SRV RR in the DNS, the client calculates a hash for the user component > and use the SRV RR with a hash value equal or lower to the > user hash value). Sure, but you could do that without usernames by encoding that value you want to hash as if it was a hostname, turn:dan.wing.turn.example.com turn:joe.sixpack.turn.example.com and a wildcarded DNS record (yes, not pretty) could be tied into the hash generation. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 23 14:10:59 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D9728C109; Wed, 23 Apr 2008 14:10:59 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DAF428C11A for ; Wed, 23 Apr 2008 14:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvmdS6Inu4IB for ; Wed, 23 Apr 2008 14:10:53 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 5AB1328C109 for ; Wed, 23 Apr 2008 14:10:53 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id A1EC829E1484; Wed, 23 Apr 2008 17:10:28 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 990FC29E130C for ; Wed, 23 Apr 2008 17:10:28 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: behave@ietf.org Date: Wed, 23 Apr 2008 17:10:28 -0400 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804231710.28415.simon.perreault@viagenie.ca> Subject: [BEHAVE] Duplicate request handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi, [draft-ietf-behave-rfc3489bis-15], Section 7.3.1, contains the following: If the request uses UDP transport and is a retransmission of a request for which the server has already generated a success response within the last 40 seconds, the server MUST retransmit the same success response. From the absence of indications pertaining to the case where the response was not a success, I deduce that the server must not remember the transaction and simply try again to fulfill a duplicated request, hoping that this new attempt succeeds. Am I right? Thanks, Simon _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Apr 23 19:10:31 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA7128C109; Wed, 23 Apr 2008 19:10:31 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8601D3A6BCC for ; Wed, 23 Apr 2008 19:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjfnPvuGbgWc for ; Wed, 23 Apr 2008 19:10:29 -0700 (PDT) Received: from mail-07.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 1BE5C3A6DFD for ; Wed, 23 Apr 2008 19:10:29 -0700 (PDT) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Joquq-0005Mm-0W; Wed, 23 Apr 2008 22:10:29 -0400 Message-Id: <59B578CA-F107-4AD1-8D13-39AC30A83EEB@magma.ca> From: Philip Matthews To: Feng Liu In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 23 Apr 2008 22:10:28 -0400 References: <00ff01c8a4d1$de3fc360$c2f0200a@cisco.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Cc: behave@ietf.org, 'Dan Wing' Subject: Re: [BEHAVE] Channel Number X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org To be more precise, channel numbers are local to an allocation, and the allocation is uniquely identified by the 5-tuple (client IP address, client port, server IP address, server port, transport protocol). Channel numbers, permissions, etc etc in two different allocations have nothing to do with each other. - Philip On Wed, 23-Apr-08, at 11:58 , Feng Liu wrote: > Thank you for clarifying it! > > Feng > > > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Tuesday, April 22, 2008 7:38 PM > To: 'Feng Liu'; behave@ietf.org > Subject: RE: [BEHAVE] Channel Number > >> -----Original Message----- >> From: behave-bounces@ietf.org >> [mailto:behave-bounces@ietf.org] On Behalf Of Feng Liu >> Sent: Tuesday, April 22, 2008 3:17 PM >> To: behave@ietf.org >> Subject: [BEHAVE] Channel Number >> >> Dear BEHAVE experts, >> >> >> >> I have two questions regarding Channel Number in TURN, and >> would like to get your advice. >> >> >> >> Assume I have two TURN clients, and each wants to bind a >> channel to its peer. When TURN clients choose Channel >> Numbers, it is likely that they pick the same Channel Number >> (e.g., both clients are from the same vendor and have the >> same initial value and number selection algorithm). >> >> >> >> My question is: what is the behavior of the server in this >> case? Will the server accept one binding request and reject >> the other? Or it accepts both as two channel bindings are >> independent of each other? > > They are independent of each other because they are over > different TURN clients (different source IP address+port). The > channel number is not unique for the entire TURN server; rather, > the channel number is unique for every TURN session with that > TURN server. > > -d > >> >> If the server accepts one and rejects another, according to >> the spec, one client will get a "bad request" response. My >> second question is: how can the client know the rejection is >> because the number is taken, as the server can reject the >> request for different reasons? >> >> >> >> Thanks, >> >> >> >> Feng >> >> >> >> >> >> >> >> >> >> >> >> Feng Liu, Ph.D. | Research Scientist, Dialogue System >> Research Group | Avaya Labs Research | Avaya | 233 Mt. Airy >> Road| Rm. 2D36 | Basking Ridge, NJ 07920 | Voice/Fax: >> 908-696-5156 / 908-696-5401 | fliu1@avaya.com >> >> >> >> >> >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 06:23:47 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09BB63A6A70; Thu, 24 Apr 2008 06:23:47 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92DA3A6BAC for ; Thu, 24 Apr 2008 06:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXrAj4Fgm4Xb for ; Thu, 24 Apr 2008 06:23:41 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 9016B3A6B3E for ; Thu, 24 Apr 2008 06:23:41 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id BDFBA29E1495; Thu, 24 Apr 2008 09:23:16 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id B677B29E1433 for ; Thu, 24 Apr 2008 09:23:16 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: behave@ietf.org Date: Thu, 24 Apr 2008 09:23:16 -0400 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804240923.16507.simon.perreault@viagenie.ca> Subject: [BEHAVE] Error code for unsupported method X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hello, What is a STUN server supposed to use as error code when an unknown method is received? From the list in 3489bis, Section 15.6, I'd be tempted to pick either 400 or 500, depending on who I'm siding with, but this doesn't seem right because it's really nobody's fault. Will people crucify me if I return a 501 Not Implemented, as in HTTP? Thanks, Simon _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 06:49:20 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1A623A6C55; Thu, 24 Apr 2008 06:49:19 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B08433A6C55 for ; Thu, 24 Apr 2008 06:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bfs3xW8USNha for ; Thu, 24 Apr 2008 06:49:18 -0700 (PDT) Received: from s200aog16.obsmtp.com (s200aog16.obsmtp.com [207.126.144.130]) by core3.amsl.com (Postfix) with SMTP id 5599A3A6C3A for ; Thu, 24 Apr 2008 06:49:17 -0700 (PDT) Received: from source ([64.233.184.235]) by eu1sys200aob016.postini.com ([207.126.147.11]) with SMTP; Thu, 24 Apr 2008 13:48:54 UTC Received: by wr-out-0506.google.com with SMTP id c55so1897393wra.0 for ; Thu, 24 Apr 2008 06:49:21 -0700 (PDT) Received: by 10.141.37.8 with SMTP id p8mr1129386rvj.150.1209044960985; Thu, 24 Apr 2008 06:49:20 -0700 (PDT) Received: by 10.141.186.2 with HTTP; Thu, 24 Apr 2008 06:49:20 -0700 (PDT) Message-ID: <1879720d0804240649u4163d096rb9ce494ffa2fb80b@mail.gmail.com> Date: Thu, 24 Apr 2008 14:49:20 +0100 From: "Benny Prijono" To: "Simon Perreault" In-Reply-To: <200804231710.28415.simon.perreault@viagenie.ca> MIME-Version: 1.0 Content-Disposition: inline References: <200804231710.28415.simon.perreault@viagenie.ca> X-Google-Sender-Auth: b444439b37a9a2be Cc: behave@ietf.org Subject: Re: [BEHAVE] Duplicate request handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Wed, Apr 23, 2008 at 10:10 PM, Simon Perreault wrote: > Hi, > > [draft-ietf-behave-rfc3489bis-15], Section 7.3.1, contains the following: > > If the request uses UDP transport and is a retransmission of a > request for which the server has already generated a success response > within the last 40 seconds, the server MUST retransmit the same > success response. > > From the absence of indications pertaining to the case where the response was > not a success, I deduce that the server must not remember the transaction and > simply try again to fulfill a duplicated request, hoping that this new > attempt succeeds. Am I right? From my understanding, it doesn't have to be like that. Server may just retransmit the same failure response for the same request retransmission if it wants to. In fact I think server should do this especially for non-idempotent requests, otherwise we may end up with different state between the client and the server. For example, imagine when TURN server first returns failure response, then successful response on the second Allocate retransmission. Client most likely will ignore the second response retransmission, hence client thinks that the Allocate has failed while the server thinks it has been successful. Cheers Benny > Thanks, > Simon _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 06:53:03 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5BA828C180; Thu, 24 Apr 2008 06:53:03 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 269973A693D for ; Thu, 24 Apr 2008 06:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpJfT4MSJE1m for ; Thu, 24 Apr 2008 06:52:59 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 503E23A67A8 for ; Thu, 24 Apr 2008 06:52:59 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3ODsWtZ004078; Thu, 24 Apr 2008 08:55:30 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Apr 2008 16:52:54 +0300 Received: from esdhcp04031.research.nokia.com ([172.21.40.31]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Apr 2008 16:52:54 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia Devices R&D To: behave@ietf.org Date: Thu, 24 Apr 2008 16:53:59 +0300 User-Agent: KMail/1.9.9 References: <200804240923.16507.simon.perreault@viagenie.ca> In-Reply-To: <200804240923.16507.simon.perreault@viagenie.ca> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804241653.59243.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 24 Apr 2008 13:52:54.0050 (UTC) FILETIME=[7E692020:01C8A612] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Error code for unsupported method X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Thursday 24 April 2008 16:23:16 ext Simon Perreault, vous avez =E9crit= =A0: > Hello, > > What is a STUN server supposed to use as error code when an unknown method > is received? From the list in 3489bis, Section 15.6, I'd be tempted to pi= ck > either 400 or 500, depending on who I'm siding with, but this doesn't seem > right because it's really nobody's fault. > > Will people crucify me if I return a 501 Not Implemented, as in HTTP? Yes they will. Sending a 5xx error code allows the client to retry the requ= est = a certain number of times, hence it is only appropriate for transitional = errors. You should rather use 400 Bad Request, for lack of a more precise value in = the = 4xx range. Unknown request types can only occur if a client tries to contac= t = a server for an inappropriate "usage" of STUN. So in a sense, the request i= s = malformed. -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 06:57:30 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445AA28C136; Thu, 24 Apr 2008 06:57:30 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6210D3A6C04 for ; Thu, 24 Apr 2008 06:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7+ZBx2fiUS8 for ; Thu, 24 Apr 2008 06:57:27 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 889643A6AC0 for ; Thu, 24 Apr 2008 06:57:27 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id A09C329E1488; Thu, 24 Apr 2008 09:57:02 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 97E4B29E1433 for ; Thu, 24 Apr 2008 09:57:02 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: behave@ietf.org Date: Thu, 24 Apr 2008 09:57:02 -0400 User-Agent: KMail/1.9.9 References: <200804231710.28415.simon.perreault@viagenie.ca> <1879720d0804240649u4163d096rb9ce494ffa2fb80b@mail.gmail.com> In-Reply-To: <1879720d0804240649u4163d096rb9ce494ffa2fb80b@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804240957.02395.simon.perreault@viagenie.ca> Subject: Re: [BEHAVE] Duplicate request handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi Benny, On Thursday 24 April 2008 09:49:20 Benny Prijono wrote: > From my understanding, it doesn't have to be like that. Server may > just retransmit the same failure response for the same request > retransmission if it wants to. In fact I think server should do this > especially for non-idempotent requests, otherwise we may end up with > different state between the client and the server. For example, > imagine when TURN server first returns failure response, then > successful response on the second Allocate retransmission. Client most > likely will ignore the second response retransmission, hence client > thinks that the Allocate has failed while the server thinks it has > been successful. I think you're right and that the spec should be changed. Any kind of response (success or error) for any kind of request (indempotent or not) should be remembered and retransmitted when a duplicate request is detected. This is transport-level stuff which doesn't have to be concerned about application-level stuff. Simon _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 08:49:50 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16D2D28C19C; Thu, 24 Apr 2008 08:49:50 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357173A6D09 for ; Wed, 23 Apr 2008 11:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nHUFIPh7kdl for ; Wed, 23 Apr 2008 11:55:36 -0700 (PDT) Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by core3.amsl.com (Postfix) with SMTP id 4C2A63A6D34 for ; Wed, 23 Apr 2008 11:55:36 -0700 (PDT) Received: (qmail 67291 invoked from network); 23 Apr 2008 18:55:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding; b=Mt8oQdPGvjO1VCwHSe44yegxm+nRjX7SQA5Qa/N0RD8WCTxOmbmyCMPRGkxSUAB1HBR5waIp0RG+aru+YNu9qugF3ie/5zUq4yQIrHK9KyWMtuI2RxkSQfZL68YG29PeMrzQoPjbwt7sF5Ht+b6uvRJHar0rsdA3Pay/f+t+o6o= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@rogers.com@72.140.46.24 with plain) by smtp101.rog.mail.re2.yahoo.com with SMTP; 23 Apr 2008 18:55:41 -0000 X-YMail-OSG: DNSBSScVM1mdysWMZpfey1K58A4fAPQswM.VnJQTEpYrNP8LA5TSEd8nzpReYSn6gQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <480F8629.8080202@rogers.com> Date: Wed, 23 Apr 2008 14:55:37 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: IETF AVT WG , behave@ietf.org X-Mailman-Approved-At: Thu, 24 Apr 2008 08:49:48 -0700 Cc: MARJOU Xavier RD-MAPS-LAN Subject: [BEHAVE] Working Group Last Call: draft-ietf-avt-app-rtp-keepalive-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org This is to announce Working Group Last Call for draft-ietf-avt-app-rtp-keepalive-03.txt. Assuming all goes well, the Last Call period will end on May 7. Given the subject matter, the BEHAVE list is also copied on this message. Tom Taylor for the Chairs. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 09:01:57 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 773A23A6CC5; Thu, 24 Apr 2008 09:01:57 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 728893A6A5F for ; Thu, 24 Apr 2008 09:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QF8kcqkJ55B for ; Thu, 24 Apr 2008 09:01:50 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 0F9DF3A6B3D for ; Thu, 24 Apr 2008 09:01:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,704,1199682000"; d="scan'208";a="121010891" Received: from unknown (HELO delia.research.avayalabs.com) ([135.10.40.26]) by co300216-co-outbound.avaya.com with ESMTP; 24 Apr 2008 12:01:13 -0400 Received: from fliu1dell (fliu1-dell.woods.avayalabs.com [135.10.42.52]) by delia.research.avayalabs.com (8.14.2+Sun/8.14.2) with ESMTP id m3OG1AVd009152; Thu, 24 Apr 2008 12:01:12 -0400 (EDT) From: "Feng Liu" To: "'Philip Matthews'" References: <00ff01c8a4d1$de3fc360$c2f0200a@cisco.com> <59B578CA-F107-4AD1-8D13-39AC30A83EEB@magma.ca> Date: Thu, 24 Apr 2008 12:01:10 -0400 Organization: Avaya Labs Research, Avaya Inc. Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <59B578CA-F107-4AD1-8D13-39AC30A83EEB@magma.ca> x-mimeole: Produced By Microsoft MimeOLE V6.00.3790.4133 thread-index: AcilsGIsmh4o3GfXQE+pbwwcYeZtHgAc0hDw Cc: behave@ietf.org, 'Dan Wing' Subject: Re: [BEHAVE] Channel Number X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Philip, I was confused by the spec, and the explanations from you and Dan are much clearer for an outsider. Do you think it is a good idea to add it into the draft? Thanks, Feng -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca] Sent: Wednesday, April 23, 2008 10:10 PM To: Feng Liu Cc: 'Dan Wing'; behave@ietf.org Subject: Re: [BEHAVE] Channel Number To be more precise, channel numbers are local to an allocation, and the allocation is uniquely identified by the 5-tuple (client IP address, client port, server IP address, server port, transport protocol). Channel numbers, permissions, etc etc in two different allocations have nothing to do with each other. - Philip On Wed, 23-Apr-08, at 11:58 , Feng Liu wrote: > Thank you for clarifying it! > > Feng > > > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Tuesday, April 22, 2008 7:38 PM > To: 'Feng Liu'; behave@ietf.org > Subject: RE: [BEHAVE] Channel Number > >> -----Original Message----- >> From: behave-bounces@ietf.org >> [mailto:behave-bounces@ietf.org] On Behalf Of Feng Liu >> Sent: Tuesday, April 22, 2008 3:17 PM >> To: behave@ietf.org >> Subject: [BEHAVE] Channel Number >> >> Dear BEHAVE experts, >> >> >> >> I have two questions regarding Channel Number in TURN, and >> would like to get your advice. >> >> >> >> Assume I have two TURN clients, and each wants to bind a >> channel to its peer. When TURN clients choose Channel >> Numbers, it is likely that they pick the same Channel Number >> (e.g., both clients are from the same vendor and have the >> same initial value and number selection algorithm). >> >> >> >> My question is: what is the behavior of the server in this >> case? Will the server accept one binding request and reject >> the other? Or it accepts both as two channel bindings are >> independent of each other? > > They are independent of each other because they are over > different TURN clients (different source IP address+port). The > channel number is not unique for the entire TURN server; rather, > the channel number is unique for every TURN session with that > TURN server. > > -d > >> >> If the server accepts one and rejects another, according to >> the spec, one client will get a "bad request" response. My >> second question is: how can the client know the rejection is >> because the number is taken, as the server can reject the >> request for different reasons? >> >> >> >> Thanks, >> >> >> >> Feng >> >> >> >> >> >> >> >> >> >> >> >> Feng Liu, Ph.D. | Research Scientist, Dialogue System >> Research Group | Avaya Labs Research | Avaya | 233 Mt. Airy >> Road| Rm. 2D36 | Basking Ridge, NJ 07920 | Voice/Fax: >> 908-696-5156 / 908-696-5401 | fliu1@avaya.com >> >> >> >> >> >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 09:49:32 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222C028C1F6; Thu, 24 Apr 2008 09:49:32 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4565128C191 for ; Thu, 24 Apr 2008 09:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpA0a0aPnSnF for ; Thu, 24 Apr 2008 09:49:30 -0700 (PDT) Received: from mail-09.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id E29813A6D04 for ; Thu, 24 Apr 2008 09:46:53 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Jp4b4-0004qw-1z; Thu, 24 Apr 2008 12:46:59 -0400 Message-Id: From: Philip Matthews To: Feng Liu In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 24 Apr 2008 12:46:56 -0400 References: <00ff01c8a4d1$de3fc360$c2f0200a@cisco.com> <59B578CA-F107-4AD1-8D13-39AC30A83EEB@magma.ca> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: behave@ietf.org, 'Dan Wing' Subject: Re: [BEHAVE] Channel Number X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I believe it is already there, and you likely just missed it in your reading. Specifically, the third paragraph in section 10 of TURN-07 reads: Channel bindings are specific to an allocation, so that a binding in one allocation has no relationship to a binding in any other allocation. If an allocation expires, all its channel bindings expire with it. (A similar paragraph appears in the section on Permissions.) But if you saw this paragraph but thought it meant something else, then please let me know. - Philip On Thu, 24-Apr-08, at 12:01 , Feng Liu wrote: > Philip, > > I was confused by the spec, and the explanations from you and Dan > are much > clearer for an outsider. Do you think it is a good idea to add it > into the > draft? > > Thanks, > > Feng > > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Wednesday, April 23, 2008 10:10 PM > To: Feng Liu > Cc: 'Dan Wing'; behave@ietf.org > Subject: Re: [BEHAVE] Channel Number > > To be more precise, channel numbers are local to an allocation, and > the allocation is uniquely identified by the 5-tuple (client IP > address, client port, server IP address, server port, transport > protocol). Channel numbers, permissions, etc etc in two different > allocations have nothing to do with each other. > > - Philip > > On Wed, 23-Apr-08, at 11:58 , Feng Liu wrote: >> Thank you for clarifying it! >> >> Feng >> >> >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com] >> Sent: Tuesday, April 22, 2008 7:38 PM >> To: 'Feng Liu'; behave@ietf.org >> Subject: RE: [BEHAVE] Channel Number >> >>> -----Original Message----- >>> From: behave-bounces@ietf.org >>> [mailto:behave-bounces@ietf.org] On Behalf Of Feng Liu >>> Sent: Tuesday, April 22, 2008 3:17 PM >>> To: behave@ietf.org >>> Subject: [BEHAVE] Channel Number >>> >>> Dear BEHAVE experts, >>> >>> >>> >>> I have two questions regarding Channel Number in TURN, and >>> would like to get your advice. >>> >>> >>> >>> Assume I have two TURN clients, and each wants to bind a >>> channel to its peer. When TURN clients choose Channel >>> Numbers, it is likely that they pick the same Channel Number >>> (e.g., both clients are from the same vendor and have the >>> same initial value and number selection algorithm). >>> >>> >>> >>> My question is: what is the behavior of the server in this >>> case? Will the server accept one binding request and reject >>> the other? Or it accepts both as two channel bindings are >>> independent of each other? >> >> They are independent of each other because they are over >> different TURN clients (different source IP address+port). The >> channel number is not unique for the entire TURN server; rather, >> the channel number is unique for every TURN session with that >> TURN server. >> >> -d >> >>> >>> If the server accepts one and rejects another, according to >>> the spec, one client will get a "bad request" response. My >>> second question is: how can the client know the rejection is >>> because the number is taken, as the server can reject the >>> request for different reasons? >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Feng >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Feng Liu, Ph.D. | Research Scientist, Dialogue System >>> Research Group | Avaya Labs Research | Avaya | 233 Mt. Airy >>> Road| Rm. 2D36 | Basking Ridge, NJ 07920 | Voice/Fax: >>> 908-696-5156 / 908-696-5401 | fliu1@avaya.com >>> >>> >>> >>> >>> >>> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 10:31:26 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E7D03A68B7; Thu, 24 Apr 2008 10:31:26 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D76763A68AA for ; Thu, 24 Apr 2008 10:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0pCds4l7RXT for ; Thu, 24 Apr 2008 10:31:23 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8E6BB3A6AC0 for ; Thu, 24 Apr 2008 10:31:23 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8AD71201E7 for ; Thu, 24 Apr 2008 19:31:27 +0200 (CEST) X-AuditID: c1b4fb3e-af99bbb000004ec0-d9-4810c3ef1c47 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 74E4120147 for ; Thu, 24 Apr 2008 19:31:27 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 19:31:27 +0200 Received: from [127.0.0.1] ([153.88.44.122]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 19:31:27 +0200 Message-ID: <4810C3ED.7030901@ericsson.com> Date: Thu, 24 Apr 2008 19:31:25 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Behave WG X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 24 Apr 2008 17:31:27.0099 (UTC) FILETIME=[06659CB0:01C8A631] X-Brightmail-Tracker: AAAAAA== Subject: [BEHAVE] Consensus call on Adding "Client" attribute to STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org This is a one week+ consensus call (until the 5th of May) if the WG = thinks that STUN (draft-ietf-behave-rfc3489bis) shall be extended with = an additional attribute "Client" before publication. With the general description along the lines of: X.Y CLIENT The client attribute contains a textual description of the software being used by the client, including manufacturer and version number. The attribute has no impact on operation of the protocol, and serves only as a tool for diagnostic and debugging purposes. The value of CLIENT is variable length. It MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 763 bytes). And some Security Considerations on the risk for targeted attacks = against clients with this information. Plus other text needed to bring = it in consistently The text is open for wordsmithing by the editors of the STUN spec. Please indicate your position on adding this or not. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 10:43:35 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7E83A6AC2; Thu, 24 Apr 2008 10:43:35 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0A43A67A7 for ; Thu, 24 Apr 2008 10:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XoIKuM+Esjd for ; Thu, 24 Apr 2008 10:43:27 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 2F8EE3A6A94 for ; Thu, 24 Apr 2008 10:43:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,704,1199682000"; d="scan'208";a="121030624" Received: from unknown (HELO delia.research.avayalabs.com) ([135.10.40.26]) by co300216-co-outbound.avaya.com with ESMTP; 24 Apr 2008 13:43:32 -0400 Received: from fliu1dell (fliu1-dell.woods.avayalabs.com [135.10.42.52]) by delia.research.avayalabs.com (8.14.2+Sun/8.14.2) with ESMTP id m3OHhUax015904; Thu, 24 Apr 2008 13:43:30 -0400 (EDT) From: "Feng Liu" To: "'Philip Matthews'" References: <00ff01c8a4d1$de3fc360$c2f0200a@cisco.com> <59B578CA-F107-4AD1-8D13-39AC30A83EEB@magma.ca> Date: Thu, 24 Apr 2008 13:43:30 -0400 Organization: Avaya Labs Research, Avaya Inc. Message-ID: <357AA3E385AF45D49C81CD93006C9557@woods.avayalabs.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.3790.4133 thread-index: AcimKtCulLXBmFKRSbKhu+5XL74gaQAB6FMQ Cc: behave@ietf.org, 'Dan Wing' Subject: Re: [BEHAVE] Channel Number X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Yes, I did see the paragraph, and that's where I got confused and asked for clarification. Feng -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca] Sent: Thursday, April 24, 2008 12:47 PM To: Feng Liu Cc: 'Dan Wing'; behave@ietf.org Subject: Re: [BEHAVE] Channel Number I believe it is already there, and you likely just missed it in your reading. Specifically, the third paragraph in section 10 of TURN-07 reads: Channel bindings are specific to an allocation, so that a binding in one allocation has no relationship to a binding in any other allocation. If an allocation expires, all its channel bindings expire with it. (A similar paragraph appears in the section on Permissions.) But if you saw this paragraph but thought it meant something else, then please let me know. - Philip On Thu, 24-Apr-08, at 12:01 , Feng Liu wrote: > Philip, > > I was confused by the spec, and the explanations from you and Dan > are much > clearer for an outsider. Do you think it is a good idea to add it > into the > draft? > > Thanks, > > Feng > > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Wednesday, April 23, 2008 10:10 PM > To: Feng Liu > Cc: 'Dan Wing'; behave@ietf.org > Subject: Re: [BEHAVE] Channel Number > > To be more precise, channel numbers are local to an allocation, and > the allocation is uniquely identified by the 5-tuple (client IP > address, client port, server IP address, server port, transport > protocol). Channel numbers, permissions, etc etc in two different > allocations have nothing to do with each other. > > - Philip > > On Wed, 23-Apr-08, at 11:58 , Feng Liu wrote: >> Thank you for clarifying it! >> >> Feng >> >> >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com] >> Sent: Tuesday, April 22, 2008 7:38 PM >> To: 'Feng Liu'; behave@ietf.org >> Subject: RE: [BEHAVE] Channel Number >> >>> -----Original Message----- >>> From: behave-bounces@ietf.org >>> [mailto:behave-bounces@ietf.org] On Behalf Of Feng Liu >>> Sent: Tuesday, April 22, 2008 3:17 PM >>> To: behave@ietf.org >>> Subject: [BEHAVE] Channel Number >>> >>> Dear BEHAVE experts, >>> >>> >>> >>> I have two questions regarding Channel Number in TURN, and >>> would like to get your advice. >>> >>> >>> >>> Assume I have two TURN clients, and each wants to bind a >>> channel to its peer. When TURN clients choose Channel >>> Numbers, it is likely that they pick the same Channel Number >>> (e.g., both clients are from the same vendor and have the >>> same initial value and number selection algorithm). >>> >>> >>> >>> My question is: what is the behavior of the server in this >>> case? Will the server accept one binding request and reject >>> the other? Or it accepts both as two channel bindings are >>> independent of each other? >> >> They are independent of each other because they are over >> different TURN clients (different source IP address+port). The >> channel number is not unique for the entire TURN server; rather, >> the channel number is unique for every TURN session with that >> TURN server. >> >> -d >> >>> >>> If the server accepts one and rejects another, according to >>> the spec, one client will get a "bad request" response. My >>> second question is: how can the client know the rejection is >>> because the number is taken, as the server can reject the >>> request for different reasons? >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Feng >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Feng Liu, Ph.D. | Research Scientist, Dialogue System >>> Research Group | Avaya Labs Research | Avaya | 233 Mt. Airy >>> Road| Rm. 2D36 | Basking Ridge, NJ 07920 | Voice/Fax: >>> 908-696-5156 / 908-696-5401 | fliu1@avaya.com >>> >>> >>> >>> >>> >>> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 11:56:50 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57C928C2C7; Thu, 24 Apr 2008 11:56:50 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FDA03A6BF2 for ; Thu, 24 Apr 2008 11:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4daMdB78a-kP for ; Thu, 24 Apr 2008 11:56:48 -0700 (PDT) Received: from mail-09.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id E90323A6AE4 for ; Thu, 24 Apr 2008 11:56:22 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Jp6cN-00089Z-2E; Thu, 24 Apr 2008 14:56:28 -0400 Message-Id: <66AD7A02-369D-4343-B144-CE73BDF44B0E@magma.ca> From: Philip Matthews To: Simon Perreault In-Reply-To: <200804240923.16507.simon.perreault@viagenie.ca> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 24 Apr 2008 14:56:24 -0400 References: <200804240923.16507.simon.perreault@viagenie.ca> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: behave@ietf.org Subject: Re: [BEHAVE] Error code for unsupported method X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Thu, 24-Apr-08, at 09:23 , Simon Perreault wrote: > Hello, > > What is a STUN server supposed to use as error code when an unknown > method is > received? From the list in 3489bis, Section 15.6, I'd be tempted to > pick > either 400 or 500, depending on who I'm siding with, but this > doesn't seem > right because it's really nobody's fault. > > Will people crucify me if I return a 501 Not Implemented, as in HTTP? Section 7.3 of draft-ietf-behave-rfc3489bis-15 says (second paragraph): When a STUN agent receives a STUN message, it first checks that the message obeys the rules of Section 6. It checks that the first two bits are 0, that the magic cookie field has the correct value, that the message length is sensible, and that the method value is a supported method. If the message-class is Success Response or Error Response, the agent checks that the transaction ID matches a transaction that is still in progress. If the FINGERPRINT extension is being used, the agent checks that the FINGERPRINT attribute is present and contains the correct value. If any errors are detected, the message is silently discarded. In the case when STUN is being multiplexed with another protocol, an error may indicate that this is not really a STUN message; in this case, the agent should try to parse the message as a different protocol. Thus an implementation should silently discard an unsupported method. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 11:56:51 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 111643A6CC1; Thu, 24 Apr 2008 11:56:51 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FABF3A68F8 for ; Thu, 24 Apr 2008 11:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDww-uTW0tvW for ; Thu, 24 Apr 2008 11:56:48 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id CC10E28C2E3 for ; Thu, 24 Apr 2008 11:56:42 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id DE8CA5081A; Thu, 24 Apr 2008 12:00:17 -0700 (PDT) Date: Thu, 24 Apr 2008 12:00:17 -0700 From: Eric Rescorla To: Philip Matthews In-Reply-To: References: <00ff01c8a4d1$de3fc360$c2f0200a@cisco.com> <59B578CA-F107-4AD1-8D13-39AC30A83EEB@magma.ca> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080424190017.DE8CA5081A@romeo.rtfm.com> Cc: behave@ietf.org, 'Dan Wing' Subject: Re: [BEHAVE] Channel Number X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Thu, 24 Apr 2008 12:46:56 -0400, Philip Matthews wrote: > > I believe it is already there, and you likely just missed it in your > reading. Specifically, the third paragraph in section 10 of TURN-07 > reads: > > Channel bindings are specific to an allocation, so that a binding in > one allocation has no relationship to a binding in any other > allocation. If an allocation expires, all its channel bindings > expire with it. > > (A similar paragraph appears in the section on Permissions.) > > But if you saw this paragraph but thought it meant something else, > then please let me know. I just realized we're going to be sorry about using the word "channel binding" since this already has an established meaning in the SASL half of the security community... -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 12:07:49 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5EE428C2C7; Thu, 24 Apr 2008 12:07:48 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3E63A6D16 for ; Thu, 24 Apr 2008 12:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUNNSl9SVyg3 for ; Thu, 24 Apr 2008 12:07:32 -0700 (PDT) Received: from mail-09.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id A42B028C31C for ; Thu, 24 Apr 2008 12:06:22 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Jp6m3-0006xh-1C; Thu, 24 Apr 2008 15:06:27 -0400 Message-Id: <26053FFC-8683-47BB-BC66-25B51B66D3BB@magma.ca> From: Philip Matthews To: Simon Perreault , Benny Prijono In-Reply-To: <200804240957.02395.simon.perreault@viagenie.ca> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 24 Apr 2008 15:06:23 -0400 References: <200804231710.28415.simon.perreault@viagenie.ca> <1879720d0804240649u4163d096rb9ce494ffa2fb80b@mail.gmail.com> <200804240957.02395.simon.perreault@viagenie.ca> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: behave@ietf.org Subject: Re: [BEHAVE] Duplicate request handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Thu, 24-Apr-08, at 09:57 , Simon Perreault wrote: > Hi Benny, > > On Thursday 24 April 2008 09:49:20 Benny Prijono wrote: >> From my understanding, it doesn't have to be like that. Server may >> just retransmit the same failure response for the same request >> retransmission if it wants to. In fact I think server should do this >> especially for non-idempotent requests, otherwise we may end up with >> different state between the client and the server. For example, >> imagine when TURN server first returns failure response, then >> successful response on the second Allocate retransmission. Client >> most >> likely will ignore the second response retransmission, hence client >> thinks that the Allocate has failed while the server thinks it has >> been successful. > > I think you're right and that the spec should be changed. Any kind > of response > (success or error) for any kind of request (indempotent or not) > should be > remembered and retransmitted when a duplicate request is detected. > This is > transport-level stuff which doesn't have to be concerned about > application-level stuff. I agree. We had implicitly assumed that it was ok to report different failure codes or succeed after reporting failure, but Benny's example shows this is not true. Note that the request MUST have the same transaction id. If it has a different transaction id, then it is a different transaction (and thus not a resent) and the behavior can be different. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 13:17:16 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 713163A6913; Thu, 24 Apr 2008 13:17:16 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76B13A6913 for ; Thu, 24 Apr 2008 13:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxihG-vbbwUQ for ; Thu, 24 Apr 2008 13:17:13 -0700 (PDT) Received: from mail-02.primus.ca (mail4.primus.ca [216.254.141.171]) by core3.amsl.com (Postfix) with ESMTP id D931A3A65A5 for ; Thu, 24 Apr 2008 13:17:12 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Jp7sb-0000ew-0V; Thu, 24 Apr 2008 16:17:17 -0400 Message-Id: <63DF6CD6-9865-4721-A5A8-83816D3F7918@magma.ca> From: Philip Matthews To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , Marc Petit-Huguenin In-Reply-To: <200804030732.23763.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 24 Apr 2008 16:17:13 -0400 References: <47F3FA30.2060403@acm.org> <200804030732.23763.remi.denis-courmont@nokia.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: behave@ietf.org Subject: Re: [BEHAVE] IPv4/IPv6 relayed address allocation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Thu, 3-Apr-08, at 00:32 , R=E9mi Denis-Courmont wrote: > Le Thursday 03 April 2008 00:27:12 ext Marc Petit-Huguenin, vous = > avez =E9crit : >> I think that I found a contradiction between turn-07 and turn- = >> ipv6-04: >> >> In turn-07 section 6.2, "When allocating a relayed transport = >> address for >> the allocation, the server MUST allocate an IP address of the same >> family (e.g, IPv4 vs. IPv6) as the server's transport address." >> >> In turn-ipv6 section 5.1, "If the REQUESTED-ADDRESS-TYPE attribute is >> absent, the server MUST allocate a IPv4 transport address to the TURN >> client." >> >> My understanding before trying to implement turn-07 was that TURN >> without turn-ipv6 always allocates an IPv4 relayed transport = >> address - >> in other words that a REQUESTED-ADDRESS-TYPE with a family value = >> equals >> to 0x01 is equivalent to no REQUESTED-ADDRESS-TYPE. >> >> Who's right? > > IMHO, I think TURN-07 is wrong and TURN-IPv6 is right. > > The relay cannot know if there was a protocol translator in the = > middle, so > that would be the only way to obtain sane defaults. > > So either the client must always explicitly specify the address = > family, or the > default should be independent of the relay-reflexive address of the = > client. Sorry to be slow in replying here. I would really prefer to stick with the current turn-07 proposal and = fix turn-ipv6 to match. If we went with the turn0-ipv6 proposal, then the base TURN = specification would have to specify how to relay between IPv6 and = IPv4. This would happen if the server's transport address was IPv6, = since the base specification would always allocate a v4 relayed- = transport-address. In particular, the base spec would have to go into = the details of how to translate the IP headers when doing "fully- = compliant relaying" (as described at the last meeting in Philly). This = I would really like to avoid. So instead, a TURN client much check the address family of the relayed- = transport-address it gets back, just like it much check the address = family of the mapped-address (these two families will always be the = same under the current base spec proposal). If the client cannot = handle this family, then it must delete the allocation. If the WG feels this is not acceptable, then I will propose that we = remove all handling of IPv6 from the base spec, and let draft-ietf- = behave-turn-ipv6 cover these cases. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 14:43:25 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6291928C2EC; Thu, 24 Apr 2008 14:43:25 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BD7B28C2EC for ; Thu, 24 Apr 2008 14:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvpDC64LQPlZ for ; Thu, 24 Apr 2008 14:43:22 -0700 (PDT) Received: from submit01.sysedata.no (submit01.sysedata.no [195.159.29.244]) by core3.amsl.com (Postfix) with ESMTP id 9F27D28C2AF for ; Thu, 24 Apr 2008 14:43:22 -0700 (PDT) Received: from [84.215.90.246] (helo=[10.0.0.4]) by submit01.sysedata.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.62) (envelope-from ) id 1Jp9Dw-0003jj-1L; Thu, 24 Apr 2008 23:43:24 +0200 Message-ID: <4810FEFB.3000703@db.org> Date: Thu, 24 Apr 2008 23:43:23 +0200 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.14pre (X11/20080304) MIME-Version: 1.0 To: Magnus Westerlund References: <4810C3ED.7030901@ericsson.com> In-Reply-To: <4810C3ED.7030901@ericsson.com> X-Whitelisted: X-Whitelisted: Cc: Behave WG Subject: Re: [BEHAVE] Consensus call on Adding "Client" attribute to STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi I support adding the CLIENT attribute. /alfred Magnus Westerlund wrote: > This is a one week+ consensus call (until the 5th of May) if the WG = > thinks that STUN (draft-ietf-behave-rfc3489bis) shall be extended with = > an additional attribute "Client" before publication. > = > With the general description along the lines of: > = > X.Y CLIENT > = > The client attribute contains a textual description of the software > being used by the client, including manufacturer and version number. > The attribute has no impact on operation of the protocol, and serves > only as a tool for diagnostic and debugging purposes. The value of > CLIENT is variable length. It MUST be a UTF-8 [RFC3629] encoded > sequence of less than 128 characters (which can be as long as 763 > bytes). > = > And some Security Considerations on the risk for targeted attacks = > against clients with this information. Plus other text needed to bring = > it in consistently > = > The text is open for wordsmithing by the editors of the STUN spec. > = > Please indicate your position on adding this or not. > = > Cheers > = > Magnus Westerlund > = > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > F=E4r=F6gatan 6 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > = > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 14:49:35 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F7328C31A; Thu, 24 Apr 2008 14:49:35 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CC2228C314 for ; Thu, 24 Apr 2008 14:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ITOE2qgFoZ9 for ; Thu, 24 Apr 2008 14:49:33 -0700 (PDT) Received: from mail.sipeerior.com (mail.sipeerior.com [128.239.5.131]) by core3.amsl.com (Postfix) with ESMTP id 6EDA828C2E3 for ; Thu, 24 Apr 2008 14:49:33 -0700 (PDT) Received: from [128.239.5.171] (unknown [128.239.5.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sipeerior.com (Postfix) with ESMTP id 125AC505903; Thu, 24 Apr 2008 17:49:38 -0400 (EDT) In-Reply-To: <200804240957.02395.simon.perreault@viagenie.ca> References: <200804231710.28415.simon.perreault@viagenie.ca> <1879720d0804240649u4163d096rb9ce494ffa2fb80b@mail.gmail.com> <200804240957.02395.simon.perreault@viagenie.ca> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Bruce Lowekamp Date: Thu, 24 Apr 2008 17:49:36 -0400 To: Simon Perreault X-Mailer: Apple Mail (2.753) Cc: behave@ietf.org Subject: Re: [BEHAVE] Duplicate request handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Apr 24, 2008, at 9:57 AM, Simon Perreault wrote: > Hi Benny, > > On Thursday 24 April 2008 09:49:20 Benny Prijono wrote: >> From my understanding, it doesn't have to be like that. Server may >> just retransmit the same failure response for the same request >> retransmission if it wants to. In fact I think server should do this >> especially for non-idempotent requests, otherwise we may end up with >> different state between the client and the server. For example, >> imagine when TURN server first returns failure response, then >> successful response on the second Allocate retransmission. Client >> most >> likely will ignore the second response retransmission, hence client >> thinks that the Allocate has failed while the server thinks it has >> been successful. > > I think you're right and that the spec should be changed. Any kind > of response > (success or error) for any kind of request (indempotent or not) > should be > remembered and retransmitted when a duplicate request is detected. > This is > transport-level stuff which doesn't have to be concerned about > application-level stuff. > I think this is really imposing a lot of state on a stun server to solve a problem that's already solved by what's in the text. A TURN allocate is not idempotent. You have to remember the response per transaction id. That's already covered by 7.3.1. To impose that requirement for all STUN transactions essentially prevents a high-throughput stun server (for binding requests) from being deployed. If all it's doing is binding requests, the entire server really is very minimal and requires little state. 13 says that a basic STUN server SHOULD NOT use authentication, which is also there to minimize the state required for a pure STUN server. The resulting service can be very high throughput with minimalistic resources. If it has to cache every response it's issued over the last 40 seconds, that's a huge data structure that serves no useful purpose as far as I can tell. Bruce _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 15:26:53 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A95843A6C87; Thu, 24 Apr 2008 15:26:53 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F74128C184 for ; Thu, 24 Apr 2008 15:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[AWL=1.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5f3kDL-ZxMO for ; Thu, 24 Apr 2008 15:26:48 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 5BA3D3A6D75 for ; Thu, 24 Apr 2008 15:26:30 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 7249129E148C; Thu, 24 Apr 2008 18:26:05 -0400 (EDT) Received: from [192.168.1.102] (ip216-239-86-3.vif.net [216.239.86.3]) by jazz.viagenie.ca (Postfix) with ESMTP id 5AA0E29E1433 for ; Thu, 24 Apr 2008 18:26:05 -0400 (EDT) From: Simon Perreault Organization: =?utf-8?q?Viag=C3=A9nie?= To: behave@ietf.org Date: Thu, 24 Apr 2008 18:26:04 -0400 User-Agent: KMail/1.9.9 References: <200804231710.28415.simon.perreault@viagenie.ca> <200804240957.02395.simon.perreault@viagenie.ca> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804241826.04447.simon.perreault@viagenie.ca> Subject: Re: [BEHAVE] Duplicate request handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Thursday 24 April 2008 17:49:36 Bruce Lowekamp wrote: > To impose that requirement for all STUN transactions essentially > prevents a high-throughput stun server (for binding requests) from > being deployed. If all it's doing is binding requests, the entire > server really is very minimal and requires little state. 13 says > that a basic STUN server SHOULD NOT use authentication, which is also > there to minimize the state required for a pure STUN server. The > resulting service can be very high throughput with minimalistic > resources. If it has to cache every response it's issued over the > last 40 seconds, that's a huge data structure that serves no useful > purpose as far as I can tell. No. A response to a Binding request doesn't depend on any state. So you don't have to remember all past responses. What I meant was that a response, success or not, indempotent or not, should be the same for a given transaction ID during the 40 seconds following the initial reception. As is already mentioned in the draft, you can store the past responses or you can generate a new response from scratch if it generates the same response. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 15:36:37 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D7D3A68D3; Thu, 24 Apr 2008 15:36:37 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B093A67EF for ; Thu, 24 Apr 2008 15:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jArKcBaQ9Mhw for ; Thu, 24 Apr 2008 15:36:35 -0700 (PDT) Received: from mail.sipeerior.com (mail.sipeerior.com [128.239.5.131]) by core3.amsl.com (Postfix) with ESMTP id E47E93A67E6 for ; Thu, 24 Apr 2008 15:36:34 -0700 (PDT) Received: from [128.239.5.171] (unknown [128.239.5.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sipeerior.com (Postfix) with ESMTP id E974F505903; Thu, 24 Apr 2008 18:36:39 -0400 (EDT) In-Reply-To: <200804241826.04447.simon.perreault@viagenie.ca> References: <200804231710.28415.simon.perreault@viagenie.ca> <200804240957.02395.simon.perreault@viagenie.ca> <200804241826.04447.simon.perreault@viagenie.ca> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <2BEB591C-867F-4E2A-A4B3-0944F5739497@sipeerior.com> From: Bruce Lowekamp Date: Thu, 24 Apr 2008 18:36:38 -0400 To: Simon Perreault X-Mailer: Apple Mail (2.753) Cc: behave@ietf.org Subject: Re: [BEHAVE] Duplicate request handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Apr 24, 2008, at 6:26 PM, Simon Perreault wrote: > On Thursday 24 April 2008 17:49:36 Bruce Lowekamp wrote: >> To impose that requirement for all STUN transactions essentially >> prevents a high-throughput stun server (for binding requests) from >> being deployed. If all it's doing is binding requests, the entire >> server really is very minimal and requires little state. 13 says >> that a basic STUN server SHOULD NOT use authentication, which is also >> there to minimize the state required for a pure STUN server. The >> resulting service can be very high throughput with minimalistic >> resources. If it has to cache every response it's issued over the >> last 40 seconds, that's a huge data structure that serves no useful >> purpose as far as I can tell. > > No. A response to a Binding request doesn't depend on any state. So > you don't > have to remember all past responses. > > What I meant was that a response, success or not, indempotent or > not, should > be the same for a given transaction ID during the 40 seconds > following the > initial reception. As is already mentioned in the draft, you can > store the > past responses or you can generate a new response from scratch if it > generates the same response. OK, great. Then we agree. When your previous message said "any response should be remembered" and that it was a transport-level issue and not application, I had the other impression. Bruce _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 15:43:34 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E0233A6B08; Thu, 24 Apr 2008 15:43:34 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E348E3A6BA2 for ; Thu, 24 Apr 2008 15:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG+ymtxxLhNy for ; Thu, 24 Apr 2008 15:43:32 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 2CBDF3A6B08 for ; Thu, 24 Apr 2008 15:43:32 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 24 Apr 2008 15:43:37 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3OMhbD4030465; Thu, 24 Apr 2008 15:43:37 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3OMhbW8028265; Thu, 24 Apr 2008 22:43:37 GMT From: "Dan Wing" To: "'Simon Perreault'" , References: <200804231710.28415.simon.perreault@viagenie.ca><200804240957.02395.simon.perreault@viagenie.ca> <200804241826.04447.simon.perreault@viagenie.ca> Date: Thu, 24 Apr 2008 15:43:36 -0700 Message-ID: <09bb01c8a65c$a28ab320$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <200804241826.04447.simon.perreault@viagenie.ca> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcimWlVki8WDd1ZISLmo2Fweyj88nQAAaVNA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2347; t=1209077017; x=1209941017; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Duplicate=20request=20handli ng |Sender:=20; bh=OZk22oeymh0sjrCmBKoRmzbAiygbp6x3z9Hd1lf1NyU=; b=mNG5i2gnUrC189H/gpAkQGpgH2hCvZ5pba5JpjEruDKRngq8awq6zyE5gb Vnq/y7jojvoNxLhX9Cg1yRJzGhTRAHaJMm8kJFYsFZHjfEYZM+IdAW+EftPY UuKrhSX+xC; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [BEHAVE] Duplicate request handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > On Thursday 24 April 2008 17:49:36 Bruce Lowekamp wrote: > > To impose that requirement for all STUN transactions essentially > > prevents a high-throughput stun server (for binding requests) from > > being deployed. If all it's doing is binding requests, the entire > > server really is very minimal and requires little state. 13 says > > that a basic STUN server SHOULD NOT use authentication, > > which is also > > there to minimize the state required for a pure STUN server. The > > resulting service can be very high throughput with minimalistic > > resources. If it has to cache every response it's issued over the > > last 40 seconds, that's a huge data structure that serves no useful > > purpose as far as I can tell. > > No. A response to a Binding request doesn't depend on any > state. So you don't > have to remember all past responses. > > What I meant was that a response, success or not, indempotent > or not, should > be the same for a given transaction ID during the 40 seconds > following the > initial reception. As is already mentioned in the draft, you > can store the > past responses or you can generate a new response from scratch if it > generates the same response. Let me throw a wrench into this discussion... Considering the current text in rfc3489bis, imagine the following occurs: 1. STUN client sends a STUN request, which traverses a NAT and arrives at STUN server, and STUN server generates a response. 2. The NAT in front of the STUN client crashes before the response is received. 3. The NAT in front of the STUN client reboots 5 seconds later and becomes operational. 4. The STUN client's NNth retransmission is sent, which gets a different mapping than (1). Per the text in rfc3489bis, because the transaction-id is the same, the reponse is supposed to be the same. But in the case above, we wouldn't want that, would we?? (If you don't like "NAT crashes", or you feel a NAT cannot boot back up in 5 seconds then consider a slightly different case: the home network is multi-homed (two NATs to two different ISPs), and one of the NATs dies (or one ISP dies) and the other NAT begins routing traffic from the STUN client towards the Internet. This would cause the same situation as above.) -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 15:52:41 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752B93A6946; Thu, 24 Apr 2008 15:52:41 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56C053A6946 for ; Thu, 24 Apr 2008 15:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UD65h6T0eIAW for ; Thu, 24 Apr 2008 15:52:39 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 69D033A67EF for ; Thu, 24 Apr 2008 15:52:39 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 65A6E29E1498; Thu, 24 Apr 2008 18:52:14 -0400 (EDT) Received: from [192.168.1.102] (ip216-239-86-3.vif.net [216.239.86.3]) by jazz.viagenie.ca (Postfix) with ESMTP id 4E65229E1433 for ; Thu, 24 Apr 2008 18:52:14 -0400 (EDT) From: Simon Perreault Organization: =?utf-8?q?Viag=C3=A9nie?= To: behave@ietf.org Date: Thu, 24 Apr 2008 18:52:13 -0400 User-Agent: KMail/1.9.9 References: <200804231710.28415.simon.perreault@viagenie.ca> <200804241826.04447.simon.perreault@viagenie.ca> <09bb01c8a65c$a28ab320$c2f0200a@cisco.com> In-Reply-To: <09bb01c8a65c$a28ab320$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804241852.13723.simon.perreault@viagenie.ca> Subject: Re: [BEHAVE] Duplicate request handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Thursday 24 April 2008 18:43:36 Dan Wing wrote: > Let me throw a wrench into this discussion... > > Considering the current text in rfc3489bis, imagine the following > occurs: > > 1. STUN client sends a STUN request, which traverses a NAT and > arrives at STUN server, and STUN server generates a response. > 2. The NAT in front of the STUN client crashes before the response > is received. > 3. The NAT in front of the STUN client reboots 5 seconds later and > becomes operational. > 4. The STUN client's NNth retransmission is sent, which gets a > different mapping than (1). > > Per the text in rfc3489bis, because the transaction-id is the same, > the reponse is supposed to be the same. > > But in the case above, we wouldn't want that, would we?? Yes it should be the same. That's what we want. Just consider it like a retransmission, as if we were operating over TCP. The client will know its new mapped address when it issues a new Binding request, with a new transaction ID. Exactly the same as the case when the NAT crashes and reboots after the response was received correctly. There's a certain amount of time during which the client will have a wrong mapped address and the RTP (or whatever else) will get lost and everyone will wonder why and then we'll curse at NATs and we'll all migrate to IPv6 and they lived happily ever after. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 15:54:01 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB37C3A6C2F; Thu, 24 Apr 2008 15:54:01 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EED963A6C2F for ; Thu, 24 Apr 2008 15:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCW8dmVHVldd for ; Thu, 24 Apr 2008 15:53:59 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3E98B3A67EF for ; Thu, 24 Apr 2008 15:53:59 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 56D805081A; Thu, 24 Apr 2008 15:57:34 -0700 (PDT) Date: Thu, 24 Apr 2008 15:57:34 -0700 From: Eric Rescorla To: Philip Matthews In-Reply-To: <66AD7A02-369D-4343-B144-CE73BDF44B0E@magma.ca> References: <200804240923.16507.simon.perreault@viagenie.ca> <66AD7A02-369D-4343-B144-CE73BDF44B0E@magma.ca> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080424225734.56D805081A@romeo.rtfm.com> Cc: behave@ietf.org Subject: Re: [BEHAVE] Error code for unsupported method X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Thu, 24 Apr 2008 14:56:24 -0400, Philip Matthews wrote: At Thu, 24 Apr 2008 14:56:24 -0400, Philip Matthews wrote: > > > On Thu, 24-Apr-08, at 09:23 , Simon Perreault wrote: > > Hello, > > > > What is a STUN server supposed to use as error code when an unknown > > method is > > received? From the list in 3489bis, Section 15.6, I'd be tempted to > > pick > > either 400 or 500, depending on who I'm siding with, but this > > doesn't seem > > right because it's really nobody's fault. > > > > Will people crucify me if I return a 501 Not Implemented, as in HTTP? > > > Section 7.3 of draft-ietf-behave-rfc3489bis-15 says (second paragraph): > > When a STUN agent receives a STUN message, it first checks that the > message obeys the rules of Section 6. It checks that the first two > bits are 0, that the magic cookie field has the correct value, that > the message length is sensible, and that the method value is a > supported method. If the message-class is Success Response or Error > Response, the agent checks that the transaction ID matches a > transaction that is still in progress. If the FINGERPRINT extension > is being used, the agent checks that the FINGERPRINT attribute is > present and contains the correct value. If any errors are detected, > the message is silently discarded. In the case when STUN is being > multiplexed with another protocol, an error may indicate that this > is > not really a STUN message; in this case, the agent should try to > parse the message as a different protocol. > > Thus an implementation should silently discard an unsupported method. Wow. I totally never noticed this. So, I get the reasoning for silent discards for cases where we're not sure that this is STUN or not, but if everything but the method looks right, wouldn't it make more sense to send an error? -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 16:01:51 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1760028C1A7; Thu, 24 Apr 2008 16:01:51 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43FA33A6946 for ; Thu, 24 Apr 2008 16:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEeZPeeCNOAe for ; Thu, 24 Apr 2008 16:01:49 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 1587F28C1BB for ; Thu, 24 Apr 2008 16:01:06 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 2A92C29E1498; Thu, 24 Apr 2008 19:00:41 -0400 (EDT) Received: from [192.168.1.102] (ip216-239-86-3.vif.net [216.239.86.3]) by jazz.viagenie.ca (Postfix) with ESMTP id 1016929E1433 for ; Thu, 24 Apr 2008 19:00:41 -0400 (EDT) From: Simon Perreault To: behave@ietf.org Date: Thu, 24 Apr 2008 19:00:40 -0400 User-Agent: KMail/1.9.9 References: <200804231710.28415.simon.perreault@viagenie.ca> <09bb01c8a65c$a28ab320$c2f0200a@cisco.com> <200804241852.13723.simon.perreault@viagenie.ca> In-Reply-To: <200804241852.13723.simon.perreault@viagenie.ca> Organization: =?iso-8859-1?q?Viag=E9nie?= MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804241900.40484.simon.perreault@viagenie.ca> Subject: Re: [BEHAVE] Duplicate request handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Thursday 24 April 2008 18:52:13 Simon Perreault wrote: > On Thursday 24 April 2008 18:43:36 Dan Wing wrote: > > Let me throw a wrench into this discussion... > > > > Considering the current text in rfc3489bis, imagine the following > > occurs: > > > > 1. STUN client sends a STUN request, which traverses a NAT and > > arrives at STUN server, and STUN server generates a response. > > 2. The NAT in front of the STUN client crashes before the response > > is received. > > 3. The NAT in front of the STUN client reboots 5 seconds later and > > becomes operational. > > 4. The STUN client's NNth retransmission is sent, which gets a > > different mapping than (1). > > > > Per the text in rfc3489bis, because the transaction-id is the same, > > the reponse is supposed to be the same. > > > > But in the case above, we wouldn't want that, would we?? > > Yes it should be the same. That's what we want. Just consider it like a > retransmission, as if we were operating over TCP. Precision because I wasn't making a lot of sense: It might appear in this case that the stateless server is better because it reacts faster to changes in the network. But then it introduces the potential to confuse the client when it receives multiple responses to the same request containing different content. So it might appear that you *do* need to remember all previous responses. But that would be a stupid thing to do from an implementor's point of view for the case of a Binding-only STUN server. So just generate a new response, let the client be confused and sort it out (i.e. by using the first one received and throwing all other duplicate responses). So my only gripe with the current text is that it applies only to success responses. Remove the "success" part and be done with it. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 16:02:29 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B409B3A6946; Thu, 24 Apr 2008 16:02:29 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5367B3A6946 for ; Thu, 24 Apr 2008 16:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzOr3kDc5VHB for ; Thu, 24 Apr 2008 16:02:27 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 6E5803A67D8 for ; Thu, 24 Apr 2008 16:02:27 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 872F729E1498; Thu, 24 Apr 2008 19:02:02 -0400 (EDT) Received: from [192.168.1.102] (ip216-239-86-3.vif.net [216.239.86.3]) by jazz.viagenie.ca (Postfix) with ESMTP id 711BA29E1433 for ; Thu, 24 Apr 2008 19:02:02 -0400 (EDT) From: Simon Perreault Organization: =?utf-8?q?Viag=C3=A9nie?= To: behave@ietf.org Date: Thu, 24 Apr 2008 19:02:01 -0400 User-Agent: KMail/1.9.9 References: <200804240923.16507.simon.perreault@viagenie.ca> <66AD7A02-369D-4343-B144-CE73BDF44B0E@magma.ca> <20080424225734.56D805081A@romeo.rtfm.com> In-Reply-To: <20080424225734.56D805081A@romeo.rtfm.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804241902.01959.simon.perreault@viagenie.ca> Subject: Re: [BEHAVE] Error code for unsupported method X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Thursday 24 April 2008 18:57:34 Eric Rescorla wrote: > So, I get the reasoning for silent discards for cases where we're not > sure that this is STUN or not, but if everything but the method looks > right, wouldn't it make more sense to send an error? +1 _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Apr 24 19:48:49 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEAD63A6839; Thu, 24 Apr 2008 19:48:49 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3913A6965 for ; Thu, 24 Apr 2008 19:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2q1oHjqRPbP for ; Thu, 24 Apr 2008 19:48:45 -0700 (PDT) Received: from mail-07.primus.ca (mail4.primus.ca [216.254.141.171]) by core3.amsl.com (Postfix) with ESMTP id 3EAF13A6839 for ; Thu, 24 Apr 2008 19:48:45 -0700 (PDT) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JpDzR-0006Ha-0p; Thu, 24 Apr 2008 22:48:45 -0400 Message-Id: <027BEB3B-45C2-4A28-9CD2-D9E2523FBF7D@magma.ca> From: Philip Matthews To: Eric Rescorla In-Reply-To: <20080424225734.56D805081A@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 24 Apr 2008 22:48:46 -0400 References: <200804240923.16507.simon.perreault@viagenie.ca> <66AD7A02-369D-4343-B144-CE73BDF44B0E@magma.ca> <20080424225734.56D805081A@romeo.rtfm.com> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Cc: behave@ietf.org Subject: Re: [BEHAVE] Error code for unsupported method X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Thu, 24-Apr-08, at 18:57 , Eric Rescorla wrote: > At Thu, 24 Apr 2008 14:56:24 -0400, > Philip Matthews wrote: > At Thu, 24 Apr 2008 14:56:24 -0400, > Philip Matthews wrote: >> >> >> On Thu, 24-Apr-08, at 09:23 , Simon Perreault wrote: >>> Hello, >>> >>> What is a STUN server supposed to use as error code when an unknown >>> method is >>> received? From the list in 3489bis, Section 15.6, I'd be tempted to >>> pick >>> either 400 or 500, depending on who I'm siding with, but this >>> doesn't seem >>> right because it's really nobody's fault. >>> >>> Will people crucify me if I return a 501 Not Implemented, as in >>> HTTP? >> >> >> Section 7.3 of draft-ietf-behave-rfc3489bis-15 says (second >> paragraph): >> >> When a STUN agent receives a STUN message, it first checks that >> the >> message obeys the rules of Section 6. It checks that the first >> two >> bits are 0, that the magic cookie field has the correct value, >> that >> the message length is sensible, and that the method value is a >> supported method. If the message-class is Success Response or >> Error >> Response, the agent checks that the transaction ID matches a >> transaction that is still in progress. If the FINGERPRINT >> extension >> is being used, the agent checks that the FINGERPRINT attribute is >> present and contains the correct value. If any errors are >> detected, >> the message is silently discarded. In the case when STUN is being >> multiplexed with another protocol, an error may indicate that this >> is >> not really a STUN message; in this case, the agent should try to >> parse the message as a different protocol. >> >> Thus an implementation should silently discard an unsupported method. > > Wow. I totally never noticed this. > > So, I get the reasoning for silent discards for cases where we're not > sure that this is STUN or not, but if everything but the method looks > right, wouldn't it make more sense to send an error? Perhaps. It would certainly allow the client to more rapidly detect that the server doesn't support a particular method, since right now the client has to wait the 40 second timeout period to be certain. However, I vaguely remember thinking when I wrote the above text, that there were cases where a silent discard was desirable. Unfortunately, I cannot remember any right now. (And, when I wrote the text, the timeout period was 10 seconds, not 40...) - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 25 00:02:06 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECED63A6B96; Fri, 25 Apr 2008 00:02:04 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 366B33A6C2F; Fri, 25 Apr 2008 00:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B43zFSBPaUsy; Fri, 25 Apr 2008 00:02:00 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 625AC3A67F7; Fri, 25 Apr 2008 00:02:00 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3P74Ldh024159; Fri, 25 Apr 2008 02:04:35 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Apr 2008 10:02:02 +0300 Received: from esdhcp04185.research.nokia.com ([172.21.41.85]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Apr 2008 10:02:01 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia Devices R&D To: IETF AVT WG Date: Fri, 25 Apr 2008 10:03:07 +0300 User-Agent: KMail/1.9.9 References: <480F8629.8080202@rogers.com> In-Reply-To: <480F8629.8080202@rogers.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804251003.08041.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 25 Apr 2008 07:02:01.0729 (UTC) FILETIME=[42E53710:01C8A6A2] X-Nokia-AV: Clean Cc: MARJOU Xavier RD-MAPS-LAN , behave@ietf.org, ext Tom Taylor Subject: Re: [BEHAVE] Working Group Last Call: draft-ietf-avt-app-rtp-keepalive-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Wednesday 23 April 2008 21:55:37 ext Tom Taylor, vous avez =E9crit=A0: > This is to announce Working Group Last Call for > draft-ietf-avt-app-rtp-keepalive-03.txt. Assuming all goes well, the Last > Call period will end on May 7. I am fine with the document (especially, the conclusion). However, if I wan= t = to split hairs, I would argue that the 0-bytes packet stuff is slightly = incorrect. Namely, sending 0 bytes packet works for any RTP-capable transport protocol= . = Indeed, it works not only for UDP and DCCP, but also for UDP-Lite and = RTP-framing-in-TCP. I would hence argue that is _not_ specific to = UDP/DCCP/whatever, contrary to the claims thereto in the document. -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 25 00:03:04 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC82C28C14B; Fri, 25 Apr 2008 00:03:04 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B86E28C0DD for ; Fri, 25 Apr 2008 00:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3d+CXGrcN4D for ; Fri, 25 Apr 2008 00:03:02 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 42A8228C14B for ; Fri, 25 Apr 2008 00:03:02 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3P72dFs008975 for ; Fri, 25 Apr 2008 10:03:04 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Apr 2008 10:02:50 +0300 Received: from esdhcp04185.research.nokia.com ([172.21.41.85]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Apr 2008 10:02:49 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia Devices R&D To: behave@ietf.org Date: Fri, 25 Apr 2008 10:03:56 +0300 User-Agent: KMail/1.9.9 References: <4810C3ED.7030901@ericsson.com> In-Reply-To: <4810C3ED.7030901@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804251003.56424.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 25 Apr 2008 07:02:49.0948 (UTC) FILETIME=[5FA2D9C0:01C8A6A2] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Consensus call on Adding "Client" attribute to STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Thursday 24 April 2008 20:31:25 ext Magnus Westerlund, vous avez =E9crit= =A0: > This is a one week+ consensus call (until the 5th of May) if the WG > thinks that STUN (draft-ietf-behave-rfc3489bis) shall be extended with > an additional attribute "Client" before publication. (...) > Please indicate your position on adding this or not. I support the addition. -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 25 00:08:52 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924623A6BA9; Fri, 25 Apr 2008 00:08:52 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E86B33A6CD4 for ; Fri, 25 Apr 2008 00:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bvTykcy7o7I for ; Fri, 25 Apr 2008 00:08:50 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C622A3A6A52 for ; Fri, 25 Apr 2008 00:08:49 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3P78ofW014836; Fri, 25 Apr 2008 10:08:50 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Apr 2008 10:08:49 +0300 Received: from esdhcp04185.research.nokia.com ([172.21.41.85]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Apr 2008 10:08:49 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia Devices R&D To: behave@ietf.org Date: Fri, 25 Apr 2008 10:09:55 +0300 User-Agent: KMail/1.9.9 References: <200804231710.28415.simon.perreault@viagenie.ca> <09bb01c8a65c$a28ab320$c2f0200a@cisco.com> <200804241852.13723.simon.perreault@viagenie.ca> In-Reply-To: <200804241852.13723.simon.perreault@viagenie.ca> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804251009.55629.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 25 Apr 2008 07:08:49.0224 (UTC) FILETIME=[35C80480:01C8A6A3] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Duplicate request handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Friday 25 April 2008 01:52:13 ext Simon Perreault, vous avez =E9crit=A0: > > Considering the current text in rfc3489bis, imagine the following > > occurs: > > > > 1. STUN client sends a STUN request, which traverses a NAT and > > arrives at STUN server, and STUN server generates a response. > > 2. The NAT in front of the STUN client crashes before the response > > is received. > > 3. The NAT in front of the STUN client reboots 5 seconds later and > > becomes operational. > > 4. The STUN client's NNth retransmission is sent, which gets a > > different mapping than (1). > > > > Per the text in rfc3489bis, because the transaction-id is the same, > > the reponse is supposed to be the same. > > > > But in the case above, we wouldn't want that, would we?? > > Yes it should be the same. That's what we want. Just consider it like a > retransmission, as if we were operating over TCP. Oh, no. I strongly disagree. If the NAT reboots and yields a different = mapping, the TURN server has to consider this is a different client, hence = return a different result. Imagine a client with weak transaction ID randomness (which may be unavoida= ble = given 1/ hardware constraints, and 2/ that "secure" randomness is better us= ed = for cryptography than for NAT traversal). We'd have a trivial denial of = service attack/hijacking. In the case Dan describes, there is no problem in considering the two reque= sts = as different. The earlier mapping will simply expire, as the client will us= e = the later one. -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 25 00:12:23 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29BDE3A68C0; Fri, 25 Apr 2008 00:12:21 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477E53A6D70 for ; Fri, 25 Apr 2008 00:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fu5gX7Vp4bCM for ; Fri, 25 Apr 2008 00:12:09 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 069373A6A1C for ; Fri, 25 Apr 2008 00:11:56 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3P7BUGB017704; Fri, 25 Apr 2008 10:11:59 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Apr 2008 10:11:44 +0300 Received: from esdhcp04185.research.nokia.com ([172.21.41.85]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Apr 2008 10:11:43 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia Devices R&D To: behave@ietf.org Date: Fri, 25 Apr 2008 10:12:49 +0300 User-Agent: KMail/1.9.9 References: <200804231710.28415.simon.perreault@viagenie.ca> <1879720d0804240649u4163d096rb9ce494ffa2fb80b@mail.gmail.com> In-Reply-To: <1879720d0804240649u4163d096rb9ce494ffa2fb80b@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804251012.50144.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 25 Apr 2008 07:11:43.0659 (UTC) FILETIME=[9DC0AFB0:01C8A6A3] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Duplicate request handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Thursday 24 April 2008 16:49:20 ext Benny Prijono, vous avez =E9crit=A0: > Server may > just retransmit the same failure response for the same request > retransmission if it wants to. In fact I think server should do this > especially for non-idempotent requests, otherwise we may end up with > different state between the client and the server. For example, > imagine when TURN server first returns failure response, then > successful response on the second Allocate retransmission. Client most > likely will ignore the second response retransmission, hence client > thinks that the Allocate has failed while the server thinks it has > been successful. So what is the big deal? The server will just garbage collect the allocatio= n = eventually. This is perfectly normal operation. Clients can always "vanish" = unexpectedly, such as if their network connection fails. It's totally fine if the server thinks a request has succeeded and the clie= nt = thinks it's failed. Only the opposite would be an issue. -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 25 04:52:22 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03BE93A6B34; Fri, 25 Apr 2008 04:52:22 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65803A6B34 for ; Fri, 25 Apr 2008 04:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24vDklW20JiJ for ; Fri, 25 Apr 2008 04:52:19 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 608B93A6920 for ; Fri, 25 Apr 2008 04:52:19 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 1636429E148D; Fri, 25 Apr 2008 07:51:54 -0400 (EDT) Received: from [192.168.1.102] (ip216-239-79-48.vif.net [216.239.79.48]) by jazz.viagenie.ca (Postfix) with ESMTP id EE6EC29E1482 for ; Fri, 25 Apr 2008 07:51:53 -0400 (EDT) From: Simon Perreault Organization: =?utf-8?q?Viag=C3=A9nie?= To: behave@ietf.org Date: Fri, 25 Apr 2008 07:51:51 -0400 User-Agent: KMail/1.9.9 References: <200804231710.28415.simon.perreault@viagenie.ca> <200804241852.13723.simon.perreault@viagenie.ca> <200804251009.55629.remi.denis-courmont@nokia.com> In-Reply-To: <200804251009.55629.remi.denis-courmont@nokia.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804250751.51121.simon.perreault@viagenie.ca> Subject: Re: [BEHAVE] Duplicate request handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Friday 25 April 2008 03:09:55 R=E9mi Denis-Courmont wrote: > Oh, no. I strongly disagree. If the NAT reboots and yields a different > mapping, the TURN server has to consider this is a different client, hence > return a different result. Can I s/TURN/STUN/ or you were really talking about the specifics of TURN? So basically what you're saying is that a transaction is identified not onl= y = by the transaction ID but also by the mapped address. The STUN 3-tuple? ;) = But the text doesn't specify that. I can't think of any situation where what you're suggesting wouldn't be the = right thing to do. And, once again, a server that remembers responses and another that = regenerates new ones for indempotent request would yield exactly the same = result if they detect retransmissions by considering the 3-tuple instead of = only the TID. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 25 05:46:27 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18EE3A6B52; Fri, 25 Apr 2008 05:46:27 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15DB13A693C for ; Fri, 25 Apr 2008 05:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyINWlyvqgp2 for ; Fri, 25 Apr 2008 05:46:25 -0700 (PDT) Received: from mail.sipeerior.com (mail.sipeerior.com [128.239.5.131]) by core3.amsl.com (Postfix) with ESMTP id E63E228C28E for ; Fri, 25 Apr 2008 05:46:11 -0700 (PDT) Received: from [128.239.5.171] (unknown [128.239.5.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sipeerior.com (Postfix) with ESMTP id BF3DF505AAF; Fri, 25 Apr 2008 08:46:16 -0400 (EDT) In-Reply-To: <200804241826.04447.simon.perreault@viagenie.ca> References: <200804231710.28415.simon.perreault@viagenie.ca> <200804240957.02395.simon.perreault@viagenie.ca> <200804241826.04447.simon.perreault@viagenie.ca> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <2BEB591C-867F-4E2A-A4B3-0944F5739497@sipeerior.com> From: Bruce Lowekamp Date: Thu, 24 Apr 2008 18:36:38 -0400 To: Simon Perreault X-Mailer: Apple Mail (2.753) Cc: behave@ietf.org Subject: Re: [BEHAVE] Duplicate request handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Apr 24, 2008, at 6:26 PM, Simon Perreault wrote: > On Thursday 24 April 2008 17:49:36 Bruce Lowekamp wrote: >> To impose that requirement for all STUN transactions essentially >> prevents a high-throughput stun server (for binding requests) from >> being deployed. If all it's doing is binding requests, the entire >> server really is very minimal and requires little state. 13 says >> that a basic STUN server SHOULD NOT use authentication, which is also >> there to minimize the state required for a pure STUN server. The >> resulting service can be very high throughput with minimalistic >> resources. If it has to cache every response it's issued over the >> last 40 seconds, that's a huge data structure that serves no useful >> purpose as far as I can tell. > > No. A response to a Binding request doesn't depend on any state. So > you don't > have to remember all past responses. > > What I meant was that a response, success or not, indempotent or > not, should > be the same for a given transaction ID during the 40 seconds > following the > initial reception. As is already mentioned in the draft, you can > store the > past responses or you can generate a new response from scratch if it > generates the same response. OK, great. Then we agree. When your previous message said "any response should be remembered" and that it was a transport-level issue and not application, I had the other impression. Bruce _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 25 05:54:17 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA093A69DE; Fri, 25 Apr 2008 05:54:17 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2E43A69DE for ; Fri, 25 Apr 2008 05:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cY9-KGLy7eeI for ; Fri, 25 Apr 2008 05:54:15 -0700 (PDT) Received: from s200aog13.obsmtp.com (s200aog13.obsmtp.com [207.126.144.127]) by core3.amsl.com (Postfix) with SMTP id E3FF53A693C for ; Fri, 25 Apr 2008 05:54:14 -0700 (PDT) Received: from source ([209.85.198.227]) by eu1sys200aob013.postini.com ([207.126.147.11]) with SMTP; Fri, 25 Apr 2008 12:54:18 UTC Received: by rv-out-0506.google.com with SMTP id g37so1801477rvb.21 for ; Fri, 25 Apr 2008 05:54:18 -0700 (PDT) Received: by 10.141.180.5 with SMTP id h5mr1864871rvp.240.1209128058352; Fri, 25 Apr 2008 05:54:18 -0700 (PDT) Received: by 10.141.186.2 with HTTP; Fri, 25 Apr 2008 05:54:18 -0700 (PDT) Message-ID: <1879720d0804250554g15394aa9v12cc154d5abd498e@mail.gmail.com> Date: Fri, 25 Apr 2008 13:54:18 +0100 From: "Benny Prijono" To: "=?ISO-8859-1?Q?R=E9mi_Denis-Courmont?=" In-Reply-To: <200804251012.50144.remi.denis-courmont@nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <200804231710.28415.simon.perreault@viagenie.ca> <1879720d0804240649u4163d096rb9ce494ffa2fb80b@mail.gmail.com> <200804251012.50144.remi.denis-courmont@nokia.com> X-Google-Sender-Auth: a3a307c6ba449ee0 Cc: behave@ietf.org Subject: Re: [BEHAVE] Duplicate request handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Fri, Apr 25, 2008 at 8:12 AM, R=E9mi Denis-Courmont wrote: > Le Thursday 24 April 2008 16:49:20 ext Benny Prijono, vous avez =E9crit : > > > Server may > > just retransmit the same failure response for the same request > > retransmission if it wants to. In fact I think server should do this > > especially for non-idempotent requests, otherwise we may end up with > > different state between the client and the server. For example, > > imagine when TURN server first returns failure response, then > > successful response on the second Allocate retransmission. Client most > > likely will ignore the second response retransmission, hence client > > thinks that the Allocate has failed while the server thinks it has > > been successful. > > So what is the big deal? The server will just garbage collect the alloca= tion > eventually. This is perfectly normal operation. Clients can always "vani= sh" > unexpectedly, such as if their network connection fails. > Sure client vanishing in TURN is not a big deal and it's just something that we have to accept in real life. > It's totally fine if the server thinks a request has succeeded and the c= lient > thinks it's failed. Only the opposite would be an issue. > I disagree here. Big deal or not, I think it just doesn't make sense to return both failure and successful response in the same transaction. If server resource is your concern, Simon's proposal doesn't suggest that server must always cache failure responses. It only suggests that server returns the same failure response for the same request (or should it be the same failure class?), which means that server can always return 400 or 401 response statelessly for example, since retransmission of the request will always yield the same response. I think this is good and I support that. Cheers Benny > -- > R=E9mi Denis-Courmont > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 25 06:37:25 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12A463A6DFD; Fri, 25 Apr 2008 06:37:25 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261BB3A6E0E for ; Fri, 25 Apr 2008 06:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpaVNALWmcAC for ; Fri, 25 Apr 2008 06:37:23 -0700 (PDT) Received: from s200aog17.obsmtp.com (s200aog17.obsmtp.com [207.126.144.131]) by core3.amsl.com (Postfix) with SMTP id B414E3A6E07 for ; Fri, 25 Apr 2008 06:37:22 -0700 (PDT) Received: from source ([64.233.184.229]) by eu1sys200aob017.postini.com ([207.126.147.11]) with SMTP; Fri, 25 Apr 2008 13:37:26 UTC Received: by wr-out-0506.google.com with SMTP id c55so2208450wra.0 for ; Fri, 25 Apr 2008 06:37:26 -0700 (PDT) Received: by 10.140.140.3 with SMTP id n3mr1859577rvd.299.1209130644957; Fri, 25 Apr 2008 06:37:24 -0700 (PDT) Received: by 10.141.186.2 with HTTP; Fri, 25 Apr 2008 06:37:24 -0700 (PDT) Message-ID: <1879720d0804250637y43cf70bak610cb6b4aaea183e@mail.gmail.com> Date: Fri, 25 Apr 2008 14:37:24 +0100 From: "Benny Prijono" To: "Simon Perreault" In-Reply-To: <200804250751.51121.simon.perreault@viagenie.ca> MIME-Version: 1.0 Content-Disposition: inline References: <200804231710.28415.simon.perreault@viagenie.ca> <200804241852.13723.simon.perreault@viagenie.ca> <200804251009.55629.remi.denis-courmont@nokia.com> <200804250751.51121.simon.perreault@viagenie.ca> X-Google-Sender-Auth: c720d7df8393c91b Cc: behave@ietf.org Subject: Re: [BEHAVE] Duplicate request handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Fri, Apr 25, 2008 at 12:51 PM, Simon Perreault wrote: > On Friday 25 April 2008 03:09:55 R=E9mi Denis-Courmont wrote: > > Oh, no. I strongly disagree. If the NAT reboots and yields a different > > mapping, the TURN server has to consider this is a different client, h= ence > > return a different result. > > Can I s/TURN/STUN/ or you were really talking about the specifics of TUR= N? > > So basically what you're saying is that a transaction is identified not = only > by the transaction ID but also by the mapped address. The STUN 3-tuple? = ;) > But the text doesn't specify that. > Interestingly we probably do this already in TURN. In TURN, the 5-tuple matching would probably the very first thing that the server checks when processing a packet, to get the client allocation context. It may do this even before passing the request to STUN "transaction layer". Well at least that's what I do in my code, since response retransmission is done by (or in the context of) client allocation, once the client allocation is created by the first successful response. So in this case, the request retransmission after NAT reboot will be handled as a brand new allocation since the 5-tuple is different. > I can't think of any situation where what you're suggesting wouldn't be = the > right thing to do. > Well it kinds of breaks the idempotent-ness property of a request (imagine if we have PleaseDebitMyBankAccount request in STUN, your account will be debited twice). It may also not help if the client receives two different successful responses, as the client will ignore the second response and we're back with the same problem. On the other hand, this may have an advantage, for example when only the later responses get through after NAT reboot hence client will get the latest result, and it's natural with what we do in TURN. Frankly I'm not sure which one to choose. > And, once again, a server that remembers responses and another that > regenerates new ones for indempotent request would yield exactly the same > result if they detect retransmissions by considering the 3-tuple instead= of > only the TID. > I agree. Cheers Benny _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 25 06:39:49 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A958528C301; Fri, 25 Apr 2008 06:39:49 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2C728C324 for ; Fri, 25 Apr 2008 06:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuNVQSzWbUdv for ; Fri, 25 Apr 2008 06:39:47 -0700 (PDT) Received: from mail.sipeerior.com (mail.sipeerior.com [128.239.5.131]) by core3.amsl.com (Postfix) with ESMTP id 7178928C320 for ; Fri, 25 Apr 2008 06:39:47 -0700 (PDT) Received: from [128.239.5.171] (unknown [128.239.5.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sipeerior.com (Postfix) with ESMTP id 585AB505AAF; Fri, 25 Apr 2008 09:39:52 -0400 (EDT) In-Reply-To: <200804241900.40484.simon.perreault@viagenie.ca> References: <200804231710.28415.simon.perreault@viagenie.ca> <09bb01c8a65c$a28ab320$c2f0200a@cisco.com> <200804241852.13723.simon.perreault@viagenie.ca> <200804241900.40484.simon.perreault@viagenie.ca> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <37547E02-D9E2-426D-838E-E441B913235A@sipeerior.com> From: Bruce Lowekamp Date: Fri, 25 Apr 2008 09:39:50 -0400 To: Simon Perreault X-Mailer: Apple Mail (2.753) Cc: behave@ietf.org Subject: Re: [BEHAVE] Duplicate request handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Apr 24, 2008, at 7:00 PM, Simon Perreault wrote: > On Thursday 24 April 2008 18:52:13 Simon Perreault wrote: >> On Thursday 24 April 2008 18:43:36 Dan Wing wrote: >>> Let me throw a wrench into this discussion... >>> >>> Considering the current text in rfc3489bis, imagine the following >>> occurs: >>> >>> 1. STUN client sends a STUN request, which traverses a NAT and >>> arrives at STUN server, and STUN server generates a response. >>> 2. The NAT in front of the STUN client crashes before the response >>> is received. >>> 3. The NAT in front of the STUN client reboots 5 seconds later and >>> becomes operational. >>> 4. The STUN client's NNth retransmission is sent, which gets a >>> different mapping than (1). >>> >>> Per the text in rfc3489bis, because the transaction-id is the same, >>> the reponse is supposed to be the same. >>> >>> But in the case above, we wouldn't want that, would we?? >> >> Yes it should be the same. That's what we want. Just consider it >> like a >> retransmission, as if we were operating over TCP. > > Precision because I wasn't making a lot of sense: > > It might appear in this case that the stateless server is better > because it > reacts faster to changes in the network. But then it introduces the > potential > to confuse the client when it receives multiple responses to the > same request > containing different content. > A client following the rules of 7.3 will discard the second response ("the agent checks that the transaction ID matches a transaction that is still in progress"). Presumably if someone implements a client that doesn't both to remember its own transaction IDs, they either know it doesn't matter for their application or it's just a bug. > So it might appear that you *do* need to remember all previous > responses. But > that would be a stupid thing to do from an implementor's point of > view for > the case of a Binding-only STUN server. So just generate a new > response, let > the client be confused and sort it out (i.e. by using the first one > received > and throwing all other duplicate responses). > > So my only gripe with the current text is that it applies only to > success > responses. Remove the "success" part and be done with it. I've been trying to construct a case where it matters that the response isn't a success response. The only case I've been able to come up with is 500. In that case, the server has said it has a temporary error and the client can retry. The client is allowed to resend the original request. But since all 300 and 400 response codes indicate the current transaction has failed (although in many cases it may be retried, I believe it will always be a new tid), I think in those cases the response should always be the same. Bruce _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 25 07:25:29 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B16B23A6DDF; Fri, 25 Apr 2008 07:25:29 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F433A6DDF for ; Fri, 25 Apr 2008 07:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qcpEtG0iwFk for ; Fri, 25 Apr 2008 07:25:25 -0700 (PDT) Received: from mail.sipeerior.com (mail.sipeerior.com [128.239.5.131]) by core3.amsl.com (Postfix) with ESMTP id C638D3A6DDE for ; Fri, 25 Apr 2008 07:25:24 -0700 (PDT) Received: from [128.239.5.171] (unknown [128.239.5.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sipeerior.com (Postfix) with ESMTP id C0160505AB9; Fri, 25 Apr 2008 10:25:28 -0400 (EDT) In-Reply-To: <027BEB3B-45C2-4A28-9CD2-D9E2523FBF7D@magma.ca> References: <200804240923.16507.simon.perreault@viagenie.ca> <66AD7A02-369D-4343-B144-CE73BDF44B0E@magma.ca> <20080424225734.56D805081A@romeo.rtfm.com> <027BEB3B-45C2-4A28-9CD2-D9E2523FBF7D@magma.ca> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Bruce Lowekamp Date: Fri, 25 Apr 2008 10:25:25 -0400 To: Philip Matthews X-Mailer: Apple Mail (2.753) Cc: behave@ietf.org Subject: Re: [BEHAVE] Error code for unsupported method X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org It seems like the intention should be something along the lines of (merging in a clarification from the duplicate request handling issue): When a STUN agent receives a STUN message, it first checks that the message obeys the rules of Section 6. It checks that the first two bits are 0, that the magic cookie field has the correct value, and that the message length is sensible. If the FINGERPRINT extension is being used, the agent checks that the FINGERPRINT attribute is present and contains the correct value. If any of these conditions are not met, the message is silently discarded or, in the case when STUN is being multiplexed with another protocol, the agent should try to parse the message as a different protocol. If the message-class is Success Response or Error Response, the agent checks that the transaction ID matches a transaction that is still in progress. If the transaction ID does not match an in- progress transaction, the response is silently discarded. Then move the case of the unknown method check to 7.3.1 and return a 400 (actually, I think a new error response would be appropriate here). Actually, I think there's a bizarre pathological case here. I don't see a specification that Is there a requirement anywhere in the protocol that the UAC must check that the method in a response matches the method in the request. So possibly the above tid check should also check that the method matches the original request. Bruce On Apr 24, 2008, at 10:48 PM, Philip Matthews wrote: > > On Thu, 24-Apr-08, at 18:57 , Eric Rescorla wrote: >> At Thu, 24 Apr 2008 14:56:24 -0400, >> Philip Matthews wrote: >> At Thu, 24 Apr 2008 14:56:24 -0400, >> Philip Matthews wrote: >>> >>> >>> On Thu, 24-Apr-08, at 09:23 , Simon Perreault wrote: >>>> Hello, >>>> >>>> What is a STUN server supposed to use as error code when an unknown >>>> method is >>>> received? From the list in 3489bis, Section 15.6, I'd be tempted to >>>> pick >>>> either 400 or 500, depending on who I'm siding with, but this >>>> doesn't seem >>>> right because it's really nobody's fault. >>>> >>>> Will people crucify me if I return a 501 Not Implemented, as in >>>> HTTP? >>> >>> >>> Section 7.3 of draft-ietf-behave-rfc3489bis-15 says (second >>> paragraph): >>> >>> When a STUN agent receives a STUN message, it first checks that >>> the >>> message obeys the rules of Section 6. It checks that the first >>> two >>> bits are 0, that the magic cookie field has the correct value, >>> that >>> the message length is sensible, and that the method value is a >>> supported method. If the message-class is Success Response or >>> Error >>> Response, the agent checks that the transaction ID matches a >>> transaction that is still in progress. If the FINGERPRINT >>> extension >>> is being used, the agent checks that the FINGERPRINT attribute is >>> present and contains the correct value. If any errors are >>> detected, >>> the message is silently discarded. In the case when STUN is >>> being >>> multiplexed with another protocol, an error may indicate that >>> this >>> is >>> not really a STUN message; in this case, the agent should try to >>> parse the message as a different protocol. >>> >>> Thus an implementation should silently discard an unsupported >>> method. >> >> Wow. I totally never noticed this. >> >> So, I get the reasoning for silent discards for cases where we're not >> sure that this is STUN or not, but if everything but the method looks >> right, wouldn't it make more sense to send an error? > > Perhaps. > It would certainly allow the client to more rapidly detect that the > server doesn't support a particular method, since right now the client > has to wait the 40 second timeout period to be certain. > However, I vaguely remember thinking when I wrote the above text, that > there were cases where a silent discard was desirable. Unfortunately, > I cannot remember any right now. (And, when I wrote the text, the > timeout period was 10 seconds, not 40...) > > - Philip > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 25 07:27:06 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28E1B3A6DD5; Fri, 25 Apr 2008 07:27:06 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C305D3A6DD5 for ; Fri, 25 Apr 2008 07:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWWiIt4pVJdN for ; Fri, 25 Apr 2008 07:26:59 -0700 (PDT) Received: from mail.sipeerior.com (mail.sipeerior.com [128.239.5.131]) by core3.amsl.com (Postfix) with ESMTP id C8D373A685D for ; Fri, 25 Apr 2008 07:26:59 -0700 (PDT) Received: from [128.239.5.171] (unknown [128.239.5.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sipeerior.com (Postfix) with ESMTP id A0B9F505AB9; Fri, 25 Apr 2008 10:27:04 -0400 (EDT) In-Reply-To: <4810C3ED.7030901@ericsson.com> References: <4810C3ED.7030901@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <583CE3D4-8313-4250-A5A4-FC9A0004BC5C@sipeerior.com> From: Bruce Lowekamp Date: Fri, 25 Apr 2008 10:27:03 -0400 To: Magnus Westerlund X-Mailer: Apple Mail (2.753) Cc: Behave WG Subject: Re: [BEHAVE] Consensus call on Adding "Client" attribute to STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Apr 24, 2008, at 1:31 PM, Magnus Westerlund wrote: > This is a one week+ consensus call (until the 5th of May) if the WG > thinks that STUN (draft-ietf-behave-rfc3489bis) shall be extended with > an additional attribute "Client" before publication. > > With the general description along the lines of: > > X.Y CLIENT > > The client attribute contains a textual description of the > software > being used by the client, including manufacturer and version > number. > The attribute has no impact on operation of the protocol, and > serves > only as a tool for diagnostic and debugging purposes. The > value of > CLIENT is variable length. It MUST be a UTF-8 [RFC3629] encoded > sequence of less than 128 characters (which can be as long as 763 > bytes). > > And some Security Considerations on the risk for targeted attacks > against clients with this information. Plus other text needed to bring > it in consistently > > The text is open for wordsmithing by the editors of the STUN spec. > > Please indicate your position on adding this or not. I support the addition as long as it is a comprehension-optional attribute. Bruce _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 25 07:49:48 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CF2C28C34F; Fri, 25 Apr 2008 07:49:48 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FB273A6BBB for ; Fri, 25 Apr 2008 07:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyzYazDQ982H for ; Fri, 25 Apr 2008 07:49:46 -0700 (PDT) Received: from mail-05.primus.ca (mail4.primus.ca [216.254.141.171]) by core3.amsl.com (Postfix) with ESMTP id 390BC28C34F for ; Fri, 25 Apr 2008 07:49:46 -0700 (PDT) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JpPE8-00089h-02; Fri, 25 Apr 2008 10:48:40 -0400 Message-Id: <6D9F0AC0-5D14-4AAE-A33E-3B2FA4EF5F96@magma.ca> From: Philip Matthews To: Bruce Lowekamp In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 25 Apr 2008 10:49:47 -0400 References: <200804240923.16507.simon.perreault@viagenie.ca> <66AD7A02-369D-4343-B144-CE73BDF44B0E@magma.ca> <20080424225734.56D805081A@romeo.rtfm.com> <027BEB3B-45C2-4A28-9CD2-D9E2523FBF7D@magma.ca> X-Mailer: Apple Mail (2.919.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: behave@ietf.org Subject: Re: [BEHAVE] Error code for unsupported method X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I am not the editor of ietf-behave-rfc3489bis. However, if I was the editor, I would ask: 1) Is this an important enough change to modify a document that is almost through IESG processing (and which has TWICE gone through WGLC)? 2) What do existing deployed STUN servers do today? Unlike the proposed new CLIENT attribute, this proposed change does not add any new functionality, but just gives faster recovery from an error case. How many people think that a change along the lines that Bruce sketched below is important? - Philip PS. I agree that, _if_ we were to make this change, a new error code would be appropriate. PPS. I also agree that a client implemented using defensive programming techniques should confirm that the method in the response matches that in the request, even though the match on the transaction id should guarantee this. PPPS. And I still wonder if there are not cases where we want a silent drop, and not an error response. On Fri, 25-Apr-08, at 10:25 , Bruce Lowekamp wrote: > > It seems like the intention should be something along the lines of > (merging in a clarification from the duplicate request handling > issue): > > When a STUN agent receives a STUN message, it first checks that > the message obeys the rules of Section 6. It checks that the > first two bits are 0, that the magic cookie field has the correct > value, and that the message length is sensible. If the > FINGERPRINT extension is being used, the agent checks that the > FINGERPRINT attribute is present and contains the correct value. > If any of these conditions are not met, the message is silently > discarded or, in the case when STUN is being multiplexed with > another protocol, the agent should try to parse the message as a > different protocol. > > If the message-class is Success Response or Error Response, the > agent checks that the transaction ID matches a transaction that is > still in progress. If the transaction ID does not match an in- > progress transaction, the response is silently discarded. > > > Then move the case of the unknown method check to 7.3.1 and return a > 400 (actually, I think a new error response would be appropriate > here). > > Actually, I think there's a bizarre pathological case here. I don't > see a specification that Is there a requirement anywhere in the > protocol that the UAC must check that the method in a response > matches the method in the request. So possibly the above tid check > should also check that the method matches the original request. > > Bruce > > > > On Apr 24, 2008, at 10:48 PM, Philip Matthews wrote: >> >> On Thu, 24-Apr-08, at 18:57 , Eric Rescorla wrote: >>> At Thu, 24 Apr 2008 14:56:24 -0400, >>> Philip Matthews wrote: >>> At Thu, 24 Apr 2008 14:56:24 -0400, >>> Philip Matthews wrote: >>>> >>>> >>>> On Thu, 24-Apr-08, at 09:23 , Simon Perreault wrote: >>>>> Hello, >>>>> >>>>> What is a STUN server supposed to use as error code when an >>>>> unknown >>>>> method is >>>>> received? From the list in 3489bis, Section 15.6, I'd be tempted >>>>> to >>>>> pick >>>>> either 400 or 500, depending on who I'm siding with, but this >>>>> doesn't seem >>>>> right because it's really nobody's fault. >>>>> >>>>> Will people crucify me if I return a 501 Not Implemented, as in >>>>> HTTP? >>>> >>>> >>>> Section 7.3 of draft-ietf-behave-rfc3489bis-15 says (second >>>> paragraph): >>>> >>>> When a STUN agent receives a STUN message, it first checks that >>>> the >>>> message obeys the rules of Section 6. It checks that the first >>>> two >>>> bits are 0, that the magic cookie field has the correct value, >>>> that >>>> the message length is sensible, and that the method value is a >>>> supported method. If the message-class is Success Response or >>>> Error >>>> Response, the agent checks that the transaction ID matches a >>>> transaction that is still in progress. If the FINGERPRINT >>>> extension >>>> is being used, the agent checks that the FINGERPRINT attribute is >>>> present and contains the correct value. If any errors are >>>> detected, >>>> the message is silently discarded. In the case when STUN is >>>> being >>>> multiplexed with another protocol, an error may indicate that >>>> this >>>> is >>>> not really a STUN message; in this case, the agent should try to >>>> parse the message as a different protocol. >>>> >>>> Thus an implementation should silently discard an unsupported >>>> method. >>> >>> Wow. I totally never noticed this. >>> >>> So, I get the reasoning for silent discards for cases where we're >>> not >>> sure that this is STUN or not, but if everything but the method >>> looks >>> right, wouldn't it make more sense to send an error? >> >> Perhaps. >> It would certainly allow the client to more rapidly detect that the >> server doesn't support a particular method, since right now the >> client >> has to wait the 40 second timeout period to be certain. >> However, I vaguely remember thinking when I wrote the above text, >> that >> there were cases where a silent discard was desirable. Unfortunately, >> I cannot remember any right now. (And, when I wrote the text, the >> timeout period was 10 seconds, not 40...) >> >> - Philip >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 25 08:02:08 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C3228C31F; Fri, 25 Apr 2008 08:02:08 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E39B53A6CF1 for ; Fri, 25 Apr 2008 08:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6Qdr1+NIzfl for ; Fri, 25 Apr 2008 08:02:01 -0700 (PDT) Received: from mail.sipeerior.com (mail.sipeerior.com [128.239.5.131]) by core3.amsl.com (Postfix) with ESMTP id 9CCA13A6B5F for ; Fri, 25 Apr 2008 08:02:01 -0700 (PDT) Received: from [128.239.5.171] (unknown [128.239.5.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sipeerior.com (Postfix) with ESMTP id EF416505AAF; Fri, 25 Apr 2008 11:02:04 -0400 (EDT) In-Reply-To: <6D9F0AC0-5D14-4AAE-A33E-3B2FA4EF5F96@magma.ca> References: <200804240923.16507.simon.perreault@viagenie.ca> <66AD7A02-369D-4343-B144-CE73BDF44B0E@magma.ca> <20080424225734.56D805081A@romeo.rtfm.com> <027BEB3B-45C2-4A28-9CD2-D9E2523FBF7D@magma.ca> <6D9F0AC0-5D14-4AAE-A33E-3B2FA4EF5F96@magma.ca> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <4B43D0EE-506D-4944-A8F2-0FD95F98157C@sipeerior.com> From: Bruce Lowekamp Date: Fri, 25 Apr 2008 11:02:03 -0400 To: Philip Matthews X-Mailer: Apple Mail (2.753) Cc: Behave WG Subject: Re: [BEHAVE] Error code for unsupported method X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I don't know if you're looking for my own comments on my own suggestion, but regardless: - I view not reporting some sort of error for an unknown method to be important enough that it needs to be fixed - The rest I think is just a clarifying change to the text that's already there, which I think would be fine for author's 48. The existing text mixes the issues of unknown method, dropping completed/ unknown transactions, and ignoring messages that don't appear to be stun into one paragraph that really doesn't specify what should be done and only gives hints that need to be interpreted and reordered in an implementation. Bruce On Apr 25, 2008, at 10:49 AM, Philip Matthews wrote: > I am not the editor of ietf-behave-rfc3489bis. > > However, if I was the editor, I would ask: > 1) Is this an important enough change to modify a document that is > almost through IESG processing (and which has TWICE gone through > WGLC)? > 2) What do existing deployed STUN servers do today? > > Unlike the proposed new CLIENT attribute, this proposed change does > not add any new functionality, but just gives faster recovery from > an error case. > > How many people think that a change along the lines that Bruce > sketched below is important? > > - Philip > > PS. I agree that, _if_ we were to make this change, a new error > code would be appropriate. > PPS. I also agree that a client implemented using defensive > programming techniques should confirm that the method in the > response matches that in the request, even though the match on the > transaction id should guarantee this. > PPPS. And I still wonder if there are not cases where we want a > silent drop, and not an error response. > > On Fri, 25-Apr-08, at 10:25 , Bruce Lowekamp wrote: >> >> It seems like the intention should be something along the lines of >> (merging in a clarification from the duplicate request handling >> issue): >> >> When a STUN agent receives a STUN message, it first checks that >> the message obeys the rules of Section 6. It checks that the >> first two bits are 0, that the magic cookie field has the >> correct value, and that the message length is sensible. If the >> FINGERPRINT extension is being used, the agent checks that the >> FINGERPRINT attribute is present and contains the correct >> value. If any of these conditions are not met, the message is >> silently discarded or, in the case when STUN is being >> multiplexed with another protocol, the agent should try to >> parse the message as a different protocol. >> >> If the message-class is Success Response or Error Response, the >> agent checks that the transaction ID matches a transaction that >> is still in progress. If the transaction ID does not match an in- >> progress transaction, the response is silently discarded. >> >> >> Then move the case of the unknown method check to 7.3.1 and return >> a 400 (actually, I think a new error response would be appropriate >> here). >> >> Actually, I think there's a bizarre pathological case here. I >> don't see a specification that Is there a requirement anywhere in >> the protocol that the UAC must check that the method in a response >> matches the method in the request. So possibly the above tid >> check should also check that the method matches the original request. >> >> Bruce >> >> >> >> On Apr 24, 2008, at 10:48 PM, Philip Matthews wrote: >>> >>> On Thu, 24-Apr-08, at 18:57 , Eric Rescorla wrote: >>>> At Thu, 24 Apr 2008 14:56:24 -0400, >>>> Philip Matthews wrote: >>>> At Thu, 24 Apr 2008 14:56:24 -0400, >>>> Philip Matthews wrote: >>>>> >>>>> >>>>> On Thu, 24-Apr-08, at 09:23 , Simon Perreault wrote: >>>>>> Hello, >>>>>> >>>>>> What is a STUN server supposed to use as error code when an >>>>>> unknown >>>>>> method is >>>>>> received? From the list in 3489bis, Section 15.6, I'd be >>>>>> tempted to >>>>>> pick >>>>>> either 400 or 500, depending on who I'm siding with, but this >>>>>> doesn't seem >>>>>> right because it's really nobody's fault. >>>>>> >>>>>> Will people crucify me if I return a 501 Not Implemented, as in >>>>>> HTTP? >>>>> >>>>> >>>>> Section 7.3 of draft-ietf-behave-rfc3489bis-15 says (second >>>>> paragraph): >>>>> >>>>> When a STUN agent receives a STUN message, it first checks that >>>>> the >>>>> message obeys the rules of Section 6. It checks that the first >>>>> two >>>>> bits are 0, that the magic cookie field has the correct value, >>>>> that >>>>> the message length is sensible, and that the method value is a >>>>> supported method. If the message-class is Success Response or >>>>> Error >>>>> Response, the agent checks that the transaction ID matches a >>>>> transaction that is still in progress. If the FINGERPRINT >>>>> extension >>>>> is being used, the agent checks that the FINGERPRINT >>>>> attribute is >>>>> present and contains the correct value. If any errors are >>>>> detected, >>>>> the message is silently discarded. In the case when STUN is >>>>> being >>>>> multiplexed with another protocol, an error may indicate that >>>>> this >>>>> is >>>>> not really a STUN message; in this case, the agent should try to >>>>> parse the message as a different protocol. >>>>> >>>>> Thus an implementation should silently discard an unsupported >>>>> method. >>>> >>>> Wow. I totally never noticed this. >>>> >>>> So, I get the reasoning for silent discards for cases where >>>> we're not >>>> sure that this is STUN or not, but if everything but the method >>>> looks >>>> right, wouldn't it make more sense to send an error? >>> >>> Perhaps. >>> It would certainly allow the client to more rapidly detect that the >>> server doesn't support a particular method, since right now the >>> client >>> has to wait the 40 second timeout period to be certain. >>> However, I vaguely remember thinking when I wrote the above text, >>> that >>> there were cases where a silent discard was desirable. >>> Unfortunately, >>> I cannot remember any right now. (And, when I wrote the text, the >>> timeout period was 10 seconds, not 40...) >>> >>> - Philip >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >> >> > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 25 08:09:18 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E010028C357; Fri, 25 Apr 2008 08:09:18 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE46928C355 for ; Fri, 25 Apr 2008 08:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2cijJ35zHjN for ; Fri, 25 Apr 2008 08:09:17 -0700 (PDT) Received: from s200aog17.obsmtp.com (s200aog17.obsmtp.com [207.126.144.131]) by core3.amsl.com (Postfix) with SMTP id 8379528C350 for ; Fri, 25 Apr 2008 08:09:16 -0700 (PDT) Received: from source ([64.233.184.225]) by eu1sys200aob017.postini.com ([207.126.147.11]) with SMTP; Fri, 25 Apr 2008 15:09:20 UTC Received: by wr-out-0506.google.com with SMTP id c55so2244252wra.0 for ; Fri, 25 Apr 2008 08:09:20 -0700 (PDT) Received: by 10.140.170.12 with SMTP id s12mr855071rve.83.1209136159313; Fri, 25 Apr 2008 08:09:19 -0700 (PDT) Received: by 10.141.186.2 with HTTP; Fri, 25 Apr 2008 08:09:19 -0700 (PDT) Message-ID: <1879720d0804250809l4adaaf69h28a9a5d142144af5@mail.gmail.com> Date: Fri, 25 Apr 2008 16:09:19 +0100 From: "Benny Prijono" To: "Behave WG" In-Reply-To: <4810C3ED.7030901@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline References: <4810C3ED.7030901@ericsson.com> X-Google-Sender-Auth: 9084a770b84b4837 Subject: Re: [BEHAVE] Consensus call on Adding "Client" attribute to STUN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Thu, Apr 24, 2008 at 6:31 PM, Magnus Westerlund wrote: > This is a one week+ consensus call (until the 5th of May) if the WG > thinks that STUN (draft-ietf-behave-rfc3489bis) shall be extended with > an additional attribute "Client" before publication. > > With the general description along the lines of: > > X.Y CLIENT > > The client attribute contains a textual description of the software > being used by the client, including manufacturer and version number. > The attribute has no impact on operation of the protocol, and serves > only as a tool for diagnostic and debugging purposes. The value of > CLIENT is variable length. It MUST be a UTF-8 [RFC3629] encoded > sequence of less than 128 characters (which can be as long as 763 > bytes). > I support adding the CLIENT attribute. However I'm a bit concerned with the requirement to include manufacturer and software version number. Isn't that too restrictive, and may make the system more vulnerable? I propose we remove the "including manufacturer and version number" part of the sentence (and the same for SERVER attribute as well). This then would be similar to what we have in User-Agent header in SIP/RFC 3261: "20.41 User-Agent The User-Agent header field contains information about the UAC originating the request. The semantics of this header field are defined in [H14.43]. Revealing the specific software version of the user agent might allow the user agent to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make the User-Agent header field a configurable option. " I also support the "The attribute has no impact on operation of the protocol" sentence, which implies that server implementations must not do anything differently based on the value of this attribute (such as to allow/block access based on the this value, which what has been originally proposed). Cheers Benny _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 25 13:04:34 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B16928C241; Fri, 25 Apr 2008 13:04:34 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD7723A6AFD; Fri, 25 Apr 2008 13:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQ7qAzM74SPr; Fri, 25 Apr 2008 13:04:32 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D837728C1B1; Fri, 25 Apr 2008 13:04:30 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.263.0; Fri, 25 Apr 2008 16:04:02 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 25 Apr 2008 16:04:03 -0400 From: Hadriel Kaplan To: Tom Taylor , IETF AVT WG , "behave@ietf.org" Date: Fri, 25 Apr 2008 16:00:55 -0400 Thread-Topic: [AVT] Working Group Last Call: draft-ietf-avt-app-rtp-keepalive-03.txt Thread-Index: Acilc5CY4IIjoR3jTRKh0H3OXBO5CQBkyupw Message-ID: References: <480F8629.8080202@rogers.com> In-Reply-To: <480F8629.8080202@rogers.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: MARJOU Xavier RD-MAPS-LAN Subject: Re: [BEHAVE] [AVT] Working Group Last Call: draft-ietf-avt-app-rtp-keepalive-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Howdy, In general I like the draft - it's short and to the point. :) I have the following comments: 1) The recommended "fallback" mechanism of using an RTP packet with an unknown payload format has issues. I *know* there are devices which can't handle it. I know this because SBC's have been specifically requested by operators to block such packets, because they were causing issues for some RTP devices. We can argue that RFC 3550 said a receiver MUST ignore such packets, but there is a big difference between handling error cases, and *testing* for such compliance by using it actively for a "feature". For example on some devices it causes error logs to be generated. (on others, worse) I recognize that this is probably unavoidable for any mechanism we pick, because the requirements are that it not be negotiated in SDP (right?). But I think it warrants certain changes in the text of the draft, which I note here: a) Section 4.7 Recommendation section currently implies this is the recommendation, but that's not really true. It should say "This method is recommended as a fallback, only if explicitly signaled methods such as [DRAFT-RTP-RTCP] or STUN through [DRAFT-ICE] are not possible." b) Section 5, page 8, last sentence should be changed from "...as it will always work." to "...as it will usually work." c) Security section 8 is wrong - it *does* imply security issues, clearly. So I recommend you add "Using the mechanism in Section 4.7 could be perceived as an attack by the peer. [RFC3550] explicitly stated devices MUST ignore unknown payload formats, however security devices may block such packets." Or something like that I guess. 2) In some ways, the recommended fallback of RTP with an unknown payload type is simply the draft-ietf-avt-rtp-no-op packet, just without SDP negotiation, and no 4-byte payload - right? One of the things I liked about that draft was it negotiated it in SDP. :) I realize you're trying to not make that necessary, so can we at least give this a fixed defined payload type number?? I think giving up one of the few left (are there any?) is worth it for this, because we're not negotiating it in SDP. 3) I also still think there should be optional SDP for the empty RTP keeaplive, just so that "evil" middleboxes trying to protect devices can know they can let these things past. I realize that can't be done in a BCP, so I think draft-ietf-avt-rtp-no-op-04 should *become* the empty RTP keepalive, and define the SDP. (I'm not sure why it expired) 4) This is basically a nit: like Remi, I'm not quite clear why Sections 4.1 and 4.2 UDP and DCCP transports are separate from each other or others, for zero-byte "packets". With TCP, obviously a 0-byte segment is not exactly the same as a TCP keepalive, and for SCTP it has a native heartbeat, so maybe those differences explain it. (and I'm not sure how one forces a TCP stack to send a 0 byte segment from above the socket) But as far as I know, all of them can handle receiving a 0-byte payload. A nit, anyway. -hadriel > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Tom > Taylor > Sent: Wednesday, April 23, 2008 2:56 PM > To: IETF AVT WG; behave@ietf.org > Cc: Cullen Jennings; MARJOU Xavier RD-MAPS-LAN > Subject: [AVT] Working Group Last Call: draft-ietf-avt-app-rtp-keepalive- > 03.txt > > This is to announce Working Group Last Call for > draft-ietf-avt-app-rtp-keepalive-03.txt. Assuming all goes well, the Last > Call > period will end on May 7. > > Given the subject matter, the BEHAVE list is also copied on this message. > > Tom Taylor for the Chairs. > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 25 18:22:03 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519D43A6D2C; Fri, 25 Apr 2008 18:22:03 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708113A6BE1; Fri, 25 Apr 2008 18:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKZ1+pkw7+jX; Fri, 25 Apr 2008 18:22:00 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 634023A6AC8; Fri, 25 Apr 2008 18:22:00 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 25 Apr 2008 18:22:05 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3Q1M5X0016834; Fri, 25 Apr 2008 18:22:05 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m3Q1M4eQ005953; Sat, 26 Apr 2008 01:22:04 GMT From: "Dan Wing" To: "'Hadriel Kaplan'" , "'Tom Taylor'" , "'IETF AVT WG'" , References: <480F8629.8080202@rogers.com> Date: Fri, 25 Apr 2008 18:22:04 -0700 Message-ID: <097c01c8a73b$efe6f9a0$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Acilc5CY4IIjoR3jTRKh0H3OXBO5CQBkyupwAA0KnAA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5613; t=1209172925; x=1210036925; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[AVT]=20Working=20Group=20LastCall=3A=0 9draft-ietf-avt-app-rtp-keepalive-03.txt |Sender:=20; bh=ug5IOUU0xyLDOj6vihRheKYshIdCUoTI7K9UyYqTdcE=; b=Z0MFNW8My5RmLFJtbfWMpkXPbjeRXvU58eoLT/apzby2PdH+UEMViNwX41 rE8FC6qDPnSOOPK+XNOgTXQG89DGH0Rv1QS3nACcZNK/is13OS6xxeuHIPYI JHOeZ5aLR/; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'MARJOU Xavier RD-MAPS-LAN' Subject: Re: [BEHAVE] [AVT] Working Group LastCall: draft-ietf-avt-app-rtp-keepalive-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Friday, April 25, 2008 1:01 PM > To: Tom Taylor; IETF AVT WG; behave@ietf.org > Cc: Cullen Jennings; MARJOU Xavier RD-MAPS-LAN > Subject: Re: [AVT] Working Group LastCall: > draft-ietf-avt-app-rtp-keepalive-03.txt > > > Howdy, > In general I like the draft - it's short and to the point. :) > I have the following comments: > > 1) The recommended "fallback" mechanism of using an RTP > packet with an unknown payload format has issues. I *know* > there are devices which can't handle it. I know this because > SBC's have been specifically requested by operators to block > such packets, because they were causing issues for some RTP > devices. We can argue that RFC 3550 said a receiver MUST > ignore such packets, but there is a big difference between > handling error cases, and *testing* for such compliance by > using it actively for a "feature". For example on some > devices it causes error logs to be generated. (on others, worse) > > I recognize that this is probably unavoidable for any > mechanism we pick, because the requirements are that it not > be negotiated in SDP (right?). But I think it warrants > certain changes in the text of the draft, which I note here: > a) Section 4.7 Recommendation section currently > implies this is the recommendation, but that's not really > true. It should say "This method is recommended as a > fallback, only if explicitly signaled methods such as > [DRAFT-RTP-RTCP] or STUN through [DRAFT-ICE] are not possible." > b) Section 5, page 8, last sentence should be changed > from "...as it will always work." to "...as it will usually work." This draft is all about mechanisms to keep NAT mapping alive, which is what this draft means by "work". And sending a packet will keep that binding alive -- always. I do agree the existing wording is a bit awkward. I would suggest: ... as it will always keep the NAT's mapping alive, but may cause undesirable behavior on the remote peer. > c) Security section 8 is wrong - it *does* imply > security issues, clearly. So I recommend you add "Using the > mechanism in Section 4.7 could be perceived as an attack by > the peer. [RFC3550] explicitly stated devices MUST ignore > unknown payload formats, however security devices may block > such packets." Or something like that I guess. I agree some text should be added to address you point, but (going back to my point above that this draft describes how to keep your NAT mapping alive), we don't care if a device on the remote network drops the packet; the packet will have already traversed our NAT and kept our NAT's mapping alive. > 2) In some ways, the recommended fallback of RTP with an > unknown payload type is simply the draft-ietf-avt-rtp-no-op > packet, just without SDP negotiation, and no 4-byte payload - > right? One of the things I liked about that draft was it > negotiated it in SDP. :) I realize you're trying to not make > that necessary, so can we at least give this a fixed defined > payload type number?? I think giving up one of the few left > (are there any?) is worth it for this, because we're not > negotiating it in SDP. I recall we asked for a fixed payload number for no-op a few years ago, but were told 'no'. Maybe that has changed; I do think it would be useful for this situation, but it only reduces the risk of a no-op packet being mis-identified as some sort of attack packet. > 3) I also still think there should be optional SDP for the > empty RTP keeaplive, just so that "evil" middleboxes trying > to protect devices can know they can let these things past. > > I realize that can't be done in a BCP, so I think > draft-ietf-avt-rtp-no-op-04 should *become* the empty RTP > keepalive, and define the SDP. (I'm not sure why it expired) Nobody seemed to need it. -d > 4) This is basically a nit: like Remi, I'm not quite clear > why Sections 4.1 and 4.2 UDP and DCCP transports are separate > from each other or others, for zero-byte "packets". With > TCP, obviously a 0-byte segment is not exactly the same as a > TCP keepalive, and for SCTP it has a native heartbeat, so > maybe those differences explain it. (and I'm not sure how one > forces a TCP stack to send a 0 byte segment from above the > socket) But as far as I know, all of them can handle > receiving a 0-byte payload. A nit, anyway. > > -hadriel > > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Tom > > Taylor > > Sent: Wednesday, April 23, 2008 2:56 PM > > To: IETF AVT WG; behave@ietf.org > > Cc: Cullen Jennings; MARJOU Xavier RD-MAPS-LAN > > Subject: [AVT] Working Group Last Call: > draft-ietf-avt-app-rtp-keepalive- > > 03.txt > > > > This is to announce Working Group Last Call for > > draft-ietf-avt-app-rtp-keepalive-03.txt. Assuming all goes > well, the Last > > Call > > period will end on May 7. > > > > Given the subject matter, the BEHAVE list is also copied on > this message. > > > > Tom Taylor for the Chairs. > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Apr 25 19:01:33 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77D623A6A34; Fri, 25 Apr 2008 19:01:33 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53283A6A34; Fri, 25 Apr 2008 19:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKJCKZ34D6B4; Fri, 25 Apr 2008 19:01:31 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 687263A6998; Fri, 25 Apr 2008 19:01:31 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.263.0; Fri, 25 Apr 2008 22:01:03 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 25 Apr 2008 22:01:00 -0400 From: Hadriel Kaplan To: Dan Wing , 'Tom Taylor' , 'IETF AVT WG' , "behave@ietf.org" Date: Fri, 25 Apr 2008 21:57:10 -0400 Thread-Topic: [AVT] Working Group LastCall: draft-ietf-avt-app-rtp-keepalive-03.txt Thread-Index: Acilc5CY4IIjoR3jTRKh0H3OXBO5CQBkyupwAA0KnAAAAKSo4A== Message-ID: References: <480F8629.8080202@rogers.com> <097c01c8a73b$efe6f9a0$c2f0200a@cisco.com> In-Reply-To: <097c01c8a73b$efe6f9a0$c2f0200a@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: 'MARJOU Xavier RD-MAPS-LAN' Subject: Re: [BEHAVE] [AVT] Working Group LastCall: draft-ietf-avt-app-rtp-keepalive-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > > > c) Security section 8 is wrong - it *does* imply > > security issues, clearly. So I recommend you add "Using the > > mechanism in Section 4.7 could be perceived as an attack by > > the peer. [RFC3550] explicitly stated devices MUST ignore > > unknown payload formats, however security devices may block > > such packets." Or something like that I guess. > > I agree some text should be added to address you point, but > (going back to my point above that this draft describes how > to keep your NAT mapping alive), we don't care if a device > on the remote network drops the packet; the packet will have > already traversed our NAT and kept our NAT's mapping alive. Yup, I realize it achieves that goal, and *I* don't care if a SBC-type-thing blocks and discard the packet either, because it achieves that goal - but that doesn't mean it has no security implications if it goes direct, and this is a WG doc after all. :) > I recall we asked for a fixed payload number for no-op a few > years ago, but were told 'no'. Maybe that has changed; I > do think it would be useful for this situation, but it only > reduces the risk of a no-op packet being mis-identified as > some sort of attack packet. It would do more than that. It would let monitoring software (wireshark/whatever) identify it as a keepalive. It may let QoS monitoring devices ignore it more easily. It would let middleboxes detect it as a keepalive, instead of attack packets. It would let DSP's have a way to off-load discarding of it. It would let SRTP bump-in-the-wire chips or shims avoid calculating auth for it, on both generation and reception. (because auth won't matter) If SDP negotiated it, that's possible too - but for this mechanism I think a defined number makes sense, especially if we don't want to use SDP. > > 3) I also still think there should be optional SDP for the > > empty RTP keeaplive, just so that "evil" middleboxes trying > > to protect devices can know they can let these things past. > > > > I realize that can't be done in a BCP, so I think > > draft-ietf-avt-rtp-no-op-04 should *become* the empty RTP > > keepalive, and define the SDP. (I'm not sure why it expired) > > Nobody seemed to need it. I find it odd that a WG BCP would recommend a mechanism (albeit a fallback one), that is not itself defined in a standards track doc anywhere. Maybe it's just me though. :) -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Apr 26 07:35:19 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 123BB3A6CD6; Sat, 26 Apr 2008 07:35:19 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00BA928C129; Sat, 26 Apr 2008 07:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxtq4Oo+xTts; Sat, 26 Apr 2008 07:35:14 -0700 (PDT) Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by core3.amsl.com (Postfix) with ESMTP id C899A3A67D7; Sat, 26 Apr 2008 07:35:13 -0700 (PDT) Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61929 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1JplUg-0002ud-D1; Sat, 26 Apr 2008 15:35:14 +0100 In-Reply-To: References: <480F8629.8080202@rogers.com> <097c01c8a73b$efe6f9a0$c2f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <40799673-8425-476F-ABA4-2FC49297BFF2@csperkins.org> From: Colin Perkins Date: Sat, 26 Apr 2008 15:35:11 +0100 To: Hadriel Kaplan X-Mailer: Apple Mail (2.753) Cc: 'MARJOU Xavier RD-MAPS-LAN' , 'Tom Taylor' , 'IETF AVT WG' , Dan Wing , "behave@ietf.org" Subject: Re: [BEHAVE] [AVT] Working Group LastCall: draft-ietf-avt-app-rtp-keepalive-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On 26 Apr 2008, at 02:57, Hadriel Kaplan wrote: ... >> I recall we asked for a fixed payload number for no-op a few >> years ago, but were told 'no'. Maybe that has changed; I >> do think it would be useful for this situation, but it only >> reduces the risk of a no-op packet being mis-identified as >> some sort of attack packet. > > It would do more than that. It would let monitoring software > (wireshark/whatever) identify it as a keepalive. It may let QoS > monitoring devices ignore it more easily. It would let middleboxes > detect it as a keepalive, instead of attack packets. It would let > DSP's have a way to off-load discarding of it. It would let SRTP > bump-in-the-wire chips or shims avoid calculating auth for it, on > both generation and reception. (because auth won't matter) > > If SDP negotiated it, that's possible too - but for this mechanism > I think a defined number makes sense, especially if we don't want > to use SDP. Static payload types were deprecated over a decade ago. Negotiating a no-op payload type in SDP makes sense, but I really don't want to revisit static assignments. >>> 3) I also still think there should be optional SDP for the >>> empty RTP keeaplive, just so that "evil" middleboxes trying >>> to protect devices can know they can let these things past. >>> >>> I realize that can't be done in a BCP, so I think >>> draft-ietf-avt-rtp-no-op-04 should *become* the empty RTP >>> keepalive, and define the SDP. (I'm not sure why it expired) >> >> Nobody seemed to need it. > > I find it odd that a WG BCP would recommend a mechanism (albeit a > fallback one), that is not itself defined in a standards track doc > anywhere. Maybe it's just me though. :) There were also concerns about having IPR on a no-op format, if I remember correctly. https://datatracker.ietf.org/ipr/854/ -- Colin Perkins http://csperkins.org/ _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Apr 26 09:16:20 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 154683A6D38; Sat, 26 Apr 2008 09:16:20 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F2A3A6A31; Sat, 26 Apr 2008 09:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaNL8zmNlqSt; Sat, 26 Apr 2008 09:16:18 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5E4EF3A6CED; Sat, 26 Apr 2008 09:15:57 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.263.0; Sat, 26 Apr 2008 12:15:28 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 26 Apr 2008 12:15:28 -0400 From: Hadriel Kaplan To: Colin Perkins Date: Sat, 26 Apr 2008 12:11:43 -0400 Thread-Topic: [AVT] Working Group LastCall: draft-ietf-avt-app-rtp-keepalive-03.txt Thread-Index: Acinqq5sMYO4v7BUTNKb3ggEAvF2fAAC3RmA Message-ID: References: <480F8629.8080202@rogers.com> <097c01c8a73b$efe6f9a0$c2f0200a@cisco.com> <40799673-8425-476F-ABA4-2FC49297BFF2@csperkins.org> In-Reply-To: <40799673-8425-476F-ABA4-2FC49297BFF2@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "behave@ietf.org" , Dan Wing , 'Cullen@core3.amsl.com, 'Tom Taylor' , AVT WG' , 'IETF@core3.amsl.com, 'MARJOU Xavier RD-MAPS-LAN' Subject: Re: [BEHAVE] [AVT] Working Group LastCall: draft-ietf-avt-app-rtp-keepalive-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > > Static payload types were deprecated over a decade ago. Negotiating a > no-op payload type in SDP makes sense, but I really don't want to > revisit static assignments. Yeah, I knew you'd say that. :) I'd be happy if there were at least some SDP indication. Even if the sender ignores the lack of it in received SDP and sends empty RTP anyway, it would be useful to have it indicate support for it and its PT in the SDP it sends. > > I find it odd that a WG BCP would recommend a mechanism (albeit a > > fallback one), that is not itself defined in a standards track doc > > anywhere. Maybe it's just me though. :) > > There were also concerns about having IPR on a no-op format, if I > remember correctly. https://datatracker.ietf.org/ipr/854/ I thought that was Cisco's classic defensive patent statement, which other IETF RFC's have been OK with. And I'm suggesting a different form of no-op: an empty one. Regardless, if an empty RTP is covered by that IPR, then so is this keepalive draft, no? -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Apr 26 09:17:08 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F22A28C19D; Sat, 26 Apr 2008 09:17:08 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0383A3A6B9E; Sat, 26 Apr 2008 09:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id at4KBQwRTOhW; Sat, 26 Apr 2008 09:17:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C9F853A6A31; Sat, 26 Apr 2008 09:17:04 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 26 Apr 2008 09:17:09 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3QGH9Ah013382; Sat, 26 Apr 2008 09:17:09 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m3QGH8nO022743; Sat, 26 Apr 2008 16:17:08 GMT From: "Dan Wing" To: "'Hadriel Kaplan'" , "'Tom Taylor'" , "'IETFAVT WG'" , References: <480F8629.8080202@rogers.com><097c01c8a73b$efe6f9a0$c2f0200a@cisco.com> Date: Sat, 26 Apr 2008 09:17:08 -0700 Message-ID: <0b0f01c8a7b8$fa1e2600$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Acilc5CY4IIjoR3jTRKh0H3OXBO5CQBkyupwAA0KnAAAAKSo4AADwIZg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3945; t=1209226629; x=1210090629; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20[AVT]=20Working=20GroupLastC all=3A=09draft-ietf-avt-app-rtp-keepalive-03.txt |Sender:=20; bh=5l6S4pDsAH7Mxog1woB+VRFCG2BcTEuZ8PZe/xTl9Dg=; b=CaquVVMOX6PGEcS5CNcLpnd1TMltJdqLv6xZ/3kXKJFASj8AfTO4te473E 6tU3Ac2QeY3VeNCLglBhrmfKL3L2LbctgNGtTLGQpv6sCyJFb6QGYIbfSYcA tNiW2PSLVO; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'MARJOU Xavier RD-MAPS-LAN' Subject: Re: [BEHAVE] [AVT] Working GroupLastCall: draft-ietf-avt-app-rtp-keepalive-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: Friday, April 25, 2008 6:57 PM > To: Dan Wing; 'Tom Taylor'; 'IETFAVT WG'; behave@ietf.org > Cc: 'MARJOU Xavier RD-MAPS-LAN' > Subject: Re: [BEHAVE] [AVT] Working GroupLastCall: > draft-ietf-avt-app-rtp-keepalive-03.txt > > > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > > > > c) Security section 8 is wrong - it *does* imply > > > security issues, clearly. So I recommend you add "Using the > > > mechanism in Section 4.7 could be perceived as an attack by > > > the peer. [RFC3550] explicitly stated devices MUST ignore > > > unknown payload formats, however security devices may block > > > such packets." Or something like that I guess. > > > > I agree some text should be added to address you point, but > > (going back to my point above that this draft describes how > > to keep your NAT mapping alive), we don't care if a device > > on the remote network drops the packet; the packet will have > > already traversed our NAT and kept our NAT's mapping alive. > > Yup, I realize it achieves that goal, and *I* don't care if a > SBC-type-thing blocks and discard the packet either, because > it achieves that goal - but that doesn't mean it has no > security implications if it goes direct, and this is a WG doc > after all. :) I don't know how the IETF could say something like "sending a bogus packet to a device might cause it to crash, due to a bug". I mean, nearly every implementation of every protocol has bugs in it, and negotiating a payload type via SDP does _not_ cause the bugs to go away -- some well-formed, legal RTP packet could still tickle a bug in an implementation. RTP options, for example; or RTP options combined with IP options (but, hey, everyone blocks IP options because those have all been found to be implemented too poorly...) > > I recall we asked for a fixed payload number for no-op a few > > years ago, but were told 'no'. Maybe that has changed; I > > do think it would be useful for this situation, but it only > > reduces the risk of a no-op packet being mis-identified as > > some sort of attack packet. > > It would do more than that. It would let monitoring software > (wireshark/whatever) identify it as a keepalive. It may let > QoS monitoring devices ignore it more easily. It would let > middleboxes detect it as a keepalive, instead of attack > packets. It would let DSP's have a way to off-load > discarding of it. It would let SRTP bump-in-the-wire chips > or shims avoid calculating auth for it, on both generation > and reception. (because auth won't matter) > > If SDP negotiated it, that's possible too - but for this > mechanism I think a defined number makes sense, especially if > we don't want to use SDP. All great reasons, in my opinion. Perhaps this can be re-visited. > > > 3) I also still think there should be optional SDP for the > > > empty RTP keeaplive, just so that "evil" middleboxes trying > > > to protect devices can know they can let these things past. > > > > > > I realize that can't be done in a BCP, so I think > > > draft-ietf-avt-rtp-no-op-04 should *become* the empty RTP > > > keepalive, and define the SDP. (I'm not sure why it expired) > > > > Nobody seemed to need it. > > I find it odd that a WG BCP would recommend a mechanism > (albeit a fallback one), that is not itself defined in a > standards track doc anywhere. Maybe it's just me though. :) I agree that sending an RTP payload type that was not negotiated in SDP is hard to justify in this document; afterall, you're Not Supposed To Need To Do That. But, pragmatically, you need to send *something*, or else the call will get torn down by the NAT. I am all for additional pragmatism. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Apr 26 10:10:18 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AACE03A6C33; Sat, 26 Apr 2008 10:10:17 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799663A6AC8; Sat, 26 Apr 2008 10:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8r9ICspcaS2; Sat, 26 Apr 2008 10:10:13 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7D48B3A6C33; Sat, 26 Apr 2008 10:10:12 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.263.0; Sat, 26 Apr 2008 13:09:43 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 26 Apr 2008 13:09:43 -0400 From: Hadriel Kaplan To: Dan Wing , 'Tom Taylor' , 'IETFAVT WG' , "behave@ietf.org" Date: Sat, 26 Apr 2008 13:05:59 -0400 Thread-Topic: [BEHAVE] [AVT] Working GroupLastCall: draft-ietf-avt-app-rtp-keepalive-03.txt Thread-Index: Acilc5CY4IIjoR3jTRKh0H3OXBO5CQBkyupwAA0KnAAAAKSo4AADwIZgABtzAfA= Message-ID: References: <480F8629.8080202@rogers.com><097c01c8a73b$efe6f9a0$c2f0200a@cisco.com> <0b0f01c8a7b8$fa1e2600$c2f0200a@cisco.com> In-Reply-To: <0b0f01c8a7b8$fa1e2600$c2f0200a@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: 'MARJOU Xavier RD-MAPS-LAN' Subject: Re: [BEHAVE] [AVT] Working GroupLastCall: draft-ietf-avt-app-rtp-keepalive-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > > I don't know how the IETF could say something like "sending a bogus > packet to a device might cause it to crash, due to a bug". I mean, > nearly every implementation of every protocol has bugs in it, and > negotiating a payload type via SDP does _not_ cause the bugs to > go away -- some well-formed, legal RTP packet could still tickle a > bug in an implementation. RTP options, for example; or RTP options > combined with IP options (but, hey, everyone blocks IP options > because those have all been found to be implemented too poorly...) Absolutely agree - and I'm not suggesting that "crash/bug" wording, nor that this means we shouldn't use this mechanism. :) For pragmatic reasons I agree with (and condone) sending the empty RTP. I think it will be very popular (though I prefer RTCP muxing, but that appears to be a higher bar for folks). I just think the security section shouldn't claim it has "no" implications. My argument is: (a) we have a defined mechanism for announcing dynamic payload types in SDP. (b) devices use that mechanism to indicate what they expect to receive. (c) we're ignoring that standardized announcement SDP mechanism and sending something they didn't indicate they expect to receive. Therefore (d) bad things may happen, due to the mechanism we're choosing. This isn't analogous to "legal RTP packets could still tickle bugs". That analogy breaks down because they're *legal* RTP packets conforming to the SDP mechanism we have in place for announcing them, and so on. This new mechanism is more analogous (although not identical) to the debate SIP WG had about sending STUN messages in the SIP port without any prior negotiation of support. Some argued legacy SIP servers should ignore it because it didn't conform to SIP ABNF and 3261 said to ignore it, and that if they didn't they were just poor designs. But that was not the issue in debate. We all agreed that was true. But the real issue that finally convinced people (I think) was that legacy SIP security devices would blacklist UA's sending the STUN, *because* it wasn't legal SIP. > > If SDP negotiated it, that's possible too - but for this > > mechanism I think a defined number makes sense, especially if > > we don't want to use SDP. > > All great reasons, in my opinion. Perhaps this can be re-visited. My spidey sense tells me we won't get a static payload for it. So I'd be happy with SDP indication. > > I find it odd that a WG BCP would recommend a mechanism > > (albeit a fallback one), that is not itself defined in a > > standards track doc anywhere. Maybe it's just me though. :) > > I agree that sending an RTP payload type that was not negotiated > in SDP is hard to justify in this document; afterall, you're Not > Supposed To Need To Do That. But, pragmatically, you need to send > *something*, or else the call will get torn down by the NAT. I am > all for additional pragmatism. Me too. So I think a wholesome-and-pragmatic way to do this is simply revive rtp-no-op, redefine it as the empty RTP packet, with a defined SDP, and WGLC it quickly. Then this BCP can point to that draft, and say "one could send rtp-no-op even if the peer does not indicate support for it in SDP, but one should still include its indication in the SDP". I don't think that's very hard to accomplish. -hadriel _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 27 07:27:20 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B123A6AFE; Sun, 27 Apr 2008 07:27:20 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 699363A6A59; Sun, 27 Apr 2008 07:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBzqtHbxAIRG; Sun, 27 Apr 2008 07:27:18 -0700 (PDT) Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by core3.amsl.com (Postfix) with ESMTP id 5EB903A6A0B; Sun, 27 Apr 2008 07:27:18 -0700 (PDT) Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:62518 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1Jq7qa-0001tb-Kp; Sun, 27 Apr 2008 15:27:20 +0100 In-Reply-To: References: <480F8629.8080202@rogers.com> <097c01c8a73b$efe6f9a0$c2f0200a@cisco.com> <40799673-8425-476F-ABA4-2FC49297BFF2@csperkins.org> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Colin Perkins Date: Sun, 27 Apr 2008 15:27:17 +0100 To: Hadriel Kaplan X-Mailer: Apple Mail (2.753) Cc: MARJOU Xavier RD-MAPS-LAN , Tom Taylor , IETF AVT WG , Dan Wing , "behave@ietf.org WG" Subject: Re: [BEHAVE] [AVT] Working Group LastCall: draft-ietf-avt-app-rtp-keepalive-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On 26 Apr 2008, at 17:11, Hadriel Kaplan wrote: >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> >> Static payload types were deprecated over a decade ago. Negotiating a >> no-op payload type in SDP makes sense, but I really don't want to >> revisit static assignments. > > Yeah, I knew you'd say that. :) > I'd be happy if there were at least some SDP indication. Even if > the sender ignores the lack of it in received SDP and sends empty > RTP anyway, it would be useful to have it indicate support for it > and its PT in the SDP it sends. Sure, I have no argument with that. >>> I find it odd that a WG BCP would recommend a mechanism (albeit a >>> fallback one), that is not itself defined in a standards track doc >>> anywhere. Maybe it's just me though. :) >> >> There were also concerns about having IPR on a no-op format, if I >> remember correctly. https://datatracker.ietf.org/ipr/854/ > > I thought that was Cisco's classic defensive patent statement, > which other IETF RFC's have been OK with. And I'm suggesting a > different form of no-op: an empty one. Regardless, if an empty RTP > is covered by that IPR, then so is this keepalive draft, no? Possibly - you'd have to ask Cisco. -- Colin Perkins http://csperkins.org/ _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Apr 27 10:16:48 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8809F28C113; Sun, 27 Apr 2008 10:16:48 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48E63A6C01; Sun, 27 Apr 2008 10:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0upZZ9OsTEgA; Sun, 27 Apr 2008 10:16:46 -0700 (PDT) Received: from mailman.packetdesign.com (firewall-gw-dirty-n.packetdesign.com [65.87.20.98]) by core3.amsl.com (Postfix) with ESMTP id 3F0B33A68CC; Sun, 27 Apr 2008 10:16:46 -0700 (PDT) Received: from packetdesign.com (dns.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.13.1/8.13.1) with ESMTP id m3RHGW6X001427; Sun, 27 Apr 2008 10:16:32 -0700 Date: Sun, 27 Apr 2008 10:16:33 -0700 (PDT) From: Stephen Casner To: Colin Perkins In-Reply-To: Message-ID: References: <480F8629.8080202@rogers.com> <097c01c8a73b$efe6f9a0$c2f0200a@cisco.com> <40799673-8425-476F-ABA4-2FC49297BFF2@csperkins.org> MIME-Version: 1.0 Cc: MARJOU Xavier RD-MAPS-LAN , Tom Taylor , IETF AVT WG , Dan Wing , "behave@ietf.org WG" Subject: Re: [BEHAVE] [AVT] Working Group LastCall: draft-ietf-avt-app-rtp-keepalive-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Sun, 27 Apr 2008, Colin Perkins wrote: > On 26 Apr 2008, at 17:11, Hadriel Kaplan wrote: >>> -----Original Message----- >>> From: Colin Perkins [mailto:csp@csperkins.org] >>> >>> Static payload types were deprecated over a decade ago. Negotiating a >>> no-op payload type in SDP makes sense, but I really don't want to >>> revisit static assignments. >> >> Yeah, I knew you'd say that. :) >> I'd be happy if there were at least some SDP indication. Even if >> the sender ignores the lack of it in received SDP and sends empty >> RTP anyway, it would be useful to have it indicate support for it >> and its PT in the SDP it sends. > > Sure, I have no argument with that. I'd be willing to have my arm twisted for defining a static PT because I could be convinced that this is a special case. However, it seems to me that it would not help the backwards compatibility problem at all. Old receivers that were unprepared for it, or that implemented strict conformance requirements, would still have a problem. It seems that the SDP negotiation at least lets a new sender know that an old receiver might fail. -- Steve _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 28 11:19:13 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74CD3A6BE9; Mon, 28 Apr 2008 11:19:13 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26CC13A6D99 for ; Mon, 28 Apr 2008 11:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N08642lsvuJc for ; Mon, 28 Apr 2008 11:19:03 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id B6B863A69C8 for ; Mon, 28 Apr 2008 11:19:03 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 3D34A29E1481; Mon, 28 Apr 2008 14:18:37 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 3594029E1457 for ; Mon, 28 Apr 2008 14:18:37 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: "Behave WG" Date: Mon, 28 Apr 2008 14:18:36 -0400 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804281418.36762.simon.perreault@viagenie.ca> Subject: [BEHAVE] [TURN] Response to a bad Send Indication X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hello, From [draft-ietf-behave-turn-07], Section 9.2: The resulting UDP datagram is then sent to the peer. If any errors are detected during this process (e.g., the Send indication does not contain a PEER-ADDRESS attribute), the received indication is silently discarded and no UDP datagram is sent. Wouldn't it be better to send a 400 Bad Request to the client instead? Thanks, Simon _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Apr 28 12:17:39 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC6A328C2C9; Mon, 28 Apr 2008 12:17:38 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C88FF28C2A8 for ; Mon, 28 Apr 2008 12:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyQTq52jYVwS for ; Mon, 28 Apr 2008 12:17:33 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 6D31528C30F for ; Mon, 28 Apr 2008 12:16:40 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id DF65329E148F; Mon, 28 Apr 2008 15:16:13 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id D649929E1457 for ; Mon, 28 Apr 2008 15:16:13 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: behave@ietf.org Date: Mon, 28 Apr 2008 15:16:13 -0400 User-Agent: KMail/1.9.9 References: <200804281418.36762.simon.perreault@viagenie.ca> In-Reply-To: <200804281418.36762.simon.perreault@viagenie.ca> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804281516.13654.simon.perreault@viagenie.ca> Subject: Re: [BEHAVE] [TURN] Response to a bad Send Indication X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Monday 28 April 2008 14:18:36 Simon Perreault wrote: > The resulting UDP datagram is then sent to the peer. If any errors > are detected during this process (e.g., the Send indication does not > contain a PEER-ADDRESS attribute), the received indication is > silently discarded and no UDP datagram is sent. > > Wouldn't it be better to send a 400 Bad Request to the client instead? I just realized that this is an Indication and as such never receives any response. Nothing to see here, move along... _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Apr 29 06:12:09 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3D083A6D75; Tue, 29 Apr 2008 06:12:09 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA143A6D7B for ; Tue, 29 Apr 2008 06:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcLLrBxZBJLm for ; Tue, 29 Apr 2008 06:12:08 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id D25523A6D75 for ; Tue, 29 Apr 2008 06:12:07 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 9597B29E1488; Tue, 29 Apr 2008 09:11:37 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 8D4A729E1461; Tue, 29 Apr 2008 09:11:37 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: Gonzalo.Camarillo@ericsson.com, Oscar.Novo@ericsson.com Date: Tue, 29 Apr 2008 09:11:31 -0400 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804290911.32173.simon.perreault@viagenie.ca> Cc: behave@ietf.org Subject: [BEHAVE] Comments on draft-ietf-behave-turn-ipv6-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hello, I had a first reading of draft-ietf-behave-turn-ipv6-04. Here are a few comments. 1. Last paragraph of section 4.1: The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate Requests. This is in contradiction with section 4.2 which describes the usage of REQUESTED-ADDRESS-TYPE in the Refresh request. Also, s/REQUEST/REQUESTED/. 2. In section 4.2, there is confusing talk about bindings. Please s/binding/allocation/ because you do not want to confuse the reader with STUN bindings when you're really talking about TURN allocations. 3. In section 4.2: If the Allocate Response contains the same transport address as previously obtained, the binding has been refreshed. There's an "else" missing. I suggest that server refresh the allocation if the REQUESTED-ADDRESS-TYPE attribute is missing or of the same type as previously allocated. If it is present but of the wrong family, reply with a 400 Bad Request. 4. The last paragraph of section 5.1: If the REQUESTED-ADDRESS-TYPE attribute is absent, the server MUST allocate a IPv4 transport address to the TURN client. This is incompatible with the current TURN draft, which says that the relayed address must be of the same family as the mapped address, which may be IPv6. Otherwise, this draft is very straightforward and easy to understand. Thanks, Simon _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave