Subject: [grobj] Initial and preliminary comment on draft-carpenter-behave-referral-object-00

From: Andrew Sullivan <[email-masked]>
Date: Thu, 1 Oct 2009 18:28:28 -0400

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
[email-masked]
Shinkuro, Inc.

---

From: Keith Moore <[email-masked]>
Date: Thu, 01 Oct 2009 19:11:08 -0400

> 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.

> 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.
> 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 <[email-masked]>
Date: Fri, 02 Oct 2009 13:57:17 +1300

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: <[email-masked]>
Date: Fri, 2 Oct 2009 08:37:01 +0200

Hi all,

I fully agree with Keith and also with operational issues which even aggravates the problem as listed by Andrew. 

Having a FQDN does not mean that you will succeed to establish a communication. Particularly, Hosts are identified with a set of locators, these locators may be volatile and their scope limited. Having a means to discover/advertise these locators with more information about their validity would increase the chance to establish a communication, but... without any guarantee!

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Keith Moore
Envoyé : vendredi 2 octobre 2009 01:11
À : Andrew Sullivan
Cc : [email-masked]
Objet : Re: [grobj] Initial and preliminary comment on draft-carpenter-behave-referral-object-00

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.

> 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.
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

_______________________________________________
grobj mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/grobj

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 2 Oct 2009 12:07:59 -0400

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.

> 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?
 
> 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.)

> 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.
  
> reachable from the second location.

Why wouldn't the application do another DNS lookup?
 
> 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.

> 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
 
> 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.

> 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
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 2 Oct 2009 12:15:16 -0400

> 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
[email-masked]
Shinkuro, Inc.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 03 Oct 2009 08:26:33 +1300

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