From safe-bounces@ietf.org Mon Oct 08 13:53:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IewnN-0004dR-G8; Mon, 08 Oct 2007 13:53:33 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1Ievqv-0000ic-47 for safe-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 12:53:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ievqu-0000XW-Nf; Mon, 08 Oct 2007 12:53:08 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ievqe-00082A-TU; Mon, 08 Oct 2007 12:52:53 -0400 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l98Gqm2L003780; Mon, 8 Oct 2007 12:52:48 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l98GpwEB024670; Mon, 8 Oct 2007 12:52:46 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Oct 2007 12:52:28 -0400 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: Mon, 8 Oct 2007 12:52:16 -0400 Message-ID: In-Reply-To: <470A480C.4040506@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tsv-area] BOF request under consideration: SAFE thread-index: AcgJvZ0rI60KpXPdQB6jKQIn8+/2ywADLx3Q References: <470A480C.4040506@ericsson.com> To: , , X-OriginalArrivalTime: 08 Oct 2007 16:52:28.0878 (UTC) FILETIME=[9C8126E0:01C809CB] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 X-Mailman-Approved-At: Mon, 08 Oct 2007 13:53:32 -0400 Cc: Black_David@emc.com Subject: [SAFE] RE: [tsv-area] BOF request under consideration: SAFE 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 Magnus, IKE and IKEv2 NAT Traversal for IPsec (also widely deployed, e.g., I believe my VPN client is using it to send this message ;-) ...) are not on the list of related technologies. This might be an omission, but I suspect that the (assumed) problem definition for SAFE may exclude IPsec (e.g., IKE and IKEv2 have a different security model for which a server like the STUN server may be problematic). This should be clarified. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Monday, October 08, 2007 11:09 AM > To: TSV Area; Behave WG; mmusic (E-mail) > Subject: [tsv-area] BOF request under consideration: SAFE >=20 > Hi, >=20 > We ADs have received a request for a BOF in Vancouver: SAFE - > Self-Address Fixing Evolution. See description below. I would appreciate > any feedback on this. For public discussion please use the SAFE mailing > list. >=20 > Post: safe@ietf.org > Subscribe: https://www1.ietf.org/mailman/listinfo/safe >=20 > Draft: > http://www.ietf.org/internet-drafts/draft-wing-behave-nat-control-stun-u sage-03.txt >=20 >=20 > SAFE - Self-Address Fixing Evolution > ------------------------------------ >=20 > Chairs: > TBD >=20 >=20 > ICE and its companion protocol STUN have been successfully deployed on > the Internet for NAT traversal. ICE and STUN have several characteristics > which contribute to their success: >=20 > 1. incremental deployment. ICE and STUN are functional without any > modifications to existing NATs. > 2. nested NATs. ICE and STUN work when there are multiple NATs > between a host and the Internet. > 3. topology unaware. ICE and STUN are not configured with > information about NATs, firewalls, or their locations -- only > with the IP address of a server on the Internet. > 4. simple security model. If a host behind a NAT is allowed to send > a packet across the NAT, it is allowed to receive a response. > 5. works on routed networks, which allows operation in both > enterprise networks and home networks. >=20 > Other NAT traversal protocols do not share these characteristics, > which hinders their widespread deployment. Specifically, >=20 > * incremental deployment is not possible with MIDCOM, NSIS-NSLP, > UPnP, or Bonjour. With all of these protocols, both the NAT > and the endpoint have to support the same protocol. > * nested NATs are not possible with UPnP or Bonjour. > * topology awareness is required of MIDCOM. > * security must be established between the controlling entity > and the NAT for MIDCOM and NSIS-NSLP. > * Both UPnP and Bonjour use broadcast packets which don't work > well on routed networks. >=20 > However, a drawback of ICE/STUN is its chatty keepalive traffic, > which is a result of STUN not knowing the binding lifetime of its > on-path NATs. This chattiness causes a burden on servers and > consumes network bandwidth, which is especially critical on wireless > networks. It is desirable to reduce this chattiness while still > retaining the important characteristics of STUN and ICE. >=20 > This BoF is intended to discuss one proposed technique, > draft-wing-behave-nat-control-stun-usage, which nearly eliminates > STUN's keepalive chatter and still preserves the desirable > characteristics of STUN/ICE. >=20 > The purpose of this BoF is to create a working group for this effort. >=20 >=20 > Agenda: > Introduction, Agenda .................................... 5 > Summary of existing NAT traversal techniques ............ 40 > (UPnP, NAT-PMP/Bonjour, MIDCOM techniques, NSIS-NSLP, ICE) > draft-wing-behave-nat-control-stun-usage ................ 40 > Q&A ..................................................... 25 > ---------- > total: 110 >=20 > Cheers >=20 > Magnus Westerlund >=20 > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 >=20 >=20 _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Tue Oct 09 15:43: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 1IfKz3-0002pP-ST; Tue, 09 Oct 2007 15:43:13 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IfKz1-0002p9-Uk for safe-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 15:43:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfKyw-0002mw-QT; Tue, 09 Oct 2007 15:43:06 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfKyv-0001Jm-Cf; Tue, 09 Oct 2007 15:43:06 -0400 X-IronPort-AV: E=Sophos;i="4.21,250,1188802800"; d="scan'208";a="22354175" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 09 Oct 2007 12:43:04 -0700 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 l99Jh4er019627; Tue, 9 Oct 2007 12:43:04 -0700 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l99Jh4Zp019511; Tue, 9 Oct 2007 19:43:04 GMT From: "Dan Wing" To: References: <470A480C.4040506@ericsson.com> Date: Tue, 9 Oct 2007 12:43:04 -0700 Message-ID: <09ec01c80aac$9bf1d8f0$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgJvZ0rI60KpXPdQB6jKQIn8+/2ywADLx3QADhZ4oA= In-Reply-To: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5586; t=1191958984; x=1192822984; 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:=20RE=3A=20[tsv-area]=20BOF=20request=20under=20consideration=3A =20SAFE |Sender:=20; bh=ptBSOaM/rlBxIS+CVNNM7bcd+DAEiSUPFLr2Mnzfa80=; b=QF5RRcqNyihT4dlWgDxyqJB4KfRbu+BtHTH+J3FycLWqSBGc5GtpD2z8fPB4VoBG72ogAVXm XYGt88p/Ehlw+/rLDxSiR08Vh8o6ai1q0b47TFRuGoBs3FdF1rN9Y5eQ; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: safe@ietf.org, tsv-area@ietf.org Subject: [SAFE] RE: [tsv-area] BOF request under consideration: SAFE 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, David. I am aware of IPsec-over-UDP (RFC3947, RFC3948), but I'm not sure how it applies in a comparison of MIDCOM, UPnP, NSIS-NSLP, NAT-PMP, and STUN/ICE. -d > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Monday, October 08, 2007 9:52 AM > To: magnus.westerlund@ericsson.com; tsv-area@ietf.org; safe@ietf.org > Cc: Black_David@emc.com > Subject: RE: [tsv-area] BOF request under consideration: SAFE > > Magnus, > > IKE and IKEv2 NAT Traversal for IPsec (also widely deployed, e.g., > I believe my VPN client is using it to send this message ;-) ...) > are not on the list of related technologies. This might be an > omission, but I suspect that the (assumed) problem definition > for SAFE may exclude IPsec (e.g., IKE and IKEv2 have a different > security model for which a server like the STUN server may be > problematic). This should be clarified. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Monday, October 08, 2007 11:09 AM > > To: TSV Area; Behave WG; mmusic (E-mail) > > Subject: [tsv-area] BOF request under consideration: SAFE > > > > Hi, > > > > We ADs have received a request for a BOF in Vancouver: SAFE - > > Self-Address Fixing Evolution. See description below. I would > appreciate > > any feedback on this. For public discussion please use the SAFE > mailing > > list. > > > > Post: safe@ietf.org > > Subscribe: https://www1.ietf.org/mailman/listinfo/safe > > > > Draft: > > > http://www.ietf.org/internet-drafts/draft-wing-behave-nat-cont > rol-stun-u > sage-03.txt > > > > > > SAFE - Self-Address Fixing Evolution > > ------------------------------------ > > > > Chairs: > > TBD > > > > > > ICE and its companion protocol STUN have been successfully > deployed on > > the Internet for NAT traversal. ICE and STUN have several > characteristics > > which contribute to their success: > > > > 1. incremental deployment. ICE and STUN are functional > without any > > modifications to existing NATs. > > 2. nested NATs. ICE and STUN work when there are multiple NATs > > between a host and the Internet. > > 3. topology unaware. ICE and STUN are not configured with > > information about NATs, firewalls, or their locations -- only > > with the IP address of a server on the Internet. > > 4. simple security model. If a host behind a NAT is > allowed to send > > a packet across the NAT, it is allowed to receive a response. > > 5. works on routed networks, which allows operation in both > > enterprise networks and home networks. > > > > Other NAT traversal protocols do not share these characteristics, > > which hinders their widespread deployment. Specifically, > > > > * incremental deployment is not possible with MIDCOM, NSIS-NSLP, > > UPnP, or Bonjour. With all of these protocols, both the NAT > > and the endpoint have to support the same protocol. > > * nested NATs are not possible with UPnP or Bonjour. > > * topology awareness is required of MIDCOM. > > * security must be established between the controlling entity > > and the NAT for MIDCOM and NSIS-NSLP. > > * Both UPnP and Bonjour use broadcast packets which don't work > > well on routed networks. > > > > However, a drawback of ICE/STUN is its chatty keepalive traffic, > > which is a result of STUN not knowing the binding lifetime of its > > on-path NATs. This chattiness causes a burden on servers and > > consumes network bandwidth, which is especially critical on wireless > > networks. It is desirable to reduce this chattiness while still > > retaining the important characteristics of STUN and ICE. > > > > This BoF is intended to discuss one proposed technique, > > draft-wing-behave-nat-control-stun-usage, which nearly eliminates > > STUN's keepalive chatter and still preserves the desirable > > characteristics of STUN/ICE. > > > > The purpose of this BoF is to create a working group for > this effort. > > > > > > Agenda: > > Introduction, Agenda .................................... 5 > > Summary of existing NAT traversal techniques ............ 40 > > (UPnP, NAT-PMP/Bonjour, MIDCOM techniques, NSIS-NSLP, ICE) > > draft-wing-behave-nat-control-stun-usage ................ 40 > > Q&A ..................................................... 25 > > ---------- > > total: 110 > > > > Cheers > > > > Magnus Westerlund > > > > IETF Transport Area Director & TSVWG Chair > > > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM/M > > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > ---------------------------------------------------------------------- > > > > > > > > _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Tue Oct 09 18:11:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfNIY-0007aW-8A; Tue, 09 Oct 2007 18:11:30 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IfNIX-0007aH-RO for safe-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 18:11:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfNIX-0007YV-FQ; Tue, 09 Oct 2007 18:11:29 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfNIM-0001Bo-M5; Tue, 09 Oct 2007 18:11:19 -0400 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l99MBE0B009466; Tue, 9 Oct 2007 18:11:14 -0400 (EDT) Received: from corpussmtp2.corp.emc.com (corpussmtp2.corp.emc.com [128.221.14.146]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l99MB17t025456; Tue, 9 Oct 2007 18:11:11 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 18:10:54 -0400 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, 9 Oct 2007 18:10:54 -0400 Message-ID: In-Reply-To: <09ec01c80aac$9bf1d8f0$c3f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tsv-area] BOF request under consideration: SAFE thread-index: AcgJvZ0rI60KpXPdQB6jKQIn8+/2ywADLx3QADhZ4oAABTDrAA== References: <470A480C.4040506@ericsson.com> <09ec01c80aac$9bf1d8f0$c3f0200a@cisco.com> To: X-OriginalArrivalTime: 09 Oct 2007 22:10:54.0971 (UTC) FILETIME=[430954B0:01C80AC1] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: safe@ietf.org, tsv-area@ietf.org Subject: [SAFE] RE: [tsv-area] BOF request under consideration: SAFE 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, Section 2.23 of RFC 4306 is also part of this technology. I'm also not sure how any of this applies to the BoF. The BoF proposal should probably contain a few sentences to say that IPsec NAT Traversal is a different problem, including a brief explanation of why it's different, and state that therefore it's outside the scope of the BoF. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: Tuesday, October 09, 2007 3:43 PM > To: Black, David > Cc: magnus.westerlund@ericsson.com; tsv-area@ietf.org; safe@ietf.org > Subject: RE: [tsv-area] BOF request under consideration: SAFE >=20 > Hi, David. =20 >=20 > I am aware of IPsec-over-UDP (RFC3947, RFC3948), but I'm not sure=20 > how it applies in a comparison of MIDCOM, UPnP, NSIS-NSLP,=20 > NAT-PMP, and STUN/ICE. >=20 > -d >=20 >=20 > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com]=20 > > Sent: Monday, October 08, 2007 9:52 AM > > To: magnus.westerlund@ericsson.com; tsv-area@ietf.org; safe@ietf.org > > Cc: Black_David@emc.com > > Subject: RE: [tsv-area] BOF request under consideration: SAFE > >=20 > > Magnus, > >=20 > > IKE and IKEv2 NAT Traversal for IPsec (also widely deployed, e.g., > > I believe my VPN client is using it to send this message ;-) ...) > > are not on the list of related technologies. This might be an > > omission, but I suspect that the (assumed) problem definition > > for SAFE may exclude IPsec (e.g., IKE and IKEv2 have a different > > security model for which a server like the STUN server may be > > problematic). This should be clarified. > >=20 > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > >=20 > > > -----Original Message----- > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > > > Sent: Monday, October 08, 2007 11:09 AM > > > To: TSV Area; Behave WG; mmusic (E-mail) > > > Subject: [tsv-area] BOF request under consideration: SAFE > > >=20 > > > Hi, > > >=20 > > > We ADs have received a request for a BOF in Vancouver: SAFE - > > > Self-Address Fixing Evolution. See description below. I would > > appreciate > > > any feedback on this. For public discussion please use the SAFE > > mailing > > > list. > > >=20 > > > Post: safe@ietf.org > > > Subscribe: https://www1.ietf.org/mailman/listinfo/safe > > >=20 > > > Draft: > > > > > http://www.ietf.org/internet-drafts/draft-wing-behave-nat-cont > > rol-stun-u > > sage-03.txt > > >=20 > > >=20 > > > SAFE - Self-Address Fixing Evolution > > > ------------------------------------ > > >=20 > > > Chairs: > > > TBD > > >=20 > > >=20 > > > ICE and its companion protocol STUN have been successfully=20 > > deployed on > > > the Internet for NAT traversal. ICE and STUN have several > > characteristics > > > which contribute to their success: > > >=20 > > > 1. incremental deployment. ICE and STUN are functional=20 > > without any > > > modifications to existing NATs. > > > 2. nested NATs. ICE and STUN work when there are multiple NATs > > > between a host and the Internet. > > > 3. topology unaware. ICE and STUN are not configured with > > > information about NATs, firewalls, or their locations -- only > > > with the IP address of a server on the Internet. > > > 4. simple security model. If a host behind a NAT is=20 > > allowed to send > > > a packet across the NAT, it is allowed to receive a response. > > > 5. works on routed networks, which allows operation in both > > > enterprise networks and home networks. > > >=20 > > > Other NAT traversal protocols do not share these characteristics, > > > which hinders their widespread deployment. Specifically, > > >=20 > > > * incremental deployment is not possible with MIDCOM, NSIS-NSLP, > > > UPnP, or Bonjour. With all of these protocols, both the NAT > > > and the endpoint have to support the same protocol. > > > * nested NATs are not possible with UPnP or Bonjour. > > > * topology awareness is required of MIDCOM. > > > * security must be established between the controlling entity > > > and the NAT for MIDCOM and NSIS-NSLP. > > > * Both UPnP and Bonjour use broadcast packets which don't work > > > well on routed networks. > > >=20 > > > However, a drawback of ICE/STUN is its chatty keepalive traffic, > > > which is a result of STUN not knowing the binding lifetime of its > > > on-path NATs. This chattiness causes a burden on servers and > > > consumes network bandwidth, which is especially critical=20 > on wireless > > > networks. It is desirable to reduce this chattiness while still > > > retaining the important characteristics of STUN and ICE. > > >=20 > > > This BoF is intended to discuss one proposed technique, > > > draft-wing-behave-nat-control-stun-usage, which nearly eliminates > > > STUN's keepalive chatter and still preserves the desirable > > > characteristics of STUN/ICE. > > >=20 > > > The purpose of this BoF is to create a working group for=20 > > this effort. > > >=20 > > >=20 > > > Agenda: > > > Introduction, Agenda .................................... 5 > > > Summary of existing NAT traversal techniques ............ 40 > > > (UPnP, NAT-PMP/Bonjour, MIDCOM techniques, NSIS-NSLP, ICE) > > > draft-wing-behave-nat-control-stun-usage ................ 40 > > > Q&A ..................................................... 25 > > > ---------- > > > total: 110 > > >=20 > > > Cheers > > >=20 > > > Magnus Westerlund > > >=20 > > > IETF Transport Area Director & TSVWG Chair > > >=20 > >=20 > ---------------------------------------------------------------------- > > > Multimedia Technologies, Ericsson Research EAB/TVM/M > > >=20 > >=20 > ---------------------------------------------------------------------- > > > Ericsson AB | Phone +46 8 4048287 > > > Torshamsgatan 23 | Fax +46 8 7575550 > > > S-164 80 Stockholm, Sweden | mailto:=20 > magnus.westerlund@ericsson.com > > >=20 > >=20 > ---------------------------------------------------------------------- > > >=20 > > >=20 > > >=20 > > >=20 >=20 >=20 _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Tue Oct 09 20:04:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfP3t-0006yC-O1; Tue, 09 Oct 2007 20:04:29 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IfP3s-0006y0-Mq for safe-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 20:04:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfP3s-0006xf-3L; Tue, 09 Oct 2007 20:04:28 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfP3l-0000V2-Md; Tue, 09 Oct 2007 20:04:28 -0400 X-IronPort-AV: E=Sophos;i="4.21,251,1188802800"; d="scan'208";a="533212952" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 09 Oct 2007 17:04:16 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9A04Gwm010160; Tue, 9 Oct 2007 17:04:16 -0700 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9A04FZo013481; Wed, 10 Oct 2007 00:04:15 GMT From: "Dan Wing" To: References: <470A480C.4040506@ericsson.com> <09ec01c80aac$9bf1d8f0$c3f0200a@cisco.com> Date: Tue, 9 Oct 2007 17:04:14 -0700 Message-ID: <0c6101c80ad1$189dda60$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgJvZ0rI60KpXPdQB6jKQIn8+/2ywADLx3QADhZ4oAABTDrAAADeRtg In-Reply-To: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8845; t=1191974656; x=1192838656; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[tsv-area]=20BOF=20request=20under=20consideration=3A =20SAFE |Sender:=20; bh=gFi8lE/e4tiQrT3GUpMMxIzKPMaQSHsFJ/RtKLk7l6I=; b=HS5DAKrQml80MtMt4Bh+kfdnYLRdUr61nATlMoe2LQUUPOuepcUq51LB1NvB/9ulfKYyJqDi D6hFDmx5hMULzTVeYhdDrcApBuCWzIAPO3C5WhZS//+bpbkQcZzlvBoF; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: safe@ietf.org, tsv-area@ietf.org Subject: [SAFE] RE: [tsv-area] BOF request under consideration: SAFE 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 Thanks for the pointer. I read RFC4306 section 2.23, and IKE (and IPsec) could benefit from reduced keepalive traffic if it knew how often to send the keeaplive. It could learn or adjust the keepalive interval using UPnP, STUN Control, NAT-PMP, etc. So, the IPsec/IKE UDP-based NAT traversal technique is another thing that could benefit from knowing the NAT binding lifetime -- much like SIP-Outbound benefits from knowing the NAT binding lifetime and is able to reduce keepalive traffic. So, I think I'll mention this reduction of IPsec keepalive traffic is another benefit that STUN Control could bring. In that light, I added the following to the soon-to-be-published draft-wing-behave-nat-control-stun-usage-04.txt: 2.4. Reduce IPsec keepalive messages STUN Control is also able to reduce keepalive traffic for non-STUN protocols. In Section 4 of [RFC3948], it is suggested that IPsec keepalive packets be sent every 20 seconds if an on-path NAT is detected. If a host and its NAT were to implement STUN Control, the host can query and control the NAT's binding lifetime, and thus reduce the NAT keepalive traffic. This reduction in keepalive traffic would slightly reduce the load on its IPsec concentrator. -d > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Tuesday, October 09, 2007 3:11 PM > To: dwing@cisco.com > Cc: magnus.westerlund@ericsson.com; tsv-area@ietf.org; safe@ietf.org > Subject: RE: [tsv-area] BOF request under consideration: SAFE > > Dan, > > Section 2.23 of RFC 4306 is also part of this technology. > > I'm also not sure how any of this applies to the BoF. The > BoF proposal should probably contain a few sentences to > say that IPsec NAT Traversal is a different problem, > including a brief explanation of why it's different, and > state that therefore it's outside the scope of the BoF. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Tuesday, October 09, 2007 3:43 PM > > To: Black, David > > Cc: magnus.westerlund@ericsson.com; tsv-area@ietf.org; safe@ietf.org > > Subject: RE: [tsv-area] BOF request under consideration: SAFE > > > > Hi, David. > > > > I am aware of IPsec-over-UDP (RFC3947, RFC3948), but I'm not sure > > how it applies in a comparison of MIDCOM, UPnP, NSIS-NSLP, > > NAT-PMP, and STUN/ICE. > > > > -d > > > > > > > -----Original Message----- > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > Sent: Monday, October 08, 2007 9:52 AM > > > To: magnus.westerlund@ericsson.com; tsv-area@ietf.org; > safe@ietf.org > > > Cc: Black_David@emc.com > > > Subject: RE: [tsv-area] BOF request under consideration: SAFE > > > > > > Magnus, > > > > > > IKE and IKEv2 NAT Traversal for IPsec (also widely deployed, e.g., > > > I believe my VPN client is using it to send this message ;-) ...) > > > are not on the list of related technologies. This might be an > > > omission, but I suspect that the (assumed) problem definition > > > for SAFE may exclude IPsec (e.g., IKE and IKEv2 have a different > > > security model for which a server like the STUN server may be > > > problematic). This should be clarified. > > > > > > Thanks, > > > --David > > > ---------------------------------------------------- > > > David L. Black, Senior Technologist > > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > ---------------------------------------------------- > > > > > > > -----Original Message----- > > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > > Sent: Monday, October 08, 2007 11:09 AM > > > > To: TSV Area; Behave WG; mmusic (E-mail) > > > > Subject: [tsv-area] BOF request under consideration: SAFE > > > > > > > > Hi, > > > > > > > > We ADs have received a request for a BOF in Vancouver: SAFE - > > > > Self-Address Fixing Evolution. See description below. I would > > > appreciate > > > > any feedback on this. For public discussion please use the SAFE > > > mailing > > > > list. > > > > > > > > Post: safe@ietf.org > > > > Subscribe: https://www1.ietf.org/mailman/listinfo/safe > > > > > > > > Draft: > > > > > > > http://www.ietf.org/internet-drafts/draft-wing-behave-nat-cont > > > rol-stun-u > > > sage-03.txt > > > > > > > > > > > > SAFE - Self-Address Fixing Evolution > > > > ------------------------------------ > > > > > > > > Chairs: > > > > TBD > > > > > > > > > > > > ICE and its companion protocol STUN have been successfully > > > deployed on > > > > the Internet for NAT traversal. ICE and STUN have several > > > characteristics > > > > which contribute to their success: > > > > > > > > 1. incremental deployment. ICE and STUN are functional > > > without any > > > > modifications to existing NATs. > > > > 2. nested NATs. ICE and STUN work when there are > multiple NATs > > > > between a host and the Internet. > > > > 3. topology unaware. ICE and STUN are not configured with > > > > information about NATs, firewalls, or their > locations -- only > > > > with the IP address of a server on the Internet. > > > > 4. simple security model. If a host behind a NAT is > > > allowed to send > > > > a packet across the NAT, it is allowed to receive > a response. > > > > 5. works on routed networks, which allows operation in both > > > > enterprise networks and home networks. > > > > > > > > Other NAT traversal protocols do not share these > characteristics, > > > > which hinders their widespread deployment. Specifically, > > > > > > > > * incremental deployment is not possible with MIDCOM, > NSIS-NSLP, > > > > UPnP, or Bonjour. With all of these protocols, both the NAT > > > > and the endpoint have to support the same protocol. > > > > * nested NATs are not possible with UPnP or Bonjour. > > > > * topology awareness is required of MIDCOM. > > > > * security must be established between the controlling entity > > > > and the NAT for MIDCOM and NSIS-NSLP. > > > > * Both UPnP and Bonjour use broadcast packets which don't work > > > > well on routed networks. > > > > > > > > However, a drawback of ICE/STUN is its chatty keepalive traffic, > > > > which is a result of STUN not knowing the binding > lifetime of its > > > > on-path NATs. This chattiness causes a burden on servers and > > > > consumes network bandwidth, which is especially critical > > on wireless > > > > networks. It is desirable to reduce this chattiness while still > > > > retaining the important characteristics of STUN and ICE. > > > > > > > > This BoF is intended to discuss one proposed technique, > > > > draft-wing-behave-nat-control-stun-usage, which nearly > eliminates > > > > STUN's keepalive chatter and still preserves the desirable > > > > characteristics of STUN/ICE. > > > > > > > > The purpose of this BoF is to create a working group for > > > this effort. > > > > > > > > > > > > Agenda: > > > > Introduction, Agenda .................................... 5 > > > > Summary of existing NAT traversal techniques ............ 40 > > > > (UPnP, NAT-PMP/Bonjour, MIDCOM techniques, NSIS-NSLP, ICE) > > > > draft-wing-behave-nat-control-stun-usage ................ 40 > > > > Q&A ..................................................... 25 > > > > ---------- > > > > total: 110 > > > > > > > > Cheers > > > > > > > > Magnus Westerlund > > > > > > > > IETF Transport Area Director & TSVWG Chair > > > > > > > > > > ---------------------------------------------------------------------- > > > > Multimedia Technologies, Ericsson Research EAB/TVM/M > > > > > > > > > > ---------------------------------------------------------------------- > > > > Ericsson AB | Phone +46 8 4048287 > > > > Torshamsgatan 23 | Fax +46 8 7575550 > > > > S-164 80 Stockholm, Sweden | mailto: > > magnus.westerlund@ericsson.com > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Wed Oct 10 15:32:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfhIQ-0001Rg-3U; Wed, 10 Oct 2007 15:32:42 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IfhIN-00014U-VJ for safe-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 15:32:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfhIJ-0000xJ-Ee for safe@ietf.org; Wed, 10 Oct 2007 15:32:35 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfhII-00081C-VT for safe@ietf.org; Wed, 10 Oct 2007 15:32:35 -0400 X-IronPort-AV: E=Sophos;i="4.21,255,1188802800"; d="scan'208";a="405375777" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 10 Oct 2007 12:32:34 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9AJWYL1023260 for ; Wed, 10 Oct 2007 12:32:34 -0700 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l9AJWXpH003194 for ; Wed, 10 Oct 2007 19:32:33 GMT From: "Dan Wing" To: Date: Wed, 10 Oct 2007 12:32:37 -0700 Message-ID: <042001c80b74$509c46b0$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgLbNxFEbzYYiATRru6vIm1L1ePxQAAbM5A DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=627; t=1192044754; x=1192908754; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20nat-control-stun-usage-04 |Sender:=20; bh=cEungfNMd1PYNtHNB/nSXG8xrQ2xTpgYsCAO1JXtl0U=; b=nptDsKPkp7vZ6H4nfhVHizMYKHdP3+xELAdOGy5HjXQWmbfOR1J6bWILiZAAlQfhH3Hyjj76 vNQTMC2NtjNWT6mvM85fIRUIWqMi97j4DCDJJ2wCiJAmB+R0uKzsm/Q8/FX8CgLcAhJ53aVNTX /tLUa0A6IiOLpMWCMnRcJRTq8=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [SAFE] nat-control-stun-usage-04 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 We just submitted a new version of STUN Control, http://www.ietf.org/internet-drafts/draft-wing-behave-nat-control-stun-usage-0 4.txt The changes were mostly organizational and editorial, and included: o Clarified that all existing bindings, for that source IP address and UDP port, are controlled with STUN Control. o Introduction now concentrates on the primary purpose of STUN Control, namely reducing keepalive traffic for SIP-Outbound. There is also an appendix which describes Linux implementation specifics. Diffs are at: http://www.tinyurl.com/2bak33 Comments welcome, -d _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Wed Oct 10 18:26:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifk0o-0000I9-QE; Wed, 10 Oct 2007 18:26:42 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1Ifk0n-0000Hz-NF for safe-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 18:26:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifk0n-0000Hr-D6 for safe@ietf.org; Wed, 10 Oct 2007 18:26:41 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifk0m-0004eY-WE for safe@ietf.org; Wed, 10 Oct 2007 18:26:41 -0400 Received: from win2003.dickmann2003.home (p548A6837.dip.t-dialin.net [84.138.104.55]) by www.difra-computer.de (Postfix) with ESMTP id 7D6A63E404A for ; Wed, 10 Oct 2007 23:57:57 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Oct 2007 00:08:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Linux implementation of STUN Control Thread-Index: AcgLjFEkbIldg2RiRaCROUzHtGMgAw== From: "Christian Dickmann" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [SAFE] Linux implementation of STUN Control 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 all, I wanted to make you aware of a Linux-based implementation of STUN = Control I have been working on recently. It uses the open source STUN = implementation coming with NICE [1] and extends it to support = controlling the Linux NAT functionality. In order to interface with the = NAT functionality, I created a Linux kernel module which does the actual = job of extending NAT binding lifetimes.=20 I created a webpage that describes the structure and some implementation = details (mostly Linux specifics). It also shows the nested-NAT discovery = and reduced-refreshes use-cases in action. Take a look at: http://www.christian-dickmann.de/stun.php I am still working on adding things like the BOOTNONCE, testing = stability, documentation and tying up some loose ends. Once this is = done, I plan on releasing the full source. At the moment, parts of the = current source code are available on the webpage as a patch to NICE. Overall, I can already say that implementing STUN Control (at least the = Outside-In mechanism) is not a lot of work and pretty much straight = forward.=20 Best regards, Christian Dickmann University of G=F6ttingen [1] http://nice.freedesktop.org/wiki/ _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Thu Oct 11 06:39: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 1IfvRb-0001AO-Er; Thu, 11 Oct 2007 06:39:07 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IfvRb-0001AE-2P for safe-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 06:39:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfvRW-00016C-7i; Thu, 11 Oct 2007 06:39:02 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfvRU-0004qs-II; Thu, 11 Oct 2007 06:39:02 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9BAcqDl022675; Thu, 11 Oct 2007 13:38:52 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 13:38:51 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 13:22:29 +0300 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] RE: [tsv-area] BOF request under consideration: SAFE Date: Thu, 11 Oct 2007 13:22:27 +0300 Message-ID: In-Reply-To: <0c6101c80ad1$189dda60$c3f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SAFE] RE: [tsv-area] BOF request under consideration: SAFE Thread-Index: AcgJvZ0rI60KpXPdQB6jKQIn8+/2ywADLx3QADhZ4oAABTDrAAADeRtgAEgK72A= References: <470A480C.4040506@ericsson.com><09ec01c80aac$9bf1d8f0$c3f0200a@cisco.com> <0c6101c80ad1$189dda60$c3f0200a@cisco.com> From: To: , X-OriginalArrivalTime: 11 Oct 2007 10:22:29.0131 (UTC) FILETIME=[A0685DB0:01C80BF0] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: safe@ietf.org, tsv-area@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, STUN control would be able to reduce keepalive traffic for all UDP-based applications or UDP encapsultated protocols. In addition to IPSec/IKE, there are also other protocols such as DSMIPv6 and Teredo, that use UDP encapsulation to work through NATs. So, one clear use case for STUN control is to optimize how any of those protocols work through NATs. IPSec VPNs are of special interest as they are already widely used. For instance you can try to run a VPN connection on any handheld device in any wide-area radio network (CDMA EV-DO, WCDMA, EDGE, WiMAX) and see how long the battery on the device will last. Most of the battery is consumed by NAT keepalives sent every 20 to 120 seconds while there is no real traffic to send. Optimizing this should be of interest to:=20 a) users (get their work done before the battery dies)=20 b) enterprises (allow their employees get their work done while on the road)=20 c) handheld device vendors (make VPN usable in the devices)=20 d) wireless operators (make VPN usable in their network)=20 e) NAT vendors (sell boxes that meet the reqs of the above groups) In the long run any IPv6 over IPv4 solutions might also become necessary for mobile hosts and they will face the same UDP NAT problem.=20 Markus =20 >-----Original Message----- >From: ext Dan Wing [mailto:dwing@cisco.com]=20 >Sent: 10 October, 2007 03:04 >To: Black_David@emc.com >Cc: safe@ietf.org; tsv-area@ietf.org >Subject: [SAFE] RE: [tsv-area] BOF request under consideration: SAFE > >Thanks for the pointer. I read RFC4306 section 2.23, and IKE=20 >(and IPsec) could benefit from reduced keepalive traffic if it=20 >knew how often to send the keeaplive. It could learn or=20 >adjust the keepalive interval using UPnP, STUN Control, NAT-PMP, etc. > >So, the IPsec/IKE UDP-based NAT traversal technique is another=20 >thing that could benefit from knowing the NAT binding lifetime >-- much like SIP-Outbound benefits from knowing the NAT=20 >binding lifetime and is able to reduce keepalive traffic. > >So, I think I'll mention this reduction of IPsec keepalive=20 >traffic is another benefit that STUN Control could bring. In=20 >that light, I added the following to the soon-to-be-published >draft-wing-behave-nat-control-stun-usage-04.txt: > > 2.4. Reduce IPsec keepalive messages > > STUN Control is also able to reduce keepalive traffic for non-STUN > protocols. In Section 4 of [RFC3948], it is suggested that IPsec > keepalive packets be sent every 20 seconds if an on-path NAT is > detected. If a host and its NAT were to implement STUN Control, the > host can query and control the NAT's binding lifetime, and thus > reduce the NAT keepalive traffic. This reduction in keepalive > traffic would slightly reduce the load on its IPsec concentrator. > >-d > > >> -----Original Message----- >> From: Black_David@emc.com [mailto:Black_David@emc.com] >> Sent: Tuesday, October 09, 2007 3:11 PM >> To: dwing@cisco.com >> Cc: magnus.westerlund@ericsson.com; tsv-area@ietf.org; safe@ietf.org >> Subject: RE: [tsv-area] BOF request under consideration: SAFE >>=20 >> Dan, >>=20 >> Section 2.23 of RFC 4306 is also part of this technology. >>=20 >> I'm also not sure how any of this applies to the BoF. The BoF=20 >> proposal should probably contain a few sentences to say that=20 >IPsec NAT=20 >> Traversal is a different problem, including a brief=20 >explanation of why=20 >> it's different, and state that therefore it's outside the=20 >scope of the=20 >> BoF. >>=20 >> Thanks, >> --David >> ---------------------------------------------------- >> David L. Black, Senior Technologist >> EMC Corporation, 176 South St., Hopkinton, MA 01748 >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> black_david@emc.com Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >>=20 >> > -----Original Message----- >> > From: Dan Wing [mailto:dwing@cisco.com] >> > Sent: Tuesday, October 09, 2007 3:43 PM >> > To: Black, David >> > Cc: magnus.westerlund@ericsson.com; tsv-area@ietf.org;=20 >safe@ietf.org >> > Subject: RE: [tsv-area] BOF request under consideration: SAFE >> >=20 >> > Hi, David. =20 >> >=20 >> > I am aware of IPsec-over-UDP (RFC3947, RFC3948), but I'm not sure=20 >> > how it applies in a comparison of MIDCOM, UPnP, NSIS-NSLP,=20 >NAT-PMP,=20 >> > and STUN/ICE. >> >=20 >> > -d >> >=20 >> >=20 >> > > -----Original Message----- >> > > From: Black_David@emc.com [mailto:Black_David@emc.com] >> > > Sent: Monday, October 08, 2007 9:52 AM >> > > To: magnus.westerlund@ericsson.com; tsv-area@ietf.org; >> safe@ietf.org >> > > Cc: Black_David@emc.com >> > > Subject: RE: [tsv-area] BOF request under consideration: SAFE >> > >=20 >> > > Magnus, >> > >=20 >> > > IKE and IKEv2 NAT Traversal for IPsec (also widely=20 >deployed, e.g.,=20 >> > > I believe my VPN client is using it to send this message=20 >;-) ...)=20 >> > > are not on the list of related technologies. This might be an=20 >> > > omission, but I suspect that the (assumed) problem=20 >definition for=20 >> > > SAFE may exclude IPsec (e.g., IKE and IKEv2 have a different=20 >> > > security model for which a server like the STUN server may be=20 >> > > problematic). This should be clarified. >> > >=20 >> > > Thanks, >> > > --David >> > > ---------------------------------------------------- >> > > David L. Black, Senior Technologist EMC Corporation, 176 South=20 >> > > St., Hopkinton, MA 01748 >> > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> > > black_david@emc.com Mobile: +1 (978) 394-7754 >> > > ---------------------------------------------------- >> > >=20 >> > > > -----Original Message----- >> > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> > > > Sent: Monday, October 08, 2007 11:09 AM >> > > > To: TSV Area; Behave WG; mmusic (E-mail) >> > > > Subject: [tsv-area] BOF request under consideration: SAFE >> > > >=20 >> > > > Hi, >> > > >=20 >> > > > We ADs have received a request for a BOF in Vancouver: SAFE -=20 >> > > > Self-Address Fixing Evolution. See description below. I would >> > > appreciate >> > > > any feedback on this. For public discussion please use the SAFE >> > > mailing >> > > > list. >> > > >=20 >> > > > Post: safe@ietf.org >> > > > Subscribe: https://www1.ietf.org/mailman/listinfo/safe >> > > >=20 >> > > > Draft: >> > > > >> > > http://www.ietf.org/internet-drafts/draft-wing-behave-nat-cont >> > > rol-stun-u >> > > sage-03.txt >> > > >=20 >> > > >=20 >> > > > SAFE - Self-Address Fixing Evolution >> > > > ------------------------------------ >> > > >=20 >> > > > Chairs: >> > > > TBD >> > > >=20 >> > > >=20 >> > > > ICE and its companion protocol STUN have been successfully >> > > deployed on >> > > > the Internet for NAT traversal. ICE and STUN have several >> > > characteristics >> > > > which contribute to their success: >> > > >=20 >> > > > 1. incremental deployment. ICE and STUN are functional >> > > without any >> > > > modifications to existing NATs. >> > > > 2. nested NATs. ICE and STUN work when there are >> multiple NATs >> > > > between a host and the Internet. >> > > > 3. topology unaware. ICE and STUN are not configured with >> > > > information about NATs, firewalls, or their >> locations -- only >> > > > with the IP address of a server on the Internet. >> > > > 4. simple security model. If a host behind a NAT is >> > > allowed to send >> > > > a packet across the NAT, it is allowed to receive >> a response. >> > > > 5. works on routed networks, which allows operation in both >> > > > enterprise networks and home networks. >> > > >=20 >> > > > Other NAT traversal protocols do not share these >> characteristics, >> > > > which hinders their widespread deployment. Specifically, >> > > >=20 >> > > > * incremental deployment is not possible with MIDCOM, >> NSIS-NSLP, >> > > > UPnP, or Bonjour. With all of these protocols,=20 >both the NAT >> > > > and the endpoint have to support the same protocol. >> > > > * nested NATs are not possible with UPnP or Bonjour. >> > > > * topology awareness is required of MIDCOM. >> > > > * security must be established between the controlling entity >> > > > and the NAT for MIDCOM and NSIS-NSLP. >> > > > * Both UPnP and Bonjour use broadcast packets which=20 >don't work >> > > > well on routed networks. >> > > >=20 >> > > > However, a drawback of ICE/STUN is its chatty=20 >keepalive traffic,=20 >> > > > which is a result of STUN not knowing the binding >> lifetime of its >> > > > on-path NATs. This chattiness causes a burden on servers and=20 >> > > > consumes network bandwidth, which is especially critical >> > on wireless >> > > > networks. It is desirable to reduce this chattiness=20 >while still=20 >> > > > retaining the important characteristics of STUN and ICE. >> > > >=20 >> > > > This BoF is intended to discuss one proposed technique,=20 >> > > > draft-wing-behave-nat-control-stun-usage, which nearly >> eliminates >> > > > STUN's keepalive chatter and still preserves the desirable=20 >> > > > characteristics of STUN/ICE. >> > > >=20 >> > > > The purpose of this BoF is to create a working group for >> > > this effort. >> > > >=20 >> > > >=20 >> > > > Agenda: >> > > > Introduction, Agenda .................................... 5 >> > > > Summary of existing NAT traversal techniques ............ 40 >> > > > (UPnP, NAT-PMP/Bonjour, MIDCOM techniques, NSIS-NSLP, ICE) >> > > > draft-wing-behave-nat-control-stun-usage ................ 40 >> > > > Q&A ..................................................... 25 >> > > > ---------- >> > > > total: 110 >> > > >=20 >> > > > Cheers >> > > >=20 >> > > > Magnus Westerlund >> > > >=20 >> > > > IETF Transport Area Director & TSVWG Chair >> > > >=20 >> > >=20 >> >=20 >>=20 >---------------------------------------------------------------------- >> > > > Multimedia Technologies, Ericsson Research EAB/TVM/M >> > > >=20 >> > >=20 >> >=20 >>=20 >---------------------------------------------------------------------- >> > > > Ericsson AB | Phone +46 8 4048287 >> > > > Torshamsgatan 23 | Fax +46 8 7575550 >> > > > S-164 80 Stockholm, Sweden | mailto:=20 >> > magnus.westerlund@ericsson.com >> > > >=20 >> > >=20 >> >=20 >>=20 >---------------------------------------------------------------------- >> > > >=20 >> > > >=20 >> > > >=20 >> > > >=20 >> >=20 >> >=20 > > >_______________________________________________ >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 Oct 11 06:57: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 1Ifvjb-0005m8-4b; Thu, 11 Oct 2007 06:57:43 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IfvjZ-0005ko-Vj for safe-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 06:57:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfvjZ-0005kf-Kw for safe@ietf.org; Thu, 11 Oct 2007 06:57:41 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfvjZ-0005SA-3V for safe@ietf.org; Thu, 11 Oct 2007 06:57:41 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9BAvYfa017592; Thu, 11 Oct 2007 13:57:34 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 13:57:14 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 13:57:14 +0300 Received: from esdhcp04049.research.nokia.com ([172.21.40.49]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 13:57:14 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: safe@ietf.org Subject: Re: [SAFE] nat-control-stun-usage-04 Date: Thu, 11 Oct 2007 13:57:44 +0300 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <042001c80b74$509c46b0$c3f0200a@cisco.com> In-Reply-To: <042001c80b74$509c46b0$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710111357.44688.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 11 Oct 2007 10:57:14.0105 (UTC) FILETIME=[7B262690:01C80BF5] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: 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 Wednesday 10 October 2007 22:32:37 ext Dan Wing, vous avez =E9crit=A0: > We just submitted a new version of STUN Control, > http://www.ietf.org/internet-drafts/draft-wing-behave-nat-control-stun-us= ag >e-0 4.txt > > The changes were mostly organizational and editorial, and included: > > o Clarified that all existing bindings, for that source IP address > and UDP port, are controlled with STUN Control. > > o Introduction now concentrates on the primary purpose of STUN > Control, namely reducing keepalive traffic for SIP-Outbound. As far as I understand, STUN in general, and STUN in particular, can be use= d=20 for any UDP-based always-on protocol. ESP-in-UDP, TEREDO, perhaps some long= =20 usages of RTP (such as MIDI-over-RTP(?) or RTSP-based streaming), proprieta= ry=20 UDP overlays (not giving any names)... And then, there is the relation to ICE in finding "intermediary" NAT mappin= gs=20 in nested NATs scenarios. At the same time, I thought SIP Outbound was going to recommend TCP, so tha= t=20 it could end up being a less likely "customer" of STUN control?? =2D-=20 R=E9mi Denis-Courmont _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Thu Oct 11 08:54:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfxYR-0003om-NF; Thu, 11 Oct 2007 08:54:19 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IfxYQ-0003oQ-Fz for safe-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 08:54:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfxYQ-0003oC-2W for safe@ietf.org; Thu, 11 Oct 2007 08:54:18 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfxYO-0000pA-Rx for safe@ietf.org; Thu, 11 Oct 2007 08:54:17 -0400 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 l9BCs3jV028971; Thu, 11 Oct 2007 15:54:13 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 15:53:58 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 15:53:58 +0300 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: Thu, 11 Oct 2007 15:53:56 +0300 Message-ID: In-Reply-To: <470A480C.4040506@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] BOF request under consideration: SAFE Thread-Index: AcgJvnf9Mynnb4zGT9exNDYn1iSzyACRCb/A References: <470A480C.4040506@ericsson.com> From: To: , X-OriginalArrivalTime: 11 Oct 2007 12:53:58.0396 (UTC) FILETIME=[CA0823C0:01C80C05] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: Subject: [SAFE] RE: [BEHAVE] BOF request under consideration: SAFE 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, I support the goals of this BOF and I believe in the reasoning provided by the charter. I have two concerns that should be addressed before I think STUN NAT control could become successfully deployed: 1. Technical issue: STUN control allows a host/application to discover NATs and disover/set NAT binding timers for UDP (typically to higher values than what the defaults, perhaps around 30-300 s, would be). However, BEFORE the application can start using the increased keepalive period, it needs to have a some sort of assurance that there aren't OTHER middleboxes on its path with lower keepalive values. Otherwise it would be impossible to rely on the increased timer values, and thus the whole mechanism might fail in practice. So, I would like to include in the charter a goal where such discovery mechanisms and their applicability are considered. The actual mechanism might be based on STUN or something else. I know this is a hard problem in general, but in many access network topologies the problem can be solved by configuration + discovery. I'd be happy to contribute in this area. Actually I believe this discovery part to be the real issue with this whole work, rather than the details of STUN itself.=20 2. Deployment issue: We do have several protocols in this area, for instance NSIS. Their deployment does not look to be happening. For STUN control to be useful, we would need real interest from some real NAT/FW vendors. It's of course difficult to say how to verify this in a BOF beyond matching people's e-mail addresses to NAT/FW product brands :-) Personally I can speak for a single client/host/device vendor only. Markus =20 =20 >-----Original Message----- >From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 >Sent: 08 October, 2007 18:09 >To: TSV Area; Behave WG; mmusic (E-mail) >Subject: [BEHAVE] BOF request under consideration: SAFE > >Hi, > >We ADs have received a request for a BOF in Vancouver: SAFE -=20 >Self-Address Fixing Evolution. See description below. I would=20 >appreciate any feedback on this. For public discussion please=20 >use the SAFE mailing list. > >Post: safe@ietf.org >Subscribe: https://www1.ietf.org/mailman/listinfo/safe > >Draft: >http://www.ietf.org/internet-drafts/draft-wing-behave-nat-contr ol-stun-usage-03.txt > > >SAFE - Self-Address Fixing Evolution >------------------------------------ > >Chairs: > TBD > > >ICE and its companion protocol STUN have been successfully=20 >deployed on the Internet for NAT traversal. ICE and STUN have=20 >several characteristics which contribute to their success: > > 1. incremental deployment. ICE and STUN are functional without any > modifications to existing NATs. > 2. nested NATs. ICE and STUN work when there are multiple NATs > between a host and the Internet. > 3. topology unaware. ICE and STUN are not configured with > information about NATs, firewalls, or their locations -- only > with the IP address of a server on the Internet. > 4. simple security model. If a host behind a NAT is allowed to send > a packet across the NAT, it is allowed to receive a response. > 5. works on routed networks, which allows operation in both > enterprise networks and home networks. > >Other NAT traversal protocols do not share these=20 >characteristics, which hinders their widespread deployment. =20 >Specifically, > > * incremental deployment is not possible with MIDCOM, NSIS-NSLP, > UPnP, or Bonjour. With all of these protocols, both the NAT > and the endpoint have to support the same protocol. > * nested NATs are not possible with UPnP or Bonjour. > * topology awareness is required of MIDCOM. > * security must be established between the controlling entity > and the NAT for MIDCOM and NSIS-NSLP. > * Both UPnP and Bonjour use broadcast packets which don't work > well on routed networks. > >However, a drawback of ICE/STUN is its chatty keepalive=20 >traffic, which is a result of STUN not knowing the binding=20 >lifetime of its on-path NATs. This chattiness causes a burden=20 >on servers and consumes network bandwidth, which is especially=20 >critical on wireless networks. It is desirable to reduce this=20 >chattiness while still retaining the important characteristics=20 >of STUN and ICE. > >This BoF is intended to discuss one proposed technique,=20 >draft-wing-behave-nat-control-stun-usage, which nearly=20 >eliminates STUN's keepalive chatter and still preserves the=20 >desirable characteristics of STUN/ICE. > >The purpose of this BoF is to create a working group for this effort. > > >Agenda: > Introduction, Agenda .................................... 5 > Summary of existing NAT traversal techniques ............ 40 > (UPnP, NAT-PMP/Bonjour, MIDCOM techniques, NSIS-NSLP, ICE) > draft-wing-behave-nat-control-stun-usage ................ 40 > Q&A ..................................................... 25 > ---------- > total: 110 > >Cheers > >Magnus Westerlund > >IETF Transport Area Director & TSVWG Chair >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM/M >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > > >_______________________________________________ >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 Thu Oct 11 09:33: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 1IfyAR-0008Qe-7f; Thu, 11 Oct 2007 09:33:35 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IfyAP-0008Pp-VJ for safe-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 09:33:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfyAP-0008Pg-KH for safe@ietf.org; Thu, 11 Oct 2007 09:33:33 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfyAP-0004Nn-1r for safe@ietf.org; Thu, 11 Oct 2007 09:33:33 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 858252051D for ; Thu, 11 Oct 2007 15:33:32 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-28-470e262c37c0 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 755C5211F0 for ; Thu, 11 Oct 2007 15:33:32 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 15:33:32 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 15:33:31 +0200 Message-ID: <470E262B.1080505@ericsson.com> Date: Thu, 11 Oct 2007 15:33:31 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: safe@ietf.org X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Oct 2007 13:33:31.0851 (UTC) FILETIME=[50B8A1B0:01C80C0B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF request under consideration: SAFE 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, This was sent to the V6OPS list by Pekka Savola. I forward it to the SAFE list with his permission for commenting. Magnus Westerlund -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Monday, October 08, 2007 7:07 PM To: Romascanu, Dan (Dan) Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] FW: [tsv-area] BOF request under consideration: SAFE On Mon, 8 Oct 2007, Romascanu, Dan (Dan) wrote: > ICE and its companion protocol STUN have been successfully deployed on > the Internet for NAT traversal. ICE and STUN have several > characteristics which contribute to their success: > > 1. incremental deployment. ICE and STUN are functional without any > modifications to existing NATs. > 2. nested NATs. ICE and STUN work when there are multiple NATs > between a host and the Internet. > 3. topology unaware. ICE and STUN are not configured with > information about NATs, firewalls, or their locations -- only > with the IP address of a server on the Internet. > 4. simple security model. If a host behind a NAT is allowed to send > a packet across the NAT, it is allowed to receive a response. > 5. works on routed networks, which allows operation in both > enterprise networks and home networks. Teredo also fulfills these characteristics (and has none of the drawbacks listed later). I'm confident that the BOF proposers will be able to invent new drawbacks to exclude Teredo from consideration, though. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Thu Oct 11 09:34:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfyBL-0000Yv-Rv; Thu, 11 Oct 2007 09:34:31 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IfyBK-0000Xf-92 for safe-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 09:34:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfyBJ-0000XX-UU for safe@ietf.org; Thu, 11 Oct 2007 09:34:29 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfyBJ-0004Q9-DP for safe@ietf.org; Thu, 11 Oct 2007 09:34:29 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9BDY5dE026100 for ; Thu, 11 Oct 2007 16:34:27 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 16:33:59 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 16:27:35 +0300 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 Subject: RE: [SAFE] nat-control-stun-usage-04 Date: Thu, 11 Oct 2007 16:27:35 +0300 Message-ID: In-Reply-To: <200710111357.44688.remi.denis-courmont@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SAFE] nat-control-stun-usage-04 Thread-Index: AcgL+D6/hnCGW2h8Ro+j0um9i3jInAADZQ7g References: <042001c80b74$509c46b0$c3f0200a@cisco.com> <200710111357.44688.remi.denis-courmont@nokia.com> From: To: , X-OriginalArrivalTime: 11 Oct 2007 13:27:35.0104 (UTC) FILETIME=[7C155C00:01C80C0A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: 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, R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com] wrote: >> >> The changes were mostly organizational and editorial, and included: >> >> o Clarified that all existing bindings, for that source=20 >IP address >> and UDP port, are controlled with STUN Control. >> >> o Introduction now concentrates on the primary purpose of STUN >> Control, namely reducing keepalive traffic for SIP-Outbound. > >As far as I understand, STUN in general, and STUN in=20 >particular, can be used for any UDP-based always-on protocol.=20 >ESP-in-UDP, TEREDO, perhaps some long usages of RTP (such as=20 >MIDI-over-RTP(?) or RTSP-based streaming), proprietary UDP=20 >overlays (not giving any names)... > >And then, there is the relation to ICE in finding=20 >"intermediary" NAT mappings in nested NATs scenarios. > >At the same time, I thought SIP Outbound was going to=20 >recommend TCP, so that it could end up being a less likely=20 >"customer" of STUN control?? > I agree with R=E9mi. For protocols like SIP it would be much better to = switch to TCP than to build NAT control solutions for UDP. (For instance = XMPP uses only TCP and it is proven to scale well.) But there are = protocols like those listed above where UDP probably is the only option, = and for them controlling UDP NAT bindings makes sense. Markus=20 _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Thu Oct 11 10:38:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfzAo-0002u6-Qj; Thu, 11 Oct 2007 10:38:02 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IfzAn-0002tp-Vi for safe-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 10:38:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfzAn-0002s4-LA for safe@ietf.org; Thu, 11 Oct 2007 10:38:01 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfzAi-0008Kr-82 for safe@ietf.org; Thu, 11 Oct 2007 10:37:56 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IfzAh-0007gZ-1a; Thu, 11 Oct 2007 10:37:55 -0400 In-Reply-To: <200710111357.44688.remi.denis-courmont@nokia.com> References: <042001c80b74$509c46b0$c3f0200a@cisco.com> <200710111357.44688.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <68B6A2E2-CBCE-4ADB-9047-149F5926E21D@magma.ca> Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [SAFE] nat-control-stun-usage-04 Date: Thu, 11 Oct 2007 10:38:19 -0400 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= 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: 8b431ad66d60be2d47c7bfeb879db82c 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 On 11-Oct-07, at 06:57 , R=E9mi Denis-Courmont wrote: > Le Wednesday 10 October 2007 22:32:37 ext Dan Wing, vous avez =E9crit = : >> We just submitted a new version of STUN Control, >> http://www.ietf.org/internet-drafts/draft-wing-behave-nat-control-=20 >> stun-usag >> e-0 4.txt >> >> The changes were mostly organizational and editorial, and included: >> >> o Clarified that all existing bindings, for that source IP =20 >> address >> and UDP port, are controlled with STUN Control. >> >> o Introduction now concentrates on the primary purpose of STUN >> Control, namely reducing keepalive traffic for SIP-Outbound. > > As far as I understand, STUN in general, and STUN in particular, =20 > can be used > for any UDP-based always-on protocol. ESP-in-UDP, TEREDO, perhaps =20 > some long > usages of RTP (such as MIDI-over-RTP(?) or RTSP-based streaming), =20 > proprietary > UDP overlays (not giving any names)... > > And then, there is the relation to ICE in finding "intermediary" =20 > NAT mappings > in nested NATs scenarios. This remains a big interest of mine, though increasing the lifetime =20 of UDP mapping and filtering entries is also a big win. I am not sure =20= why the focus is SIP-Outbound as opposed to other UDP uses. > > At the same time, I thought SIP Outbound was going to recommend =20 > TCP, so that > it could end up being a less likely "customer" of STUN control?? > > --=20 > R=E9mi Denis-Courmont > > > _______________________________________________ > 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 Oct 11 12:45: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 1Ig19v-0003tU-9y; Thu, 11 Oct 2007 12:45:15 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1Ig19t-0003tC-Ue for safe-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 12:45:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig19t-0003sd-6b; Thu, 11 Oct 2007 12:45:13 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig19r-0002H7-Vr; Thu, 11 Oct 2007 12:45:13 -0400 X-IronPort-AV: E=Sophos;i="4.21,260,1188802800"; d="scan'208";a="22753639" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 11 Oct 2007 09:45:11 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9BGjBTn025706; Thu, 11 Oct 2007 09:45:11 -0700 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9BGjAZo012650; Thu, 11 Oct 2007 16:45:10 GMT From: "Dan Wing" To: References: <470E262B.1080505@ericsson.com> Subject: RE: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF request underconsideration: SAFE Date: Thu, 11 Oct 2007 09:45:10 -0700 Message-ID: <024901c80c26$16fd9ff0$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <470E262B.1080505@ericsson.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgMC1y7oKPEPD1MQzOxYj1HsGSnpQAGinFQ DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2719; t=1192121111; x=1192985111; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[SAFE]=20FW=3A=20[OPS-AREA]=20FW=3A=20[tsv-area]=20BO F=20request=20underconsideration=3A=20SAFE |Sender:=20; bh=fN91Xlu01F9jgzX1uvyvnPE1QyTibggKJUQFFSN3+ak=; b=j9bNTWfeDOavy4uLzE49RUhidlOWZVH+zt4WPP9UfOt3bGaTp9gI3AuMaqyPdlEYRuO2wRHb 1Y1LLCc/uXzDOFqD7DlVHx4rTrvgHYEgKrUHxxxJtuG2auH1uYb2Zvs5; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: safe@ietf.org, ops-area@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 Pekka, The SAFE BoF isn't about comparing Teredo to STUN/ICE. Rather, it is about querying and controlling binding lifetimes of NATs in order to reduce the frequency of keepalive messages across those NATs. This would benefit any UDP-based protocol that traverses NATs and, today, needs to send keepalives every 20-30 seconds; such a protocol could reduce its keepalive traffic substantially. Teredo and IPsec-over-UDP would benefit from such a reduction in keepalive traffic. -d > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Thursday, October 11, 2007 6:34 AM > To: safe@ietf.org > Subject: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF request > underconsideration: SAFE > > Hi, > > This was sent to the V6OPS list by Pekka Savola. I forward it to the > SAFE list with his permission for commenting. > > Magnus Westerlund > > > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, October 08, 2007 7:07 PM > To: Romascanu, Dan (Dan) > Cc: ops-area@ietf.org > Subject: Re: [OPS-AREA] FW: [tsv-area] BOF request under > consideration: > SAFE > > On Mon, 8 Oct 2007, Romascanu, Dan (Dan) wrote: > > ICE and its companion protocol STUN have been successfully > deployed on > > > the Internet for NAT traversal. ICE and STUN have several > > characteristics which contribute to their success: > > > > 1. incremental deployment. ICE and STUN are functional without any > > modifications to existing NATs. > > 2. nested NATs. ICE and STUN work when there are multiple NATs > > between a host and the Internet. > > 3. topology unaware. ICE and STUN are not configured with > > information about NATs, firewalls, or their locations -- only > > with the IP address of a server on the Internet. > > 4. simple security model. If a host behind a NAT is > allowed to send > > a packet across the NAT, it is allowed to receive a response. > > 5. works on routed networks, which allows operation in both > > enterprise networks and home networks. > > Teredo also fulfills these characteristics (and has none of the > drawbacks listed later). > > I'm confident that the BOF proposers will be able to invent new > drawbacks to exclude Teredo from consideration, though. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > 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 Oct 11 12:48:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig1Cu-0006G7-Ad; Thu, 11 Oct 2007 12:48:20 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1Ig1Cs-0006C3-DK for safe-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 12:48:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig1Cs-0006B3-2e for safe@ietf.org; Thu, 11 Oct 2007 12:48:18 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig1Cq-0002Q6-SR for safe@ietf.org; Thu, 11 Oct 2007 12:48:18 -0400 X-IronPort-AV: E=Sophos;i="4.21,260,1188802800"; d="scan'208";a="22754715" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 11 Oct 2007 09:48:16 -0700 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 l9BGmGuQ001262; Thu, 11 Oct 2007 09:48:16 -0700 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9BGmFZp021397; Thu, 11 Oct 2007 16:48:15 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" , References: <042001c80b74$509c46b0$c3f0200a@cisco.com> <200710111357.44688.remi.denis-courmont@nokia.com> Subject: RE: [SAFE] nat-control-stun-usage-04 Date: Thu, 11 Oct 2007 09:48:15 -0700 Message-ID: <024a01c80c26$85317280$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200710111357.44688.remi.denis-courmont@nokia.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgL9YsutvTZGQ/6R66ac1MMABSL+QAMJq6Q DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=954; t=1192121296; x=1192985296; 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:=20RE=3A=20[SAFE]=20nat-control-stun-usage-04 |Sender:=20; bh=tZwA7fuq61RkRjXlURb7A3P0WSRixcksXha9zc0pUcQ=; b=gYhknN+1o+TMKweCODmEuf32D65gp8VcJKRnu/sC3chAEkaoPNMGxHoPQ9TBMw4ha/PLAZOt RX5uHOy/U1JGwm3ZTrWEa2Hz1q8XsqQhJTiSwDOFtN+8R+Qh4YXjggkf; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 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 > > o Introduction now concentrates on the primary purpose of STUN > > Control, namely reducing keepalive traffic for SIP-Outbound. > > As far as I understand, STUN in general, and STUN in > particular, can be used for any UDP-based always-on protocol. > ESP-in-UDP, TEREDO, perhaps some long usages of RTP (such as > MIDI-over-RTP(?) or RTSP-based streaming), proprietary > UDP overlays (not giving any names)... You're right. I will expand the draft to describe how STUN Control could reduce keepalive traffic for those protocols. > And then, there is the relation to ICE in finding > "intermediary" NAT mappings > in nested NATs scenarios. > > At the same time, I thought SIP Outbound was going to > recommend TCP, so that > it could end up being a less likely "customer" of STUN control?? Unfortunately, most SIP signaling remains UDP no matter the statements or warnings in IETF specifications. -d _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Fri Oct 12 04:59:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgGN5-0008Go-GX; Fri, 12 Oct 2007 04:59:51 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IgGN5-0008E1-5T for safe-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 04:59:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgGN0-00088E-33 for safe@ietf.org; Fri, 12 Oct 2007 04:59:46 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgGMt-0002ud-MM for safe@ietf.org; Fri, 12 Oct 2007 04:59:46 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9C8x6i4015014 for ; Fri, 12 Oct 2007 11:59:32 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 11:59:10 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 11:59:10 +0300 Received: from esdhcp04194.research.nokia.com ([172.21.41.94]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 11:59:09 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: safe@ietf.org Subject: Re: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF request underconsideration: SAFE Date: Fri, 12 Oct 2007 11:59:41 +0300 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <470E262B.1080505@ericsson.com> <024901c80c26$16fd9ff0$c3f0200a@cisco.com> In-Reply-To: <024901c80c26$16fd9ff0$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710121159.41676.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 12 Oct 2007 08:59:09.0998 (UTC) FILETIME=[271AF4E0:01C80CAE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Thursday 11 October 2007 19:45:10 ext Dan Wing, vous avez =E9crit=A0: > The SAFE BoF isn't about comparing Teredo to STUN/ICE. > > Rather, it is about querying and controlling binding lifetimes of > NATs in order to reduce the frequency of keepalive messages across > those NATs. This would benefit any UDP-based protocol that > traverses NATs and, today, needs to send keepalives every 20-30 > seconds; such a protocol could reduce its keepalive traffic > substantially. Teredo and IPsec-over-UDP would benefit from > such a reduction in keepalive traffic. The Outside-In method would work, though the client would run a Teredo=20 qualification procedure rather than a STUN Binding transaction with its=20 server. When concluded, the the client can send a STUN Binding Request to i= ts=20 NAT. The tagging approach fails terribly since Teredo qualification packet forma= t=20 is incompatible with STUN. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Fri Oct 12 08:06:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgJHb-0007gZ-Bz; Fri, 12 Oct 2007 08:06:23 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IgJHZ-0007gT-QK for safe-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 08:06:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgJHZ-0007db-FC for safe@ietf.org; Fri, 12 Oct 2007 08:06:21 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgJHT-0001py-A6 for safe@ietf.org; Fri, 12 Oct 2007 08:06:16 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IgJHR-0001d1-36; Fri, 12 Oct 2007 08:06:14 -0400 In-Reply-To: References: <470A480C.4040506@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2E64FBC4-2ACD-4707-A17F-72A964105BB6@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [SAFE] RE: [BEHAVE] BOF request under consideration: SAFE Date: Fri, 12 Oct 2007 08:06:12 -0400 To: 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: 995b2e24d23b953c94bac5288c432399 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 I would like to second Markus comments: I also support the goals of the BOF, but I share his two technical concerns. The second concern was raised at the "informal BOF" in Chicago, but the first concern I have not hear discussed before. Regarding the first concern, I think this might actually go beyond just STUN Control to be a general STUN/ICE issue. Even without STUN Control, it seems important for an endpoint to know if its keep-alive rate is sufficient to keep the bindings in intermediate NATs alive. The way I see this might be done is for the STUN server (or perhaps the remote endpoint) to send data at regular intervals while the client sends keep-alives at some rate. If the client continues to receive data after one or two keep-alive intervals have passed, the client knows its keep-alive rate is sufficient. A client may choose to test a lower keep-alive rate in this manner to see if that is also sufficient. - Philip On 11-Oct-07, at 08:53 , wrote: > Hi, > > I support the goals of this BOF and I believe in the reasoning > provided > by the charter. I have two concerns that should be addressed before I > think STUN NAT control could become successfully deployed: > > 1. Technical issue: STUN control allows a host/application to discover > NATs and disover/set NAT binding timers for UDP (typically to higher > values than what the defaults, perhaps around 30-300 s, would be). > However, BEFORE the application can start using the increased > keepalive > period, it needs to have a some sort of assurance that there aren't > OTHER middleboxes on its path with lower keepalive values. > Otherwise it > would be impossible to rely on the increased timer values, and thus > the > whole mechanism might fail in practice. So, I would like to include in > the charter a goal where such discovery mechanisms and their > applicability are considered. The actual mechanism might be based on > STUN or something else. I know this is a hard problem in general, > but in > many access network topologies the problem can be solved by > configuration + discovery. I'd be happy to contribute in this area. > Actually I believe this discovery part to be the real issue with this > whole work, rather than the details of STUN itself. > > 2. Deployment issue: We do have several protocols in this area, for > instance NSIS. Their deployment does not look to be happening. For > STUN > control to be useful, we would need real interest from some real > NAT/FW > vendors. It's of course difficult to say how to verify this in a BOF > beyond matching people's e-mail addresses to NAT/FW product brands :-) > Personally I can speak for a single client/host/device vendor only. > > Markus > > >> -----Original Message----- >> From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: 08 October, 2007 18:09 >> To: TSV Area; Behave WG; mmusic (E-mail) >> Subject: [BEHAVE] BOF request under consideration: SAFE >> >> Hi, >> >> We ADs have received a request for a BOF in Vancouver: SAFE - >> Self-Address Fixing Evolution. See description below. I would >> appreciate any feedback on this. For public discussion please >> use the SAFE mailing list. >> >> Post: safe@ietf.org >> Subscribe: https://www1.ietf.org/mailman/listinfo/safe >> >> Draft: >> http://www.ietf.org/internet-drafts/draft-wing-behave-nat-contr > ol-stun-usage-03.txt >> >> >> SAFE - Self-Address Fixing Evolution >> ------------------------------------ >> >> Chairs: >> TBD >> >> >> ICE and its companion protocol STUN have been successfully >> deployed on the Internet for NAT traversal. ICE and STUN have >> several characteristics which contribute to their success: >> >> 1. incremental deployment. ICE and STUN are functional without any >> modifications to existing NATs. >> 2. nested NATs. ICE and STUN work when there are multiple NATs >> between a host and the Internet. >> 3. topology unaware. ICE and STUN are not configured with >> information about NATs, firewalls, or their locations -- only >> with the IP address of a server on the Internet. >> 4. simple security model. If a host behind a NAT is allowed to send >> a packet across the NAT, it is allowed to receive a response. >> 5. works on routed networks, which allows operation in both >> enterprise networks and home networks. >> >> Other NAT traversal protocols do not share these >> characteristics, which hinders their widespread deployment. >> Specifically, >> >> * incremental deployment is not possible with MIDCOM, NSIS-NSLP, >> UPnP, or Bonjour. With all of these protocols, both the NAT >> and the endpoint have to support the same protocol. >> * nested NATs are not possible with UPnP or Bonjour. >> * topology awareness is required of MIDCOM. >> * security must be established between the controlling entity >> and the NAT for MIDCOM and NSIS-NSLP. >> * Both UPnP and Bonjour use broadcast packets which don't work >> well on routed networks. >> >> However, a drawback of ICE/STUN is its chatty keepalive >> traffic, which is a result of STUN not knowing the binding >> lifetime of its on-path NATs. This chattiness causes a burden >> on servers and consumes network bandwidth, which is especially >> critical on wireless networks. It is desirable to reduce this >> chattiness while still retaining the important characteristics >> of STUN and ICE. >> >> This BoF is intended to discuss one proposed technique, >> draft-wing-behave-nat-control-stun-usage, which nearly >> eliminates STUN's keepalive chatter and still preserves the >> desirable characteristics of STUN/ICE. >> >> The purpose of this BoF is to create a working group for this effort. >> >> >> Agenda: >> Introduction, Agenda .................................... 5 >> Summary of existing NAT traversal techniques ............ 40 >> (UPnP, NAT-PMP/Bonjour, MIDCOM techniques, NSIS-NSLP, ICE) >> draft-wing-behave-nat-control-stun-usage ................ 40 >> Q&A ..................................................... 25 >> ---------- >> total: 110 >> >> Cheers >> >> Magnus Westerlund >> >> IETF Transport Area Director & TSVWG Chair >> --------------------------------------------------------------------- >> - >> Multimedia Technologies, Ericsson Research EAB/TVM/M >> --------------------------------------------------------------------- >> - >> Ericsson AB | Phone +46 8 4048287 >> Torshamsgatan 23 | Fax +46 8 7575550 >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> --------------------------------------------------------------------- >> - >> >> >> _______________________________________________ >> 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 > _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Fri Oct 12 08:19:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgJU9-0006vA-VA; Fri, 12 Oct 2007 08:19:21 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IgJU9-0006v5-Am for safe-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 08:19:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgJU9-0006ux-02 for safe@ietf.org; Fri, 12 Oct 2007 08:19:21 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgJU7-0002Cx-Rb for safe@ietf.org; Fri, 12 Oct 2007 08:19:20 -0400 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 l9CCJGCR018743; Fri, 12 Oct 2007 15:19:16 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 15:19:02 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 15:19:02 +0300 Received: from esdhcp04194.research.nokia.com ([172.21.41.94]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 15:19:00 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: safe@ietf.org, "ext Philip Matthews" Subject: Re: [SAFE] RE: [BEHAVE] BOF request under consideration: SAFE Date: Fri, 12 Oct 2007 15:19:33 +0300 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <470A480C.4040506@ericsson.com> <2E64FBC4-2ACD-4707-A17F-72A964105BB6@magma.ca> In-Reply-To: <2E64FBC4-2ACD-4707-A17F-72A964105BB6@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710121519.33190.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 12 Oct 2007 12:19:00.0366 (UTC) FILETIME=[11EBEAE0:01C80CCA] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 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 Friday 12 October 2007 15:06:12 ext Philip Matthews, vous avez =E9crit= =A0: > I would like to second Markus comments: I also support the goals of > the BOF, but I share his two technical concerns. The second concern > was raised at the "informal BOF" in Chicago, but the first concern I > have not hear discussed before. > > Regarding the first concern, I think this might actually go beyond > just STUN Control to be a general STUN/ICE issue. Even without STUN > Control, it seems important for an endpoint to know if its keep-alive > rate is sufficient to keep the bindings in intermediate NATs alive. > The way I see this might be done is for the STUN server (or perhaps > the remote endpoint) to send data at regular intervals while the > client sends keep-alives at some rate. If the client continues to > receive data after one or two keep-alive intervals have passed, the > client knows its keep-alive rate is sufficient. A client may choose > to test a lower keep-alive rate in this manner to see if that is also > sufficient. =46rom RFC4380, see =A75.2.7 "Optional Refresh Interval Determination Proce= dure",=20 which is exactly that. I had the feeling that "old" STUN also had such a=20 thing as part of the behavior analysis stuff, but that this was considered= =20 bad, though. Maybe I got it wrong... ? In any case, how often one sends keep-alives is a matter of engineering=20 tradeoff between increased battery consumption and increased failure rate. = I=20 guess if the battery footprint is really bad, the industry will try to use= =20 longer refresh intervals whatever IETF recommends. Nevertheless, I agree with Markus and you that there may be value in=20 investigating STUN NAT control (and perhaps ALD and as well?), e.g. to=20 negociate longer refresh intervals whenever possible. Hence, I support this= =20 BoF proposal. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Fri Oct 12 13:15: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 1IgO77-0003At-Cj; Fri, 12 Oct 2007 13:15:53 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IgO75-0003Aj-C4 for safe-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 13:15:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgO74-0003Ab-Ln for safe@ietf.org; Fri, 12 Oct 2007 13:15:50 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgO74-0000j1-8G for safe@ietf.org; Fri, 12 Oct 2007 13:15:50 -0400 X-IronPort-AV: E=Sophos;i="4.21,267,1188802800"; d="scan'208";a="405983285" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 12 Oct 2007 10:15:50 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9CHFnQL008941; Fri, 12 Oct 2007 10:15:49 -0700 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9CHFnZo010999; Fri, 12 Oct 2007 17:15:49 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" , References: <470E262B.1080505@ericsson.com><024901c80c26$16fd9ff0$c3f0200a@cisco.com> <200710121159.41676.remi.denis-courmont@nokia.com> Subject: RE: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF requestunderconsideration: SAFE Date: Fri, 12 Oct 2007 10:15:48 -0700 Message-ID: <0dfa01c80cf3$89063210$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200710121159.41676.remi.denis-courmont@nokia.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgMrk1AesovFx4vQfqVYUjsXzLxnQARMnKA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1893; t=1192209349; x=1193073349; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[SAFE]=20FW=3A=20[OPS-AREA]=20FW=3A=20[tsv-area]=20BO F=20requestunderconsideration=3A=20SAFE |Sender:=20; bh=2Sz0IQfrQyA5dpTE9tAj9pOoeb8HvlgGV55NPqqWwj8=; b=RFj3VYG8S68kWbrclbgZHX3n9GdR38YDPCBl/m5GoGwVyQjfMJzW3ARapgo0mpFgQhGM6XSL HGTFccAhrf6EEbX0LAGZ6RAs7bCqU37bHt2uy2ZLj8CFMdG2J7R03/t+; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 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 R=E9mi Denis-Courmont wrote: > Le Thursday 11 October 2007 19:45:10 ext Dan Wing, vous avez = =E9crit=A0: > > The SAFE BoF isn't about comparing Teredo to STUN/ICE. > > > > Rather, it is about querying and controlling binding lifetimes of > > NATs in order to reduce the frequency of keepalive messages across > > those NATs. This would benefit any UDP-based protocol that > > traverses NATs and, today, needs to send keepalives every 20-30 > > seconds; such a protocol could reduce its keepalive traffic > > substantially. Teredo and IPsec-over-UDP would benefit from > > such a reduction in keepalive traffic. >=20 > The Outside-In method would work, though the client would run=20 > a Teredo qualification procedure rather than a STUN Binding=20 > transaction with its server. When concluded, the the client can=20 > send a STUN Binding Request to its NAT. Agreed. Here is what I am planning to add to -05: Endpoints that implement Teredo [RFC4380] learn their outer-most NATs address as their Teredo Mapped Address. Once learned, the Teredo client can utilize STUN Control to query and control that NAT's UDP keepalive timeout, and thus reduce the Teredo refresh interval. Controlling the NAT's refresh interval explicitly is less brittle than Teredo's "interval determination procedure". Nested NATs can be similarly discovered, queried, and controlled. > The tagging approach fails terribly since Teredo=20 > qualification packet format is incompatible with STUN. Agreed. But, thinking aloud: after Teredo qualification the Teredo client=20 could send a STUN packet to a STUN server (running on the same host=20 it ran its Teredo qualification against), and get that STUN packet=20 tagged. So long as the UDP packets to those different UDP ports=20 were routed the same, the same firewalls would be traversed. -d _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Fri Oct 12 13:20:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOBg-0004T4-8x; Fri, 12 Oct 2007 13:20:36 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IgOBe-0004Sy-V5 for safe-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 13:20:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOBe-0004Sq-LF for safe@ietf.org; Fri, 12 Oct 2007 13:20:34 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgOBa-00062I-7j for safe@ietf.org; Fri, 12 Oct 2007 13:20:34 -0400 X-IronPort-AV: E=Sophos;i="4.21,267,1188802800"; d="scan'208";a="22997440" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 12 Oct 2007 10:20:29 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9CHKTYB026570; Fri, 12 Oct 2007 10:20:29 -0700 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9CHKSZp012809; Fri, 12 Oct 2007 17:20:28 GMT From: "Dan Wing" To: "'Philip Matthews'" References: <470A480C.4040506@ericsson.com> <2E64FBC4-2ACD-4707-A17F-72A964105BB6@magma.ca> Subject: RE: [SAFE] RE: [BEHAVE] BOF request under consideration: SAFE Date: Fri, 12 Oct 2007 10:20:28 -0700 Message-ID: <0dfb01c80cf4$2fc96360$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2E64FBC4-2ACD-4707-A17F-72A964105BB6@magma.ca> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgMyHJC1OqzDhamS8yLliNBGrYIQAAKzNIw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8218; t=1192209629; x=1193073629; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[SAFE]=20RE=3A=20[BEHAVE]=20BOF=20request=20under=20c onsideration=3A=20SAFE |Sender:=20; bh=ReNrvZsRXvMqu4sG9ZkUO49FUA5LI08vlRLtShgn1ow=; b=ZJtnSNnzv1WZf4JNM6VP8Lw1pbDWlPmefyPWCsCnbasWU5E3WIR+S/bwOO7GqGxIuES0JLlr fh3DAvSIV+nAs5FEL/fBlfYlUkPBqqJh24X+kxuppH9mkYgxKvy1Z21Lb+8oyez9yPv1IIz4nZ Fjo+flUdeaCEAiLSQV50cLRrI=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: safe@ietf.org, Markus.Isomaki@nokia.com 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 > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Friday, October 12, 2007 5:06 AM > To: > Cc: safe@ietf.org > Subject: Re: [SAFE] RE: [BEHAVE] BOF request under consideration: SAFE > > I would like to second Markus comments: I also support the goals of > the BOF, but I share his two technical concerns. The second concern > was raised at the "informal BOF" in Chicago, but the first concern I > have not hear discussed before. > > Regarding the first concern, I think this might actually go beyond > just STUN Control to be a general STUN/ICE issue. Even without STUN > Control, it seems important for an endpoint to know if its > keep-alive rate is sufficient to keep the bindings in intermediate > NATs alive. The way I see this might be done is for the STUN server > (or perhaps the remote endpoint) to send data at regular intervals > while the client sends keep-alives at some rate. If the client > continues to receive data after one or two keep-alive intervals have > passed, the client knows its keep-alive rate is sufficient. A client > may choose to test a lower keep-alive rate in this manner to see > if that is also sufficient. Teredo (Section 5.2.7 of RFC4380, http://tools.ietf.org/html/rfc4380#section-5.2.7) has a documented procedure for doing what you describe. -d > - Philip > > On 11-Oct-07, at 08:53 , > wrote: > > > Hi, > > > > I support the goals of this BOF and I believe in the reasoning > > provided > > by the charter. I have two concerns that should be > addressed before I > > think STUN NAT control could become successfully deployed: > > > > 1. Technical issue: STUN control allows a host/application > to discover > > NATs and disover/set NAT binding timers for UDP (typically to higher > > values than what the defaults, perhaps around 30-300 s, would be). > > However, BEFORE the application can start using the increased > > keepalive > > period, it needs to have a some sort of assurance that there aren't > > OTHER middleboxes on its path with lower keepalive values. > > Otherwise it > > would be impossible to rely on the increased timer values, > and thus > > the > > whole mechanism might fail in practice. So, I would like to > include in > > the charter a goal where such discovery mechanisms and their > > applicability are considered. The actual mechanism might be based on > > STUN or something else. I know this is a hard problem in general, > > but in > > many access network topologies the problem can be solved by > > configuration + discovery. I'd be happy to contribute in this area. > > Actually I believe this discovery part to be the real issue > with this > > whole work, rather than the details of STUN itself. > > > > 2. Deployment issue: We do have several protocols in this area, for > > instance NSIS. Their deployment does not look to be happening. For > > STUN > > control to be useful, we would need real interest from some real > > NAT/FW > > vendors. It's of course difficult to say how to verify this in a BOF > > beyond matching people's e-mail addresses to NAT/FW product > brands :-) > > Personally I can speak for a single client/host/device vendor only. > > > > Markus > > > > > >> -----Original Message----- > >> From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >> Sent: 08 October, 2007 18:09 > >> To: TSV Area; Behave WG; mmusic (E-mail) > >> Subject: [BEHAVE] BOF request under consideration: SAFE > >> > >> Hi, > >> > >> We ADs have received a request for a BOF in Vancouver: SAFE - > >> Self-Address Fixing Evolution. See description below. I would > >> appreciate any feedback on this. For public discussion please > >> use the SAFE mailing list. > >> > >> Post: safe@ietf.org > >> Subscribe: https://www1.ietf.org/mailman/listinfo/safe > >> > >> Draft: > >> http://www.ietf.org/internet-drafts/draft-wing-behave-nat-contr > > ol-stun-usage-03.txt > >> > >> > >> SAFE - Self-Address Fixing Evolution > >> ------------------------------------ > >> > >> Chairs: > >> TBD > >> > >> > >> ICE and its companion protocol STUN have been successfully > >> deployed on the Internet for NAT traversal. ICE and STUN have > >> several characteristics which contribute to their success: > >> > >> 1. incremental deployment. ICE and STUN are functional > without any > >> modifications to existing NATs. > >> 2. nested NATs. ICE and STUN work when there are multiple NATs > >> between a host and the Internet. > >> 3. topology unaware. ICE and STUN are not configured with > >> information about NATs, firewalls, or their locations -- only > >> with the IP address of a server on the Internet. > >> 4. simple security model. If a host behind a NAT is > allowed to send > >> a packet across the NAT, it is allowed to receive a response. > >> 5. works on routed networks, which allows operation in both > >> enterprise networks and home networks. > >> > >> Other NAT traversal protocols do not share these > >> characteristics, which hinders their widespread deployment. > >> Specifically, > >> > >> * incremental deployment is not possible with MIDCOM, NSIS-NSLP, > >> UPnP, or Bonjour. With all of these protocols, both the NAT > >> and the endpoint have to support the same protocol. > >> * nested NATs are not possible with UPnP or Bonjour. > >> * topology awareness is required of MIDCOM. > >> * security must be established between the controlling entity > >> and the NAT for MIDCOM and NSIS-NSLP. > >> * Both UPnP and Bonjour use broadcast packets which don't work > >> well on routed networks. > >> > >> However, a drawback of ICE/STUN is its chatty keepalive > >> traffic, which is a result of STUN not knowing the binding > >> lifetime of its on-path NATs. This chattiness causes a burden > >> on servers and consumes network bandwidth, which is especially > >> critical on wireless networks. It is desirable to reduce this > >> chattiness while still retaining the important characteristics > >> of STUN and ICE. > >> > >> This BoF is intended to discuss one proposed technique, > >> draft-wing-behave-nat-control-stun-usage, which nearly > >> eliminates STUN's keepalive chatter and still preserves the > >> desirable characteristics of STUN/ICE. > >> > >> The purpose of this BoF is to create a working group for > this effort. > >> > >> > >> Agenda: > >> Introduction, Agenda .................................... 5 > >> Summary of existing NAT traversal techniques ............ 40 > >> (UPnP, NAT-PMP/Bonjour, MIDCOM techniques, NSIS-NSLP, ICE) > >> draft-wing-behave-nat-control-stun-usage ................ 40 > >> Q&A ..................................................... 25 > >> ---------- > >> total: 110 > >> > >> Cheers > >> > >> Magnus Westerlund > >> > >> IETF Transport Area Director & TSVWG Chair > >> > --------------------------------------------------------------------- > >> - > >> Multimedia Technologies, Ericsson Research EAB/TVM/M > >> > --------------------------------------------------------------------- > >> - > >> Ericsson AB | Phone +46 8 4048287 > >> Torshamsgatan 23 | Fax +46 8 7575550 > >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >> > --------------------------------------------------------------------- > >> - > >> > >> > >> _______________________________________________ > >> 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 > > > > > > _______________________________________________ > 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 Oct 12 14:08:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOwE-0001FS-Ti; Fri, 12 Oct 2007 14:08:42 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IgOwD-0001AL-Pm for safe-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 14:08:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOwD-000151-5I for safe@ietf.org; Fri, 12 Oct 2007 14:08:41 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgOwB-0007LX-B2 for safe@ietf.org; Fri, 12 Oct 2007 14:08:41 -0400 X-IronPort-AV: E=Sophos;i="4.21,267,1188802800"; d="scan'208";a="23014943" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 12 Oct 2007 11:08:38 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9CI8cpw016501; Fri, 12 Oct 2007 11:08:38 -0700 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9CI8cZp001367; Fri, 12 Oct 2007 18:08:38 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" References: <042001c80b74$509c46b0$c3f0200a@cisco.com> <200710111357.44688.remi.denis-courmont@nokia.com> Date: Fri, 12 Oct 2007 11:08:37 -0700 Message-ID: <0e6401c80cfa$e9fd0650$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200710111357.44688.remi.denis-courmont@nokia.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgL9YsutvTZGQ/6R66ac1MMABSL+QBAt16g DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1914; t=1192212518; x=1193076518; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20IKE/IPsec=20with=20STUN=20Control |Sender:=20; bh=ljHI1c4TqaW1EnJXTySt8j8eIFcE5w1UG/yUqUH/Pg8=; b=ko6CRpDp6iibbAvL759pL5dNEL7uhSZ4FRp7sFqv2ie1Ib5oJhR5JNB6Urh2slICIgt2yYi3 1zsZKcF6uZhwmWxMriDcGntSWJkleQQXnN+OAAh3ybpRdi14CaWjgHFc4MvixMuRoff/QH02It 9VB15wLm+EBpN7AfNtxR58zoI=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: safe@ietf.org Subject: [SAFE] IKE/IPsec with STUN Control 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 > As far as I understand, STUN in general, and STUN in=20 > particular, can be used for any UDP-based always-on protocol.=20 > ESP-in-UDP, TEREDO, perhaps some long usages of RTP (such=20 > as MIDI-over-RTP(?) or RTSP-based streaming), proprietary=20 > UDP overlays (not giving any names)... I looked at how IKE learns of an on-path NAT, and unfortunately the IP addresses are hashed in the IKE exchange. This prevents the IKE endpoint from learning the IP address seen by its IKE peer, and thus prevents the IKE endpoint from learning its own public IP address. To use STUN Control, you need to learn that public IP address. I see two approaches: * It is possible to multiplex STUN, IKE, and IPsec ESP on the same UDP port. IKE-over-UDP starts with 4 bytes of zeros, IPsec ESP starts with the 32-bit SPI, and STUN has known bits in its header (first 16 bits indicate a STUN Request, Response, or Indication, and has a fixed magic cookie in bits 32-64) and the STUN SHA-1 fingerprint attribute. While not ideal, it would be possible for the IKE peers to demultiplex STUN on that same UDP port so that they could learn the IP address as seen by the other peer and use STUN Control to adjust their timings. =20 * Alternatively, the IKE peer (VPN concentrator) could run a normal STUN server on the STUN port (UDP/3478) if we make the (reasonable) assumption that the same NATs would be be traversed for traffic to UDP/500, UDP/4500, and UDP/3478. This wouldn't require changes to VPN concentrator code. I would lean towards the second approach. -d > And then, there is the relation to ICE in finding=20 > "intermediary" NAT mappings in nested NATs scenarios. >=20 > At the same time, I thought SIP Outbound was going to=20 > recommend TCP, so that=20 > it could end up being a less likely "customer" of STUN control?? >=20 > --=20 > R=E9mi Denis-Courmont >=20 _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Mon Oct 15 09:38:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQ9P-00044I-BK; Mon, 15 Oct 2007 09:38:31 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IhQ9O-00040B-3h for safe-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 09:38:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQ9D-0003hn-Oo for safe@ietf.org; Mon, 15 Oct 2007 09:38:19 -0400 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 1IhQ97-0000ZX-C7 for safe@ietf.org; Mon, 15 Oct 2007 09:38:19 -0400 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 l9FDbomM016755; Mon, 15 Oct 2007 16:38:04 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 16:37:51 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 16:37:52 +0300 Received: from esdhcp04051.research.nokia.com ([172.21.40.51]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 16:37:51 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Dan Wing" Subject: Re: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF requestunderconsideration: SAFE Date: Mon, 15 Oct 2007 16:38:28 +0300 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <470E262B.1080505@ericsson.com> <200710121159.41676.remi.denis-courmont@nokia.com> <0dfa01c80cf3$89063210$c3f0200a@cisco.com> In-Reply-To: <0dfa01c80cf3$89063210$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710151638.28827.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 15 Oct 2007 13:37:51.0129 (UTC) FILETIME=[94EA5090:01C80F30] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Le Friday 12 October 2007 20:15:48 ext Dan Wing, vous avez =E9crit=A0: > But, thinking aloud: after Teredo qualification the Teredo client > could send a STUN packet to a STUN server (running on the same host > it ran its Teredo qualification against), and get that STUN packet > tagged. So long as the UDP packets to those different UDP ports > were routed the same, the same firewalls would be traversed. Yes, but that adds a dependency on an otherwise not needed server only for = the=20 sake of STUN control. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Mon Oct 15 11:31:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRuQ-0001c1-Ox; Mon, 15 Oct 2007 11:31:10 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IhRuP-0001Y0-NT for safe-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 11:31:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRuO-0001UI-Pl for safe@ietf.org; Mon, 15 Oct 2007 11:31:08 -0400 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 1IhRuO-0001hl-Dg for safe@ietf.org; Mon, 15 Oct 2007 11:31:08 -0400 X-IronPort-AV: E=Sophos;i="4.21,278,1188802800"; d="scan'208";a="535466354" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 15 Oct 2007 08:30:46 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9FFUkEU006877; Mon, 15 Oct 2007 08:30:46 -0700 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9FFUksZ002569; Mon, 15 Oct 2007 15:30:46 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" References: <470E262B.1080505@ericsson.com> <200710121159.41676.remi.denis-courmont@nokia.com> <0dfa01c80cf3$89063210$c3f0200a@cisco.com> <200710151638.28827.remi.denis-courmont@nokia.com> Subject: RE: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF requestunderconsideration: SAFE Date: Mon, 15 Oct 2007 08:30:46 -0700 Message-ID: <14cd01c80f40$5bd35800$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200710151638.28827.remi.denis-courmont@nokia.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgPMKFaKpabNEj8Sh+Iji5WyrHY8gADss/g DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1065; t=1192462246; x=1193326246; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[SAFE]=20FW=3A=20[OPS-AREA]=20FW=3A=20[tsv-area]=20BO F=20requestunderconsideration=3A=20SAFE |Sender:=20; bh=UF1mIfFYRrI2TnckwCZ2Q2tX8DNC9FancK3ILD7if8A=; b=KyK2sl5tNvrJxp1lZaKDF3JsoqQeF8jukR7xvlcQbd7m9Rmhuus5le+95w64l/ykJxkEXgKc HGeBFDaiBHxzsLdQYIhYB1J+ank53GUlimJ3dKhFjgfhfgAkxdgoDlHD; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 > Le Friday 12 October 2007 20:15:48 ext Dan Wing, vous avez =E9crit=A0: > > But, thinking aloud: after Teredo qualification the Teredo client > > could send a STUN packet to a STUN server (running on the same host > > it ran its Teredo qualification against), and get that STUN packet > > tagged. So long as the UDP packets to those different UDP ports > > were routed the same, the same firewalls would be traversed. >=20 > Yes, but that adds a dependency on an otherwise not needed=20 > server only for the sake of STUN control. Right; but I don't know if that's harder than multiplexing the same=20 code on UDP/500 or UDP/4500, though. My worry about IKE is that the IP address hashing was done on purpose, and I don't know what that purpose was. Learning your public IP address (and UDP port) must have been considered sensitive information to some; of course=20 the various tell-me-my-address services on the Internet makes that=20 a moot argument. =20 I agree putting the STUN server on the same port as IKE would be=20 best. -d _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Mon Oct 15 12:20:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhSg0-0002LB-F8; Mon, 15 Oct 2007 12:20:20 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IhIm7-0001sP-71 for safe-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 01:45:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhIlu-0001bC-TV; Mon, 15 Oct 2007 01:45:46 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhIlu-0000me-0O; Mon, 15 Oct 2007 01:45:46 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l9F5jCs9017643; Mon, 15 Oct 2007 08:45:12 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l9F5jCrZ017640; Mon, 15 Oct 2007 08:45:12 +0300 Date: Mon, 15 Oct 2007 08:45:11 +0300 (EEST) From: Pekka Savola To: Dan Wing Subject: RE: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF request underconsideration: SAFE In-Reply-To: <024901c80c26$16fd9ff0$c3f0200a@cisco.com> Message-ID: References: <470E262B.1080505@ericsson.com> <024901c80c26$16fd9ff0$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4540/Sun Oct 14 04:43:55 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on otso.netcore.fi X-Spam-Score: -1.4 (-) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-Mailman-Approved-At: Mon, 15 Oct 2007 12:20:19 -0400 Cc: safe@ietf.org, ops-area@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 Dan, Please forward this to the SAFE list as appropriate. On Thu, 11 Oct 2007, Dan Wing wrote: > The SAFE BoF isn't about comparing Teredo to STUN/ICE. > > Rather, it is about querying and controlling binding lifetimes of > NATs in order to reduce the frequency of keepalive messages across > those NATs. This would benefit any UDP-based protocol that > traverses NATs and, today, needs to send keepalives every 20-30 > seconds; such a protocol could reduce its keepalive traffic > substantially. Teredo and IPsec-over-UDP would benefit from > such a reduction in keepalive traffic. The list of drawbacks of existing solutions (that I clipped off in the mail *) seemed to be written in a way that implied that the BOF proposal wanted to express the superiority of STUN/ICE compared to the other solutions. I think you'll need to include a complete list, reword to make the intent of the text clearer or remove the drawback list completely. FWIW, as it happens, Teredo already supports automatic adjustment to NAT timeouts. *) http://www1.ietf.org/mail-archive/web/tsv-area/current/msg00116.html >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Thursday, October 11, 2007 6:34 AM >> To: safe@ietf.org >> Subject: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF request >> underconsideration: SAFE >> >> Hi, >> >> This was sent to the V6OPS list by Pekka Savola. I forward it to the >> SAFE list with his permission for commenting. >> >> Magnus Westerlund >> >> >> -----Original Message----- >> From: Pekka Savola [mailto:pekkas@netcore.fi] >> Sent: Monday, October 08, 2007 7:07 PM >> To: Romascanu, Dan (Dan) >> Cc: ops-area@ietf.org >> Subject: Re: [OPS-AREA] FW: [tsv-area] BOF request under >> consideration: >> SAFE >> >> On Mon, 8 Oct 2007, Romascanu, Dan (Dan) wrote: >>> ICE and its companion protocol STUN have been successfully >> deployed on >> >>> the Internet for NAT traversal. ICE and STUN have several >>> characteristics which contribute to their success: >>> >>> 1. incremental deployment. ICE and STUN are functional without any >>> modifications to existing NATs. >>> 2. nested NATs. ICE and STUN work when there are multiple NATs >>> between a host and the Internet. >>> 3. topology unaware. ICE and STUN are not configured with >>> information about NATs, firewalls, or their locations -- only >>> with the IP address of a server on the Internet. >>> 4. simple security model. If a host behind a NAT is >> allowed to send >>> a packet across the NAT, it is allowed to receive a response. >>> 5. works on routed networks, which allows operation in both >>> enterprise networks and home networks. >> >> Teredo also fulfills these characteristics (and has none of the >> drawbacks listed later). >> >> I'm confident that the BOF proposers will be able to invent new >> drawbacks to exclude Teredo from consideration, though. >> >> -- >> Pekka Savola "You each name yourselves king, yet the >> Netcore Oy kingdom bleeds." >> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >> >> >> _______________________________________________ >> SAFE mailing list >> SAFE@ietf.org >> https://www1.ietf.org/mailman/listinfo/safe > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Tue Oct 16 09:44: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 1Ihmir-0000F1-5n; Tue, 16 Oct 2007 09:44:37 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1Ihmip-0000Ed-VQ for safe-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 09:44:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihmio-0000ET-RJ; Tue, 16 Oct 2007 09:44:34 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihmin-0003iP-R5; Tue, 16 Oct 2007 09:44:34 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9GDi4id012607; Tue, 16 Oct 2007 16:44:29 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 16:44:25 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 16:36:27 +0300 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] FW: [OPS-AREA] FW: [tsv-area] BOF requestunderconsideration: SAFE Date: Tue, 16 Oct 2007 16:36:26 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF requestunderconsideration: SAFE Thread-Index: AcgPR0zOY/pDDy2kTtOLDSyDk8tNcwArGCRg References: <470E262B.1080505@ericsson.com><024901c80c26$16fd9ff0$c3f0200a@cisco.com> From: To: , X-OriginalArrivalTime: 16 Oct 2007 13:36:27.0482 (UTC) FILETIME=[8D788BA0:01C80FF9] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: safe@ietf.org, ops-area@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, The NAT timeout adjustment specified in Teredo would indeed a useful practice not only to Teredo but any other UDP-based protocols that need connectivity through NATs (or firewalls, so even with native IPv6 or public IPv4). Perhaps we should generalize it so that it could be used also with e.g. IPSec ESP UDP encapslulation, DSMIPv6 and SIP-outbound (if people keep insisting running SIP over UDP). I wonder if STUN could be a good baseline for such a generalization. Something would be needed on the "public side" of NAT to respond to the UDP packets creating the "secondary" bindings which are used to determine the timeout period.=20 I suppose the caveat is that the determination algorithm does not always give correct results with non-BEHAVE compliant NATs, as different bindings will behave differently. The benefit of STUN control (implemented within the NAT itself) would be to make the determination more explicit, even in cases where there are multiple layers of NAT. And it would even be possible to increase the NAT timer from the default value. But even if we could communicate to all NATs with STUN control, I believe the application SHOULD use something like the procedure described in Teredo and gradually increase the keepalive period towards the one it configured/queried with STUN. This would alleviate the problem of connectivity breaks caused by "invisible" firewalls etc. Markus=20 =20 >-----Original Message----- >From: ext Pekka Savola [mailto:pekkas@netcore.fi]=20 >Sent: 15 October, 2007 08:45 >To: Dan Wing >Cc: safe@ietf.org; ops-area@ietf.org >Subject: RE: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF=20 >requestunderconsideration: SAFE > >Hi Dan, > >Please forward this to the SAFE list as appropriate. > >On Thu, 11 Oct 2007, Dan Wing wrote: >> The SAFE BoF isn't about comparing Teredo to STUN/ICE. >> >> Rather, it is about querying and controlling binding=20 >lifetimes of NATs=20 >> in order to reduce the frequency of keepalive messages across those=20 >> NATs. This would benefit any UDP-based protocol that traverses NATs=20 >> and, today, needs to send keepalives every 20-30 seconds; such a=20 >> protocol could reduce its keepalive traffic substantially. =20 >Teredo and=20 >> IPsec-over-UDP would benefit from such a reduction in keepalive=20 >> traffic. > >The list of drawbacks of existing solutions (that I clipped=20 >off in the mail *) seemed to be written in a way that implied=20 >that the BOF proposal wanted to express the superiority of=20 >STUN/ICE compared to the other solutions. I think you'll need=20 >to include a complete list, reword to make the intent of the=20 >text clearer or remove the drawback list completely. > >FWIW, as it happens, Teredo already supports automatic=20 >adjustment to NAT timeouts. > >*) >http://www1.ietf.org/mail-archive/web/tsv-area/current/msg00116.html > >>> -----Original Message----- >>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >>> Sent: Thursday, October 11, 2007 6:34 AM >>> To: safe@ietf.org >>> Subject: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF request >>> underconsideration: SAFE >>> >>> Hi, >>> >>> This was sent to the V6OPS list by Pekka Savola. I forward=20 >it to the=20 >>> SAFE list with his permission for commenting. >>> >>> Magnus Westerlund >>> >>> >>> -----Original Message----- >>> From: Pekka Savola [mailto:pekkas@netcore.fi] >>> Sent: Monday, October 08, 2007 7:07 PM >>> To: Romascanu, Dan (Dan) >>> Cc: ops-area@ietf.org >>> Subject: Re: [OPS-AREA] FW: [tsv-area] BOF request under >>> consideration: >>> SAFE >>> >>> On Mon, 8 Oct 2007, Romascanu, Dan (Dan) wrote: >>>> ICE and its companion protocol STUN have been successfully >>> deployed on >>> >>>> the Internet for NAT traversal. ICE and STUN have several=20 >>>> characteristics which contribute to their success: >>>> >>>> 1. incremental deployment. ICE and STUN are functional=20 >without any >>>> modifications to existing NATs. >>>> 2. nested NATs. ICE and STUN work when there are multiple NATs >>>> between a host and the Internet. >>>> 3. topology unaware. ICE and STUN are not configured with >>>> information about NATs, firewalls, or their locations -- only >>>> with the IP address of a server on the Internet. >>>> 4. simple security model. If a host behind a NAT is >>> allowed to send >>>> a packet across the NAT, it is allowed to receive a response. >>>> 5. works on routed networks, which allows operation in both >>>> enterprise networks and home networks. >>> >>> Teredo also fulfills these characteristics (and has none of the=20 >>> drawbacks listed later). >>> >>> I'm confident that the BOF proposers will be able to invent new=20 >>> drawbacks to exclude Teredo from consideration, though. >>> >>> -- >>> Pekka Savola "You each name yourselves king, yet the >>> Netcore Oy kingdom bleeds." >>> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >>> >>> >>> _______________________________________________ >>> SAFE mailing list >>> SAFE@ietf.org >>> https://www1.ietf.org/mailman/listinfo/safe >> > >--=20 >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > >_______________________________________________ >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 Tue Oct 16 12:29:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhpIJ-0005Pa-FU; Tue, 16 Oct 2007 12:29:23 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IhpIH-0005O3-4D for safe-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 12:29:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhpIG-0005Ns-7y; Tue, 16 Oct 2007 12:29:20 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhpIE-0002P9-UY; Tue, 16 Oct 2007 12:29:20 -0400 X-IronPort-AV: E=Sophos;i="4.21,284,1188802800"; d="scan'208";a="406980393" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 16 Oct 2007 09:29:18 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9GGTI7L012289; Tue, 16 Oct 2007 09:29:18 -0700 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9GGTCm9013041; Tue, 16 Oct 2007 16:29:17 GMT From: "Dan Wing" To: "'Pekka Savola'" References: <470E262B.1080505@ericsson.com> <024901c80c26$16fd9ff0$c3f0200a@cisco.com> Subject: RE: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF request underconsideration: SAFE Date: Tue, 16 Oct 2007 09:29:09 -0700 Message-ID: <1d7701c81011$b0db7540$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgO7pXmYvK0Hpa5RFKJxJkKxn6DIgAU0r0A DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4642; t=1192552158; x=1193416158; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[SAFE]=20FW=3A=20[OPS-AREA]=20FW=3A=20[tsv-area]=20BO F=20request=20underconsideration=3A=20SAFE |Sender:=20; bh=Y86UGv40SL5Zss7gzRef8kGlx1NnkW7WwVFyU/dbGxU=; b=tSpBcxKYVTv7R9nfMcaRRdhuU9aQ/5lOfcKzNQSfcVA5zYb1zKKp5cKhZBLzyY8cqG+XBWLH 3xCtN7KweGEfSuDgVgC0ls7xQsVqwEwFxo3MPjfydoQf9Dg3tG35ZEFB; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: safe@ietf.org, ops-area@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 Pekka Savola wrote: > Hi Dan, Hi. > Please forward this to the SAFE list as appropriate. It's CC'd. > On Thu, 11 Oct 2007, Dan Wing wrote: > > The SAFE BoF isn't about comparing Teredo to STUN/ICE. > > > > Rather, it is about querying and controlling binding lifetimes of > > NATs in order to reduce the frequency of keepalive messages across > > those NATs. This would benefit any UDP-based protocol that > > traverses NATs and, today, needs to send keepalives every 20-30 > > seconds; such a protocol could reduce its keepalive traffic > > substantially. Teredo and IPsec-over-UDP would benefit from > > such a reduction in keepalive traffic. > > The list of drawbacks of existing solutions (that I clipped > off in the mail *) seemed to be written in a way that implied > that the BOF proposal wanted to express the superiority of > STUN/ICE compared to the other solutions. I think you'll need to > include a complete list, reword to make the intent of the text > clearer or remove the drawback list completely. I have tweaked the BoF request to clarify the intent of the BoF. It is now at http://www.employees.org/safe/bof-request.html > FWIW, as it happens, Teredo already supports automatic adjustment to > NAT timeouts. Yes, and this is effective to learn the NAT's default timeout and to adjust keepalive traffic accordingly. To be effective at reducing keepalive traffic, the NAT's default timeout has to be increased for all UDP traffic (or, at a minimum, for all UDP traffic the NAT can identify as Teredo traffic). However, Teredo doesn't have a way to request an _increase_ of the NAT's timeout from the NAT's default. That is what STUN Control can do. Thus, with STUN Control, the NAT could retain its default timeout (30, 60, 120 seconds, or whatever) for most UDP traffic, and have a much longer timeout (e.g., 5-10 minutes) for the UDP bindings that request a longer timeout. -d > *) > http://www1.ietf.org/mail-archive/web/tsv-area/current/msg00116.html > > >> -----Original Message----- > >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >> Sent: Thursday, October 11, 2007 6:34 AM > >> To: safe@ietf.org > >> Subject: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF request > >> underconsideration: SAFE > >> > >> Hi, > >> > >> This was sent to the V6OPS list by Pekka Savola. I forward > it to the > >> SAFE list with his permission for commenting. > >> > >> Magnus Westerlund > >> > >> > >> -----Original Message----- > >> From: Pekka Savola [mailto:pekkas@netcore.fi] > >> Sent: Monday, October 08, 2007 7:07 PM > >> To: Romascanu, Dan (Dan) > >> Cc: ops-area@ietf.org > >> Subject: Re: [OPS-AREA] FW: [tsv-area] BOF request under > >> consideration: > >> SAFE > >> > >> On Mon, 8 Oct 2007, Romascanu, Dan (Dan) wrote: > >>> ICE and its companion protocol STUN have been successfully > >> deployed on > >> > >>> the Internet for NAT traversal. ICE and STUN have several > >>> characteristics which contribute to their success: > >>> > >>> 1. incremental deployment. ICE and STUN are functional > without any > >>> modifications to existing NATs. > >>> 2. nested NATs. ICE and STUN work when there are multiple NATs > >>> between a host and the Internet. > >>> 3. topology unaware. ICE and STUN are not configured with > >>> information about NATs, firewalls, or their locations -- only > >>> with the IP address of a server on the Internet. > >>> 4. simple security model. If a host behind a NAT is > >> allowed to send > >>> a packet across the NAT, it is allowed to receive a response. > >>> 5. works on routed networks, which allows operation in both > >>> enterprise networks and home networks. > >> > >> Teredo also fulfills these characteristics (and has none of the > >> drawbacks listed later). > >> > >> I'm confident that the BOF proposers will be able to invent new > >> drawbacks to exclude Teredo from consideration, though. > >> > >> -- > >> Pekka Savola "You each name yourselves > king, yet the > >> Netcore Oy kingdom bleeds." > >> Systems. Networks. Security. -- George R.R. Martin: A > Clash of Kings > >> > >> > >> _______________________________________________ > >> SAFE mailing list > >> SAFE@ietf.org > >> https://www1.ietf.org/mailman/listinfo/safe > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Thu Oct 25 09:42:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2yC-00017L-Il; Thu, 25 Oct 2007 09:41:56 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1Il2yA-00014k-Pz for safe-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 09:41:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2y5-0000yg-E3 for safe@ietf.org; Thu, 25 Oct 2007 09:41:49 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il2y4-0003jt-6Z for safe@ietf.org; Thu, 25 Oct 2007 09:41:49 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BC25320783 for ; Thu, 25 Oct 2007 15:41:42 +0200 (CEST) X-AuditID: c1b4fb3c-ae67bbb0000007e1-32-47209d16885a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AC777203F3 for ; Thu, 25 Oct 2007 15:41:42 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 15:41:42 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 15:41:42 +0200 Message-ID: <47209D16.7010902@ericsson.com> Date: Thu, 25 Oct 2007 15:41:42 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: safe@ietf.org X-Enigmail-Version: 0.95.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2007 13:41:42.0490 (UTC) FILETIME=[C6F2B3A0:01C8170C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [SAFE] Addressing nested NAT issues for STUN control 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, Isn't there a related issue to what is brought up in section 8.1 in that the STUN client will be able to send packets to that NAT. If a NAT on the path has the same address as another NAT then you can only send to the closest one. STUN Client 192.168.1.2 NAT-A 192.168.1.1/10.0.0.45 NAT-B 10.0.0.1/192.168.1.2 NAT-C 192.168.1.1/192.0.2.53 In this case the STUN client can't send to NAT-B as there is no external address which routes from STUN client to NAT-B. Have you thought of this problem? I think this one is more serious as private address spaces used on the internal side are limited to a few common ones. And here it is likely that even if the client in the above example wasn't using 192.168.1.2 then another host in his private network would. cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Thu Oct 25 15:51:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il8k7-0002zD-N1; Thu, 25 Oct 2007 15:51:47 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1Il8k5-0002xX-Nk for safe-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 15:51:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il8k5-0002xK-E1 for safe@ietf.org; Thu, 25 Oct 2007 15:51:45 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il8jz-0002pW-3m for safe@ietf.org; Thu, 25 Oct 2007 15:51:45 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 25 Oct 2007 12:51:33 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9PJpWoJ017693; Thu, 25 Oct 2007 12:51:32 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l9PJpVBu005487; Thu, 25 Oct 2007 19:51:32 GMT From: "Dan Wing" To: "'Magnus Westerlund'" , References: <47209D16.7010902@ericsson.com> Subject: RE: [SAFE] Addressing nested NAT issues for STUN control Date: Thu, 25 Oct 2007 12:51:31 -0700 Message-ID: <092101c81740$7125fd40$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <47209D16.7010902@ericsson.com> Thread-Index: AcgXDN3m/RbQqD1RTb+pVs9b/shl9AAMNROg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4614; t=1193341892; x=1194205892; 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:=20RE=3A=20[SAFE]=20Addressing=20nested=20NAT=20issues=20for=20S TUN=20control |Sender:=20; bh=yHDYsG6LPVMK5Hi7NejL/AnjTaxWMCQ3+cK2hIdCb0A=; b=lulGUOVHrj0qLbUpJosk1sjyjC6p8FDcXDOElQn1Z/EV7btArLFv0vnNzurUaCZ0KACxuJR6 O13LgpC8mPzGibhNPGcLEU6inLHh605+cj0RisuGccnlZ9t2Lr6t6KKY; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: 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 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Thursday, October 25, 2007 6:42 AM > To: safe@ietf.org > Subject: [SAFE] Addressing nested NAT issues for STUN control > > Hi, > > Isn't there a related issue to what is brought up in section > 8.1 in that > the STUN client will be able to send packets to that NAT. > > If a NAT on the path has the same address as another NAT then you can > only send to the closest one. > > STUN Client 192.168.1.2 > > NAT-A 192.168.1.1/10.0.0.45 > > NAT-B 10.0.0.1/192.168.1.2 > > NAT-C 192.168.1.1/192.0.2.53 > > In this case the STUN client can't send to NAT-B as there is > no external > address which routes from STUN client to NAT-B. > > Have you thought of this problem? Yes. > I think this one is more serious as > private address spaces used on the internal side are limited to a few > common ones. And here it is likely that even if the client in > the above > example wasn't using 192.168.1.2 then another host in his private > network would. I know a way to detect such an address overlap has occurred, and abandon STUN Control in that situation. The only way to allow STUN Control to work is to have each NAT participate as a STUN Control client itself (and control the next-hop NAT). This could work, but I haven't put much thought into that and it seems to get complex quickly. Detecting address overlap ------------------------- If we want to merely detect address overlap (so that STUN Control can be abandoned), we would need to add a way for each NAT to identify itself uniquely, and allow the outer NAT to learn that unique identifier from its next-innermost NAT. Using your example above: STUN Client 192.168.1.2 NAT-A 192.168.1.1/10.0.0.45 NAT-B 10.0.0.1/192.168.1.2 NAT-C 192.168.1.1/192.0.2.53 STUN server 161.44.1.1 (on the Internet) The STUN client would contact the STUN server on the Internet and learn the public IP address (192.0.2.53) of the outer-most NAT (NAT-C). The STUN client would then send a STUN Control message to that public IP address on the STUN port 192.0.2.53, UDP port 3478. NAT-C would receive that message. What we would add to the existing STUN Control procedure is to have NAT-C then send its own STUN Control message to the STUN port of the next-innermost NAT's IP address (this is the IP address NAT-C normally sends in XOR-INTERNAL-ADDRESS), and collect a NAT-IDENTIFIER value in the response. NAT-C would include that NAT-IDENTIFIER value to the STUN client. Then, when the STUN client tries to contact 192.168.1.1, and sees a different NAT-IDENTIFIER value, it knows it is talking to a different NAT. The STUN client could then abandon the STUN Control optimization. Message flow: STUN Client NAT-A NAT-B NAT-C STUN Server | | | | | 1. |---------------------------------->| | | | | | 2. |<----------------------------------| | | | | | 3. |------------------------->| | | | | | | 4. | | |<-----| | | | | | | 5. | | |----->| | | | | | | 6. |<-------------------------| | | | | | | 7. |---------->| | | | | | | | | 8. |<----------| | | | 1-2 are classic RFC3489 STUN. Message 3 is the existing STUN Control request message. Messages 4-5 are new; In message 4, NAT-C sends a STUN request to NAT-B. Message 5 contains NAT-B's NAT-IDENTIFIER value. In message 6, NAT-B's NAT-IDENTIFIER value is returned (in a new NAT-IDENTIFIER-INTERNAL attribute), and NAT-C's identifier is returned (in a new NAT-IDENTIFIER attribute). In message 7, the STUN client is sending a packet to NAT-B's public IP address; however, this is also NAT-A's public IP address, so the message is routed to NAT-A. In message 8, the STUN client learns NAT-A's NAT-IDENTIFIER value, and sees it differs from the value returned in message 6. This causes the STUN client to abandon STUN Control. Today, STUN Control encourages the NAT to not listen on the STUN port on its public (WAN) interface. For this idea to work, that would need to be softened so the NAT listens on its public interface has an RFC1918 address. -d _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Fri Oct 26 03:34:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJhr-0006f4-6W; Fri, 26 Oct 2007 03:34:11 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IlJhq-0006eu-0b for safe-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 03:34:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJhk-0006cU-Qs for safe@ietf.org; Fri, 26 Oct 2007 03:34:04 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlJhf-0007Mu-Sl for safe@ietf.org; Fri, 26 Oct 2007 03:34:00 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 10AA5208F4; Fri, 26 Oct 2007 09:33:59 +0200 (CEST) X-AuditID: c1b4fb3c-ae67bbb0000007e1-f7-47219866561e Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E7EC0205A5; Fri, 26 Oct 2007 09:33:58 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 09:33:58 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 09:33:57 +0200 Message-ID: <47219865.9000103@ericsson.com> Date: Fri, 26 Oct 2007 09:33:57 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing Subject: Re: [SAFE] Addressing nested NAT issues for STUN control References: <47209D16.7010902@ericsson.com> <092101c81740$7125fd40$c4f0200a@cisco.com> In-Reply-To: <092101c81740$7125fd40$c4f0200a@cisco.com> X-Enigmail-Version: 0.95.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2007 07:33:57.0637 (UTC) FILETIME=[91AF1350:01C817A2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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 See below Dan Wing skrev: >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Thursday, October 25, 2007 6:42 AM >> To: safe@ietf.org >> Subject: [SAFE] Addressing nested NAT issues for STUN control >> >> Hi, >> >> Isn't there a related issue to what is brought up in section >> 8.1 in that >> the STUN client will be able to send packets to that NAT. >> >> If a NAT on the path has the same address as another NAT then you can >> only send to the closest one. >> >> STUN Client 192.168.1.2 >> >> NAT-A 192.168.1.1/10.0.0.45 >> >> NAT-B 10.0.0.1/192.168.1.2 >> >> NAT-C 192.168.1.1/192.0.2.53 >> >> In this case the STUN client can't send to NAT-B as there is >> no external >> address which routes from STUN client to NAT-B. >> >> Have you thought of this problem? > > Yes. > >> I think this one is more serious as >> private address spaces used on the internal side are limited to a few >> common ones. And here it is likely that even if the client in >> the above >> example wasn't using 192.168.1.2 then another host in his private >> network would. > > I know a way to detect such an address overlap has occurred, and abandon > STUN Control in that situation. The only way to allow STUN Control to > work is to have each NAT participate as a STUN Control client itself > (and control the next-hop NAT). This could work, but I haven't put much > thought into that and it seems to get complex quickly. > > > Detecting address overlap > ------------------------- > > If we want to merely detect address overlap (so that STUN Control can > be abandoned), we would need to add a way for each NAT to identify itself > uniquely, and allow the outer NAT to learn that unique identifier from its > next-innermost NAT. Using your example above: > > STUN Client 192.168.1.2 > > NAT-A 192.168.1.1/10.0.0.45 > > NAT-B 10.0.0.1/192.168.1.2 > > NAT-C 192.168.1.1/192.0.2.53 > > STUN server 161.44.1.1 (on the Internet) > > The STUN client would contact the STUN server on the Internet and learn the > public IP address (192.0.2.53) of the outer-most NAT (NAT-C). The STUN client > would then send a STUN Control message to that public IP address on the STUN > port 192.0.2.53, UDP port 3478. NAT-C would receive that message. What we > would add to the existing STUN Control procedure is to have NAT-C then send > its own STUN Control message to the STUN port of the next-innermost NAT's IP > address (this is the IP address NAT-C normally sends in XOR-INTERNAL-ADDRESS), > and collect a NAT-IDENTIFIER value in the response. NAT-C would include that > NAT-IDENTIFIER value to the STUN client. Then, when the STUN client tries to > contact 192.168.1.1, and sees a different NAT-IDENTIFIER value, it knows it is > talking to a different NAT. The STUN client could then abandon the STUN > Control optimization. > > Message flow: > > STUN Client NAT-A NAT-B NAT-C STUN Server > | | | | | > 1. |---------------------------------->| > | | | | | > 2. |<----------------------------------| > | | | | | > 3. |------------------------->| | > | | | | | > 4. | | |<-----| | > | | | | | > 5. | | |----->| | > | | | | | > 6. |<-------------------------| | > | | | | | > 7. |---------->| | | | > | | | | | > 8. |<----------| | | | > > > 1-2 are classic RFC3489 STUN. Message 3 is the existing STUN Control request > message. Messages 4-5 are new; In message 4, NAT-C sends a STUN request to > NAT-B. Message 5 contains NAT-B's NAT-IDENTIFIER value. In message 6, > NAT-B's NAT-IDENTIFIER value is returned (in a new NAT-IDENTIFIER-INTERNAL > attribute), and NAT-C's identifier is returned (in a new NAT-IDENTIFIER > attribute). In message 7, the STUN client is sending a packet to NAT-B's > public IP address; however, this is also NAT-A's public IP address, so the > message is routed to NAT-A. In message 8, the STUN client learns NAT-A's > NAT-IDENTIFIER value, and sees it differs from the value returned in message > 6. This causes the STUN client to abandon STUN Control. > > Today, STUN Control encourages the NAT to not listen on the STUN port on its > public (WAN) interface. For this idea to work, that would need to be softened > so the NAT listens on its public interface has an RFC1918 address. > Are you not misstating yourself here? Section 5.1 in the draft states the following: "After learning the public IP address of its outer-most NAT, the endpoint sends a STUN packet to the STUN port (UDP/3478) of its outer-most NAT's public IP address. " And for the whole walk from out to in you only know the external IP address of the NAT. I thought the issue with my example is that when stun client tries to send to 192.168.1.2/3478 it will only reach itself. Rather then being issues to send to the gateway address. My initial reaction is that this is a big limitation. Nested NATs seems to be the most common case when STUN control would provide any serious benefit. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Fri Oct 26 03:56:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlK3f-0005U1-By; Fri, 26 Oct 2007 03:56:43 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IlK3e-0005Tu-7X for safe-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 03:56:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlK3d-0005Tm-UF for safe@ietf.org; Fri, 26 Oct 2007 03:56:41 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlK3X-0001TV-OV for safe@ietf.org; Fri, 26 Oct 2007 03:56:41 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 26 Oct 2007 00:56:25 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9Q7uPVJ018788; Fri, 26 Oct 2007 00:56:25 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l9Q7uNPX004728; Fri, 26 Oct 2007 07:56:23 GMT From: "Dan Wing" To: "'Magnus Westerlund'" References: <47209D16.7010902@ericsson.com> <092101c81740$7125fd40$c4f0200a@cisco.com> <47219865.9000103@ericsson.com> Subject: RE: [SAFE] Addressing nested NAT issues for STUN control Date: Fri, 26 Oct 2007 00:56:23 -0700 Message-ID: <135e01c817a5$b46093d0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <47219865.9000103@ericsson.com> Thread-Index: AcgXopTh+oAOjkUQTTWb3pWVMGBgjQAAlhxg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1736; t=1193385385; x=1194249385; 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:=20RE=3A=20[SAFE]=20Addressing=20nested=20NAT=20issues=20for=20S TUN=20control |Sender:=20; bh=kVOLb8KzWzYv0CWXUceMgt+GsJBOKy9vUaf9u7AUaaw=; b=WcotPxK5HopRzlObdGpe/tqRxyQu80NoF/3ZYnTNp5mPrpadVYdo9zq9UbB4uMY/M75FlWsh C1tr0SNxI3KbLTHELZinxycLF3L2q5p9DfrXYPrBR8kyXBqNJouxAS41; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 ... > Are you not misstating yourself here? Section 5.1 in the draft states > the following: > > "After learning the public IP address of its outer-most NAT, the > endpoint sends a STUN packet to the STUN port (UDP/3478) of its > outer-most NAT's public IP address. " > > And for the whole walk from out to in you only know the external IP > address of the NAT. > > I thought the issue with my example is that when stun client tries to > send to 192.168.1.2/3478 it will only reach itself. Rather then being > issues to send to the gateway address. Either way, the STUN client has reached an incorrect conclusion: the STUN client is unaware of a NAT. My proposal to use NAT-IDENTIFIER prevents that incorrect conclusion. > My initial reaction is that this is a big limitation. Nested > NATs seems to be the most common case when STUN control would provide > any serious benefit. Let's separate (a) nested NATs with non-overlapping IP addresses from (b) nested NATs with overlapping IP addresses. I believe STUN Control works fine with (a), and you are pointing out that it doesn't work well with (b). (Let me know if I'm correct on that point.) To resolve overlapping IP addresses, first we need to see how to detect that, and then avoid doing STUN Control. It might also be possible, by doing more creative things, to have the outer-most NAT contact the NATs on the inside by itself (and repeat that procedure on each inner NAT). I'm worried that could cause some horrid security implications (packet expansion) and have not investigated it. That is why I proposed in my previous email a mechanism to use NAT-IDENTIFIER to detect NATs with overlapping IP addresses. -d _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Fri Oct 26 04:07: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 1IlKER-0002Xe-W4; Fri, 26 Oct 2007 04:07:51 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IlKER-0002XZ-J1 for safe-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 04:07:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlKER-0002Wt-9V for safe@ietf.org; Fri, 26 Oct 2007 04:07:51 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlKEN-0001xf-V4 for safe@ietf.org; Fri, 26 Oct 2007 04:07:49 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 72FEB2128E; Fri, 26 Oct 2007 10:07:42 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-64-4721a04ef536 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5AB5F21283; Fri, 26 Oct 2007 10:07:42 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 10:07:42 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 10:07:41 +0200 Message-ID: <4721A04D.8040008@ericsson.com> Date: Fri, 26 Oct 2007 10:07:41 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing Subject: Re: [SAFE] Addressing nested NAT issues for STUN control References: <47209D16.7010902@ericsson.com> <092101c81740$7125fd40$c4f0200a@cisco.com> <47219865.9000103@ericsson.com> <135e01c817a5$b46093d0$c4f0200a@cisco.com> In-Reply-To: <135e01c817a5$b46093d0$c4f0200a@cisco.com> X-Enigmail-Version: 0.95.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2007 08:07:42.0002 (UTC) FILETIME=[484CA920:01C817A7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Dan Wing skrev: > ... >> Are you not misstating yourself here? Section 5.1 in the draft states >> the following: >> >> "After learning the public IP address of its outer-most NAT, the >> endpoint sends a STUN packet to the STUN port (UDP/3478) of its >> outer-most NAT's public IP address. " >> >> And for the whole walk from out to in you only know the external IP >> address of the NAT. >> >> I thought the issue with my example is that when stun client tries to >> send to 192.168.1.2/3478 it will only reach itself. Rather then being >> issues to send to the gateway address. > > Either way, the STUN client has reached an incorrect conclusion: the > STUN client is unaware of a NAT. My proposal to use NAT-IDENTIFIER > prevents that incorrect conclusion. Sure, it is important to be aware of the situation. > >> My initial reaction is that this is a big limitation. Nested >> NATs seems to be the most common case when STUN control would provide >> any serious benefit. > > Let's separate (a) nested NATs with non-overlapping IP addresses from > (b) nested NATs with overlapping IP addresses. I believe STUN Control > works fine with (a), and you are pointing out that it doesn't work > well with (b). (Let me know if I'm correct on that point.) Yes, that seems correct to me. > > To resolve overlapping IP addresses, first we need to see how to > detect that, and then avoid doing STUN Control. It might also be > possible, by doing more creative things, to have the outer-most > NAT contact the NATs on the inside by itself (and repeat that > procedure on each inner NAT). I'm worried that could cause some > horrid security implications (packet expansion) and have not > investigated it. That is why I proposed in my previous email > a mechanism to use NAT-IDENTIFIER to detect NATs with overlapping > IP addresses. > I am worried that NATs that hand out overlapping addresses will be fairly common. Most home NATs or modems seem to use 192.168.1.1/26 as default range to hand out and those will easily be nested. But we maybe should avoid getting to far into this issue. I think the main issue is that there need to be a discussion on how common is this issue and do it needs to be solved. After answering these questions we can start talking about a solution. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Fri Oct 26 13:11:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlSiX-00020a-PM; Fri, 26 Oct 2007 13:11:29 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IlSiV-0001xt-T4 for safe-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 13:11:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlSiV-0001xk-7x for safe@ietf.org; Fri, 26 Oct 2007 13:11:27 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlSiP-0004uu-0x for safe@ietf.org; Fri, 26 Oct 2007 13:11:27 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2007 10:11:15 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9QHBFap027926; Fri, 26 Oct 2007 10:11:15 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l9QHBEPX003177; Fri, 26 Oct 2007 17:11:14 GMT From: "Dan Wing" To: "'Magnus Westerlund'" References: <47209D16.7010902@ericsson.com><092101c81740$7125fd40$c4f0200a@cisco.com><47219865.9000103@ericsson.com> <135e01c817a5$b46093d0$c4f0200a@cisco.com> Subject: RE: [SAFE] Addressing nested NAT issues for STUN control Date: Fri, 26 Oct 2007 10:11:14 -0700 Message-ID: <164701c817f3$3772eeb0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <135e01c817a5$b46093d0$c4f0200a@cisco.com> Thread-Index: AcgXopTh+oAOjkUQTTWb3pWVMGBgjQAAlhxgABN9DKA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=524; t=1193418675; x=1194282675; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[SAFE]=20Addressing=20nested=20NAT=20issues=20for=20S TUN=20control |Sender:=20; bh=FMwdInrVkX74a8Einpvo57IGL/YVelQEOEIbBhcpkTs=; b=QauaUtb92zQ9u6PL4gzMG6nlk7dXXhFYGa0jAOwMBn3x4KCqCghpzfNvrF1oExe04Rjg39oS ZdfAiTGsyVbwQipSmjZ8XRywiTjD2dOmLoxHAYaW7et6/1vruZ/5AmCBe3Adhir79HjTqJsbu6 vDFy7lLxtQ6hIroPJc2a+NS00=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 > > I thought the issue with my example is that when stun > > client tries to > > send to 192.168.1.2/3478 it will only reach itself. Rather > > then being issues to send to the gateway address. I looked at your original email in more detail, and now understand the case you were depicting. In that case, the STUN client will know the next-closer NAT has a certain NAT-IDENTIFIER value, and it knows it isn't itself listening on UDP/3478, so it knows that NAT-IDENTIFIER value came from an upstream NAT. -d _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Mon Oct 29 06:32:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImRtP-00027q-TB; Mon, 29 Oct 2007 06:30:47 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1ImRtO-00027a-LL for safe-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 06:30:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImRtJ-000224-7e for safe@ietf.org; Mon, 29 Oct 2007 06:30:41 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImRtC-0006S7-RH for safe@ietf.org; Mon, 29 Oct 2007 06:30:41 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9TAU6WU004977; Mon, 29 Oct 2007 12:30:29 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 12:29:57 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 12:29:57 +0200 Received: from esdhcp041111.research.nokia.com ([172.21.41.111]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 12:29:56 +0200 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: safe@ietf.org Subject: Re: [SAFE] Addressing nested NAT issues for STUN control Date: Mon, 29 Oct 2007 12:30:58 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47209D16.7010902@ericsson.com> In-Reply-To: <47209D16.7010902@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710291230.58654.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 29 Oct 2007 10:29:56.0745 (UTC) FILETIME=[A6A45790:01C81A16] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: 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 =46rom a higher-level stand point: Le Thursday 25 October 2007 16:41:42 ext Magnus Westerlund, vous avez =C3= =A9crit=C2=A0: > Isn't there a related issue to what is brought up in section 8.1 in that > the STUN client will be able to send packets to that NAT. > > If a NAT on the path has the same address as another NAT then you can > only send to the closest one. This is a subset of the more general problem of overlapping net ranges. In= =20 that case, not only can't you reach the outer NAT, but you can't reach any= =20 node on the overlapping outer net. As such, collecting "candidates" (in ICE sense) for that net is pretty=20 useless, since you will not be able to communicate with any=20 remote "candidate" from that same network. As regard the binding refresh negociation, I would suppose the Tagging meth= od=20 could be made to work relatively easily, while indeed the Outside-In approa= ch=20 fails. > Have you thought of this problem? I think this one is more serious as > private address spaces used on the internal side are limited to a few > common ones. And here it is likely that even if the client in the above > example wasn't using 192.168.1.2 then another host in his private > network would. Agreed. I would say this is unlikely to occur with 2 NATs, likely to occur= =20 with 3 of them, very likely with 4 or more. In principle, off-the-shelves NATs should probably bridge rather than NAT w= hen=20 the outer network is using private space though. But I am not gullible enou= gh=20 to think they will. As far as I can tell, the only way to properly solve this, would involve so= me=20 kind of TURNish thing on the NAT. Basically, we'd end up doing source=20 routing - which might bring some unwelcome security issues, and surely bad= =20 publicity. =46or the ICE nested "candidate" scenario, this also adds significant compl= exity=20 to the client side, as it involves adding "foundations" to each "components= "=20 (recycling ICE terminology). =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe From safe-bounces@ietf.org Wed Oct 31 08:37:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InCoL-0000YG-BD; Wed, 31 Oct 2007 08:36:41 -0400 Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1InCoK-0000YA-C1 for safe-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 08:36:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InCoE-0000W8-ET for safe@ietf.org; Wed, 31 Oct 2007 08:36:34 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InCo6-0002lT-A7 for safe@ietf.org; Wed, 31 Oct 2007 08:36:32 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1InCnK-0005ts-1J; Wed, 31 Oct 2007 08:35:38 -0400 In-Reply-To: <4721A04D.8040008@ericsson.com> References: <47209D16.7010902@ericsson.com> <092101c81740$7125fd40$c4f0200a@cisco.com> <47219865.9000103@ericsson.com> <135e01c817a5$b46093d0$c4f0200a@cisco.com> <4721A04D.8040008@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5C470B4E-7832-4912-89C4-034807E668FE@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [SAFE] Addressing nested NAT issues for STUN control Date: Wed, 31 Oct 2007 08:36:47 -0400 To: Magnus Westerlund 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: de4f315c9369b71d7dd5909b42224370 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 On 26-Oct-07, at 04:07 , Magnus Westerlund wrote: > > I am worried that NATs that hand out overlapping addresses will be > fairly common. Most home NATs or modems seem to use 192.168.1.1/26 as > default range to hand out and those will easily be nested. I think this is a hard question to answer without solid experimental evidence. (As antidotal evidence, my home Internet access is through four levels of NAT -- two in my house and two from my ISP, and I (at least) did nothing to avoid IP address overlap.) - Philip _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe