From ayourtch@cisco.com Thu Oct 1 05:27:05 2009 Return-Path: X-Original-To: tae@core3.amsl.com Delivered-To: tae@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC62228C45A for ; Thu, 1 Oct 2009 05:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id En9Ev84W1eZo for ; Thu, 1 Oct 2009 05:27:05 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 3585428CD0F for ; Thu, 1 Oct 2009 05:11:30 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n91C96kR002632; Thu, 1 Oct 2009 14:09:06 +0200 (CEST) Received: from kk-son (dhcp-peg3-vl30-144-254-7-191.cisco.com [144.254.7.191]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n91C95BA028651; Thu, 1 Oct 2009 14:09:05 +0200 (CEST) Date: Thu, 1 Oct 2009 14:09:23 +0200 (CEST) From: Andrew Yourtchenko X-X-Sender: ayourtch@zippy.stdio.be To: Joe Touch In-Reply-To: <4AB7910D.3030007@isi.edu> Message-ID: References: <77F0974F-62CD-411C-96D3-C29E6D872DEA@asomi.com> <4AB2E6AB.7020409@gmail.com><4AB3A33B.7080909@ifi.uio.no> <4AB3A5DE.1040708@isi.edu> <055001ca388b$163a0070$5da36b80@cisco.com> <4AB3CF61.5060208@isi.edu> <38542A4D-C3D0-4BE8-BF2B-FB99252C596C@asomi.com> <4AB7910D.3030007@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tae@ietf.org Subject: Re: [tae] New draft: announcing the supported transports via DNS X-BeenThere: tae@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ayourtch@cisco.com List-Id: Transport Architecture Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 12:27:05 -0000 On Mon, 21 Sep 2009, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Caitlin Bestler wrote: >> >> On Sep 18, 2009, at 11:20 AM, Joe Touch wrote: > ... >>> As you note, addresses are sometimes used for non-human purposes, and >>> with IPv6 they could be created on the fly - I wouldn't want to have to >>> wait to register them in the DNS vs exchanging them in-band. >> >> Of course if you have already used application specific mechanisms to >> exchange >> IP addresses in-band then you obviously have the means to specify which >> transport protocol and options to use as well. > > I could give you an IP address, and still want you to negotiate a > transport you support with a transport that IP address supports. I can't > know that answer, so it's not my business to specify the transport. > > Ultimately, either you're solving the transport discovery problem, or > you're solving some other much more limited, DNS-focused case driven by > a particular example. I'm not sure why that would be useful if you can > solve the general case, but if so, it'd be important to explain that the > 'applicability' of DNS-focused solutions. I agree that a better view of the problem space is useful to see if we can arrive to a more generic solution - I made a first rough cut to it in my (overly long) mail to Caitlin, please feel free to amend. thanks, andrew > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAkq3kQwACgkQE5f5cImnZrupagCdFO7Gc4iNmNGrkhrUoSIvX6pJ > t+cAni6PaLP63Zrgo8uvrqgSKe7oJ5wv > =fMso > -----END PGP SIGNATURE----- > _______________________________________________ > tae mailing list > tae@ietf.org > https://www.ietf.org/mailman/listinfo/tae > From ayourtch@cisco.com Thu Oct 1 05:34:18 2009 Return-Path: X-Original-To: tae@core3.amsl.com Delivered-To: tae@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA783A6A79 for ; Thu, 1 Oct 2009 05:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94nxAv2Whiy6 for ; Thu, 1 Oct 2009 05:34:17 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id CE4D428C161 for ; Thu, 1 Oct 2009 05:29:52 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n91CVGE9006774; Thu, 1 Oct 2009 14:31:16 +0200 (CEST) Received: from kk-son (dhcp-peg3-vl30-144-254-7-191.cisco.com [144.254.7.191]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n91CVEqs001390; Thu, 1 Oct 2009 14:31:15 +0200 (CEST) Date: Thu, 1 Oct 2009 14:31:32 +0200 (CEST) From: Andrew Yourtchenko X-X-Sender: ayourtch@zippy.stdio.be To: Michael Welzl In-Reply-To: <4AB5DCE4.4070008@ifi.uio.no> Message-ID: References: <77F0974F-62CD-411C-96D3-C29E6D872DEA@asomi.com> <4AB2E6AB.7020409@gmail.com><4AB3A33B.7080909@ifi.uio.no> <4AB3A5DE.1040708@isi.edu> <055001ca388b$163a0070$5da36b80@cisco.com> <4AB3CF61.5060208@isi.edu> <057601ca388e$d775e620$5da36b80@cisco.com> <4AB3D3ED.5010002@isi.edu> <058401ca3891$8b0e3d20$5da36b80@cisco.com> <4AB3D84E.3090408@isi.edu> <058b01ca3893$36cad190$5da36b80@cisco.com> <4AB5DCE4.4070008@ifi.uio.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tae@ietf.org Subject: Re: [tae] New draft: announcing the supported transports via DNS X-BeenThere: tae@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ayourtch@cisco.com List-Id: Transport Architecture Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 12:34:19 -0000 my 2 cents based also on reading of the exchange between Bryan, Dan and Caitlin inline: On Sun, 20 Sep 2009, Michael Welzl wrote: > >> I think the following objectives need to be met for any probe-based >> solution: >> >> 1) Must add no additional messages when the default protocol is selected. There are at least two possible scenarios I'd see: a) default protocol is "selected" in case the peer simply does not have the support for the transport selection b) the default protocol is "selected" after the fact because the more advanced protocol that was negotiated does not succeed. and a worst case to consider is where the piggybacking on the existing "default" protocol breaks it - so there needs to be a fallback scenario for that case. (a) is quite possible. (b) very much not sure if possible. >> 2) TCP must be a valid default protocol. >> 3) There may be a case for adding UDP to that set for RTTP. I'd phrase it something like: "There should always exist a valid fallback/default protocol that is defined on a per-application basis under the assumption that the transport selected is not implemented on the other endpoint". >> 4) It should be capable of learning when a given client/server pair is >> blocked >> from using Transport X by some middle-box. Note: this is something a >> directory-based solution probably cannot do., +1. And the directory-based solution alone indeed can not do it. However, learning about the protocol being blocked, implies extra messages followed by a fallback to the "default" - the case of (1b) above. I think it could be useful for first explicitly splitting the functions of "discovery" and "selection", and then seeing how they can be combined, if - a form of refactoring. Having them originally split allows to focus on smaller chunks at a time, IMHO. When those chunks are well understood, it is easier to compose them. thanks, andrew From touch@ISI.EDU Fri Oct 2 06:45:45 2009 Return-Path: X-Original-To: tae@core3.amsl.com Delivered-To: tae@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50DB23A6951 for ; Fri, 2 Oct 2009 06:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzK6QhGnYQzZ for ; Fri, 2 Oct 2009 06:45:44 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D2A1728C0E6 for ; Fri, 2 Oct 2009 06:45:43 -0700 (PDT) Received: from [192.168.1.47] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n92Dkou0014374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Oct 2009 06:46:52 -0700 (PDT) Message-ID: <4AC60448.2050507@isi.edu> Date: Fri, 02 Oct 2009 06:46:48 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ayourtch@cisco.com References: <77F0974F-62CD-411C-96D3-C29E6D872DEA@asomi.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tae@ietf.org Subject: Re: [tae] New draft: announcing the supported transports via DNS X-BeenThere: tae@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Architecture Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 13:45:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Some comments below... Andrew Yourtchenko wrote: ... > Also, if we assume "evil middlebox" in the middle, that decides to drop > this new option, we will have a TCP connection that would not succeed, > so then still there needs to be a fallback to "plain TCP". > > That's one of the rationales of bringing up the use of DNS in lieu of a > in-band selection in general - we would still need to be able to > fallback to probing in the worst case (how frequent is the worst case > would of course need some more investigation). Use of the DNS is problematic on many levels: - - many users have IP addresses they don't control, e.g., assigned by an ISP, and those ISPs don't offer the ability to register services with their DNS - - you're involving a third party in a two-party problem - - you still have a bootstrapping problem -- by what transport do you talk to the DNS? - if you solve that for DNS, why not use that solution at the endpoint? > Now, a few variables in discussion of selection via a separate protocol > vs. DNS-based. > > 1) neither actually proves the possibility of the new protocol to > traverse the middleboxes - so probing is needed for either case. The > policy enforcement points are (at least now) frequently decoupled from > the endpoints, so the probing would be needed regardless. > > 2) The separate protocol is more distinct than using a DNS record, so > requires a separate explicit policy decision and enforcement. (of course > the actual transport policy needs to be enforced separately for both). > > 3) If the DNS is used, then the failure to pass the particular DNS > record would mean we can'd do "advanced" transports - however, this does > not preclude from already starting on the "default" transport - since it > is not express a requirement, but a desire/proposal. > If we fail to get the reply using the separate protocol, then we need to > fallback to default, how do we do that ? (and for in-band negotiation > within transports, would it suffice to define a single method of > fallback ?) > > 4) Assuming the decisions re. the advertised transports are relatively > long-lived, in the case of DNS we should be able to benefit of > distributed caching, in case the cached replies do not fully correspond, > the fallback/probing that has to be there anyway, will help to with a > smoother fallback. > > 5) the caching nature of DNS, while providing a benefit, exposes one new > attack vector that I did not think of before - which is the > reconnaissance without the knowledge of the party that advertizes the > transports. The explicit protocol does not have such a property. This > may or may not be important. > > 6) Assuming the responder does not change its "default" graph > on a per-connection basis, it may be more beneficial to "pre-create" the > proposal and let the initiator do the work of creating the mutable > "common" graph - DNS might be more appropriate here. OTOH if the server > *needs* different graphs on a per-session basis, then a separate > protocol is more appropriate. > > 7) Introduction of the new protocol for negotiation of the new transport > protocols looks to be the same higher order function of "introducing a > new protocol", just with a different parameter. > The more distinctly "new" this protocol is, the more distinct this > property is. So maybe a combined, staged approach is something to consider. It sounds like you've talked yourself out of using the DNS, or mostly so. Is that the case? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrGBEgACgkQE5f5cImnZrsrKwCgsDuDfgbkmvPNJj+HZOZJZAZ8 u84AoIPG8G6Idm4LHaeJdAhFCUBhcI7P =Vdz+ -----END PGP SIGNATURE----- From ayourtch@cisco.com Mon Oct 5 06:05:10 2009 Return-Path: X-Original-To: tae@core3.amsl.com Delivered-To: tae@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DC673A694F for ; Mon, 5 Oct 2009 06:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.615 X-Spam-Level: X-Spam-Status: No, score=-0.615 tagged_above=-999 required=5 tests=[AWL=-1.685, BAYES_50=0.001, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Pg53CUgm1dr for ; Mon, 5 Oct 2009 06:05:09 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 0C6E53A6910 for ; Mon, 5 Oct 2009 06:05:08 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n95CpdH1022064; Mon, 5 Oct 2009 14:51:39 +0200 (CEST) Received: from kk-son (dhcp-peg3-vl30-144-254-7-191.cisco.com [144.254.7.191]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n95Cpc6K013298; Mon, 5 Oct 2009 14:51:39 +0200 (CEST) Date: Mon, 5 Oct 2009 07:51:41 +0200 (CEST) From: Andrew Yourtchenko X-X-Sender: ayourtch@zippy.stdio.be To: Joe Touch In-Reply-To: <4AC60448.2050507@isi.edu> Message-ID: References: <77F0974F-62CD-411C-96D3-C29E6D872DEA@asomi.com> <4AC60448.2050507@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tae@ietf.org Subject: Re: [tae] New draft: announcing the supported transports via DNS X-BeenThere: tae@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ayourtch@cisco.com List-Id: Transport Architecture Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 13:05:10 -0000 On Fri, 2 Oct 2009, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Some comments below... > > Andrew Yourtchenko wrote: > ... >> Also, if we assume "evil middlebox" in the middle, that decides to drop >> this new option, we will have a TCP connection that would not succeed, >> so then still there needs to be a fallback to "plain TCP". >> >> That's one of the rationales of bringing up the use of DNS in lieu of a >> in-band selection in general - we would still need to be able to >> fallback to probing in the worst case (how frequent is the worst case >> would of course need some more investigation). > > Use of the DNS is problematic on many levels: > > - - many users have IP addresses they don't control, e.g., assigned by an > ISP, and those ISPs don't offer the ability to register services with > their DNS Use one of the dynamic DNS services. They exist and work well for the dynamic addresses. The ISP who assigns the IP has not much to do with the forward DNS resolution. > > - - you're involving a third party in a two-party problem It's not a two-party problem - at a minimum because the policy/protocol support on the nodes inbetween will influence the odds of being able to run a new transport. > > - - you still have a bootstrapping problem -- by what transport do you > talk to the DNS? I already know the addresses of the DNS servers. I know the default transport will work. I know my hosts's domain. Hence I can resolve the hostnames of my DNS servers. Hence I can lookup the transport record, and see if they offer something more, that I could try - keeping in mind that it is a suggestion and not an imperative. If it does not work I fall back onto using the default transport. > - if you solve that for DNS, why not use that solution at the > endpoint? > See above. It works, because the lowest common denominator is always available. So the DNS can work both for the "upgrade" of the DNS and on the endpoints for the suggestions about the new transports. >> Now, a few variables in discussion of selection via a separate protocol >> vs. DNS-based. >> >> 1) neither actually proves the possibility of the new protocol to >> traverse the middleboxes - so probing is needed for either case. The >> policy enforcement points are (at least now) frequently decoupled from >> the endpoints, so the probing would be needed regardless. >> >> 2) The separate protocol is more distinct than using a DNS record, so >> requires a separate explicit policy decision and enforcement. (of course >> the actual transport policy needs to be enforced separately for both). >> >> 3) If the DNS is used, then the failure to pass the particular DNS >> record would mean we can'd do "advanced" transports - however, this does >> not preclude from already starting on the "default" transport - since it >> is not express a requirement, but a desire/proposal. >> If we fail to get the reply using the separate protocol, then we need to >> fallback to default, how do we do that ? (and for in-band negotiation >> within transports, would it suffice to define a single method of >> fallback ?) >> >> 4) Assuming the decisions re. the advertised transports are relatively >> long-lived, in the case of DNS we should be able to benefit of >> distributed caching, in case the cached replies do not fully correspond, >> the fallback/probing that has to be there anyway, will help to with a >> smoother fallback. >> >> 5) the caching nature of DNS, while providing a benefit, exposes one new >> attack vector that I did not think of before - which is the >> reconnaissance without the knowledge of the party that advertizes the >> transports. The explicit protocol does not have such a property. This >> may or may not be important. >> >> 6) Assuming the responder does not change its "default" graph >> on a per-connection basis, it may be more beneficial to "pre-create" the >> proposal and let the initiator do the work of creating the mutable >> "common" graph - DNS might be more appropriate here. OTOH if the server >> *needs* different graphs on a per-session basis, then a separate >> protocol is more appropriate. >> >> 7) Introduction of the new protocol for negotiation of the new transport >> protocols looks to be the same higher order function of "introducing a >> new protocol", just with a different parameter. >> The more distinctly "new" this protocol is, the more distinct this >> property is. So maybe a combined, staged approach is something to consider. > > It sounds like you've talked yourself out of using the DNS, or mostly > so. Is that the case? No. What I am saying is that there is a place for both approaches. In any case, would be interesting to know what constructive suggestions would you have on this topic ? TCP option "let's kickstart a negotiation for a different protocol" ? thanks, andrew From touch@ISI.EDU Mon Oct 5 06:27:13 2009 Return-Path: X-Original-To: tae@core3.amsl.com Delivered-To: tae@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23FEE28C1CA for ; Mon, 5 Oct 2009 06:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.213 X-Spam-Level: X-Spam-Status: No, score=-1.213 tagged_above=-999 required=5 tests=[AWL=-1.214, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHNpB-OPY8sl for ; Mon, 5 Oct 2009 06:27:11 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 37C0328C1C6 for ; Mon, 5 Oct 2009 06:27:11 -0700 (PDT) Received: from [192.168.1.47] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n95DSOr1020215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Oct 2009 06:28:26 -0700 (PDT) Message-ID: <4AC9F478.6080308@isi.edu> Date: Mon, 05 Oct 2009 06:28:24 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ayourtch@cisco.com References: <77F0974F-62CD-411C-96D3-C29E6D872DEA@asomi.com> <4AC60448.2050507@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tae@ietf.org Subject: Re: [tae] New draft: announcing the supported transports via DNS X-BeenThere: tae@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Architecture Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 13:27:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Yourtchenko wrote: > > > On Fri, 2 Oct 2009, Joe Touch wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Some comments below... >> >> Andrew Yourtchenko wrote: >> ... >>> Also, if we assume "evil middlebox" in the middle, that decides to drop >>> this new option, we will have a TCP connection that would not succeed, >>> so then still there needs to be a fallback to "plain TCP". >>> >>> That's one of the rationales of bringing up the use of DNS in lieu of a >>> in-band selection in general - we would still need to be able to >>> fallback to probing in the worst case (how frequent is the worst case >>> would of course need some more investigation). >> >> Use of the DNS is problematic on many levels: >> >> - - many users have IP addresses they don't control, e.g., assigned by an >> ISP, and those ISPs don't offer the ability to register services with >> their DNS > > Use one of the dynamic DNS services. They exist and work well for the > dynamic addresses. The ISP who assigns the IP has not much to do with > the forward DNS resolution. There are numerous applications that use reverse DNS for verification, e.g., HTTP name-based access, SSL, etc. Users don't have control over reverse DNS. >> - - you're involving a third party in a two-party problem > > It's not a two-party problem - at a minimum because the policy/protocol > support on the nodes inbetween will influence the odds of being able to > run a new transport. Endpoints determine the meaning of a protocol. I can format messages that look like UDP, and have the endpoints parse them as TCP if I want - -- e.g., by having the endpoints interpret the transport protocol numbers accordingly. Intermediate points can think they know what's going on, and either try to help, block, or whatever, but they can be fooled. I'm also considering other issues - first-contact delay, fault tolerance, etc. Involving a DNS node on the other side of the planet in a shakey ISP might not be in the best interest of the two endpoints of a connection. >> - - you still have a bootstrapping problem -- by what transport do you >> talk to the DNS? > > I already know the addresses of the DNS servers. I know the default > transport will work. Why? Why should DNS have a default transport? I know my hosts's domain. Hence I can resolve the > hostnames of my DNS servers. Hence I can lookup the transport record, > and see if they offer something more, that I could try - keeping in mind > that it is a suggestion and not an imperative. If it does not work I > fall back onto using the default transport. Hmm. So you can try a default to the DNS, and ask *it* for other suggestions if it supports them. Why isn't this good enough for the two endpoints as well? >> - if you solve that for DNS, why not use that solution at the >> endpoint? >> > > See above. It works, because the lowest common denominator is always > available. So the DNS can work both for the "upgrade" of the DNS and on > the endpoints for the suggestions about the new transports. First, the DNS is not always available or desirable. Second, if you solve this for the DNS, you can use a similar solution directly between the endpoints without involving the DNS. Third, if you force all endpoints to support a default transport to talk to the DNS, you have a default transport to talk to all other endpoints anyway. ... >> It sounds like you've talked yourself out of using the DNS, or mostly >> so. Is that the case? > > No. What I am saying is that there is a place for both approaches. > > In any case, would be interesting to know what constructive suggestions > would you have on this topic ? > > TCP option "let's kickstart a negotiation for a different protocol" ? How about a SYN for a new protocol that has room for negotiating other transports? (I see no need - or, as importantly, room, for doing this inside TCP SYN option space). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrJ9HgACgkQE5f5cImnZrvZkgCfcpAWc0DT/uRyvZ/Db51Cn77b aLcAoO6kLdO8LAPrwynC47OJGIa9siCY =cKDO -----END PGP SIGNATURE----- From dwing@cisco.com Mon Oct 5 10:44:17 2009 Return-Path: X-Original-To: tae@core3.amsl.com Delivered-To: tae@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB5963A6A14 for ; Mon, 5 Oct 2009 10:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9o0vgAGX0g1 for ; Mon, 5 Oct 2009 10:44:16 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 398043A69A4 for ; Mon, 5 Oct 2009 10:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5388; q=dns/txt; s=sjiport02001; t=1254764751; x=1255974351; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Dan=20Wing"=20|Subject:=20RE: =20[tae]=20New=20draft:=20announcing=20the=20supported=20 transports=20via=20DNS|Date:=20Mon,=205=20Oct=202009=2010 :45:44=20-0700|Message-ID:=20<038301ca45e3$aa7ad5b0$c2f02 00a@cisco.com>|To:=20"'Joe=20Touch'"=20, =20|Cc:=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<4AC9F478.6080308@isi.edu>|References:=20 =09<77F0 974F-62CD-411C-96D3-C29E6D872DEA@asomi.com>=09=09<4AC60448.205050 7@isi.edu>=20<4AC9F478.6080308@isi.edu>; bh=++dGQ+okPTwLXPXuBNF9pc/4dX9jW3IOqHiPatRWf7o=; b=BzC/1n0tNLpuTazap9wjzR4Uld935AgCPpgU/aJpDnrdewNjGfENJDan z2WAwRaVQlFvnXA7MKqPkG8JJM4ee+3J3Pj/qvogd4AprcbbxWhURqSrd VRsKQ55WSzXiI31n6FsduwEyQRMaBQqjy5EMZn8DtJiiLgmJ25vygt/NB o=; Authentication-Results: sj-iport-2.cisco.com; dkim=pass (signature verified [TEST]) header.i=dwing@cisco.com X-IronPort-AV: E=Sophos;i="4.44,507,1249257600"; d="scan'208";a="211179954" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 05 Oct 2009 17:45:50 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n95HjoIC009697; Mon, 5 Oct 2009 10:45:50 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n95Hhx6m023123; Mon, 5 Oct 2009 17:45:50 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 13:45:45 -0400 Received: from dwingwxp01 ([10.32.240.194]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 13:45:45 -0400 From: "Dan Wing" To: "'Joe Touch'" , References: <77F0974F-62CD-411C-96D3-C29E6D872DEA@asomi.com> <4AC60448.2050507@isi.edu> <4AC9F478.6080308@isi.edu> Date: Mon, 5 Oct 2009 10:45:44 -0700 Message-ID: <038301ca45e3$aa7ad5b0$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpFv8dngAlogiJ3QUm0nGu0FWDWlgAIqokA In-Reply-To: <4AC9F478.6080308@isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-OriginalArrivalTime: 05 Oct 2009 17:45:45.0267 (UTC) FILETIME=[AA6D6830:01CA45E3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5388; t=1254764750; x=1255628750; 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[tae]=20New=20draft=3A=20announcing=20t he=20supported=20transports=20via=20DNS |Sender:=20; bh=++dGQ+okPTwLXPXuBNF9pc/4dX9jW3IOqHiPatRWf7o=; b=gZ13ALapPXFrcFvWnHIOyDjLXOYjYDACgL327kDa++ol/4U+Z/aED6Rnj5 hPYp7KyvLvMOwbADsWie/Yi0Da+Lcb9vSyUy9o6Fb4DttFA34HPzoEl3JXWD 19QIAYYcdG; Cc: tae@ietf.org Subject: Re: [tae] New draft: announcing the supported transports via DNS X-BeenThere: tae@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Architecture Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 17:44:18 -0000 > -----Original Message----- > From: tae-bounces@ietf.org [mailto:tae-bounces@ietf.org] On > Behalf Of Joe Touch > Sent: Monday, October 05, 2009 6:28 AM > To: ayourtch@cisco.com > Cc: tae@ietf.org > Subject: Re: [tae] New draft: announcing the supported > transports via DNS > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Andrew Yourtchenko wrote: > > > > > > On Fri, 2 Oct 2009, Joe Touch wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Some comments below... > >> > >> Andrew Yourtchenko wrote: > >> ... > >>> Also, if we assume "evil middlebox" in the middle, that > decides to drop > >>> this new option, we will have a TCP connection that would > not succeed, > >>> so then still there needs to be a fallback to "plain TCP". > >>> > >>> That's one of the rationales of bringing up the use of > DNS in lieu of a > >>> in-band selection in general - we would still need to be able to > >>> fallback to probing in the worst case (how frequent is > the worst case > >>> would of course need some more investigation). > >> > >> Use of the DNS is problematic on many levels: > >> > >> - - many users have IP addresses they don't control, e.g., > assigned by an > >> ISP, and those ISPs don't offer the ability to register > services with > >> their DNS > > > > Use one of the dynamic DNS services. They exist and work > well for the > > dynamic addresses. The ISP who assigns the IP has not much > to do with > > the forward DNS resolution. > > There are numerous applications that use reverse DNS for verification, > e.g., HTTP name-based access, SSL, etc. Users don't have control over > reverse DNS. Agreed. But how is reverse DNS authentication relevant to selection of a transport protocol? > >> - - you're involving a third party in a two-party problem > > > > It's not a two-party problem - at a minimum because the > policy/protocol > > support on the nodes inbetween will influence the odds of > being able to > > run a new transport. > > Endpoints determine the meaning of a protocol. I can format messages > that look like UDP, and have the endpoints parse them as TCP if I want > - -- e.g., by having the endpoints interpret the transport protocol > numbers accordingly. Intermediate points can think they know what's > going on, and either try to help, block, or whatever, but they can be > fooled. > > I'm also considering other issues - first-contact delay, fault > tolerance, etc. Involving a DNS node on the other side of the > planet in > a shakey ISP might not be in the best interest of the two > endpoints of a connection. draft-wood-tae-specifying-uri-transports meets those requirements, at least as I understand what you have described in this email. > >> - - you still have a bootstrapping problem -- by what > transport do you > >> talk to the DNS? > > > > I already know the addresses of the DNS servers. I know the default > > transport will work. > > Why? Why should DNS have a default transport? > > I know my hosts's domain. Hence I can resolve the > > hostnames of my DNS servers. Hence I can lookup the > transport record, > > and see if they offer something more, that I could try - > keeping in mind > > that it is a suggestion and not an imperative. If it does not work I > > fall back onto using the default transport. > > Hmm. So you can try a default to the DNS, and ask *it* for other > suggestions if it supports them. > > Why isn't this good enough for the two endpoints as well? > > >> - if you solve that for DNS, why not use that solution at the > >> endpoint? > >> > > > > See above. It works, because the lowest common denominator is always > > available. So the DNS can work both for the "upgrade" of > the DNS and on > > the endpoints for the suggestions about the new transports. > > First, the DNS is not always available or desirable. > > Second, if you solve this for the DNS, you can use a similar solution > directly between the endpoints without involving the DNS. > > Third, if you force all endpoints to support a default > transport to talk > to the DNS, you have a default transport to talk to all other > endpoints anyway. I sure would like to see your straw man proposal, because I cannot fathom how you would accomplish this feat. -d > ... > >> It sounds like you've talked yourself out of using the > DNS, or mostly > >> so. Is that the case? > > > > No. What I am saying is that there is a place for both approaches. > > > > In any case, would be interesting to know what constructive > suggestions > > would you have on this topic ? > > > > TCP option "let's kickstart a negotiation for a different > protocol" ? > > How about a SYN for a new protocol that has room for negotiating other > transports? (I see no need - or, as importantly, room, for doing this > inside TCP SYN option space). > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAkrJ9HgACgkQE5f5cImnZrvZkgCfcpAWc0DT/uRyvZ/Db51Cn77b > aLcAoO6kLdO8LAPrwynC47OJGIa9siCY > =cKDO > -----END PGP SIGNATURE----- > _______________________________________________ > tae mailing list > tae@ietf.org > https://www.ietf.org/mailman/listinfo/tae > From ayourtch@cisco.com Mon Oct 5 10:51:02 2009 Return-Path: X-Original-To: tae@core3.amsl.com Delivered-To: tae@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3C9D28C22F for ; Mon, 5 Oct 2009 10:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.775 X-Spam-Level: X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfKhfu375Upu for ; Mon, 5 Oct 2009 10:51:00 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 082A33A699E for ; Mon, 5 Oct 2009 10:50:57 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n95HqVlA009861; Mon, 5 Oct 2009 19:52:31 +0200 (CEST) Received: from kk-son (dhcp-peg3-vl30-144-254-7-191.cisco.com [144.254.7.191]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n95HqS4a014672; Mon, 5 Oct 2009 19:52:28 +0200 (CEST) Date: Mon, 5 Oct 2009 12:52:31 +0200 (CEST) From: Andrew Yourtchenko X-X-Sender: ayourtch@zippy.stdio.be To: Joe Touch In-Reply-To: <4AC9F478.6080308@isi.edu> Message-ID: References: <77F0974F-62CD-411C-96D3-C29E6D872DEA@asomi.com> <4AC60448.2050507@isi.edu> <4AC9F478.6080308@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tae@ietf.org Subject: Re: [tae] New draft: announcing the supported transports via DNS X-BeenThere: tae@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ayourtch@cisco.com List-Id: Transport Architecture Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 17:51:02 -0000 On Mon, 5 Oct 2009, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Andrew Yourtchenko wrote: >> >> >> On Fri, 2 Oct 2009, Joe Touch wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Some comments below... >>> >>> Andrew Yourtchenko wrote: >>> ... >>>> Also, if we assume "evil middlebox" in the middle, that decides to drop >>>> this new option, we will have a TCP connection that would not succeed, >>>> so then still there needs to be a fallback to "plain TCP". >>>> >>>> That's one of the rationales of bringing up the use of DNS in lieu of a >>>> in-band selection in general - we would still need to be able to >>>> fallback to probing in the worst case (how frequent is the worst case >>>> would of course need some more investigation). >>> >>> Use of the DNS is problematic on many levels: >>> >>> - - many users have IP addresses they don't control, e.g., assigned by an >>> ISP, and those ISPs don't offer the ability to register services with >>> their DNS >> >> Use one of the dynamic DNS services. They exist and work well for the >> dynamic addresses. The ISP who assigns the IP has not much to do with >> the forward DNS resolution. > > There are numerous applications that use reverse DNS for verification, > e.g., HTTP name-based access, SSL, etc. Users don't have control over > reverse DNS. This implies that these services would not work today with the dynamic address. Which is something understandable. However, the item we were discussing was about forward DNS - for the case where one point wants to talk to the other point by name. > >>> - - you're involving a third party in a two-party problem >> >> It's not a two-party problem - at a minimum because the policy/protocol >> support on the nodes inbetween will influence the odds of being able to >> run a new transport. > > Endpoints determine the meaning of a protocol. I can format messages > that look like UDP, and have the endpoints parse them as TCP if I want > - -- e.g., by having the endpoints interpret the transport protocol > numbers accordingly. Intermediate points can think they know what's > going on, and either try to help, block, or whatever, but they can be > fooled. Yes, you indeed can fool the intermediate points. http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-kaminsky/bh-us-04-kaminsky.ppt But that's dangerous route. > > I'm also considering other issues - first-contact delay, fault > tolerance, etc. please bookmark this place [*]- I will reference it later. > Involving a DNS node on the other side of the planet in > a shakey ISP might not be in the best interest of the two endpoints of a > connection. DNS on a "shakey ISP" is not in the best interest of anyone. Besides, as I mentioned, this "shakey ISP" would already need to be used for determining name->address mapping. > >>> - - you still have a bootstrapping problem -- by what transport do you >>> talk to the DNS? >> >> I already know the addresses of the DNS servers. I know the default >> transport will work. > > Why? Why should DNS have a default transport? Same as any other app. There will be endpoints that do not implement the transport selection, so they will assume whichever the legacy transport was. > > I know my hosts's domain. Hence I can resolve the >> hostnames of my DNS servers. Hence I can lookup the transport record, >> and see if they offer something more, that I could try - keeping in mind >> that it is a suggestion and not an imperative. If it does not work I >> fall back onto using the default transport. > > Hmm. So you can try a default to the DNS, and ask *it* for other > suggestions if it supports them. > > Why isn't this good enough for the two endpoints as well? per-application transport negotiation at the application layer ? > >>> - if you solve that for DNS, why not use that solution at the >>> endpoint? >>> >> >> See above. It works, because the lowest common denominator is always >> available. So the DNS can work both for the "upgrade" of the DNS and on >> the endpoints for the suggestions about the new transports. > > First, the DNS is not always available or desirable. That's why I asked about the use cases, in the very beginning. I am suspecting I am talking about the use case that does involve the DNS, and you talk about the use case that does not. Makes it hard to converge, I guess. > > Second, if you solve this for the DNS, you can use a similar solution > directly between the endpoints without involving the DNS. > > Third, if you force all endpoints to support a default transport to talk > to the DNS, you have a default transport to talk to all other endpoints > anyway. ...which is the today's status quo. Every application runs on its transport. Where do we go from here ? > > ... >>> It sounds like you've talked yourself out of using the DNS, or mostly >>> so. Is that the case? >> >> No. What I am saying is that there is a place for both approaches. >> >> In any case, would be interesting to know what constructive suggestions >> would you have on this topic ? >> >> TCP option "let's kickstart a negotiation for a different protocol" ? > > How about a SYN for a new protocol that has room for negotiating other > transports? Here I will backreference the [*] - and quote your argument, which precisely coincides with mine about the new protocol: > I'm also considering other issues - first-contact delay, fault > tolerance, etc. A) If we *start* with the new protocol, and it simply does not go through, we: 1) can not determine whether it was because the request was blocked or because the other end does not support this protocol. 2) still need to fallback to something that you know may work better. B) Moreover, assuming we start the exchange on the new protocol in parallel with the "default fallback protocol", then either: 1) we still need to verify whether the negotiated protocol works (since the protocol negotiation protocol is a different one) 2) or we need to upfront use the inband negotiation within the protocol that the other end will speculatively support. Which we can not know because of the (A.1) above. As I wrote earlier, "introducing new protocol" for a transport and and "introducing new protocol" for the selection of new protocols for share a common subset of issues, the above is one of the examples. What's your opininon ? > (I see no need - or, as importantly, room, for doing this > inside TCP SYN option space). ok. thanks, andrew > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAkrJ9HgACgkQE5f5cImnZrvZkgCfcpAWc0DT/uRyvZ/Db51Cn77b > aLcAoO6kLdO8LAPrwynC47OJGIa9siCY > =cKDO > -----END PGP SIGNATURE----- > From touch@ISI.EDU Tue Oct 6 09:42:05 2009 Return-Path: X-Original-To: tae@core3.amsl.com Delivered-To: tae@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B41528C0F0 for ; Tue, 6 Oct 2009 09:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8TB7merU8cM for ; Tue, 6 Oct 2009 09:42:04 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 1C05D3A6877 for ; Tue, 6 Oct 2009 09:42:04 -0700 (PDT) Received: from [75.214.167.79] (79.sub-75-214-167.myvzw.com [75.214.167.79]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n96GgNtx003994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Oct 2009 09:42:25 -0700 (PDT) Message-ID: <4ACB736F.7010501@isi.edu> Date: Tue, 06 Oct 2009 09:42:23 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ayourtch@cisco.com References: <77F0974F-62CD-411C-96D3-C29E6D872DEA@asomi.com> <4AC60448.2050507@isi.edu> <4AC9F478.6080308@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n96GgNtx003994 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tae@ietf.org Subject: Re: [tae] New draft: announcing the supported transports via DNS X-BeenThere: tae@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Architecture Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 16:42:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jumping down to the punchline: > A) If we *start* with the new protocol, and it simply does not go through, we: > > 1) can not determine whether it was because the request was blocked > or because the other end does not support this protocol. True if you start with an existing protocol (e.g., TCP) and add an option as well. > 2) still need to fallback to something that you know may work better. Agreed. > B) Moreover, assuming we start the exchange on the new protocol in > parallel with the "default fallback protocol", then either: > > 1) we still need to verify whether the negotiated protocol works > (since the protocol negotiation protocol is a different one) > > 2) or we need to upfront use the inband negotiation within the > protocol that the other end will speculatively support. Which we can not > know because of the (A.1) above. > > As I wrote earlier, "introducing new protocol" for a transport and > and "introducing new protocol" for the selection of new protocols for > share a common subset of issues, the above is one of the examples. > > What's your opininon ? I agree. IMO, this calls for a a protocol *between the endpoints* to determine how to proceed. I don't think that fits or is appropriate for a TCP option. I don't think the DNS is a useful protocol for this purpose (whether between the endpoints or placed separately in the network). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrLc28ACgkQE5f5cImnZrsZWwCfec4qgI74IlMP1KmQ0DTOBr+5 GDAAn2MZS2G4DoDdnJyf3Repmj9XKvn3 =OQXq -----END PGP SIGNATURE----- From touch@ISI.EDU Tue Oct 6 09:52:37 2009 Return-Path: X-Original-To: tae@core3.amsl.com Delivered-To: tae@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21BD628C186 for ; Tue, 6 Oct 2009 09:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcyvPnyrW2hy for ; Tue, 6 Oct 2009 09:52:36 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 2C26028C14B for ; Tue, 6 Oct 2009 09:52:36 -0700 (PDT) Received: from [75.214.167.79] (79.sub-75-214-167.myvzw.com [75.214.167.79]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n96GpNYc006379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Oct 2009 09:51:25 -0700 (PDT) Message-ID: <4ACB758B.909@isi.edu> Date: Tue, 06 Oct 2009 09:51:23 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dan Wing References: <77F0974F-62CD-411C-96D3-C29E6D872DEA@asomi.com> <4AC60448.2050507@isi.edu> <4AC9F478.6080308@isi.edu> <038301ca45e3$aa7ad5b0$c2f0200a@cisco.com> In-Reply-To: <038301ca45e3$aa7ad5b0$c2f0200a@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n96GpNYc006379 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tae@ietf.org Subject: Re: [tae] New draft: announcing the supported transports via DNS X-BeenThere: tae@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Architecture Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 16:52:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... >> > There are numerous applications that use reverse DNS for verification, >> > e.g., HTTP name-based access, SSL, etc. Users don't have control over >> > reverse DNS. > > Agreed. > > But how is reverse DNS authentication relevant to selection of > a transport protocol? If all you have is an IP address (whether the user types it in or it is provided in-band), the only thing you can lookup in the DNS (to find the supported transports for that address) is reverse DNS. ... >> > First, the DNS is not always available or desirable. >> > >> > Second, if you solve this for the DNS, you can use a similar solution >> > directly between the endpoints without involving the DNS. >> > >> > Third, if you force all endpoints to support a default >> > transport to talk >> > to the DNS, you have a default transport to talk to all other >> > endpoints anyway. > > I sure would like to see your straw man proposal, because I > cannot fathom how you would accomplish this feat. First, I don't need to provide a strawman to express concerns with an existing proposal. We aren't picking a place for lunch*. Second, I'm basically suggesting that this all boils down to the need for a transport negotiation protocol between the endpoints. There are numerous challenges to designing an effective negotiation protocol: - latency to detect supported protocols - latency to fallback if not supported - interaction with NATs/firewalls Just saying "use the DNS" doesn't solve these problems any better than "build a new exchange protocol", and adds other problems: - support for non-DNS endpoints (IP address specified) - involvement of a third party (lack of fate-sharing) Joe *(typical lunch location negotiation rules are "if you shoot down a proposed site, you must counter with an alternative you are willing to accept") -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrLdYsACgkQE5f5cImnZrvsjwCg5P6SGGzdxBwr2FtPr2aSPS/k Fa0AnjEmKD99tDni7QysjTpPDAeC/B4Z =+SUt -----END PGP SIGNATURE----- From dwing@cisco.com Tue Oct 6 10:54:17 2009 Return-Path: X-Original-To: tae@core3.amsl.com Delivered-To: tae@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3713A69F1 for ; Tue, 6 Oct 2009 10:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7p9hShYOyk0 for ; Tue, 6 Oct 2009 10:54:16 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id CE7483A69A3 for ; Tue, 6 Oct 2009 10:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2879; q=dns/txt; s=sjiport01001; t=1254851744; x=1256061344; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Dan=20Wing"=20|Subject:=20RE: =20[tae]=20New=20draft:=20announcing=20the=20supported=20 transports=20via=20DNS|Date:=20Tue,=206=20Oct=202009=2010 :55:41=20-0700|Message-ID:=20<072201ca46ae$3925e8c0$c2f02 00a@cisco.com>|To:=20"'Joe=20Touch'"=20 |Cc:=20,=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<4ACB758B.909@isi.edu>|References:=20=09<77F0974F -62CD-411C-96D3-C29E6D872DEA@asomi.com>=09=09<4AC60448.2050507@is i.edu> =20<4AC9F478.6080308@isi.edu>=20<038301ca45e3$aa7ad5b0$c2 f0200a@cisco.com>=20<4ACB758B.909@isi.edu>; bh=PtGmCurN1JkMCEfyDslsNe9D247qAV5WF6BIL27zyBM=; b=JSRh7/zYw5IrKWJHH7CAILcZHTOistGwnNZ5RYB8chozOTpncILR7bCj x3uDaJ5OvkVNDpx4/p4SmtXz4C1m+GqVxYy2pIGcB29RZpCyJjY5pa8D+ Qt8mnAxhxJnlZ7cbDU8uTDEtTNtgaXLVLQoFWJ1kYSGtk6U029TiDz7fZ 4=; Authentication-Results: sj-iport-1.cisco.com; dkim=pass (partially verified [2848 bytes] [TEST]) header.i=dwing@cisco.com X-IronPort-AV: E=Sophos;i="4.44,513,1249257600"; d="scan'208";a="251733000" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 06 Oct 2009 17:55:44 +0000 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 n96Htik2032005; Tue, 6 Oct 2009 10:55:44 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n96HtidM022845; Tue, 6 Oct 2009 17:55:44 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 19:55:43 +0200 Received: from dwingwxp01 ([10.21.86.124]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 19:55:43 +0200 From: "Dan Wing" To: "'Joe Touch'" References: <77F0974F-62CD-411C-96D3-C29E6D872DEA@asomi.com> <4AC60448.2050507@isi.edu> <4AC9F478.6080308@isi.edu> <038301ca45e3$aa7ad5b0$c2f0200a@cisco.com> <4ACB758B.909@isi.edu> Date: Tue, 6 Oct 2009 10:55:41 -0700 Message-ID: <072201ca46ae$3925e8c0$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpGpWWBM2c9boCfSBKCI+hbRTMk5QACBJWw In-Reply-To: <4ACB758B.909@isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-OriginalArrivalTime: 06 Oct 2009 17:55:43.0333 (UTC) FILETIME=[3950C950:01CA46AE] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16930.003 X-TM-AS-Result: No--30.884900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2848; t=1254851744; x=1255715744; 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[tae]=20New=20draft=3A=20announcing=20t he=20supported=20transports=20via=20DNS |Sender:=20; bh=E9Ica54bmRYvHBgVVsCi0e4d1aJVJDeWr89II7xCdzo=; b=fQGHdtmHYDEQQicaIVQpSatBuatznD0QYFo7Jn9pt2/U1SakCUji4lcIGV 80xkM0btPId2Mulf/r+ktMlWNVEYP3mdQcm8EQYo4VkDGU0XHOam/WJ45PNz 9J4+u3s1bw; Cc: tae@ietf.org Subject: Re: [tae] New draft: announcing the supported transports via DNS X-BeenThere: tae@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Architecture Evolution List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 17:54:17 -0000 > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Tuesday, October 06, 2009 9:51 AM > To: Dan Wing > Cc: ayourtch@cisco.com; tae@ietf.org > Subject: Re: [tae] New draft: announcing the supported > transports via DNS > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > ... > >> > There are numerous applications that use reverse DNS for > verification, > >> > e.g., HTTP name-based access, SSL, etc. Users don't have > control over > >> > reverse DNS. > > > > Agreed. > > > > But how is reverse DNS authentication relevant to selection of > > a transport protocol? > > If all you have is an IP address (whether the user types it > in or it is > provided in-band), the only thing you can lookup in the DNS > (to find the > supported transports for that address) is reverse DNS. Our proposal, draft-yourtchenko-tran-announce-dns-00, does not suggest looking up PTR records. We're trying to optimize the Happy Eyeballs probing (draft-wing-http-new-tech-00) for the 99.65% of websites that have DNS names. 99.65% comes from Alexa's list of top 1,000,000 websites; 3455 of them are IPv4 address literals. -d > ... > >> > First, the DNS is not always available or desirable. > >> > > >> > Second, if you solve this for the DNS, you can use a > similar solution > >> > directly between the endpoints without involving the DNS. > >> > > >> > Third, if you force all endpoints to support a default > >> > transport to talk > >> > to the DNS, you have a default transport to talk to all other > >> > endpoints anyway. > > > > I sure would like to see your straw man proposal, because I > > cannot fathom how you would accomplish this feat. > > First, I don't need to provide a strawman to express concerns with an > existing proposal. We aren't picking a place for lunch*. > > Second, I'm basically suggesting that this all boils down to the need > for a transport negotiation protocol between the endpoints. There are > numerous challenges to designing an effective negotiation protocol: > > - latency to detect supported protocols > - latency to fallback if not supported > - interaction with NATs/firewalls > > Just saying "use the DNS" doesn't solve these problems any better than > "build a new exchange protocol", and adds other problems: > > - support for non-DNS endpoints (IP address specified) > - involvement of a third party (lack of fate-sharing) > > Joe > > *(typical lunch location negotiation rules are "if you shoot down a > proposed site, you must counter with an alternative you are willing to > accept") > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAkrLdYsACgkQE5f5cImnZrvsjwCg5P6SGGzdxBwr2FtPr2aSPS/k > Fa0AnjEmKD99tDni7QysjTpPDAeC/B4Z > =+SUt > -----END PGP SIGNATURE-----