Re: [SAFE] RE: [BEHAVE] BOF request under consideration: SAFE
Philip Matthews <philip_matthews@magma.ca> Fri, 12 October 2007 12:06 UTC
Return-path: <safe-bounces@ietf.org>
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 <philip_matthews@magma.ca>) id 1IgJHR-0001d1-36; Fri, 12 Oct 2007 08:06:14 -0400
In-Reply-To: <C84E0A4ABA6DD74DA5221E0833A35DF30A069164@esebe101.NOE.Nokia.com>
References: <470A480C.4040506@ericsson.com> <C84E0A4ABA6DD74DA5221E0833A35DF30A069164@esebe101.NOE.Nokia.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 <philip_matthews@magma.ca>
Subject: Re: [SAFE] RE: [BEHAVE] BOF request under consideration: SAFE
Date: Fri, 12 Oct 2007 08:06:12 -0400
To: Markus.Isomaki@nokia.com
X-Mailer: Apple Mail (2.752.2)
X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 995b2e24d23b953c94bac5288c432399
Cc: safe@ietf.org
X-BeenThere: safe@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Self-Address Fixing Evolution <safe.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/safe>, <mailto:safe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/safe>
List-Post: <mailto:safe@ietf.org>
List-Help: <mailto:safe-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/safe>, <mailto:safe-request@ietf.org?subject=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 , <Markus.Isomaki@nokia.com> <Markus.Isomaki@nokia.com> 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] RE: [tsv-area] BOF request under considera… Black_David
- [SAFE] RE: [tsv-area] BOF request under considera… Dan Wing
- [SAFE] RE: [tsv-area] BOF request under considera… Black_David
- [SAFE] RE: [tsv-area] BOF request under considera… Dan Wing
- RE: [SAFE] RE: [tsv-area] BOF request under consi… Markus.Isomaki
- [SAFE] RE: [BEHAVE] BOF request under considerati… Markus.Isomaki
- [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF request … Magnus Westerlund
- RE: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF requ… Dan Wing
- Re: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF requ… Rémi Denis-Courmont
- Re: [SAFE] RE: [BEHAVE] BOF request under conside… Philip Matthews
- Re: [SAFE] RE: [BEHAVE] BOF request under conside… Rémi Denis-Courmont
- RE: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF requ… Dan Wing
- RE: [SAFE] RE: [BEHAVE] BOF request under conside… Dan Wing
- Re: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF requ… Rémi Denis-Courmont
- RE: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF requ… Dan Wing
- RE: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF requ… Pekka Savola
- RE: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF requ… Markus.Isomaki
- RE: [SAFE] FW: [OPS-AREA] FW: [tsv-area] BOF requ… Dan Wing