From ajs@shinkuro.com Thu Oct 1 15:27:08 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61CE13A67B3 for ; Thu, 1 Oct 2009 15:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.510, 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 vHIfbRPBSccJ for ; Thu, 1 Oct 2009 15:27:07 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 3D3013A67A4 for ; Thu, 1 Oct 2009 15:27:07 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 94F8F2FE8CA1 for ; Thu, 1 Oct 2009 22:28:30 +0000 (UTC) Date: Thu, 1 Oct 2009 18:28:28 -0400 From: Andrew Sullivan To: grobj@ietf.org Message-ID: <20091001222828.GQ7059@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [grobj] Initial and preliminary comment on draft-carpenter-behave-referral-object-00 X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 22:27:08 -0000 Dear colleagues, I have only just started to read draft-carpenter-behave-referral-object-00, but I am having a bit of a difficult time with the motivation for this work. In particular, the following paragraph seems a little odd to me. I quote at length, but insert some numbers to identify some important conditions called out here. In some cases, this problem may be readily solved by passing a Fully Qualified Domain Name (FQDN) instead of an address. Indeed, that is an architecturally preferred solution [RFC1958]. However, it is not sufficient in many cases of dynamic referrals. Experience shows that an application cannot use a domain name in order to reliably find the address(es) of an arbitrary peer. Domain names work fairly well to find the addresses of servers, as in web servers or SMTP servers, because operators of public servers take pains to make sure that their domain names work. But DNS records [1] are not as reliably maintained for arbitrary hosts such as might need to be contacted in peer-to-peer applications. [2] Many small networks do not even maintain DNS entries for their hosts, and for some networks that do list local hosts in DNS, [3] the listings may well be unusable from a remote location (say because of two-faced DNS, or because the A record contains a private address). Furthermore, an FQDN may not be sufficient to establish successful communications involving heterogeneous peers (i.e. IPv4 and IPv6) since [4] A and AAAA records may not be correctly provisioned. What that paragraph says, in effect, is that domain names don't work (1) when people don't maintain their DNS entries, (2) when people don't maintain their DNS entries, (3) when people maintain the DNS incorrectly, or (4) when people maintain the DNS or network infrastructure incorrectly. I'm having a very hard time seeing why we want to come up with another way to solve these problems. If the problem is a simple operational one -- people are making mistakes because their tools suck -- then I think we obviously need to work on the operational support. But if the problem is just that people don't look after their networks (and I suggest that is indeed a significant part of the problem), then surely any new mechanism is going to face exactly the same problem, no? Furthermore, badly run networks with 3 layers of NAT intended to "provide security" are indeed hard to talk into, and the people who are breaking things that way are breaking them _on purpose_, so those people aren't going to be keen on "fixing" this problem either. Moreover, the plentiful attempts to fix the problem, listed in the appendix, seem partly to confirm my view: many of them are desperate hacks that people are doing to get around badly broken networks. I am having a hard time believing that we're going to make the world better by generalizing the hacks sufficiently to call them a protocol. I suspect I'm missing something important in the motivation, however. Perhaps there's further text needed? Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From moore@network-heretics.com Thu Oct 1 16:09:49 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17F033A67DA for ; Thu, 1 Oct 2009 16:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 nR7P4ZDX4BAW for ; Thu, 1 Oct 2009 16:09:48 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id D95133A67DD for ; Thu, 1 Oct 2009 16:09:47 -0700 (PDT) Received: from lust.indecency.org (99-205-62-57.pools.spcsdns.net [99.205.62.57]) by m1.imap-partners.net (MOS 4.1.7-GA) with ESMTP id AUV86739 (AUTH admin@network-heretics.com); Thu, 1 Oct 2009 16:13:00 -0700 Message-ID: <4AC5370C.20805@network-heretics.com> Date: Thu, 01 Oct 2009 19:11:08 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Andrew Sullivan References: <20091001222828.GQ7059@shinkuro.com> In-Reply-To: <20091001222828.GQ7059@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: grobj@ietf.org Subject: Re: [grobj] Initial and preliminary comment on draft-carpenter-behave-referral-object-00 X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 23:09:49 -0000 Andrew Sullivan wrote: > Dear colleagues, > > I have only just started to read > draft-carpenter-behave-referral-object-00, but I am having a bit of a > difficult time with the motivation for this work. In particular, the > following paragraph seems a little odd to me. I quote at length, but > insert some numbers to identify some important conditions called out > here. > > In some cases, this problem may be readily solved by passing a Fully > Qualified Domain Name (FQDN) instead of an address. Indeed, that is > an architecturally preferred solution [RFC1958]. However, it is not > sufficient in many cases of dynamic referrals. Experience shows that > an application cannot use a domain name in order to reliably find the > address(es) of an arbitrary peer. Domain names work fairly well to > find the addresses of servers, as in web servers or SMTP servers, > because operators of public servers take pains to make sure that > their domain names work. But DNS records [1] are not as reliably > maintained for arbitrary hosts such as might need to be contacted in > peer-to-peer applications. [2] Many small networks do not even maintain > DNS entries for their hosts, and for some networks that do list local > hosts in DNS, [3] the listings may well be unusable from a remote > location (say because of two-faced DNS, or because the A record > contains a private address). Furthermore, an FQDN may not be > sufficient to establish successful communications involving > heterogeneous peers (i.e. IPv4 and IPv6) since [4] A and AAAA records > may not be correctly provisioned. > > What that paragraph says, in effect, is that domain names don't work > (1) when people don't maintain their DNS entries, (2) when people > don't maintain their DNS entries, (3) when people maintain the DNS > incorrectly, or (4) when people maintain the DNS or network > infrastructure incorrectly. > > I'm having a very hard time seeing why we want to come up with another > way to solve these problems. If the problem is a simple operational > one -- people are making mistakes because their tools suck -- then I > think we obviously need to work on the operational support. But if > the problem is just that people don't look after their networks (and I > suggest that is indeed a significant part of the problem), then surely > any new mechanism is going to face exactly the same problem, no? No. The fundamental problems with DNS exist mostly because the original (perhaps unstated) assumptions behind DNS no longer apply. For example: - Unlike in late ARPAnet/early Internet days, today's network operators don't always want to disclose information about their hosts' names or addresses (to say nothing about other DNS RRs) to the entire Internet or even to the set of peers with which their hosts are expected to communicate. two-faced DNS is common. - Networks are now often far larger (in number of hosts, administrative scope, geographical scope) than in those days. The situation that the DNS administrator is out of touch with the applications user or administrator, and as a result, that the DNS is out of sync with reality, is now quite common. - It is no longer the usual case that that vast majority of hosts exist in fixed locations on the network; DNS was never designed to accommodate mobile or peripatetic (relative to the network's addressing) hosts. - It is no longer reasonable to assume that a fixed-location host has a fixed address, or even a stable address. - From the application programmer's POV, it is no longer reasonable to assume that an address for host H which allows a peer to reach that host in one location, also works from a different location - even if H is reachable from the second location. - DNS has never been satisfactorily adapted to isolated, transiently-connected, or ad hoc networks. (yes, I know about LLMNR, and no, it doesn't solve the problem - it merely creates a completely and confusing different naming service that works in a different set of circumstances from DNS, but doesn't work seamlessly with it.) - It is no longer reasonable to assume that all addresses associated with a DNS name are bound to a single host. One result is that the DNS name might suffice for an initial connection, but a specific address is needed to rebind to the same peer, say, to recover from a broken connection. - It is no longer reasonable to assume that a DNS query will return all usable addresses for a host, and that "best effort" consists of trying each address in sequence. > Furthermore, badly run networks with 3 layers of NAT intended to > "provide security" are indeed hard to talk into, and the people who > are breaking things that way are breaking them _on purpose_, so those > people aren't going to be keen on "fixing" this problem either. Not at all clear. One of the many problems with NATs is that their users and network administrators often aren't aware of their implications for application interoperability, and applications are expected to work across NATs. NATs have been sold as "magic security pixie dust" which users and many network admins think will give them security without impairing anything that's "supposed" to work. It's not reasonable to assume that the presence of a NAT in a signal path says anything about intent or policy. > Moreover, the plentiful attempts to fix the problem, listed in the > appendix, seem partly to confirm my view: many of them are desperate > hacks that people are doing to get around badly broken networks. I am > having a hard time believing that we're going to make the world better > by generalizing the hacks sufficiently to call them a protocol. Yes, it's ugly. But the approaches to actually "make the world better" seem to be progressing very slowly, and frankly I don't know of a unified approach that gets us back to anything resembling global addressing and universal connectivity (modulo explicit policy). Meanwhile people need a way to get work done, and they are developing ad-hoc and vendor-proprietary solutions. Particularly for cross-application interaction, it would be nice to have a standard or at least a well-known way of solving this problem. Keith From brian.e.carpenter@gmail.com Thu Oct 1 17:56:01 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 698E83A6837 for ; Thu, 1 Oct 2009 17:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 rCIj5PP-Hc11 for ; Thu, 1 Oct 2009 17:56:00 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id 1DEB53A683B for ; Thu, 1 Oct 2009 17:56:00 -0700 (PDT) Received: by pzk35 with SMTP id 35so1001528pzk.29 for ; Thu, 01 Oct 2009 17:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=PLdFRExXPqXJa53qnYhkoI9dO1QrB9Gmxj/Bf5nif04=; b=bp2LVk2rKEVjp6Bu09j9ZC2bqgeI/4lDloIC+nMIDgxxltzViK+G1TJTPUsGs5ztIC qPD2/Vh9uGyPO6Uejhg/cJkcsfMC8EJV7uKJP+vaOAHGkoN+r8aQFPrceKqt0lIWtAZ+ QU2tmZw1AXFGnTjSIA9iwd2wbxK3wimtcRizQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=amv9NPOQb4XAUvwXuXBWQzCX40wFFONvCmoHGQqBdV5T72XpAnO0Yt8Qm5y9rFUlj/ 3R9i4iq1mXoQBXtW2JzTacIln1MnJLIZPWEexgM75gifaXQ0WnIwdY0xnJJHsbm6SXfa WRWUVHebCs554YbcN8fy85mewRcNyGtLmFIGE= Received: by 10.114.162.20 with SMTP id k20mr623100wae.135.1254445044007; Thu, 01 Oct 2009 17:57:24 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 20sm202018pxi.12.2009.10.01.17.57.22 (version=SSLv3 cipher=RC4-MD5); Thu, 01 Oct 2009 17:57:23 -0700 (PDT) Message-ID: <4AC54FED.4050206@gmail.com> Date: Fri, 02 Oct 2009 13:57:17 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Keith Moore References: <20091001222828.GQ7059@shinkuro.com> <4AC5370C.20805@network-heretics.com> In-Reply-To: <4AC5370C.20805@network-heretics.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: grobj@ietf.org Subject: Re: [grobj] Initial and preliminary comment on draft-carpenter-behave-referral-object-00 X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 00:56:01 -0000 To Andrew's point (and agreeing with what Keith wrote), 1. I hear you say that the text isn't convincing enough, and the next version will try to make the case better. 2. As an example, I spent ten years working inside a two-faced DNS and firewall boundary, which was also NATted during the second half of the time. I assure you that trying to reach w3.example.com would fail when roaming outside the company, even if you happened to have cached the A record, and even though the cached IP address was part of an IANA- allocated Class A. Also, if you hadn't cached the A record, you would get NXDOMAIN outside the company due to the two-faced DNS. Neither the address nor the DNS name could serve as a useful referral in that case. The idea of a generic referral object is to have at least a syntax and partial semantics for this sort of situation. (Please don't forget, I've been concerned about loss of transparency since RFC2775, but wringing our hands is not enough. Address and name scope boundaries are a fact of life.) Brian From mohamed.boucadair@orange-ftgroup.com Thu Oct 1 23:35:38 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0823A68DA for ; Thu, 1 Oct 2009 23:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BANG_GUAR=0.939, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 s8MD5tO00Rbg for ; Thu, 1 Oct 2009 23:35:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id C7F733A67F4 for ; Thu, 1 Oct 2009 23:35:36 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id EE3A9374465; Fri, 2 Oct 2009 08:37:02 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id C584B158061; Fri, 2 Oct 2009 08:37:02 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 2 Oct 2009 08:37:02 +0200 From: To: Andrew Sullivan Date: Fri, 2 Oct 2009 08:37:01 +0200 Thread-Topic: [grobj] Initial and preliminary comment on draft-carpenter-behave-referral-object-00 Thread-Index: AcpC7HzJnydSzf5BTf+aI3VR4aS9wgAPUWQA Message-ID: <5127_1254465422_4AC59F8E_5127_24542_1_94C682931C08B048B7A8645303FDC9F307815B45A8@PUEXCB1B.nanterre.francetelecom.fr> References: <20091001222828.GQ7059@shinkuro.com> <4AC5370C.20805@network-heretics.com> In-Reply-To: <4AC5370C.20805@network-heretics.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.10.2.52120 Cc: "grobj@ietf.org" Subject: Re: [grobj] Initial and preliminary comment on draft-carpenter-behave-referral-object-00 X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 06:35:38 -0000 Hi all, I fully agree with Keith and also with operational issues which even aggrav= ates the problem as listed by Andrew.=20 Having a FQDN does not mean that you will succeed to establish a communicat= ion. Particularly, Hosts are identified with a set of locators, these locat= ors may be volatile and their scope limited. Having a means to discover/adv= ertise these locators with more information about their validity would incr= ease the chance to establish a communication, but... without any guarantee! Cheers, Med =20 -----Message d'origine----- De : grobj-bounces@ietf.org [mailto:grobj-bounces@ietf.org] De la part de K= eith Moore Envoy=E9 : vendredi 2 octobre 2009 01:11 =C0 : Andrew Sullivan Cc : grobj@ietf.org Objet : Re: [grobj] Initial and preliminary comment on draft-carpenter-beha= ve-referral-object-00 Andrew Sullivan wrote: > Dear colleagues, > > I have only just started to read > draft-carpenter-behave-referral-object-00, but I am having a bit of a=20 > difficult time with the motivation for this work. In particular, the=20 > following paragraph seems a little odd to me. I quote at length, but=20 > insert some numbers to identify some important conditions called out=20 > here. > > In some cases, this problem may be readily solved by passing a Fully > Qualified Domain Name (FQDN) instead of an address. Indeed, that is > an architecturally preferred solution [RFC1958]. However, it is not > sufficient in many cases of dynamic referrals. Experience shows that > an application cannot use a domain name in order to reliably find the > address(es) of an arbitrary peer. Domain names work fairly well to > find the addresses of servers, as in web servers or SMTP servers, > because operators of public servers take pains to make sure that > their domain names work. But DNS records [1] are not as reliably > maintained for arbitrary hosts such as might need to be contacted in > peer-to-peer applications. [2] Many small networks do not even mainta= in > DNS entries for their hosts, and for some networks that do list local > hosts in DNS, [3] the listings may well be unusable from a remote > location (say because of two-faced DNS, or because the A record > contains a private address). Furthermore, an FQDN may not be > sufficient to establish successful communications involving > heterogeneous peers (i.e. IPv4 and IPv6) since [4] A and AAAA records > may not be correctly provisioned. > > What that paragraph says, in effect, is that domain names don't work > (1) when people don't maintain their DNS entries, (2) when people=20 > don't maintain their DNS entries, (3) when people maintain the DNS=20 > incorrectly, or (4) when people maintain the DNS or network=20 > infrastructure incorrectly. > > I'm having a very hard time seeing why we want to come up with another=20 > way to solve these problems. If the problem is a simple operational=20 > one -- people are making mistakes because their tools suck -- then I=20 > think we obviously need to work on the operational support. But if=20 > the problem is just that people don't look after their networks (and I=20 > suggest that is indeed a significant part of the problem), then surely=20 > any new mechanism is going to face exactly the same problem, no? No.=20 The fundamental problems with DNS exist mostly because the original (perhap= s unstated) assumptions behind DNS no longer apply. For example: - Unlike in late ARPAnet/early Internet days, today's network operators don= 't always want to disclose information about their hosts' names or addresse= s (to say nothing about other DNS RRs) to the entire Internet or even to th= e set of peers with which their hosts are expected to communicate. two-fac= ed DNS is common. - Networks are now often far larger (in number of hosts, administrative sco= pe, geographical scope) than in those days. The situation that the DNS adm= inistrator is out of touch with the applications user or administrator, and= as a result, that the DNS is out of sync with reality, is now quite common= .=20 - It is no longer the usual case that that vast majority of hosts exist in = fixed locations on the network; DNS was never designed to accommodate mobil= e or peripatetic (relative to the network's addressing) hosts. - It is no longer reasonable to assume that a fixed-location host has a fix= ed address, or even a stable address. - From the application programmer's POV, it is no longer reasonable to assu= me that an address for host H which allows a peer to reach that host in one= location, also works from a different location - even if H is reachable fr= om the second location. - DNS has never been satisfactorily adapted to isolated, transiently-connec= ted, or ad hoc networks. (yes, I know about LLMNR, and no, it doesn't solv= e the problem - it merely creates a completely and confusing different nami= ng service that works in a different set of circumstances from DNS, but doe= sn't work seamlessly with it.) - It is no longer reasonable to assume that all addresses associated with a= DNS name are bound to a single host. One result is that the DNS name migh= t suffice for an initial connection, but a specific address is needed to re= bind to the same peer, say, to recover from a broken connection. - It is no longer reasonable to assume that a DNS query will return all usa= ble addresses for a host, and that "best effort" consists of trying each ad= dress in sequence. > Furthermore, badly run networks with 3 layers of NAT intended to=20 > "provide security" are indeed hard to talk into, and the people who=20 > are breaking things that way are breaking them _on purpose_, so those=20 > people aren't going to be keen on "fixing" this problem either. Not at all clear. One of the many problems with NATs is that their users a= nd network administrators often aren't aware of their implications for appl= ication interoperability, and applications are expected to work across NATs. NATs have been sold as "magic security pixie dust" which users and many network admins think will give them securi= ty without impairing anything that's "supposed" to work. It's not reasonab= le to assume that the presence of a NAT in a signal path says anything abou= t intent or policy. > Moreover, the plentiful attempts to fix the problem, listed in the=20 > appendix, seem partly to confirm my view: many of them are desperate=20 > hacks that people are doing to get around badly broken networks. I am=20 > having a hard time believing that we're going to make the world better=20 > by generalizing the hacks sufficiently to call them a protocol. Yes, it's ugly. But the approaches to actually "make the world better" seem to be progressing very slowly, and frankly I don't know of a unified a= pproach that gets us back to anything resembling global addressing and univ= ersal connectivity (modulo explicit policy).=20=20 Meanwhile people need a way to get work done, and they are developing ad-ho= c and vendor-proprietary solutions. Particularly for cross-application int= eraction, it would be nice to have a standard or at least a well-known way = of solving this problem. Keith _______________________________________________ grobj mailing list grobj@ietf.org https://www.ietf.org/mailman/listinfo/grobj ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From ajs@shinkuro.com Fri Oct 2 09:06:36 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6BD828C0E9 for ; Fri, 2 Oct 2009 09:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.508, 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 BrTsi9nN7EfO for ; Fri, 2 Oct 2009 09:06:35 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 60D953A6977 for ; Fri, 2 Oct 2009 09:06:35 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4600E2FE8CE3 for ; Fri, 2 Oct 2009 16:08:02 +0000 (UTC) Date: Fri, 2 Oct 2009 12:07:59 -0400 From: Andrew Sullivan To: grobj@ietf.org Message-ID: <20091002160756.GJ9699@shinkuro.com> References: <20091001222828.GQ7059@shinkuro.com> <4AC5370C.20805@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AC5370C.20805@network-heretics.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [grobj] Initial and preliminary comment on draft-carpenter-behave-referral-object-00 X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 16:06:36 -0000 Dear colleagues, I expect I wasn't clear enough in my note. I am not trying to argue that the DNS is the One True Answer to any of this (or, indeed, anything else). But I think that the motivation needs to explain why this effort is going to succeed where existing capabilities have been foiled on purpose. Further discussion below. On Thu, Oct 01, 2009 at 07:11:08PM -0400, Keith Moore wrote: > The fundamental problems with DNS exist mostly because the original > (perhaps unstated) assumptions behind DNS no longer apply. For example: > > - Unlike in late ARPAnet/early Internet days, today's network operators > don't always want to disclose information about their hosts' names or > addresses (to say nothing about other DNS RRs) to the entire Internet or > even to the set of peers with which their hosts are expected to > communicate. two-faced DNS is common. That's just what I numbered (1) or (2): people don't maintain their DNS entries. They happen not to do it on purpose: they're trying to achieve security by obscurity, wanting not to allow "outside" requests to "internal hosts". Why is this new effort going to succeed in that task where the available mechanisms have been broken on purpose? > - Networks are now often far larger (in number of hosts, administrative > scope, geographical scope) than in those days. The situation that the > DNS administrator is out of touch with the applications user or > administrator, and as a result, that the DNS is out of sync with > reality, is now quite common. In the presence of DNS Update, it is not plain to me that the DNS administrator actually needs to know about all this stuff. Why aren't people using those features? To the extent the answer is, "They think it won't work," what is different about this effort that will result in succees? (Is it just that the intermediation of a zone _at all_ is removed? If so, that's a compelling motivation to take on the work, I think, and could usefully be called out in the draft.) > - It is no longer the usual case that that vast majority of hosts exist > in fixed locations on the network; DNS was never designed to accommodate > mobile or peripatetic (relative to the network's addressing) hosts. > - It is no longer reasonable to assume that a fixed-location host has a > fixed address, or even a stable address. See above re: Dynamic Update. Dynamic update works so well, in fact, that we now have a problem in that Windows machines blast the entire world with their data when they get certain IP addresses. We surely do need to do something about some of this, but we actually solved the problem one time, and people didn't use it (and some people implemented it badly). So I again wonder why this effort is likely to solve the problem that already once did not get solved by a previous effort. > - From the application programmer's POV, it is no longer reasonable to > assume that an address for host H which allows a peer to reach that host > in one location, also works from a different location - even if H is > reachable from the second location. Why wouldn't the application do another DNS lookup? > - DNS has never been satisfactorily adapted to isolated, > transiently-connected, or ad hoc networks. (yes, I know about LLMNR, > and no, it doesn't solve the problem - it merely creates a completely > and confusing different naming service that works in a different set of > circumstances from DNS, but doesn't work seamlessly with it.) This is a good point, and could be added to the motivation to make it more compelling. > - It is no longer reasonable to assume that all addresses associated > with a DNS name are bound to a single host. One result is that the DNS > name might suffice for an initial connection, but a specific address is > needed to rebind to the same peer, say, to recover from a broken connection. > - It is no longer reasonable to assume that a DNS query will return all > usable addresses for a host, and that "best effort" consists of trying > each address in sequence. These both sound to me like operational considerations for how one ought to register one's address(es) in the DNS, and not something that needs a new protocol per se. Your argument seems to depend on the premise, "All this other sludge is in there, so we need a protocol to work around it." I grant that sometimes one wants a new protocol to cope with the sludge, but in the absence of a compelling reason why this will also not just be more sludge, I feel a little wary of it > Not at all clear. One of the many problems with NATs is that their > users and network administrators often aren't aware of their > implications for application interoperability, and applications are > expected to work across NATs. NATs have been sold as "magic security > pixie dust" which users and many network admins think will give them > security without impairing anything that's "supposed" to work. It's not > reasonable to assume that the presence of a NAT in a signal path says > anything about intent or policy. That argument also seems very strange to me. I read you as saying, "People have all these wrong ideas about how their networks work, and they don't work that way." But your proposed solution for that problem is not, "Explain why this is broken and how none of it achieves the result operators seem to want," but instead, "Standardize on how to kludge things up so that it'll mostly work." If the motivation for this work is to make endpoints accessible regardless of whether their networking environment is broken (whether that be on purpose to "add security" or just because of ignorance), then I think the motivation needs to call that out clearly, for I think that we ought to be up front when we don't care about clean architecture, &c. > Yes, it's ugly. But the approaches to actually "make the world better" > seem to be progressing very slowly, and frankly I don't know of a > unified approach that gets us back to anything resembling global > addressing and universal connectivity (modulo explicit policy). This puts into sharp relief one of the issues I'm trying to raise: the goal of this work is a unified approach to global addressing and universal connectivity, but I think that some people _don't want_ such global addressing and universal connectivity, and are breaking things on purpose to that end. I can't tell whether this work is intended to foil those who are breaking things on purpose, or whether we plan a mechanism to make sure that on-purpose-broken remains broken. In the current draft, there's no mention of this issue in the Security Considerations. The other interpretation I can give to the draft is that on its own a GRO definition is not enough: you need a "GRO profile" or something like that for any application wanting a GRO. If that's the goal, it wasn't clear to me from the draft. Best regards, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ajs@shinkuro.com Fri Oct 2 09:15:00 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2A63A691F for ; Fri, 2 Oct 2009 09:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=0.471, 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 j6WoOwSkloHd for ; Fri, 2 Oct 2009 09:14:59 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id DD21D28C129 for ; Fri, 2 Oct 2009 09:13:50 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7F2282FE8CA1 for ; Fri, 2 Oct 2009 16:15:18 +0000 (UTC) Date: Fri, 2 Oct 2009 12:15:16 -0400 From: Andrew Sullivan To: grobj@ietf.org Message-ID: <20091002161516.GK9699@shinkuro.com> References: <20091001222828.GQ7059@shinkuro.com> <4AC5370C.20805@network-heretics.com> <4AC54FED.4050206@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AC54FED.4050206@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [grobj] Initial and preliminary comment on draft-carpenter-behave-referral-object-00 X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 16:15:00 -0000 On Fri, Oct 02, 2009 at 01:57:17PM +1300, Brian E Carpenter wrote: > get NXDOMAIN outside the company due to the two-faced DNS. Neither the > address nor the DNS name could serve as a useful referral in that case. > The idea of a generic referral object is to have at least a syntax and > partial semantics for this sort of situation. Yep, I've been there too. Was this arranged this way on purpose? Did the network administrators set it up like you describe as a "security measure", even though it provided no security and harmed legitimate work? (I'm taking it as a given that such policies get implemented all the time.) Because if so, the first thing that such policy-makers will want to do is figure out how to block these GROs. It seems to me that network security admins and Skype have, on various occasions, been in something of an arms race on this front in the past (I can't tell how things stand right now, though I note that I have been in networks where even Skype, for all its traversal skill, fails). A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From brian.e.carpenter@gmail.com Fri Oct 2 12:25:16 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E61773A685F for ; Fri, 2 Oct 2009 12:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 FFawt+ZPJ6Cb for ; Fri, 2 Oct 2009 12:25:16 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 283543A6842 for ; Fri, 2 Oct 2009 12:25:15 -0700 (PDT) Received: by pxi6 with SMTP id 6so1558226pxi.32 for ; Fri, 02 Oct 2009 12:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=k2MOgMI3vTcz00UvNwsaWmB/iBvbkT5v+Uid9mcZsrA=; b=FindwLzum+aC+RzytdknJ8GDNUC7CB1CrWsZJpVQ1mGo/2pFLfv1i/y7Se9vXc22rs NDCKlDeJ1pQMDE/v4s1TiMKZoHY645A4ayucuf5DDNVh4S2O6Dt3mU4WBRGzvcv1zZvd XSXR2gtDiM+FzvH6UzJcnB/pf6bfOYmh/BlzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=ji0/iOgbv3DWxTUStkilHpL/74bWBjH27E/meTdAMHlrkgxPzwu7f5fFmRIkSKNY76 zomAKq/bVKEBRs4xb3sQIyS+MZabLPfeGhqbrMxTKEUAjpYi8Yth3yo2fimeWc4EI4BT 5HaQ1OzH39pUUvqedLe4z2YH9UJZSQx6wMgHA= Received: by 10.115.101.18 with SMTP id d18mr1695265wam.191.1254511601847; Fri, 02 Oct 2009 12:26:41 -0700 (PDT) Received: from ?10.1.1.4? (118-93-29-153.dsl.dyn.ihug.co.nz [118.93.29.153]) by mx.google.com with ESMTPS id 21sm819611pzk.3.2009.10.02.12.26.39 (version=SSLv3 cipher=RC4-MD5); Fri, 02 Oct 2009 12:26:41 -0700 (PDT) Message-ID: <4AC653E9.9010904@gmail.com> Date: Sat, 03 Oct 2009 08:26:33 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew Sullivan References: <20091001222828.GQ7059@shinkuro.com> <4AC5370C.20805@network-heretics.com> <4AC54FED.4050206@gmail.com> <20091002161516.GK9699@shinkuro.com> In-Reply-To: <20091002161516.GK9699@shinkuro.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: grobj@ietf.org Subject: Re: [grobj] Initial and preliminary comment on draft-carpenter-behave-referral-object-00 X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 19:25:17 -0000 Andrew, This and the related point you made in part of your reply to Keith is a very good one. If you're arguing that a lot of "security" as deployed is roughly equivalent to erecting gates across interstate highways to protect banks from bankrobbers, you won't get any disagreement from me. I don't think the GROs will help to bypass such gates. They might at least make it possible to diagnose the problem, as in "Your phone call cannot be connected because of a firewall at XXX corporation." I agree that this issue needs to be discussed. Thanks Brian On 2009-10-03 05:15, Andrew Sullivan wrote: > On Fri, Oct 02, 2009 at 01:57:17PM +1300, Brian E Carpenter wrote: > >> get NXDOMAIN outside the company due to the two-faced DNS. Neither the >> address nor the DNS name could serve as a useful referral in that case. >> The idea of a generic referral object is to have at least a syntax and >> partial semantics for this sort of situation. > > Yep, I've been there too. Was this arranged this way on purpose? Did > the network administrators set it up like you describe as a "security > measure", even though it provided no security and harmed legitimate > work? (I'm taking it as a given that such policies get implemented > all the time.) Because if so, the first thing that such policy-makers > will want to do is figure out how to block these GROs. It seems to me > that network security admins and Skype have, on various occasions, > been in something of an arms race on this front in the past (I can't > tell how things stand right now, though I note that I have been in > networks where even Skype, for all its traversal skill, fails). > > A > From brian.e.carpenter@gmail.com Mon Oct 19 15:11:36 2009 Return-Path: X-Original-To: grobj@core3.amsl.com Delivered-To: grobj@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E2C3A6914 for ; Mon, 19 Oct 2009 15:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 M15uqkjasiy6 for ; Mon, 19 Oct 2009 15:11:35 -0700 (PDT) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 5DDE03A690E for ; Mon, 19 Oct 2009 15:11:32 -0700 (PDT) Received: by pzk6 with SMTP id 6so6749712pzk.29 for ; Mon, 19 Oct 2009 15:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=8gGaIvwa8+z+6gs5KbGM1JCGHH7siZtSpilRBbUqOEA=; b=lihy8h9oIrqL3NzuHBENH5VVHQ6e5VZNOt/C0nGZnyD4VVFk9OoAwaN3z3NvgixUtd wUzJMM5sDUFqTivrNmOiiHka9kHYaOYp2OzSVNGl+1CYCI0fkJXZ4LvFqSyAeOSEFnw9 A8OhBLavk3tBa8KTiMKIHkF4HZ1MoKOpx9jG4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; b=cGRKDUjb6zU9J/I8nFIE/eudrrNVneSamU7uX2frNe7LZWQJ5Y+XsNcqgkzc34/uGP FDhg5sCa4TB3jh+ytrLQGdM4gZfDJ0timjS5OD68RGYJqHEOkOSFveSnzROrPGxqahG4 9SZJBmw1JvTqA2ZlO0bSuhFCZhImTR9CvidW0= Received: by 10.115.133.39 with SMTP id k39mr7416086wan.94.1255990297172; Mon, 19 Oct 2009 15:11:37 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 22sm254884pzk.6.2009.10.19.15.11.36 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Oct 2009 15:11:36 -0700 (PDT) Message-ID: <4ADCE416.90101@gmail.com> Date: Tue, 20 Oct 2009 11:11:34 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: grobj@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [grobj] [Fwd: I-D Action:draft-carpenter-behave-referral-object-01.txt] X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 22:11:36 -0000 -------- Original Message -------- Subject: I-D Action:draft-carpenter-behave-referral-object-01.txt Date: Mon, 19 Oct 2009 14:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Generic Referral Object for Internet Entities Author(s) : B. Carpenter, et al. Filename : draft-carpenter-behave-referral-object-01.txt Pages : 23 Date : 2009-10-19 The purpose of a referral is to enable a given entity in a multiparty application to pass information to another party. This memo specifies a Generic Referral Object (GRO) to be used in the context of referrals. The proposed object is compact and is application- independent. Both IPv4 and IPv6 schemes are supported, as well as upper layer identifiers. Additional information to characterise an enclosed reference is also described. To allow proper interpretation of referrals, a new notion of scope identifiers is introduced. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-behave-referral-object-01.txt