From safe-bounces@ietf.org Sun Dec 02 16:45:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iywcg-0006kP-HV; Sun, 02 Dec 2007 16:45:10 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1Iywcf-0006TK-2V for safe-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 16:45:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iywce-0006LR-EW for safe@ietf.org; Sun, 02 Dec 2007 16:45:08 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iywcd-0003lG-RW for safe@ietf.org; Sun, 02 Dec 2007 16:45:08 -0500 Received: from [207.236.117.226] (port=62888 helo=[198.18.140.222]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1Iywcc-0007rS-I0 for safe@ietf.org; Sun, 02 Dec 2007 21:45:06 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <130094E9-D042-4303-A431-1813E98CA60F@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [SAFE] BOF in Vancouver Date: Sun, 2 Dec 2007 13:45:24 -0800 To: safe@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 6 Nov 2007, at 09:10, Colin Perkins wrote: > 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. The current agenda for the SAFE BoF looks like the following: Self-Address Fixing Evolution (SAFE) BOF ======================================== CHAIRS: Colin Perkins Markus Isomaki AGENDA Monday, 3 December 2007 at 09:00-11:30 (Salon 2) ------------------------------------------------ 09:00 Introduction (Chairs, 10) 09:10 Problem statement and scope (Wing, 15) 09:25 Survey of existing work (Barnes, 30) draft-eggert-middlebox-control-survey-01.txt 09:55 NAT/Firewall control with STUN (Wing, 15) draft-wing-behave-nat-control-stun-usage-05.txt 10:10 Discussion (Chairs, 40) 10:50 Future directions (Chairs, 40) 11:30 End -- Colin Perkins http://csperkins.org/ _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Mon Dec 03 03:02:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6GA-0003ac-7j; Mon, 03 Dec 2007 03:02:34 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1Iz6G8-0003a1-FQ for safe-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 03:02:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6G2-0003ZR-9T for safe@ietf.org; Mon, 03 Dec 2007 03:02:26 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz6G1-00051d-Rj for safe@ietf.org; Mon, 03 Dec 2007 03:02:26 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Dec 2007 00:02:25 -0800 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 lB382PMx012775 for ; Mon, 3 Dec 2007 00:02:25 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB382P1f023284 for ; Mon, 3 Dec 2007 08:02:25 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 00:02:24 -0800 Received: from [10.21.87.30] ([10.21.87.30]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 00:02:24 -0800 Message-ID: <47530F91.8040502@cisco.com> Date: Sun, 02 Dec 2007 15:03:29 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: safe@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Dec 2007 08:02:24.0954 (UTC) FILETIME=[D70579A0:01C83582] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1831; t=1196668945; x=1197532945; 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:=20an=20idea=20on=20nested=20nats=20with=20overlapping=20address es |Sender:=20; bh=X6c/FXmuG/q2L577qXQZ9qJjG4gTbsdY0A3eN7vpbVw=; b=Uf759BBEneasGCS6Mr/9OHQZUm1h2gObri/DR3Sv6OlR+fuk15zGYUCRQILPSuHwdOQL/4SX 2yV3+g/2pSn6hJNhSYmly8M3dmVk7vuaz4UBSmM+R0gbp1JzXpyetkP4; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 1.9 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [SAFE] an idea on nested nats with overlapping addresses 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 One of the limitations of stun control is it doesn't work when there are nested NAT with overlapping address space. There isn't an easy solution for this case, but here is one idea. The client includes its own source IP in the Binding Request that gets sent to the outermost NAT. If an intervening NAT notices that this address matches its own outside IP address, a conflict is detected. Oftentimes, the nat obtained its outside IP from DHCP to the next NAT. So, the NAT that detected the conflict redoes DHCP to obtain a new IP address. If any stun-control compliant NAT does the following two things: 1. when providing DHCP responses, provide a random IP address from within the address pool 2. when receiving a packet from the inside, whose destination IP matches the netmask of the internal network, but does NOT correspond to an existing host, forward towards the outside This would cause the address space to self-organize into non-overlapping segments. There are clearly issues with this appraoch: 1. other sessions in progress would be killed when nat bindings change (though maybe the nat can obtain an additional IP via DHCP rather than replacing its existing one) 2. might cause packets targeted for a private IP to hit a network with public addresses (via the second rule). If we modify the rule so that forwarding only occurs across interfaces with private IPs, this fixes it but only allows nesting where all intermediate address spaces are private. Just a thought... -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 _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Mon Dec 03 03:02:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6GB-0003bq-CL; Mon, 03 Dec 2007 03:02:35 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1Iz6GA-0003aX-6Z for safe-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 03:02:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6G9-0003aB-QE for safe@ietf.org; Mon, 03 Dec 2007 03:02:33 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz6G8-000522-9Q for safe@ietf.org; Mon, 03 Dec 2007 03:02:33 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Dec 2007 00:02:31 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB382VeF012943; Mon, 3 Dec 2007 00:02:31 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB382Q75021999; Mon, 3 Dec 2007 08:02:31 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 00:02:26 -0800 Received: from [10.21.87.30] ([10.21.87.30]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 00:02:25 -0800 Message-ID: <47531026.9000504@cisco.com> Date: Sun, 02 Dec 2007 15:05:58 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: [SAFE] SAFE BoF in Vancouver References: <351D0D85-DE60-4F47-8D16-E61B6799EC79@csperkins.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Dec 2007 08:02:26.0014 (UTC) FILETIME=[D7A737E0:01C83582] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10781; t=1196668951; x=1197532951; 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:=20Re=3A=20[SAFE]=20SAFE=20BoF=20in=20Vancouver |Sender:=20; bh=BKBgoQ6zX7BdFz9toGZuw7zbtjMqRIaYcsaCLnew6wI=; b=GlYKnjQSMEmjR2+3IK5kgkqe5MwFKqM0/m82VQu9bz4I9XUfEH6I/LLl9D1wB7s9e7QdrQeD WQyUvooPor+HWnX4eZWiE5Fcym4o8N95x3Y4VAbZzwwE84TATTx/PkMS; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 1.9 (+) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc 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 My two cents: I think the primary requirement is the ability to control binding lifetimes explicitly for UDP, and thats it. Everything else, like discovering intervening NAT, is a consequence of that requirement, and not a requirement by itself. I think binding lifetime control is the main issue since, without NAT control, techniques like ICE and sip outbound work well-enough that really we don't need control of the NAT. So, what is it thats not working so well with ICE and sip-outbound? Really primarily in the sip-outbound case its the frequent keepalive. So lets fix just that problem. -Jonathan R. Markus.Isomaki@nokia.com 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 > -- 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 _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Mon Dec 03 16:21:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzIjh-0003Mo-BW; Mon, 03 Dec 2007 16:21:53 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IzIjg-0003Mh-9x for safe-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 16:21:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzIjf-0003JA-JT for safe@ietf.org; Mon, 03 Dec 2007 16:21:51 -0500 Received: from wa-out-1112.google.com ([209.85.146.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzIjf-0005S8-6c for safe@ietf.org; Mon, 03 Dec 2007 16:21:51 -0500 Received: by wa-out-1112.google.com with SMTP id k40so7881297wah for ; Mon, 03 Dec 2007 13:21:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=zYtV4vgXEwMWE8h+QW8Rs+HwgtkoSxxJsU/V9M0E+60=; b=oxTId3AK44dAAwdt+cotR7mvgFZnCVaVKib8UNfj/BPZxo1eMHJcoESn3hvN9IHNmIaYHV8YjR+iGSrg9QPTX7eS3e2KfwA6evmRF4dkmLm2/dGkGcabzy2X4dzI2qEnZEOmoswX6//nMCLjYnMlGGmQ42bSsdSJQCxuPHTFJWU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fidgL6sVbBWWeTnSWlmGu7cxfmiyqPXBRr7/pALimnqj+WVWjBXwv6D984qPJ862WLlbKz2ovlrmW9RFrshJk7FQ5bt3cwi3izcahB6MgQ4x897hwxD4S9JQnglp4L5aBvV+H1FUHNM+8qQr7aPINyL7XWWdblJzYRBwgvpqQUY= Received: by 10.115.89.1 with SMTP id r1mr4175618wal.1196716904531; Mon, 03 Dec 2007 13:21:44 -0800 (PST) Received: by 10.115.72.7 with HTTP; Mon, 3 Dec 2007 13:21:44 -0800 (PST) Message-ID: <458913680712031321t63482dlcf6438e7aaeebbab@mail.gmail.com> Date: Mon, 3 Dec 2007 13:21:44 -0800 From: "Xavier Marjou" To: safe@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [SAFE] Keepalive duration and radio access protocols 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 With regards to today's meeting, I would have the following question: Isn't there a risk that reducing the keepalive traffic impacts radio-access protocols? (e.g. with things like loss of radio access bearer) Cheers, Xavier _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Mon Dec 03 17:06:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJQh-0001tT-GT; Mon, 03 Dec 2007 17:06:19 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IzJQg-0001sz-Bj for safe-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 17:06:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJQf-0001sp-NI for safe@ietf.org; Mon, 03 Dec 2007 17:06:17 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzJQf-00012D-BK for safe@ietf.org; Mon, 03 Dec 2007 17:06:17 -0500 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 lB3M6SQi003724 for ; Mon, 3 Dec 2007 16:06:29 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 00:05:48 +0200 Received: from essapo-nirac253122.europe.nokia.com ([10.162.253.122]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 00:05:47 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: safe@ietf.org Subject: Re: [SAFE] Keepalive duration and radio access protocols Date: Tue, 4 Dec 2007 00:01:55 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <458913680712031321t63482dlcf6438e7aaeebbab@mail.gmail.com> In-Reply-To: <458913680712031321t63482dlcf6438e7aaeebbab@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712040001.55647.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 03 Dec 2007 22:05:48.0230 (UTC) FILETIME=[A8EC9E60:01C835F8] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Le Monday 03 December 2007 23:21:44 ext Xavier Marjou, vous avez =E9crit=A0: > With regards to today's meeting, I would have the following question: > Isn't there a risk that reducing the keepalive traffic impacts > radio-access protocols? (e.g. with things like loss of radio access > bearer) I have been able to keep a 3G PDP context for hours while not sending any I= P=20 packets through it. In any case, if the radio technology cannot keep up wit= h=20 long delays between keep-alives, it cannot be used by battery-powered=20 devices. Considering that the overwhelming majority of said devices are=20 actually battery-powered, I am pretty confident that the technology can=20 already cope with such time-distant keep-alives (and if it cannot, then som= e=20 other SIP-using SDOs have a big big problem). =2D-=20 R=E9mi Denis-Courmont _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Tue Dec 04 13:19:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcMt-00012O-Bt; Tue, 04 Dec 2007 13:19:39 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IzcMs-00010m-7g for safe-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:19:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcMr-0000zW-Sb; Tue, 04 Dec 2007 13:19:37 -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 1IzcMq-0001bv-T8; Tue, 04 Dec 2007 13:19:37 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 04 Dec 2007 10:19:36 -0800 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 lB4IJaOn028877; Tue, 4 Dec 2007 10:19:36 -0800 Received: from dwingwxp01 (sjc-vpn6-1855.cisco.com [10.21.127.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB4IJVqZ005888; Tue, 4 Dec 2007 18:19:31 GMT From: "Dan Wing" To: "'Bryan Ford'" , References: <6F9ED451-5763-48BB-83EB-D6F1185D03AE@mit.edu> Date: Tue, 4 Dec 2007 10:19:31 -0800 Message-ID: <161001c836a2$39ac1580$4e76150a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acg2n/W0r9ybHby5QUeIQ1OQPE1GsgAAY/vw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <6F9ED451-5763-48BB-83EB-D6F1185D03AE@mit.edu> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3072; t=1196792376; x=1197656376; 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:=20keepalive=20battery=20consumption |Sender:=20; bh=UMappAapIDA4YLRiB0Ze3ngeCmhspJGyH1jIzlr55ZE=; b=h7cw6eqDFlbbYcyU6EYhEZDIGUdaweh7pjqOIyZtJed58Y4lXQT8muicLihsn84qEE9jyjma x3Ux/oT4KOmdy9z4VboLYmzNuOOC2ix+ONisHU7vyMfx+9qEGltnrxFg; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: safe@ietf.org, Pasi.Eronen@nokia.com, "'Frank W. Miller'" Subject: [SAFE] keepalive battery consumption 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 (I am CC'ing the SAFE mailing list, as the motivation for reducing keepalives came up during SAFE.) Citation: http://tinyurl.com/3c63ef [IEEE] "Energy Consumption of Always-On Applications in WCDMA Networks" Haverinen, H.; Siren, J.; Eronen, P. Vehicular Technology Conference, 2007. VTC2007-Spring. IEEE 65th Volume , Issue , 22-25 April 2007 Page(s):964 - 968 Digital Object Identifier 10.1109/VETECS.2007.207 Summary: Always-on applications, such as push email and voice-over-IP, are characterized by the need to be constantly reachable for incoming communications. In the presence of stateful firewalls or NATs, such applications require "keep-alive" messages to maintain up-to-date connection state in the firewall or NAT, and thus preserve reachability. In this paper, we analyze how these keep-alive messages influence battery lifetime in WCDMA networks. Using measurements in a 3G network, we show that the energy consumption is significantly influenced by the radio resource control (RRC) parameters and the frequency of keep-alive messages. The results suggest that especially UDP-based protocols, such as mobile IPv4 and IPsec NAT traversal mechanisms, require very frequent keep-alives that can lead to unacceptably short battery lifetimes." I expect we can find a way for the paper to be made available to non-IEEE members. Pasi? -d > -----Original Message----- > From: Bryan Ford [mailto:baford@MIT.EDU] > Sent: Tuesday, December 04, 2007 10:03 AM > To: behave@ietf.org > Subject: [BEHAVE] RE: A simpler way to reduce keepalive > traffic (Frank W.Miller) > > Frank W. Miller wrote: > > Since I was not able to attend the BoF, could you provide a > synopsis > > of why > > this consensus was arrived at? Specifically, can you describe any > > deployment scenarios that were quantitatively presented that have > > difficulty > > with the "chattiness" you are referring to? I will assume that the > > chattiness is primarily a problem for the STUN servers that are > > servicing > > the keepalives. What kind of data was presented to support this > > problem? > > The minutes don't appear to be on-line yet, but they should be soon, > and the presentation slides (at least the version before the > presentation - some modifications were made during it) are available > on the "meeting materials" page at: > https://datatracker.ietf.org/meeting/70/materials.html > > The biggest motivation seemed to be the drain on the battery > power of > wireless devices: someone offered the anecdote that he'd > observed 50% > of the power of some devices go to keepalive transmissions, > although I > don't remember any "hard" data presented to back this up. Maybe > someone else on the list can point to some? > > Cheers, > Bryan > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Tue Dec 04 17:01:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfq0-0003qv-GK; Tue, 04 Dec 2007 17:01:56 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IzcaH-0000dI-Fy for safe-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:33:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcaH-0000Zj-2E for safe@ietf.org; Tue, 04 Dec 2007 13:33:29 -0500 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzcaG-0007St-Fn for safe@ietf.org; Tue, 04 Dec 2007 13:33:29 -0500 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id lB4IXPGn016991 for ; Tue, 4 Dec 2007 13:33:25 -0500 (EST) Received: from [192.168.0.182] (s209-121-68-66.bc.hsia.telus.net [209.121.68.66]) (authenticated bits=0) (User authenticated as baford@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id lB4IXMha008319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 4 Dec 2007 13:33:24 -0500 (EST) Message-Id: <43F0DC71-CE33-488F-82BF-DCACC2670540@mit.edu> From: Bryan Ford To: safe@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 4 Dec 2007 10:33:21 -0800 References: <9EEA193F-1262-4B4E-9B71-799525796E81@mit.edu> X-Mailer: Apple Mail (2.915) X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-Mailman-Approved-At: Tue, 04 Dec 2007 17:01:55 -0500 Subject: [SAFE] Fwd: A simpler way to reduce keepalive traffic 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 [For reference, this is the beginning of the thread Dan Wing's message on keepalive battery consumption derives from - I originally posted my message to the BEHAVE list because I didn't realize there was a SAFE mailing list: I learned about the SAFE BOF from the meeting 70 agenda and the mailing list isn't mentioned there.] In the "SAFE" BOF today it emerged that (a) there seems to be a clear consensus that the IETF needs to do something to reduce the "chattiness" of NAT traversal mechanisms due to the keepalive traffic they use to keep their (especially UDP) bindings open; and (b) there's definitely no consensus yet on the best approach to accomplish that. (At least that was my personal take-away from the BOF.) Although for various reasons I would love to see a decent "explicit NAT control" or "listener discovery" protocol get standardized and deployed widely, I wanted to suggest an alternative way the one small, specific problem of keepalive chattiness might be addressed without any such explicit protocol. The solution has two elements: 1. An amendment to BEHAVE-UDP, basically affecting only section 4.3 of RFC 4787 and in a backward-compatible way, recommending that NATs multiplicatively increase each mapping's timeout over the mapping's lifetime. For example, if the NAT initially uses a 2-minute timer for a brand-new mapping (the minimum allowed), then if the mapping is still alive after 2 minutes the NAT increases the timeout by (say) 2.5x to 5 minutes; then if the mapping is still alive after that 5 minutes the timeout is again increased by 2.5x to 12.5 minutes, and so on. This is the only change required to NATs. 2. Applications that wish to minimize their keepalive chattiness can now use the following technique. They initialize their keepalive transmission timer to something safely small for all "reasonable" NATs - e.g., on the order of 10 seconds - and then in the background initiate a binding lifetime discovery mechanism analogous (but not identical) to that described in section 4.5 of draft-ietf-behave-nat- behavior-discovery-02. In particular, instead of assuming the NAT's binding lifetime is fixed and doing a binary search for it as the draft suggests, the application just probes successively larger lifetimes in progression, increasing the probe by a multiplicative factor of (say) 1.5x each time. When the application has verified that the NAT seems to have a binding lifetime of "at least" x, the application sets its keepalive period for the "main" UDP session it's actually using to that value and continues on to probe larger values. Now, when the path contains one or more "legacy" NATs with a fixed binding lifetime, the above application behavior will find that lifetime and use a suitably-matched keepalive period on an ongoing basis - thus, even with no modifications to existing NATs, the application effectively minimizes its chattiness to whatever the NATs on the path will permit. On the other hand, when the path contains only NATs that behave as proposed in #1 above, as long as the application's starting period and multiplicative increase factor is less than the NAT's, then both periods will continue to increase indefinitely, resulting in O(log t) instead of O(t) keepalive traffic over a long-lived binding with a total actual lifetime of t. Once the application eventually terminates, the time it takes the NAT to notice this is now proportional to the amount of time the application's binding was actually active: so even though the NAT might take a while to garbage-collect a long-lived binding, any given binding can be in such a "dead" state for only a constant percentage of its total lifetime. Thus, the scheme guarantees both logarithmic keepalive chatter over a binding's lifetime, and an easily-computable "efficiency ratio" if you compare a binding's total lifetime against the amount of time the application actually uses that binding. Of course there are plenty of details to work out, such as what the multiplicative factors are, and whether the application should use a single UDP session for both application use and binding lifetime discovery probing as the behavior-discovery draft suggests, or a separate UDP session for each purpose. Using a single UDP session is obviously more efficient in terms of NAT state and absolute keepalive traffic load, but has the disadvantage of allowing the application's main UDP session to "go dead" for some period as the application's binding lifetime probe period exceeds the binding lifetime of some legacy NAT in the path, perhaps leaving the SIP client temporarily unreachable from the outside world for example. Cheers, Bryan _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Tue Dec 04 17:01:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfq0-0003rO-KP; Tue, 04 Dec 2007 17:01:56 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1Izdr0-0002NW-BV for safe-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 14:54:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izdqz-0002M6-MA; Tue, 04 Dec 2007 14:54:49 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izdqz-0001bq-7f; Tue, 04 Dec 2007 14:54:49 -0500 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 lB4JsFjI000908; Tue, 4 Dec 2007 21:54:27 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 21:53:56 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 21:53:55 +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: Tue, 4 Dec 2007 21:53:55 +0200 Message-ID: In-Reply-To: <161001c836a2$39ac1580$4e76150a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: keepalive battery consumption Thread-Index: Acg2n/W0r9ybHby5QUeIQ1OQPE1GsgAAY/vwAANngoA= References: <6F9ED451-5763-48BB-83EB-D6F1185D03AE@mit.edu> <161001c836a2$39ac1580$4e76150a@cisco.com> From: To: , , X-OriginalArrivalTime: 04 Dec 2007 19:53:56.0094 (UTC) FILETIME=[675639E0:01C836AF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-Mailman-Approved-At: Tue, 04 Dec 2007 17:01:55 -0500 Cc: safe@ietf.org, fwmiller@cornfed.com Subject: [SAFE] RE: keepalive battery consumption 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 Dan Wing wrote: > I expect we can find a way for the paper to be made available=20 > to non-IEEE members. Pasi? The PDF is also on my home page: http://www.iki.fi/pe/publications/ Best regards, Pasi=20 _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Fri Dec 14 08:36: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 1J3Aii-0005Lh-Fw; Fri, 14 Dec 2007 08:36:52 -0500 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1J3Aih-0005LR-JE for safe-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 08:36:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Aib-0005Kh-CQ; Fri, 14 Dec 2007 08:36:45 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3AiX-0005WA-GY; Fri, 14 Dec 2007 08:36:45 -0500 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 lBEDZCSr030141; Fri, 14 Dec 2007 15:36:30 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 15:36:04 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 15:36:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Dec 2007 15:36:03 +0200 Message-ID: In-Reply-To: <10d801c83796$975e2250$6e7a150a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft summary and minutes of SAFE BOF Thread-Index: Acg3ZOitfvvp7lNyRbyblrmjceM+3AAMYJLwAa+cMjA= References: <031101c83762$c7491f80$6e7a150a@cisco.com><4756E0CF.8020800@acm.org> <10d801c83796$975e2250$6e7a150a@cisco.com> From: To: , X-OriginalArrivalTime: 14 Dec 2007 13:36:04.0147 (UTC) FILETIME=[45EF2830:01C83E56] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 Cc: Subject: [SAFE] Draft summary and minutes of SAFE BOF 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 (Distribution: SAFE, BEHAVE lists.) Hi,=20 Here are the preliminary summary and more detailed minutes of the SAFE = BOF held at IETF 70. Please let the chairs know if you have any comments = or corrections. Regards, Markus=20 SAFE summary ------------ SAFE BOF Dec 3, 2007, 0900 - 1130 Chairs: Colin Perkins (csp@csperkins.org), Markus Isom=E4ki = (markus.isomaki@nokia.com)=20 Summary by Markus Isom=E4ki BOF proposal is available at: = http://www3.ietf.org/proceedings/07dec/agenda/safe.txt The purpose of SAFE BOF was to discuss two things: 1. Is there interest in the IETF to work on solutions to reduce = keep-alive traffic for NAT and firewall traversal.=20 2. Is the newly-proposed technique for using STUN to discover, query and = control firewalls and NATs, a reasonable approach to pursue in this = space. The intent of the BOF was not to form a new WG at this point, but to = give guidance how to continue work on this area. Scope/properties of STUN control currently is that it works for = UDP-only, supports nested NATs and firewalls, detects non-supporting = NATs and fails safely with them, and operates on one binding/pinhole at = a time using transport source address for authorization. It's main = purpose is to query and adjust the refresh period for the = binding/pinhole. The main discussion topics that were raised during the BOF were: - Is there a problem with keepalives: It was commented that 20-30 sec = keepalive for UDP will dramatically affect battery lifetime e.g. in a = device with WCDMA radio. Reference to a paper was later sent to SAFE and = BEHAVE lists. - Generality: The initial scope is only UDP. Should this work also for = TCP? TCP got a lot of support as it also has unpredictable timeouts in = middleboxes. On the other hand UDP-only solution would be simpler and = easier to deploy. IPv4/IPv6 translators were also brought into = discussion, but declared out of scope. - Future path: If we adopt this protocol now, is there a path to the = future problems we want to solve? Arguments for incremental deployment = vs. generic solution. - Which applications benefit from STUN/UDP solution: SIP/UDP, real-time = media, IPSec/UDP, Teredo, Mobile IP. Some of these don't use STUN. Some, = like SIP could run over TCP as well. In general the benefit is biggest = for "push" type of applications that need to maintain connectivity over = long periods with little actual traffic to send/receive.=20 - Security model: In STUN-control the middlebox is controlled in-band = with the application traffic and the transport source addresss is used = for authorization. No bulk provisioning of mappings/pinholes is = possible. This simplifies the security properties compared to = third-party/out-of-band control models. - Scope and difference to existing mechanisms: There was a presentation = on survey for existing mechanisms. This caused a lot of clarifying = questions on how the existing protocols were classified.=20 - What is the incentive for the vendors to implement this: None of the = previous control protocols have been deployed. STUN-control has some = simplicity and incremental deployment benefits, at least for those = applications that already use STUN.=20 - Problem with overlapping address spaces and nested NATs: Can = STUN-control deal with this? A couple of proposals exist, but are = complicated. This is a generic problem with NATs, should it be solved = regardless of STUN-control. In the end of the session several polls were taken: - Question: "Are some functional requirements (for avoiding frequent = keepalive) or deployment considerations left unsatisfied by existing = protocols?" Yes/No Result: Majority agrees, but a substantial minority disagrees - Question: "Should the IETF try to solve the problem?" Yes/No Result: Clear majority support. - Question: "Is the NAT control STUN usage a reasonable approach to NAT = control, addressing the above requirements?" Yes/Maybe/No (At this point many people commented that this is not a clear = question, as some people would also want to support TCP etc.) Result: Seems to be weighted toward "yes" and "maybe", "no" slightly = quieter. - Question: "Given that we have a number of proposals in this space, has = our understanding of this problem space changed enough that we can build = something that people actually will deploy?" Yes/No Result: Response judged 1/3 "yes", 2/3 "no". SAFE minutes ------------ Notes, SAFE Dec 3 2007 0900 recorded by Dean Willis Chaired by Colin Perkins, Markus Isomaki --- Topic: Agenda Bash slides presented by chairs Agenda accepted as proposed by chairs. "Note Well" statement and IPR notice reviewed. Chairs present slides. NOTE: THIS IS NOT A "WORKING GROUP FORMING BOF" -- we are attempting to = decide whether there is a need for work in this area. We are not = discussing charters or any formative process issues in this meeting. --- Topic: Problem Statement and Scope led by Dan Wing Slides presented Problem: current NAT traversal approaches require keepalives. This = produces traffic and power consumption issues, especially for wireless = battery powered devices. Scope: Create a NAT control technique that solves keepalive and nesting, = detects and fails safely with non-upgraded NATs, and uses source = transport address for authorization. Discussion follows . .. . Question: Need to clarify relationship between determining and = adjusting of a NAT keepalive interval. Do we need to do both, or will a = system do just one? Concluded that the critical piece is determination. = We would also like to be able to do adjustment of the timing. Question: It seems that constraining the solutions space to use source = transport address might be excessive. Do we want to constrain to this = level up front? Are there other possible techniques that should be used? = Response by JDR: The idea here is to emulate what NATs already do, which = is 5-tuple address based , which we understand well. Things that do = protocol inspection or out-of-path controls raise lots of security and = deployability issues. Suggestion: Rephrase as requirements, to 1) easy to deploy, 2) confirm = that signaling for NAT control is authenticated to at least level of = normal TCP as being from the endpoint involved. Question (Philip Matthews): Are we focusing only on UDP? This problem = may not exist for TCP. Does it affect anything else? Henning noted that = his current hotel seems to time out on IMAP in about a minute, breaking = IMAP.=20 Suggestion: Requirement: needs to work on large deployments. Conclusion: Will focus on UDP initially. IPSEC support uses the IPSEC = NAT traversal mode using UDP. native IPSEC appears to be out of scope Suggestion: It would be good if the result can be extended to support = TCP, but the measure of success is to succeed well enough to get = deployed. Comment: Key difference is that TCP has an explicit teardown that can be = seen by NATs. Perhaps we could state the scope as protocols that do not = have explicit teardowns. --- Topic: Survey of Existing Protocols led by Mary Barnes Slides presented Slide: Categorization of Protocols Question: What is the difference between two-party and multiparty? The = distinction is based on whether there's an intermediary relay node apart = from the NAT itself. Noted that this may not be a useful distinction for = some people. Slides: Protocol Summaries Question: Diameter Gq' , Rx+, Gx+: These are DIAMETER based approaches = primarily from 3GPP.=20 Comment: There is also an Megaco-based H.348 protocol. Question: Where is ICE? It probably needs to be included in this = summary. Question: What does "Supports Incremental Deployment" mean? We think = this means whether the protocol is needed in every middle box on a path = or only some. An alternative: Can someone who is interested in deploying = a VoIP service make this stuff work by putting the protocol into just = the small part of the network they control, or does it require putting = boxes into parts they don't control. For example, enterprise IT people = generally won't put MIDCOM in their firewall just so end users can = access outside applications. This seems to be a very controversial = characteristic. Noted that one of the primary goals of SAFE is getting = incremental deployability, so we need to understand this better. Slides on Protocol Comparison Noted that NAT-PMP requires direction interaction with the middlebox. Slide on topology/environments: Much discussion over the "Topology Aware" column of the slide. = Conclusion that this needs some re-thinking. Perhaps column should be = labeled "Topology Unaware". Suggestion for 4th column on this slide: Identify where "end-to-end" = breaks if you use each protocol, i.e. UNSAFE considerations. =20 Discussion of the "Nested NATS" column: Suggested that the = MIDCOM/SIMCO/DIAMETER series may not really support nested NATs. Discussion of "diverse endpoints" column: Can you give an example of yes = and no by function? JDR: For example, UPnP is designed as a residential = protocol, lacking nesting, authentication, etc. So this is a consequence = of other properties. Perhaps this could be better phrased as discrete = function layers than as the broad categorization being attempted. Summary (2) slide: Comment from Keith Moore: It seems like many of the = problems with NAT protocols stem from assumption that interactions with = the middle box are bad, so don't start with this assumption. Question from Henning Schulzrine: We seem to have a long-term goal in = mind. There's a danger that we're always incrementally fixing something. = For anything of these things to be truly useful, avoiding the probing = problem seems to require some interaction with NATs. Should we look = further ahead and start mapping out the things that we're going to want? = Response from Colin: The current intent here is to explore a = tightly-focused solution to the immediate problem. Suggested by Henning = that we at least track the problems we aren't solving, and occasionally = consider whether there are other intermediate steps that we should be = taking. Counterargument from Philip Matthews: The big problem in = getting past solutions to deploy is that the complexity isn't worth the = return to the NAT vendors. We need something tightly focused that can = get deployed quickly and easily. Comment from=20 Comment from Lars: Questions for this BOF to answer: There are lots of = solutions in this area. Do we need something else? Is STUN Control a = reasonable thing to do? Is the IETF the right place to do this? --- Topic: NAT Control STUN Usage "STUN Control" led by Dan Wing Slides presented Slide: Tagging procedure with firewalls Question: This seems to indicate that the firewall wants to be seen. = What happens when they don't? Ans: They don't tag and remain invisible. Qestion: Is there an assumption that the tagging firewall is the closest = middlebox? Ans: No, they can be stacked, or there may be other layers. Slide: Communicate to NAT's embedded STUN server Question: How is signaling directed to the STUN server in the NAT? Ans: = The source 3-tuple is reused along with the new destination address of = the STUN server in the NAT. The stun server in the NAT correlates based = on the source 3-tuple, establishing a binding on the whole 5-tuple. Slide set, nested NATs Comment: There are a lot of arrows here. Is there a way that a P2P app = might use one command to open a lot of bindings? Ans: no. Comment: Is there a way to do the overlap bindings in parallel. Noted = that since this binding adjustment can be done after the media flow = starts, then there's no real setup delay. Slideset: Overlapping address spaces Question: It seems likely that overlapping addresses will occur = everytime someone stacks up generic same-brand NAT boxes. Perhaps we = should look at a fix instead of a detection. JDR notes that he proposed = something on the list last night relating to stacked DHCP-obtained = addresses so that routers can detect the conflict and re-request IP = addresses to prevent conflict. Much groaning ensued in the audience. = Noted that this is a real issue and we need to think about it some more. Comment from Philip Matthews: We don't ned a perfect solution, just = something in STUN control that suggests address randomization. That is, = new boxes that support this would randomize in net 10 instead of using = 192.168.0.0/24 for their private-side addresses. Suggestion from Keith Moore: We need to find a way to detect this sort = of brokenness and report it to the end user(or somebody else who can do = something) so that they can do something about it. Discussion about issues of randomization in address exhaustion continued = with no clear conclusion. --- General Discussion:=20 Comment: We initially saw a lot of wrongness with NAT implementations = that included ALGs. How does this not happen here? Ans: The protocol = suggested does not do any transparent functions. It only does things by = explicit interaction. Of course, there can always be bugs. Question (Aki Niemi): Have we enumerated the applications that would use = this? Ans: Any UDP applications that have long periods of no data = transmission. Re-discussion of power-management keepalive issue = followed. Noted that the suggested approach requires changes to existing = end points to gain the advantages of the suggested approach. For = applications that aren't currently using STUN, adding STUN support is = not an incremental change, even if adding STUN control afterwards would = be. Noted that there is a larger question. This sort of keepalive problem = applies not only to STUN-enabled NATs, but to stateful firewalls and = other things. Do we want to solve this problem once or many times? Comment from Keith Moore; These partial solutions for specific = applications may actually hurt deployability. It would be nice to have a = more general solution. Open question: Should we split discovery protocol from control protocol? = Noted by Hannes Tschofenig that there are people looking at STUN for = other protocols that need NAT traversal. Discussion from Cullen: I think of generality in terms of which = transport protocols it works with. There are things, like firewalls, = where we need to manage something besides UDP. Keith Moore Comment: Two approaches: One is how to fix up the infrastructure so that = works. The second is how to establish application layer protocols that = work on an existing infrastructure. We seem to be focused on making = applications work with existing IPV4 static-addressed NATs. Perhaps we = should be looking at the infrastructure instead. Comment: We may need to take v4-v6 protocol translators into account as = well. Perhaps we can define them to be better up-front, as they have = identical issues to NATs and firewalls. Some respondents think that = anything that really solves v4-v4 aps will be directly applicable even = without considering v6 up front. Directive from Lars: Would like to suggest v4-v6 is out of scope for = this discussion. Ongoing discussion ensued as to merits of narrow targeted solutions vs. = broadly applicable solutions. (All known arguments repeated several = times). Key discussion is incentive to equipment providers. Noted that = the UDP applications being discussed here tend to drive equipment = recommendation and purchase. Question: Is it reasonable to solve the problem in-the-small in one = group and in-the-large elsewhere?=20 Concern from Aki: This proposal seems to be targeted to SIP Outbound. = It's much easier to fix SIP Outbound using TCP.=20 Comment from Keith: There seems to be an assumption that a general = solution would be expensive. This may no be valid. We need to move = towards explicit guidance on where and what to upgrade. Noted that in addition to SIP and RTP, P2PSIP control connections and = HIP are candidates for the proposed STUN control solution. Comment from JDR: The market breeds complexity and incremental = single-issue solutions on its own. This is as general a solution as we = might ever get deployed. --- Topic: Future Directions Is there a a problem that needs to be solved? Are some functional = requirements or deployment considerations left unsatisfied by existing = protocols? Noted that there are studies that show existing UDP keepalive = reduces battery life by about 50%. Answers range from clearly yes to clearly no, with at least one "can not = be determined from this BOF". Discussion by JDR: The real problem is the "push" class problems. = Solutions like SIP Outbound convert these to client-server problems, but = at significant cost.=20 Keith notes that this sort of transformation creates barriers to = deployment of many midrange protocols that can't pay for the massive = rendezvous servers needed to use the current approaches.=20 Aki reiterated arguments that fixing NAT keepalive intervals will not = occur in the timeframe needed to make W-CDMA work, and that the only = reasonable solution is to move to TCP for SIP immediately. --- Poll from chairs: For are requirements left unsatisfied (this question): = Profound majority believes there are unsatisfied requirements? Poll question rephrased as "Are some functional requirements (for = avoiding frequent keepalive) or deployment considerations left = unsatisfied by existing protocols? And: Majority agrees, but a = substantial minority disagrees Question: Is there agreement that that the IETF should consider = developing a new NAT control mechanism to address these requirements? = Discussion on whether this should be a new solution, a fix to an = existing solution, be protocol agnostic (aka work for TCP), etc. Suggested that word "new" be deleted from question. Poll: Should the IETF try to solve the above problem? Result: Clear = majority support. Question: Is the NAT control STUN usage a reasonable approach to NAT = control, addressing the above requirements? Derek and others suggested that it would be reasonable if it includes = TCP support. Francois argues that this question is premature. Keith = believes this a a reasonable protocol, but that it would be nice to not = have a separate protocol for every nob that might be tweaked on a NAT or = a firewall. Philip suggest that the approach would be to bring it in as = an individual contribution and follow the usual process. Remi and Aki = re-suggest that the approach needs to solve TCP and UDP, but that we = should clearly focus on keepalive and not tweaking NAT knobs. It seems that we are trying to control the answer by controlling the = question here. Poll: Is the NAT control STUN usage a reasonable approach to NAT = control, addressing the above requirements? Yes: No: Maybe: Seems to be weighted toward yes and maybe, no slightly quieter. Poll: Given that we have a number of proposals in this space, has our = understanding of this problem space changed enough that we can build = something that people actually will deploy? Response judged 1/3 yes, 2/3 no. _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe