From safe-bounces@ietf.org Tue Nov 06 12:10:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpRwQ-0003zT-JJ; Tue, 06 Nov 2007 12:10:18 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IpRwP-0003zN-P5 for safe-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 12:10:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpRwP-0003zE-Ek for safe@ietf.org; Tue, 06 Nov 2007 12:10:17 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpRwL-0001Nk-Ur for safe@ietf.org; Tue, 06 Nov 2007 12:10:17 -0500 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:49674) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IpRwL-0006Xh-9X; Tue, 06 Nov 2007 17:10:13 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Tue, 6 Nov 2007 17:10:10 +0000 To: safe@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [SAFE] BOF in Vancouver X-BeenThere: safe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Self-Address Fixing Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: safe-bounces@ietf.org The IESG has approved a SAFE BOF for the Vancouver IETF meeting. The chairs will be myself and Markus Isomaki . We're putting together an updated BOF description and agenda now - expect more details in the next few days. Regards, -- Colin Perkins http://csperkins.org/ _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Fri Nov 16 08:59:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It1je-000271-1m; Fri, 16 Nov 2007 08:59:54 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1It1jd-00024X-3f for safe-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 08:59:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It1jX-0001u0-Dc; Fri, 16 Nov 2007 08:59:47 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It1jW-0001Rq-P3; Fri, 16 Nov 2007 08:59:47 -0500 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:55087) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1It1jV-00053Y-UC; Fri, 16 Nov 2007 13:59:45 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <351D0D85-DE60-4F47-8D16-E61B6799EC79@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Fri, 16 Nov 2007 13:59:53 +0000 To: ietf@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: safe@ietf.org, "Isomaki Markus \(Nokia-SIR/Espoo\)" Subject: [SAFE] SAFE BoF in Vancouver X-BeenThere: safe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: safe@ietf.org List-Id: Self-Address Fixing Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: safe-bounces@ietf.org The following BoF has been proposed for the Vancouver IETF. There is a mailing list for discussion. Colin SAFE - Self-Address Fixing Evolution BoF ---------------------------------------- Chairs: Colin Perkins (csp@csperkins.org) Markus Isomaki (Markus.Isomaki@nokia.com) Mailing list: https://www1.ietf.org/mailman/listinfo/safe Various NAT hole-punching techniques such as IPsec NAT traversal, Teredo, and STUN/ICE send periodic UDP keep-alive messages to keep their NAT binding alive. However, a drawback of these techniques is their chattiness which is a result of the host application not knowing the NAT's binding lifetime (IPsec NAT traversal, STUN/ICE) or because the application is unable to extend the lifetime of the NAT's binding (Teredo). The endpoint has to send periodic packets which consume power on battery powered devices, consume network bandwidth, and place an unnecessary load on servers. There are two approaches to resolve the problem of chattiness. The first is to interact directly with the NAT using a NAT control protocol. Several of these protocols exist which unfortunately have different drawbacks: * incremental deployment is not possible with MIDCOM, NSIS-NSLP, UPnP IGD, or NAT-PMP. With all of these protocols, both the NAT and the endpoint have to support the same protocol * nested NATs are not possible with UPnP IGD or NAT-PMP * topology awareness is required of MIDCOM * security must be established between the controlling entity and the NAT for MIDCOM and NSIS-NSLP * UPnP IGD uses broadcasts packets and NAT-PMP expects the NAT to be the default gateway; neither work well on routed networks The second approach is to empirically test the NAT's binding lifetime, as done by Teredo. This can optimise the keep-alive traffic based on the NAT's binding lifetime, but cannot extend the duration of the binding lifetime. Also, empirical testing does not always give reliable results due to varying behaviour of NAT and firewall implementations. This BoF is intended to discuss a newly-proposed technique for using STUN to discover, query and control firewalls and NATs, that can eliminate UDP keep-alive traffic. The BoF will review the problem space and existing work, and decide if there is a need for new work in the area, and if the IETF is an appropriate home for that work. The intent is not to form a new working group at this time, but to gauge interest in work in this area, and consider an appropriate future home for that work. Agenda: Introduction ...................................... (Chairs, 10) Problem statement and scope ......................... (Wing, 15) Survey of existing work ........................... (Barnes, 30) draft-eggert-middlebox-control-survey-01.txt NAT/Firewall control with STUN ...................... (Wing, 15) draft-wing-behave-nat-control-stun-usage-05.txt Discussion ................................................ (20) Future directions ................................. (Chairs, 30) -- version: 1.5, 16-Nov-2007 _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Fri Nov 16 16:03:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It8LE-0001S6-FG; Fri, 16 Nov 2007 16:03:08 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1It8LD-0001Qy-Bx for safe-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 16:03:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It8LC-0001OF-Mz; Fri, 16 Nov 2007 16:03:06 -0500 Received: from mx1.its.eads.net ([193.56.40.66]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It8LA-0001CC-KT; Fri, 16 Nov 2007 16:03:06 -0500 Received: from fr-gate2.mailhub.intra.corp ([53.154.16.34]) by mx1.its.eads.net with Microsoft SMTPSVC(6.0.3790.2499); Fri, 16 Nov 2007 21:42:22 +0100 Received: from sfrsu801.hq.corp ([10.21.8.23]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Nov 2007 21:47:56 +0100 Received: from mail pickup service by sfrsu801.hq.corp with Microsoft SMTPSVC; Fri, 16 Nov 2007 21:44:39 +0100 Received: from sdeot801.hq.corp ([53.141.195.14]) by sfrsu800.hq.corp with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 15:03:36 +0100 Received: from eadsvpxy3.muc.debis.de ([53.154.240.140]) by sdeot801.hq.corp with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 15:03:00 +0100 Received: from mail.eads.net (localhost [127.0.0.1]) by eadsvpxy3.muc.debis.de (8.12.10+Sun/8.12.10) with ESMTP id lAGE0UmN029244 for ; Fri, 16 Nov 2007 15:00:30 +0100 (MET) Received: from megatron.ietf.org (optimus.ietf.ORG [156.154.16.145]) by mail.eads.net (8.13.8/8.13.8/Debian-2) with ESMTP id lAGE0XBe015900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 16 Nov 2007 15:00:34 +0100 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It1je-00027G-CI; Fri, 16 Nov 2007 08:59:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It1jX-0001u0-Dc; Fri, 16 Nov 2007 08:59:47 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It1jW-0001Rq-P3; Fri, 16 Nov 2007 08:59:47 -0500 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:55087) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1It1jV-00053Y-UC; Fri, 16 Nov 2007 13:59:45 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <351D0D85-DE60-4F47-8D16-E61B6799EC79@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Fri, 16 Nov 2007 13:59:53 +0000 To: ietf@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Scanned-By: MIMEDefang 2.56 on 80.156.44.72 X-OriginalArrivalTime: 16 Nov 2007 14:03:00.0477 (UTC) FILETIME=[65C68AD0:01C82859] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: safe@ietf.org Subject: [SAFE] SAFE BoF in Vancouver X-BeenThere: safe@ietf.org Reply-To: safe@ietf.org List-Id: Self-Address Fixing Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: safe-bounces@ietf.org The following BoF has been proposed for the Vancouver IETF. There is a mailing list for discussion. Colin SAFE - Self-Address Fixing Evolution BoF ---------------------------------------- Chairs: Colin Perkins (csp@csperkins.org) Markus Isomaki (Markus.Isomaki@nokia.com) Mailing list: https://www1.ietf.org/mailman/listinfo/safe Various NAT hole-punching techniques such as IPsec NAT traversal, Teredo, and STUN/ICE send periodic UDP keep-alive messages to keep their NAT binding alive. However, a drawback of these techniques is their chattiness which is a result of the host application not knowing the NAT's binding lifetime (IPsec NAT traversal, STUN/ICE) or because the application is unable to extend the lifetime of the NAT's binding (Teredo). The endpoint has to send periodic packets which consume power on battery powered devices, consume network bandwidth, and place an unnecessary load on servers. There are two approaches to resolve the problem of chattiness. The first is to interact directly with the NAT using a NAT control protocol. Several of these protocols exist which unfortunately have different drawbacks: * incremental deployment is not possible with MIDCOM, NSIS-NSLP, UPnP IGD, or NAT-PMP. With all of these protocols, both the NAT and the endpoint have to support the same protocol * nested NATs are not possible with UPnP IGD or NAT-PMP * topology awareness is required of MIDCOM * security must be established between the controlling entity and the NAT for MIDCOM and NSIS-NSLP * UPnP IGD uses broadcasts packets and NAT-PMP expects the NAT to be the default gateway; neither work well on routed networks The second approach is to empirically test the NAT's binding lifetime, as done by Teredo. This can optimise the keep-alive traffic based on the NAT's binding lifetime, but cannot extend the duration of the binding lifetime. Also, empirical testing does not always give reliable results due to varying behaviour of NAT and firewall implementations. This BoF is intended to discuss a newly-proposed technique for using STUN to discover, query and control firewalls and NATs, that can eliminate UDP keep-alive traffic. The BoF will review the problem space and existing work, and decide if there is a need for new work in the area, and if the IETF is an appropriate home for that work. The intent is not to form a new working group at this time, but to gauge interest in work in this area, and consider an appropriate future home for that work. Agenda: Introduction ...................................... (Chairs, 10) Problem statement and scope ......................... (Wing, 15) Survey of existing work ........................... (Barnes, 30) draft-eggert-middlebox-control-survey-01.txt NAT/Firewall control with STUN ...................... (Wing, 15) draft-wing-behave-nat-control-stun-usage-05.txt Discussion ................................................ (20) Future directions ................................. (Chairs, 30) -- version: 1.5, 16-Nov-2007 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Tue Nov 20 14:37:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYv0-0000lZ-4n; Tue, 20 Nov 2007 14:37:58 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IuYS7-0006jS-5f for safe-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 14:08:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYS2-0006iu-10; Tue, 20 Nov 2007 14:08:02 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuYRy-0004zw-67; Tue, 20 Nov 2007 14:08:01 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lAKJ7sw1022605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Nov 2007 11:07:54 -0800 Received: from [67.169.50.136] (vpn-10-50-0-144.qualcomm.com [10.50.0.144]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lAKJ7p68001738; Tue, 20 Nov 2007 11:07:52 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <351D0D85-DE60-4F47-8D16-E61B6799EC79@csperkins.org> References: <351D0D85-DE60-4F47-8D16-E61B6799EC79@csperkins.org> Date: Tue, 20 Nov 2007 11:07:55 -0800 To: safe@ietf.org, ietf@ietf.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: -4.0 (----) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-Mailman-Approved-At: Tue, 20 Nov 2007 14:37:57 -0500 Cc: Subject: [SAFE] Re: SAFE BoF in Vancouver X-BeenThere: safe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Self-Address Fixing Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: safe-bounces@ietf.org At 1:59 PM +0000 11/16/07, Colin Perkins wrote: >The following BoF has been proposed for the Vancouver IETF. There is a mailing list for discussion. > >Colin This seems to be scheduled against both the Applications area open meeting and a RAI group focused on media servers. Both groups would have an interest in following this work and discussing where future IETF work in this area will happen. Is there still a possibility of adjusting this timing? I understand, of course, that not every conflict can be resolved, but it would be useful to know whether this is still something that might be addressed. regards, Ted Hardie > > > >SAFE - Self-Address Fixing Evolution BoF >---------------------------------------- > >Chairs: > Colin Perkins (csp@csperkins.org) > Markus Isomaki (Markus.Isomaki@nokia.com) > >Mailing list: > https://www1.ietf.org/mailman/listinfo/safe > >Various NAT hole-punching techniques such as IPsec NAT traversal, Teredo, and STUN/ICE send periodic UDP keep-alive messages to keep their NAT binding alive. > >However, a drawback of these techniques is their chattiness which is a result of the host application not knowing the NAT's binding lifetime (IPsec NAT traversal, STUN/ICE) or because the application is unable to extend the lifetime of the NAT's binding (Teredo). The endpoint has to send periodic packets which consume power on battery powered devices, consume network bandwidth, and place an unnecessary load on servers. > >There are two approaches to resolve the problem of chattiness. The first is to interact directly with the NAT using a NAT control protocol. Several of these protocols exist which unfortunately have different drawbacks: > > * incremental deployment is not possible with MIDCOM, NSIS-NSLP, > UPnP IGD, or NAT-PMP. With all of these protocols, both the NAT > and the endpoint have to support the same protocol > * nested NATs are not possible with UPnP IGD or NAT-PMP > * topology awareness is required of MIDCOM > * security must be established between the controlling entity and > the NAT for MIDCOM and NSIS-NSLP > * UPnP IGD uses broadcasts packets and NAT-PMP expects the NAT to be > the default gateway; neither work well on routed networks > >The second approach is to empirically test the NAT's binding lifetime, as done by Teredo. This can optimise the keep-alive traffic based on the NAT's binding lifetime, but cannot extend the duration of the binding lifetime. Also, empirical testing does not always give reliable results due to varying behaviour of NAT and firewall implementations. > >This BoF is intended to discuss a newly-proposed technique for using STUN to discover, query and control firewalls and NATs, that can eliminate UDP >keep-alive traffic. The BoF will review the problem space and existing work, and decide if there is a need for new work in the area, and if the IETF is an appropriate home for that work. The intent is not to form a new working group at this time, but to gauge interest in work in this area, and consider an appropriate future home for that work. > > >Agenda: > Introduction ...................................... (Chairs, 10) > Problem statement and scope ......................... (Wing, 15) > Survey of existing work ........................... (Barnes, 30) > draft-eggert-middlebox-control-survey-01.txt > NAT/Firewall control with STUN ...................... (Wing, 15) > draft-wing-behave-nat-control-stun-usage-05.txt > Discussion ................................................ (20) > Future directions ................................. (Chairs, 30) > > >-- >version: 1.5, 16-Nov-2007 > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Tue Nov 20 18:38:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iucfa-0002EK-A9; Tue, 20 Nov 2007 18:38:18 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IucfZ-0002E0-MI for safe-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 18:38:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IucfZ-0002Dr-8P; Tue, 20 Nov 2007 18:38:17 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IucfY-00022y-Sb; Tue, 20 Nov 2007 18:38:17 -0500 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:60554 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IucfX-0003Ts-1v; Tue, 20 Nov 2007 23:38:15 +0000 In-Reply-To: References: <351D0D85-DE60-4F47-8D16-E61B6799EC79@csperkins.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Tue, 20 Nov 2007 23:38:25 +0000 To: Ted Hardie X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: safe@ietf.org, ietf@ietf.org Subject: [SAFE] Re: SAFE BoF in Vancouver X-BeenThere: safe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Self-Address Fixing Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: safe-bounces@ietf.org On 20 Nov 2007, at 19:07, Ted Hardie wrote: > At 1:59 PM +0000 11/16/07, Colin Perkins wrote: >> The following BoF has been proposed for the Vancouver IETF. There >> is a mailing list for discussion. > > This seems to be scheduled against both the Applications area open > meeting and a RAI group focused on media servers. Both groups > would have an interest in following this work and discussing where > future IETF work in this area will happen. Is there still a > possibility of adjusting this timing? I understand, of course, > that not every conflict can be resolved, but it would be useful to > know whether this is still something that might be addressed. We're aware of the conflicts, but this is the least bad scheduling we've been able to find. If you have suggestions for a better slot, we're open to ideas. Regards, Colin _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Tue Nov 20 18:54:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iucvc-0001gB-4T; Tue, 20 Nov 2007 18:54:52 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1Iucva-0001Yd-Td for safe-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 18:54:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iucva-0001YG-Jj; Tue, 20 Nov 2007 18:54:50 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IucvX-0000VJ-3D; Tue, 20 Nov 2007 18:54:50 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lAKNsiEJ027357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Nov 2007 15:54:44 -0800 Received: from [67.169.50.136] (vpn-10-50-0-144.qualcomm.com [10.50.0.144]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lAKNsgRO001637; Tue, 20 Nov 2007 15:54:43 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <351D0D85-DE60-4F47-8D16-E61B6799EC79@csperkins.org> Date: Tue, 20 Nov 2007 15:54:46 -0800 To: Colin Perkins From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: safe@ietf.org, ietf@ietf.org Subject: [SAFE] Re: SAFE BoF in Vancouver X-BeenThere: safe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Self-Address Fixing Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: safe-bounces@ietf.org At 11:38 PM +0000 11/20/07, Colin Perkins wrote: >On 20 Nov 2007, at 19:07, Ted Hardie wrote: >>At 1:59 PM +0000 11/16/07, Colin Perkins wrote: >>>The following BoF has been proposed for the Vancouver IETF. There is a mailing list for discussion. >> >>This seems to be scheduled against both the Applications area open meeting and a RAI group focused on media servers. Both groups would have an interest in following this work and discussing where future IETF work in this area will happen. Is there still a possibility of adjusting this timing? I understand, of course, that not every conflict can be resolved, but it would be useful to know whether this is still something that might be addressed. > >We're aware of the conflicts, but this is the least bad scheduling we've been able to find. If you have suggestions for a better slot, we're open to ideas. Friday morning? There are no APPs or TSV groups meeting then, and the RAI group is GeoPRIV, which wouldn't have as high an overlap as most other RAI groups. Again, I know we can resolve every conflict, and I appreciate your considering changes. regards, Ted _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Tue Nov 20 19:46:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IudjZ-00036c-GL; Tue, 20 Nov 2007 19:46:29 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IudjY-00030d-HT for safe-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 19:46:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IudjY-00030D-7F; Tue, 20 Nov 2007 19:46:28 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IudjT-0001pu-V5; Tue, 20 Nov 2007 19:46:28 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lAL0kKwC031583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Nov 2007 16:46:21 -0800 Received: from [67.169.50.136] (vpn-10-50-0-144.qualcomm.com [10.50.0.144]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lAL0kJ7S014158; Tue, 20 Nov 2007 16:46:19 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <351D0D85-DE60-4F47-8D16-E61B6799EC79@csperkins.org> Date: Tue, 20 Nov 2007 16:46:22 -0800 To: "James M. Polk" , Colin Perkins From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: safe@ietf.org, ietf@ietf.org Subject: [SAFE] Re: SAFE BoF in Vancouver X-BeenThere: safe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Self-Address Fixing Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: safe-bounces@ietf.org At 6:38 PM -0600 11/20/07, James M. Polk wrote: >But Ted, you're going to Geopriv? So how does this work? Hi James, I'm trying to focus on the general problem (particularly the apps open conflict), rather than my own ability to be there. I'm conflicted either way, but lots of other APPs people would be free on Friday. Similar for MEDIACTRL; some might still be conflicted, but a larger number would be free. I understand from Mary Barnes that she would have a conflict with the Friday slot, so it may be unsolvable, but I hope there may still be a way. regards, Ted > >>Again, I know we can resolve every conflict, and I appreciate your considering changes. >> regards, >> Ted >> >>_______________________________________________ >>Ietf mailing list >>Ietf@ietf.org >>https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Tue Nov 20 20:10:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iue7H-0001XI-2N; Tue, 20 Nov 2007 20:10:59 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1Iue7E-0001Jt-HW for safe-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 20:10:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iue7D-0001Bg-KL; Tue, 20 Nov 2007 20:10:55 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iue7C-0004ys-TQ; Tue, 20 Nov 2007 20:10:55 -0500 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:60857 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1Iue7B-0007dQ-H6; Wed, 21 Nov 2007 01:10:53 +0000 In-Reply-To: References: <351D0D85-DE60-4F47-8D16-E61B6799EC79@csperkins.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Wed, 21 Nov 2007 01:11:02 +0000 To: Ted Hardie X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: safe@ietf.org, "James M. Polk" , ietf@ietf.org Subject: [SAFE] Re: SAFE BoF in Vancouver X-BeenThere: safe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Self-Address Fixing Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: safe-bounces@ietf.org On 21 Nov 2007, at 00:46, Ted Hardie wrote: > At 6:38 PM -0600 11/20/07, James M. Polk wrote: >> But Ted, you're going to Geopriv? So how does this work? > > I'm trying to focus on the general problem (particularly the > apps open conflict), rather than my own ability to be there. I'm > conflicted either way, but lots of other APPs people would be free > on Friday. Similar for MEDIACTRL; some might still be conflicted, > but a larger number would be free. I understand from Mary Barnes > that she would have a conflict with the Friday slot, so it may be > unsolvable, but I hope there may still be a way. There's also a desire to avoid BoFs late in the week, to give time for hallway discussions on the outcome (as Pete Resnick has just mentioned on the WG chairs list). -- Colin Perkins http://csperkins.org/ _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Tue Nov 20 21:00:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuetV-0004eL-DU; Tue, 20 Nov 2007 21:00:49 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IudcC-0000MV-7V for safe-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 19:38:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IudcB-0000MM-Sj; Tue, 20 Nov 2007 19:38:51 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IudcB-0003zy-HC; Tue, 20 Nov 2007 19:38:51 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 20 Nov 2007 16:38:50 -0800 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 lAL0coon017238; Tue, 20 Nov 2007 16:38:50 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAL0cYHG013015; Wed, 21 Nov 2007 00:38:50 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 16:38:45 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.148.187]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 16:38:45 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Nov 2007 18:38:44 -0600 To: Ted Hardie , Colin Perkins From: "James M. Polk" In-Reply-To: References: <351D0D85-DE60-4F47-8D16-E61B6799EC79@csperkins.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 21 Nov 2007 00:38:45.0169 (UTC) FILETIME=[DF6FA210:01C82BD6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1531; t=1195605530; x=1196469530; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20SAFE=20BoF=20in=20Vancouver |Sender:=20; bh=mvLrP0bo2WLSX5+sT38m5IEUNj8NEhXGhi9Zr4IC+u8=; b=h9dlPyKxDCNPxi+m4IYinM2Ak19gyVH8dSeCM5XtzGeMf9/8OiJ23oFxOPrJ2lXomnCPwLCE yaxM955lvnFKh8/oMw+Xr93jZp2TSTd36oh2tyLBj8rAQgUrLG2+9xalo2YhNqYV7nbwfWK03U 2766rZTcPrrKVNTAOSiI7EsAk=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-Mailman-Approved-At: Tue, 20 Nov 2007 21:00:48 -0500 Cc: safe@ietf.org, ietf@ietf.org Subject: [SAFE] Re: SAFE BoF in Vancouver X-BeenThere: safe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Self-Address Fixing Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: safe-bounces@ietf.org At 05:54 PM 11/20/2007, Ted Hardie wrote: >At 11:38 PM +0000 11/20/07, Colin Perkins wrote: > >On 20 Nov 2007, at 19:07, Ted Hardie wrote: > >>At 1:59 PM +0000 11/16/07, Colin Perkins wrote: > >>>The following BoF has been proposed for the Vancouver IETF. > There is a mailing list for discussion. > >> > >>This seems to be scheduled against both the Applications area > open meeting and a RAI group focused on media servers. Both groups > would have an interest in following this work and discussing where > future IETF work in this area will happen. Is there still a > possibility of adjusting this timing? I understand, of course, > that not every conflict can be resolved, but it would be useful to > know whether this is still something that might be addressed. > > > >We're aware of the conflicts, but this is the least bad scheduling > we've been able to find. If you have suggestions for a better slot, > we're open to ideas. > >Friday morning? There are no APPs or TSV groups meeting then, and >the RAI group is >GeoPRIV, which wouldn't have as high an overlap as most other RAI groups. But Ted, you're going to Geopriv? So how does this work? >Again, I know we can resolve every conflict, and I appreciate your >considering changes. > regards, > Ted > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Wed Nov 21 08:15:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IupQI-0005qR-VF; Wed, 21 Nov 2007 08:15:22 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IupQF-0005mo-Q9 for safe-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 08:15:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IupQA-0005Jh-6v; Wed, 21 Nov 2007 08:15:14 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IupQ7-0004Qm-Kr; Wed, 21 Nov 2007 08:15:14 -0500 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 lALDES5D032220; Wed, 21 Nov 2007 07:15:11 -0600 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 15:14:15 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 14:19:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Nov 2007 14:19:07 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SAFE BoF in Vancouver Thread-Index: AcgrqO+PnbiWM/VaTxm2Zs0aqQ82YAAi1Nuw References: <351D0D85-DE60-4F47-8D16-E61B6799EC79@csperkins.org> From: To: , , X-OriginalArrivalTime: 21 Nov 2007 12:19:08.0986 (UTC) FILETIME=[B79539A0:01C82C38] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Subject: [SAFE] RE: SAFE BoF in Vancouver X-BeenThere: safe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Self-Address Fixing Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: safe-bounces@ietf.org Hi Ted, Ted Hardie [mailto:hardie@qualcomm.com] wrote:=20 > >At 1:59 PM +0000 11/16/07, Colin Perkins wrote: >>The following BoF has been proposed for the Vancouver IETF.=20 >There is a mailing list for discussion. >> >>Colin > >This seems to be scheduled against both the Applications area=20 >open meeting and a RAI group focused on media servers. Both=20 >groups would have an interest in following this work and=20 >discussing where future IETF work in this area will happen. >Is there still a possibility of adjusting this timing? I=20 >understand, of course, that not every conflict can be=20 >resolved, but it would be useful to know whether this is still=20 >something that might be addressed. > regards, > Ted Hardie > As Colin pointed out, it migth be difficult to reschedule the BoF to a better slot, especially if Friday is considered as a bad day for BoFs in general. However, I agree that middlebox control should be quite relevant to Applications community (inside and outside the IETF), also for reasons that may not be so well known yet. In general most application protocols that the IETF has developed already deal relatively well with NATs, and methods such as ICE, hole punching, symmetric RTP/UDP, persistent TCP/TLS connections are well known. The apps community outside the IETF is actually doing better (with Skype etc.), since they know that NAT traversal is a must-have feature to get anything deployed. But what is not necessarily that well known is that even if the best of these methods are used, "non-controllable" middleboxes still cause constraints on how certain applications can be used in battery-powered devices using wireless access networks. This is because the frequent keepalives sent to maintain state in the middleboxes are a huge source of power consumption. Many wide-area radio technologies (where endpoints mostly are battery-powered) have been optimized for saving power when there is nothing to send/receive. These schemes become quite useless if there are multiple applications generating keepalive traffic just to keep connected. UDP is basically totally out of question (as a transport for long-lived app sessions) for its typical sub-one-minute keepalive rate. TCP is better, but even that has visible effects on the battery lifetime and when there are multiple applications the overall rate becomes quite a problem. With IPv4 address exhaustion I'm worried that we will see multiple layers of NATs in many networks, so working with that kind of scenarios seems more and more relevant. (Currently e.g. UPnP does not address this.) Also we should consider Ipv6/IPv4 translation issues and IPv6 firewalls. So, at this point the folks designing e.g. VPN, VoIP, IM, "push" e-mail and various other apps requiring persistent connectivity for wireless devices should be aware of this issue and should be quite motivated to solve these problems in one way or another. Not to mention people with interest in running P2P apps or more genral servers in such devices. Migrating to IPv6 is a good long-term solution, but even then and especially in the meanwhile middlebox control is important. Perhaps an excplicit control protocol is not always needed, but a discovery mechnisms (how to optimize the keepalive rate) seems like a mandatory ingredient. Markus =20 _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Wed Nov 21 10:53:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IurtB-0001dT-4P; Wed, 21 Nov 2007 10:53:21 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1Iurt9-0001dN-NM for safe-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 10:53:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iurt9-0001dF-Do for safe@ietf.org; Wed, 21 Nov 2007 10:53:19 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iurt4-0000nW-T2 for safe@ietf.org; Wed, 21 Nov 2007 10:53:19 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lALFqwq9013561 for ; Wed, 21 Nov 2007 17:53:13 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 17:52:37 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 17:52:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [SAFE] SAFE BoF in Vancouver Date: Wed, 21 Nov 2007 17:52:36 +0200 Message-ID: In-Reply-To: <351D0D85-DE60-4F47-8D16-E61B6799EC79@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SAFE] SAFE BoF in Vancouver Thread-Index: AcgoWPpKEyLBk45gSfKCQraN6qORvAD4WcbA References: <351D0D85-DE60-4F47-8D16-E61B6799EC79@csperkins.org> From: To: X-OriginalArrivalTime: 21 Nov 2007 15:52:37.0640 (UTC) FILETIME=[8A22B880:01C82C56] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 X-BeenThere: safe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Self-Address Fixing Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: safe-bounces@ietf.org Hi, Here are some thougths on what I think we should be able to figure out wrt. this BoF. Not necessarily perfectly structured, but I hope this helps to initiate some discussion already *before* the actual BoF session, and helps us to formulate the actual key questions to present in the BoF. Requirements ------------ Perhaps it's fair to say that stun-control is mostly an opportunistic extension of an existing protocol (STUN) to do some new stuff (control NATs instead of just discovering them) rather than a top-down design based on pre-established requirements. However, to evaluate the usefulness of stun-control we should agree on some set of requirements that the protocol should meet and then see if it makes sense to use STUN as a starting point. It might help as as starting point to list what stun-control CAN do without taking it too far. Here is my initial attempt, please comment: - Discover the NATs between the host and its STUN server. Assuming only a "single route" between the host and it's outmost NAT, these are the NATs between the host and any other host in the Internet. Assuming a more complex topology, the set of NATs depends on the peer (and routing/link state). There may be further issues with overalapping private address spaces. - Discover the "properties" of the UDP-binding in each of the NATs, in practice the filtering rules and expiration timer. Here it is important to note that this needs to be done binding-by-binding and in it's not possible to discover bindings created by other hosts. This can be seen as a feature or a limitation.=20 - Configure the properties of the discovered bindings, if allowed by the NAT policy.=20 - Discover which "control" protocols are supported by each NAT, including other than STUN itself. The current draft also extends the discovery and control to firewalls, with a slightly different techique.=20 Based on this analysis a few questions can be raised: - Is a protocol with features and limitations listed above useful on its own, or should the functionality be offered as part of some more capable protocol? - Should firewalls be in or out of scope? - Should only UDP be considered, or should also TCP be brought to scope? If we want to include TCP, does STUN approach make sense? - Is it a feature or a limitation that bindings are controlled/discovered one-by-one and hosts can only control/discover their own bindings? Applicability ------------- This relates very much to requirements, i.e. from which real-word problem do we derive our requirements from and does stun-control indeed solve a real problem in a reasonable way. I think that the problem statement is relatively well written in the BoF proposal, including things like power consumption, server load and possibilty to optimize certain NAT traversal scenarios. Some questions related to this are: - What are the exact problems stun-control is supposed to solve? - Does it really solve them *well enough*? (For instance there are issues like the complex topologies, inability to discover non-STUN-supporting firewalls, overlapping address spaces and so on. Are these serious enough to ruin the use cases people have in mind or can we live with them?) - Can it be incrementally deployed? This has been one selling argument. Relation to other work ---------------------- This is the tough part related to dozens of other middlebox related protocols, i.e. how does stun-control fit in or differentiate itself. stun-control seems to have some distinct qualitities compared to various other protocols. It is hard to describe the differences in brief, draft-eggert-middlebox-control-survey is one attempt to classify and compare such protocols. Conserns about overlap with UPnP IGD has been specifically brough up. In that case the difference is quite clear, related e.g. to stun-control supporting nested NATs. In general there are various questions: - What is the difference/overlap between stun-control and protocols X, Y and Z? - What are the most relevant X, Y, and Z? - In cases of partial overlaps, can the protocols co-exist? - Does stun-control have some qualities why it would be easier to deploy than some of the existing protocols that (AFAIK) have not enjoyed wide deployment so far? Another area is the separation of discovery and control. In some cases, e.g. with Teredo, Teredo itself can discover the outermost NAT and stun-control can start its work from that point onward. On the other hand, stun-control can be used only for discovery and some other protocols (such as UPnP IGD) for the actual control. - Should these kind of interactions be described somewhere in more detail, or do we just leave them to the product vendors to figure out (who may come up with exotic combinations...)? Interest in the vendor/ISP/enterprise/application community ----------------------------------------------------------- By definition middlebox control solutions are not end-to-end things that we can just layer on top of the Internet. So, their success heavily depends on the vendors actually building the middleboxes. Also, in many cases the features need to be explicitly turned on by the ISPs or enterprise IT folks, so their support is also needed. Finally, support is needed from the less-well-defined applications community, who need to integrate the capabilities in the actual applications who want the control capabilities. - Can we say anyting about the interest of these communities toward stun-control? Is there any good way to find this out? Regards, Markus >-----Original Message----- >From: ext Colin Perkins [mailto:csp@csperkins.org]=20 >Sent: 16 November, 2007 16:00 >To: ietf@ietf.org >Cc: safe@ietf.org; Isomaki Markus (Nokia-SIR/Espoo) >Subject: [SAFE] SAFE BoF in Vancouver > >The following BoF has been proposed for the Vancouver IETF.=20 >There is a mailing list for discussion. > >Colin > > > > >SAFE - Self-Address Fixing Evolution BoF >---------------------------------------- > >Chairs: > Colin Perkins (csp@csperkins.org) > Markus Isomaki (Markus.Isomaki@nokia.com) > >Mailing list: > https://www1.ietf.org/mailman/listinfo/safe > >Various NAT hole-punching techniques such as IPsec NAT=20 >traversal, Teredo, and STUN/ICE send periodic UDP keep-alive=20 >messages to keep their NAT binding alive. > >However, a drawback of these techniques is their chattiness=20 >which is a result of the host application not knowing the=20 >NAT's binding lifetime (IPsec NAT traversal, STUN/ICE) or=20 >because the application is unable to extend the lifetime of=20 >the NAT's binding (Teredo). The endpoint has to send periodic=20 >packets which consume power on battery powered devices,=20 >consume network bandwidth, and place an unnecessary load on servers. > >There are two approaches to resolve the problem of chattiness.=20 >The first is to interact directly with the NAT using a NAT=20 >control protocol. Several of these protocols exist which=20 >unfortunately have different drawbacks: > > * incremental deployment is not possible with MIDCOM, NSIS-NSLP, > UPnP IGD, or NAT-PMP. With all of these protocols, both the NAT > and the endpoint have to support the same protocol > * nested NATs are not possible with UPnP IGD or NAT-PMP > * topology awareness is required of MIDCOM > * security must be established between the controlling entity and > the NAT for MIDCOM and NSIS-NSLP > * UPnP IGD uses broadcasts packets and NAT-PMP expects the NAT to be > the default gateway; neither work well on routed networks > >The second approach is to empirically test the NAT's binding=20 >lifetime, as done by Teredo. This can optimise the keep-alive=20 >traffic based on the NAT's binding lifetime, but cannot extend=20 >the duration of the binding lifetime. Also, empirical testing=20 >does not always give reliable results due to varying behaviour=20 >of NAT and firewall implementations. > >This BoF is intended to discuss a newly-proposed technique for=20 >using STUN to discover, query and control firewalls and NATs,=20 >that can eliminate UDP keep-alive traffic. The BoF will review=20 >the problem space and existing work, and decide if there is a=20 >need for new work in the area, and if the IETF is an=20 >appropriate home for that work. The intent is not to form a=20 >new working group at this time, but to gauge interest in work=20 >in this area, and consider an appropriate future home for that work. > > >Agenda: > Introduction ...................................... (Chairs, 10) > Problem statement and scope ......................... (Wing, 15) > Survey of existing work ........................... (Barnes, 30) > draft-eggert-middlebox-control-survey-01.txt > NAT/Firewall control with STUN ...................... (Wing, 15) > draft-wing-behave-nat-control-stun-usage-05.txt > Discussion ................................................ (20) > Future directions ................................. (Chairs, 30) > > >-- >version: 1.5, 16-Nov-2007 > > > >_______________________________________________ >SAFE mailing list >SAFE@ietf.org >https://www1.ietf.org/mailman/listinfo/safe > _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Thu Nov 22 10:23:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvDtk-0000Hw-4J; Thu, 22 Nov 2007 10:23:24 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IvDti-0000Cj-P8 for safe-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 10:23:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvDtd-00006Z-40 for safe@ietf.org; Thu, 22 Nov 2007 10:23:17 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvDtb-0002Dy-PC for safe@ietf.org; Thu, 22 Nov 2007 10:23:17 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IvDtZ-0004sl-0W; Thu, 22 Nov 2007 10:23:13 -0500 In-Reply-To: References: <351D0D85-DE60-4F47-8D16-E61B6799EC79@csperkins.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [SAFE] SAFE BoF in Vancouver Date: Thu, 22 Nov 2007 10:24:44 -0500 To: "Markus.Isomaki@nokia.com> X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: safe@ietf.org X-BeenThere: safe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Self-Address Fixing Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: safe-bounces@ietf.org Of all the points your raise, I think the last one (about vendor interest) is the most important. In my opinion, this is where all the existing proposals have fallen down. So perhaps any working group should be deliberately given a very constrained mandate: to produce a simple proposal that solves only the most important problems, and do it quickly. Then, if there seems to be interest, extensions can be considered. Personally, I think this would suggest the following: - The scope should be limited to UDP, since TCP mappings tend to time out much more slowly. - Only minimal extra work should be done for firewalls. Don't ignore them (because we don't want people turning on the NAT in a firewall just so it can be controlled), but really limit the firewall-only features to the minimum that seem to make sense. - Do handle the case of nested NATs/firewalls (because these are increasingly common) - Assume any NAT that supports STUN-control is BEHAVE-compliant. - Assume any firewall that supports STUN-control does NOT do address- and-port-dependent filtering. - Do provide a mechanism for path lifetime discovery (similar to path MTU discovery; what is the minimum rate that keep-alives need to be sent?) as this is very useful with only some NATs support STUN-control. - Philip On 21-Nov-07, at 10:52 , wrote: > Hi, > > Here are some thougths on what I think we should be able to figure out > wrt. this BoF. Not necessarily perfectly structured, but I hope this > helps to initiate some discussion already *before* the actual BoF > session, and helps us to formulate the actual key questions to present > in the BoF. > > > Requirements > ------------ > > Perhaps it's fair to say that stun-control is mostly an opportunistic > extension of an existing protocol (STUN) to do some new stuff (control > NATs instead of just discovering them) rather than a top-down design > based on pre-established requirements. However, to evaluate the > usefulness of stun-control we should agree on some set of requirements > that the protocol should meet and then see if it makes sense to use > STUN > as a starting point. > > It might help as as starting point to list what stun-control CAN do > without taking it too far. Here is my initial attempt, please comment: > - Discover the NATs between the host and its STUN server. Assuming > only > a "single route" between the host and it's outmost NAT, these are the > NATs between the host and any other host in the Internet. Assuming a > more complex topology, the set of NATs depends on the peer (and > routing/link state). There may be further issues with overalapping > private address spaces. > - Discover the "properties" of the UDP-binding in each of the NATs, in > practice the filtering rules and expiration timer. Here it is > important > to note that this needs to be done binding-by-binding and in it's not > possible to discover bindings created by other hosts. This can be seen > as a feature or a limitation. > - Configure the properties of the discovered bindings, if allowed > by the > NAT policy. > - Discover which "control" protocols are supported by each NAT, > including other than STUN itself. > > The current draft also extends the discovery and control to firewalls, > with a slightly different techique. > > Based on this analysis a few questions can be raised: > - Is a protocol with features and limitations listed above useful > on its > own, or should the functionality be offered as part of some more > capable > protocol? > - Should firewalls be in or out of scope? > - Should only UDP be considered, or should also TCP be brought to > scope? > If we want to include TCP, does STUN approach make sense? > - Is it a feature or a limitation that bindings are > controlled/discovered one-by-one and hosts can only control/discover > their own bindings? > > Applicability > ------------- > > This relates very much to requirements, i.e. from which real-word > problem do we derive our requirements from and does stun-control > indeed > solve a real problem in a reasonable way. I think that the problem > statement is relatively well written in the BoF proposal, including > things like power consumption, server load and possibilty to optimize > certain NAT traversal scenarios. Some questions related to this are: > - What are the exact problems stun-control is supposed to solve? > - Does it really solve them *well enough*? (For instance there are > issues like the complex topologies, inability to discover > non-STUN-supporting firewalls, overlapping address spaces and so > on. Are > these serious enough to ruin the use cases people have in mind or > can we > live with them?) > - Can it be incrementally deployed? This has been one selling > argument. > > > Relation to other work > ---------------------- > > This is the tough part related to dozens of other middlebox related > protocols, i.e. how does stun-control fit in or differentiate itself. > stun-control seems to have some distinct qualitities compared to > various > other protocols. It is hard to describe the differences in brief, > draft-eggert-middlebox-control-survey is one attempt to classify and > compare such protocols. Conserns about overlap with UPnP IGD has been > specifically brough up. In that case the difference is quite clear, > related e.g. to stun-control supporting nested NATs. In general there > are various questions: > - What is the difference/overlap between stun-control and protocols > X, Y > and Z? > - What are the most relevant X, Y, and Z? > - In cases of partial overlaps, can the protocols co-exist? > - Does stun-control have some qualities why it would be easier to > deploy > than some of the existing protocols that (AFAIK) have not enjoyed wide > deployment so far? > > Another area is the separation of discovery and control. In some > cases, > e.g. with Teredo, Teredo itself can discover the outermost NAT and > stun-control can start its work from that point onward. On the other > hand, stun-control can be used only for discovery and some other > protocols (such as UPnP IGD) for the actual control. > - Should these kind of interactions be described somewhere in more > detail, or do we just leave them to the product vendors to figure out > (who may come up with exotic combinations...)? > > Interest in the vendor/ISP/enterprise/application community > ----------------------------------------------------------- > > By definition middlebox control solutions are not end-to-end things > that > we can just layer on top of the Internet. So, their success heavily > depends on the vendors actually building the middleboxes. Also, in > many > cases the features need to be explicitly turned on by the ISPs or > enterprise IT folks, so their support is also needed. Finally, support > is needed from the less-well-defined applications community, who > need to > integrate the capabilities in the actual applications who want the > control capabilities. > - Can we say anyting about the interest of these communities toward > stun-control? Is there any good way to find this out? > > > Regards, > Markus > > > >> -----Original Message----- >> From: ext Colin Perkins [mailto:csp@csperkins.org] >> Sent: 16 November, 2007 16:00 >> To: ietf@ietf.org >> Cc: safe@ietf.org; Isomaki Markus (Nokia-SIR/Espoo) >> Subject: [SAFE] SAFE BoF in Vancouver >> >> The following BoF has been proposed for the Vancouver IETF. >> There is a mailing list for discussion. >> >> Colin >> >> >> >> >> SAFE - Self-Address Fixing Evolution BoF >> ---------------------------------------- >> >> Chairs: >> Colin Perkins (csp@csperkins.org) >> Markus Isomaki (Markus.Isomaki@nokia.com) >> >> Mailing list: >> https://www1.ietf.org/mailman/listinfo/safe >> >> Various NAT hole-punching techniques such as IPsec NAT >> traversal, Teredo, and STUN/ICE send periodic UDP keep-alive >> messages to keep their NAT binding alive. >> >> However, a drawback of these techniques is their chattiness >> which is a result of the host application not knowing the >> NAT's binding lifetime (IPsec NAT traversal, STUN/ICE) or >> because the application is unable to extend the lifetime of >> the NAT's binding (Teredo). The endpoint has to send periodic >> packets which consume power on battery powered devices, >> consume network bandwidth, and place an unnecessary load on servers. >> >> There are two approaches to resolve the problem of chattiness. >> The first is to interact directly with the NAT using a NAT >> control protocol. Several of these protocols exist which >> unfortunately have different drawbacks: >> >> * incremental deployment is not possible with MIDCOM, NSIS-NSLP, >> UPnP IGD, or NAT-PMP. With all of these protocols, both the NAT >> and the endpoint have to support the same protocol >> * nested NATs are not possible with UPnP IGD or NAT-PMP >> * topology awareness is required of MIDCOM >> * security must be established between the controlling entity and >> the NAT for MIDCOM and NSIS-NSLP >> * UPnP IGD uses broadcasts packets and NAT-PMP expects the NAT >> to be >> the default gateway; neither work well on routed networks >> >> The second approach is to empirically test the NAT's binding >> lifetime, as done by Teredo. This can optimise the keep-alive >> traffic based on the NAT's binding lifetime, but cannot extend >> the duration of the binding lifetime. Also, empirical testing >> does not always give reliable results due to varying behaviour >> of NAT and firewall implementations. >> >> This BoF is intended to discuss a newly-proposed technique for >> using STUN to discover, query and control firewalls and NATs, >> that can eliminate UDP keep-alive traffic. The BoF will review >> the problem space and existing work, and decide if there is a >> need for new work in the area, and if the IETF is an >> appropriate home for that work. The intent is not to form a >> new working group at this time, but to gauge interest in work >> in this area, and consider an appropriate future home for that work. >> >> >> Agenda: >> Introduction ...................................... (Chairs, 10) >> Problem statement and scope ......................... (Wing, 15) >> Survey of existing work ........................... (Barnes, 30) >> draft-eggert-middlebox-control-survey-01.txt >> NAT/Firewall control with STUN ...................... (Wing, 15) >> draft-wing-behave-nat-control-stun-usage-05.txt >> Discussion ................................................ (20) >> Future directions ................................. (Chairs, 30) >> >> >> -- >> version: 1.5, 16-Nov-2007 >> >> >> >> _______________________________________________ >> SAFE mailing list >> SAFE@ietf.org >> https://www1.ietf.org/mailman/listinfo/safe >> > > > _______________________________________________ > SAFE mailing list > SAFE@ietf.org > https://www1.ietf.org/mailman/listinfo/safe > _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Fri Nov 30 05:18:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy2wp-0003c5-6p; Fri, 30 Nov 2007 05:18:15 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1Iy2wn-0003bm-RJ for safe-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 05:18:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy2wi-0003a9-2H for safe@ietf.org; Fri, 30 Nov 2007 05:18:08 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy2wg-00011H-EK for safe@ietf.org; Fri, 30 Nov 2007 05:18:07 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lAUAHeE5015955; Fri, 30 Nov 2007 12:18:03 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 12:17:39 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 12:17:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [SAFE] SAFE BoF in Vancouver Date: Fri, 30 Nov 2007 12:17:25 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SAFE] SAFE BoF in Vancouver Thread-Index: AcgtG6IyQ+M9lZhdRu2Eo+LAkga/BwGHe7Fw References: <351D0D85-DE60-4F47-8D16-E61B6799EC79@csperkins.org> From: To: X-OriginalArrivalTime: 30 Nov 2007 10:17:38.0389 (UTC) FILETIME=[3BC42850:01C8333A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd Cc: safe@ietf.org X-BeenThere: safe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Self-Address Fixing Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: safe-bounces@ietf.org Hi Philip, Personally I pretty much agree with everything you say below. No one else has commented, so we can thus far declare this as the consensus on the list ;) Markus =20 >-----Original Message----- >From: ext Philip Matthews [mailto:philip_matthews@magma.ca]=20 >Sent: 22 November, 2007 17:25 >To: Isomaki Markus (Nokia-SIR/Espoo) >Cc: safe@ietf.org >Subject: Re: [SAFE] SAFE BoF in Vancouver > >Of all the points your raise, I think the last one (about vendor >interest) is the most important. In my opinion, this is where=20 >all the existing proposals have fallen down. So perhaps any=20 >working group should be deliberately given a very constrained=20 >mandate: to produce a simple proposal that solves only the=20 >most important problems, and do it quickly. Then, if there=20 >seems to be interest, extensions can be considered. > >Personally, I think this would suggest the following: >- The scope should be limited to UDP, since TCP mappings tend=20 >to time out much more slowly. >- Only minimal extra work should be done for firewalls. Don't=20 >ignore them (because we don't want people turning on the NAT=20 >in a firewall just so it can be controlled), but really limit=20 >the firewall-only features to the minimum that seem to make sense. >- Do handle the case of nested NATs/firewalls (because these=20 >are increasingly common) >- Assume any NAT that supports STUN-control is BEHAVE-compliant. >- Assume any firewall that supports STUN-control does NOT do=20 >address- and-port-dependent filtering. >- Do provide a mechanism for path lifetime discovery (similar=20 >to path MTU discovery; what is the minimum rate that=20 >keep-alives need to be >sent?) as this is very useful with only some NATs support STUN-control. > >- Philip > > >On 21-Nov-07, at 10:52 , =20 > wrote: > >> Hi, >> >> Here are some thougths on what I think we should be able to=20 >figure out=20 >> wrt. this BoF. Not necessarily perfectly structured, but I hope this=20 >> helps to initiate some discussion already *before* the actual BoF=20 >> session, and helps us to formulate the actual key questions=20 >to present=20 >> in the BoF. >> >> >> Requirements >> ------------ >> >> Perhaps it's fair to say that stun-control is mostly an=20 >opportunistic=20 >> extension of an existing protocol (STUN) to do some new=20 >stuff (control=20 >> NATs instead of just discovering them) rather than a top-down design=20 >> based on pre-established requirements. However, to evaluate the=20 >> usefulness of stun-control we should agree on some set of=20 >requirements=20 >> that the protocol should meet and then see if it makes sense to use=20 >> STUN as a starting point. >> >> It might help as as starting point to list what stun-control CAN do=20 >> without taking it too far. Here is my initial attempt,=20 >please comment: >> - Discover the NATs between the host and its STUN server. Assuming=20 >> only a "single route" between the host and it's outmost NAT,=20 >these are=20 >> the NATs between the host and any other host in the=20 >Internet. Assuming=20 >> a more complex topology, the set of NATs depends on the peer (and=20 >> routing/link state). There may be further issues with overalapping=20 >> private address spaces. >> - Discover the "properties" of the UDP-binding in each of=20 >the NATs, in=20 >> practice the filtering rules and expiration timer. Here it is=20 >> important to note that this needs to be done=20 >binding-by-binding and in=20 >> it's not possible to discover bindings created by other hosts. This=20 >> can be seen as a feature or a limitation. >> - Configure the properties of the discovered bindings, if allowed by=20 >> the NAT policy. >> - Discover which "control" protocols are supported by each NAT,=20 >> including other than STUN itself. >> >> The current draft also extends the discovery and control to=20 >firewalls,=20 >> with a slightly different techique. >> >> Based on this analysis a few questions can be raised: >> - Is a protocol with features and limitations listed above useful on=20 >> its own, or should the functionality be offered as part of some more=20 >> capable protocol? >> - Should firewalls be in or out of scope? >> - Should only UDP be considered, or should also TCP be brought to=20 >> scope? >> If we want to include TCP, does STUN approach make sense? >> - Is it a feature or a limitation that bindings are=20 >> controlled/discovered one-by-one and hosts can only control/discover=20 >> their own bindings? >> >> Applicability >> ------------- >> >> This relates very much to requirements, i.e. from which real-word=20 >> problem do we derive our requirements from and does stun-control=20 >> indeed solve a real problem in a reasonable way. I think that the=20 >> problem statement is relatively well written in the BoF proposal,=20 >> including things like power consumption, server load and=20 >possibilty to=20 >> optimize certain NAT traversal scenarios. Some questions related to=20 >> this are: >> - What are the exact problems stun-control is supposed to solve? >> - Does it really solve them *well enough*? (For instance there are=20 >> issues like the complex topologies, inability to discover=20 >> non-STUN-supporting firewalls, overlapping address spaces and so on.=20 >> Are these serious enough to ruin the use cases people have=20 >in mind or=20 >> can we live with them?) >> - Can it be incrementally deployed? This has been one selling=20 >> argument. >> >> >> Relation to other work >> ---------------------- >> >> This is the tough part related to dozens of other middlebox related=20 >> protocols, i.e. how does stun-control fit in or differentiate itself. >> stun-control seems to have some distinct qualitities compared to=20 >> various other protocols. It is hard to describe the differences in=20 >> brief, draft-eggert-middlebox-control-survey is one attempt to=20 >> classify and compare such protocols. Conserns about overlap=20 >with UPnP=20 >> IGD has been specifically brough up. In that case the difference is=20 >> quite clear, related e.g. to stun-control supporting nested NATs. In=20 >> general there are various questions: >> - What is the difference/overlap between stun-control and=20 >protocols X,=20 >> Y and Z? >> - What are the most relevant X, Y, and Z? >> - In cases of partial overlaps, can the protocols co-exist? >> - Does stun-control have some qualities why it would be easier to=20 >> deploy than some of the existing protocols that (AFAIK) have not=20 >> enjoyed wide deployment so far? >> >> Another area is the separation of discovery and control. In some=20 >> cases, e.g. with Teredo, Teredo itself can discover the=20 >outermost NAT=20 >> and stun-control can start its work from that point onward. On the=20 >> other hand, stun-control can be used only for discovery and=20 >some other=20 >> protocols (such as UPnP IGD) for the actual control. >> - Should these kind of interactions be described somewhere in more=20 >> detail, or do we just leave them to the product vendors to=20 >figure out=20 >> (who may come up with exotic combinations...)? >> >> Interest in the vendor/ISP/enterprise/application community >> ----------------------------------------------------------- >> >> By definition middlebox control solutions are not end-to-end things=20 >> that we can just layer on top of the Internet. So, their success=20 >> heavily depends on the vendors actually building the middleboxes.=20 >> Also, in many cases the features need to be explicitly turned on by=20 >> the ISPs or enterprise IT folks, so their support is also needed.=20 >> Finally, support is needed from the less-well-defined applications=20 >> community, who need to integrate the capabilities in the actual=20 >> applications who want the control capabilities. >> - Can we say anyting about the interest of these communities toward=20 >> stun-control? Is there any good way to find this out? >> >> >> Regards, >> Markus >> >> >> >>> -----Original Message----- >>> From: ext Colin Perkins [mailto:csp@csperkins.org] >>> Sent: 16 November, 2007 16:00 >>> To: ietf@ietf.org >>> Cc: safe@ietf.org; Isomaki Markus (Nokia-SIR/Espoo) >>> Subject: [SAFE] SAFE BoF in Vancouver >>> >>> The following BoF has been proposed for the Vancouver IETF. >>> There is a mailing list for discussion. >>> >>> Colin >>> >>> >>> >>> >>> SAFE - Self-Address Fixing Evolution BoF >>> ---------------------------------------- >>> >>> Chairs: >>> Colin Perkins (csp@csperkins.org) >>> Markus Isomaki (Markus.Isomaki@nokia.com) >>> >>> Mailing list: >>> https://www1.ietf.org/mailman/listinfo/safe >>> >>> Various NAT hole-punching techniques such as IPsec NAT traversal,=20 >>> Teredo, and STUN/ICE send periodic UDP keep-alive messages to keep=20 >>> their NAT binding alive. >>> >>> However, a drawback of these techniques is their chattiness=20 >which is=20 >>> a result of the host application not knowing the NAT's binding=20 >>> lifetime (IPsec NAT traversal, STUN/ICE) or because the application=20 >>> is unable to extend the lifetime of the NAT's binding=20 >(Teredo). The=20 >>> endpoint has to send periodic packets which consume power=20 >on battery=20 >>> powered devices, consume network bandwidth, and place an=20 >unnecessary=20 >>> load on servers. >>> >>> There are two approaches to resolve the problem of chattiness. >>> The first is to interact directly with the NAT using a NAT control=20 >>> protocol. Several of these protocols exist which unfortunately have=20 >>> different drawbacks: >>> >>> * incremental deployment is not possible with MIDCOM, NSIS-NSLP, >>> UPnP IGD, or NAT-PMP. With all of these protocols, both the NAT >>> and the endpoint have to support the same protocol >>> * nested NATs are not possible with UPnP IGD or NAT-PMP >>> * topology awareness is required of MIDCOM >>> * security must be established between the controlling entity and >>> the NAT for MIDCOM and NSIS-NSLP >>> * UPnP IGD uses broadcasts packets and NAT-PMP expects the NAT to=20 >>> be >>> the default gateway; neither work well on routed networks >>> >>> The second approach is to empirically test the NAT's binding=20 >>> lifetime, as done by Teredo. This can optimise the=20 >keep-alive traffic=20 >>> based on the NAT's binding lifetime, but cannot extend the duration=20 >>> of the binding lifetime. Also, empirical testing does not=20 >always give=20 >>> reliable results due to varying behaviour of NAT and firewall=20 >>> implementations. >>> >>> This BoF is intended to discuss a newly-proposed technique=20 >for using=20 >>> STUN to discover, query and control firewalls and NATs, that can=20 >>> eliminate UDP keep-alive traffic. The BoF will review the problem=20 >>> space and existing work, and decide if there is a need for new work=20 >>> in the area, and if the IETF is an appropriate home for that work.=20 >>> The intent is not to form a new working group at this time, but to=20 >>> gauge interest in work in this area, and consider an appropriate=20 >>> future home for that work. >>> >>> >>> Agenda: >>> Introduction ...................................... (Chairs, 10) >>> Problem statement and scope ......................... (Wing, 15) >>> Survey of existing work ........................... (Barnes, 30) >>> draft-eggert-middlebox-control-survey-01.txt >>> NAT/Firewall control with STUN ...................... (Wing, 15) >>> draft-wing-behave-nat-control-stun-usage-05.txt >>> Discussion ................................................ (20) >>> Future directions ................................. (Chairs, 30) >>> >>> >>> -- >>> version: 1.5, 16-Nov-2007 >>> >>> >>> >>> _______________________________________________ >>> SAFE mailing list >>> SAFE@ietf.org >>> https://www1.ietf.org/mailman/listinfo/safe >>> >> >> >> _______________________________________________ >> SAFE mailing list >> SAFE@ietf.org >> https://www1.ietf.org/mailman/listinfo/safe >> > > _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe