Subject: Re: [e2md] [DNSOP] charter discussion kick-off (fwd)

From: Alfred Hönes <[email-masked]>
Date: Wed, 24 Feb 2010 18:09:45 +0100 (MEZ)

Bernie,
thanks for the heads-up on DNSOP.

As you know, I already had reviewed (at least once) all the drafts
listed on the draft E2MD charter, most recently the -01 version
of your e164-to-metadata draft.

The idea to split off properly unrelated stuff from ENUM makes
much sense, from a DNS perspective as well, but it should perhaps
be followed one step farther than your draft proposal would take us:
The utility of NAPTR RRs suffers from the existence of an 'internal'
selector (the service field), so they cannot be selected specifically
by a DNS query -- unless the owner names are different (cf. RFC 5507).
This has unfortunate consequences on the DNS response message size
with all the consequences currently discussed in DNSEXT and elsewhere
(due to similar pressure on response message size arising from
increasing deployment of DNSSEC).
Of course, this feature of NAPTR RRs has benefits as well -- it
allows the client to obtain with one query "all that's out there",
and make the local selection of the entries best matching its local
requirements afterwards (and then try differents paths of service
location and access until success).
However, the general purpose of the lookup should remain confined
for not running too rapidly into DNS response truncation or IP
fragmentation issues, and so the splitoff of E2MD from ENUM makes
perfect sense from the DNS operational perspective.
The proposal creates a new DDDS application, and it seems good practice
to separate the DNS namespaces of different DDDS applications.
Therefore, it should be seriously considered to define a naming
convention for E2MD records that keeps ENUM and E2MD NAPTR RRs
in different RRsets.  One possibility to do that would be to
prefix the 'canonical' ENUM owner names with a specific
'undersore label' (for instance, "_E2MD"); other possibilities
to 'splice' the DNS naming tree higher up in the tree seem
inappropriate due to subdomain delegation and management concerns.

Only clients specifically interested in E2MD NAPTRs would thus look
them up and get them; if necessary, E2MD and ENUM NAPTRs could be
looked up concurrently, thus giving comparable response performance
as in a the combined case (unless the aforementioned size
limitations start to hit).

The general text of the draft charter seems reasonable, but it
might make sense to add a short note indicating the DNS protocol
considerations (as sketched above) and tasking the WG specifically
to take these into account.

A few nits:

- "Proposal", 4th para:
  s/reuse a much as possible/reuse as much as possible/
          ^                        ^^
- "Goals and Milestones": "submit" is ambiguous; you might better
  use "Submit to the IESG" or "Request publication of".

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: [email-masked]
Date: Thu, 25 Feb 2010 08:31:05 +0000

> limitations start to hit).

There are also good reasons _not_ to do this.

With my Send-N draft, for example, it's specifically intended that those 
results be returned _instead_ of normal E2U records when querying for 
nodes that are not leaf nodes.  The whole point with Send-N is that the 
client has no prior knowledge of which to expect[*] and the results of 
Send-N give a hint to the client of how many more digits must be dialled 
before leaf nodes might be found.

Ray

[*] technically these would be two separate DDDS applications, so the 
actual DDDS algorithm should be run twice, but ideally the DNS only 
queried once.

---

From: Alfred Hönes <[email-masked]>
Date: Thu, 25 Feb 2010 14:38:16 +0100 (MEZ)

> before leaf nodes might be found.

Agreed, that's another argument.

Upon solicitation, I gave a DNS perspective, and I did not say
that those argument should win; I said they (and RFC 5507) need to
be _considered_ seriously, and having that layer-8 requirement in

> actual DDDS algorithm should be run twice, but ideally the DNS only

(Local DNS caching actually should do the former job for you.)

Kind regards,
  Alfred.

---

From: [email-masked]
Date: Thu, 25 Feb 2010 15:37:31 +0100 (CET)

Hi Alfred

Thanks for your thoughts on this.

As you might remember, the DNS packet size limitation issue was being 
discussed earlier in ENUM. There was a heavy debate on whether or not 
EDNS0 should be compulsary for DNS servers running ENUM. AFAICR there was 
no consensus to make this a requirement. That might be seen differently 
nowadays. As you know there is a similar debate now in DNSEXT in the 
context of DNSsec: Mandating TCP with EDNS0 and friends...

I am not sure whether this issue should be solved on application layer. 
I am actually hoping (rather sooner than later) the DNS can cope with 
this problem (at the source of it)... [ I vote for SCTP... :-) ]

However, we could add a such requirement to the E2MD charter.
How about something along the lines of:

   "Limitations of the DNS (e.g. packet size) are to be considered while
    defining the protocol."

cheers,
  Bernie

On Wed, 24 Feb 2010, Alfred H?nes wrote:

>  Alfred H?nes.
> _______________________________________________
> e2md mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/e2md

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 25 Feb 2010 17:52:24 +0000

Hi Bernie, Alfred, folks,

Strictly, we DID work on the EDN0-unaware size limitations.
Jim Reid and I produced a Draft back in 2006 -- Alfred mailed
me in 2007 on this to suggest that fragment support could be
an issue :).
AFAICT, we were told by our AD that this is a general issue,
so it would await a DNSEXT or DNSOP draft; fair enough.

This is always going to be tricky, but maybe we could list
the assumptions we make on typical RRSet sizes? Anything more
may well be a waste.

There were versions of "the Experiences draft" (a.k.a. RFC 5483)
that had such values, and "Experiences" DID include the "SHOULD
support EDNS0" text at one point. These were removed later on in
the process -- in favour first of a separate doc, and then it was
stopped, as DNSEXT was going to produce the definitive doc.

It's not just EDNS0, of course; people are free to provision RRSets
that will go over typically advertised ENDS0 buffer sizes, so TCP
is normally a MUST. I note that nampedroppers has been active there
as well :).

all the best,
  Lawrence

On 25 Feb 2010, at 14:37, [email-masked] wrote:
> As you might remember, the DNS packet size limitation issue was being discussed earlier in ENUM. There was a heavy debate on whether or not EDNS0 should be compulsary for DNS servers running ENUM. AFAICR there was no consensus to make this a requirement. That might be seen differently nowadays. As you know there is a similar debate now in DNSEXT in the context of DNSsec: Mandating TCP with EDNS0 and friends...
> 
> I am not sure whether this issue should be solved on application layer. I am actually hoping (rather sooner than later) the DNS can cope with this problem (at the source of it)... [ I vote for SCTP... :-) ]
>

---

From: Alfred Hönes <[email-masked]>
Date: Thu, 25 Feb 2010 23:00:48 +0100 (MEZ)

> context of DNSsec: Mandating TCP with EDNS0 and friends...

Indeed.

> this problem (at the source of it)... [ I vote for SCTP... :-) ]

Hmmm.  Voting doesn't help much.  :-)

The main problem is not the DNS protocols itself.  The maximum DNS
packet size is 64k.  It's the BSD-{adam&eve}.0 motivated restriction
on 512-octet UDP payloads built upon the tiny IPv4 minimum link MTU
that unfortunately has not been overcome in the DNS-over-IPv6 specs,
for the sake of seemless switching between v4 and v6 transport.

One of the biggest problem is the lack of transparency in practice.
Middleboxes and firewalls block ICMP (making rapid Path MTU discovery
impossible) and IP fragments (making full use of EDNS0 troublesome
or impossible); home gateways with nonsensically poor "DNS Proxies"
(see RFC 5625) prohibit making proper use of EDNS0 and DNS over TCP.
I know, there are many substantial security considerations as well.

Given the barriers to actual use of decade-old protocols it is very
likely that a switch to SCTP would encounter even worse obstacles.
But it should also be noted that SCTP is not a panacea; even strong
stakeholders of SCTP admit that the burden in RTTs (delay) and server
load would not be much different from TCP; yet SCTP deployment lurks
and NAT support for SCTP is is its infancy.
TCP (and perhaps SCTP) would best be used with long-lived, persistent
connections that amortize the connection setup/teardown penalty over
many transactions, but the current practice of rather flat hierarchies
and huge 'fan-out' in DNS implementation and use make it difficult to
achieve that.

DNSEXT now has chartered work items for DNS transport, but trouble
in related WGs makes cooperation difficult.  Transport folks seem to
prefer the PoV of "We provide a service that shall survive under all
circumstances, and this comes with drawbacks for user.  Applications
must decide how they make best use of the service."
Existing legacy APIs also to some degree contribute to inefficient
use, which makes it difficult for DNS software (traditionally not
developed by OS vendors) to make better use of the transport.
The application from the transport PoV is the DNS.  Thus the
engineering problems need to be solved at the DNS level, indeed.

a)  The draft that reinforces that that the requirement for the
    implementation of DNS over TCP is in WGLC.
    (STD 13 and STD 3 hat spelled that out in pre-RFC2119 language,
    and implementers seing lowercase 'should' and 'must' did not
    recognize the age of these RFCs and did not follow the spirit
    of the words there.)

b)  A document on TCP tuning and best implementation practices
    has been conceived and will likely emerge as a BCP.

c)  There are proposals for new transports; at least one brought
    to DNSEXT recently, others being developed outside the IETF
    currently.  Since the development of a sound standard in this
    area will take time (much time!), and deployment in any case
    will be slow and not universal, this is not a short-term
    perspective for any 'new' application of the DNS.
    Transition and gracefull fallback strategies will be serious
    issues, and users suffering of related delays (due to timeouts)
    will further cause disincentives for deployment.
    DNSEXT is chartered to take on such work, on the longer term.

Long elaborations, short conclusion ...

>    "Limitations of the DNS (e.g. packet size) are to be considered while

May I suggest:

  "Limitations of deployed DNS transport (e.g. packet size restrictions)
   are to be considered while defining the protocol."

Kind regards,
  Alfred.

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 25 Feb 2010 22:25:51 +0000

Hi Alfred, Bernie, folks,

 As usual, Alfred's suggestions are good ones.
+1

... with the slight clarification that this statement should encourage folk NOT to generate long/verbose strings, rather than to state that if something can't fit in 512 bytes, then it MUST NOT be done.

In passing, ISTR that the then TSV ADs jointly ran the BOF for what would become SCTP. It was intended originally to be something "between" TCP and UDP (at least, that's what I recall Scott Bradner saying at the time).
IMHO, SCTP has the major *benefit* that it is unknown to Firewall/Home Gateways, so they don't think they know about it, and so don't try to proxy//break it :).

atb,  Lawrence

---

From: Jim Reid <[email-masked]>
Date: Fri, 26 Feb 2010 10:15:08 +0000

On 25 Feb 2010, at 22:25, Lawrence Conroy wrote:

> IMHO, SCTP has the major *benefit* that it is unknown to Firewall/ 
> Home Gateways, so they don't think they know about it, and so don't  
> try to proxy//break it :).

It would be most unwise to use this as a starting assumption. Or  
expect that situation never changes. If/when SCTP usage becomes  
significant, we can be sure that CPE vendors will update their  
firmware to make it do creative things to those packets. I would not  
be surprised too if lots of the installed base of these devices today  
simply drop SCTP traffic.

And as you know Lawrence, the idiocy of CPE vendors is something that  
has been making my life miserable recently.

---

From: [email-masked]
Date: Fri, 26 Feb 2010 10:22:21 +0000

> simply drop SCTP traffic.

Indeed, I'm sure many CPE devices simply don't know what to do with an IP 
packet that isn't UDP or TCP, and would drop it by default.

For a start, how do you NAT or firewall an SCTP flow if you don't know how 
to handle the protocol's innards.  I have seen firewalls that allow you to 
specify rules for "unknown" IP protocols, particularly to allow things 
like GRE tunnels.  However they tend to be "all or nothing" and wouldn't 
let you (for example) configure it to only allow through HTTP over SCTP, 
because they don't know about the contents of the SCTP header.

> has been making my life miserable recently.

Do please tell, if you're able :)

[this thread should of course migrate to HomeGate]

Ray

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 26 Feb 2010 11:24:14 +0100 (CET)

Hi Alfred

> Hmmm.  Voting doesn't help much.  :-)

I never claimed that voting helps, but it can contribute to the fun... ;-)

> The main problem is [...]

Thanks for your insight into the DNS transport problem space. It was very 
interesting. However, I won't comment it further on this mailing-list as 
that problem space is out-of-scope for e2md.

>    DNSEXT is chartered to take on such work, on the longer term.

Exactly as you say, DNSEXT is the venue for that discussion.

>   are to be considered while defining the protocol."

I tried to keep this requirement on high level, as opposed to your 
proposal, that gets rather specific. How about something as the following:

   "Limitations of the DNS are to be considered while defining the
   protocol; in particular packet size restrictions of deployed DNS
   transport."

cheers,
  Bernie

---

From: [email-masked]
Date: Fri, 26 Feb 2010 11:33:31 +0100 (CET)

Hi Lawrence

On Thu, 25 Feb 2010, Lawrence Conroy wrote:

> ... with the slight clarification that this statement should encourage 
> folk NOT to generate long/verbose strings, rather than to state that if 
> something can't fit in 512 bytes, then it MUST NOT be done.

I consider such an additon not suitable to be included to the charter. 
However, I am happy to discuss this later for inclusion into the base spec 
of e2md.

Does this work for you?

cheers,
  Bernie

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 26 Feb 2010 12:09:11 +0100 (MEZ)

Bernie,
thans again for your response.

> ...

Agreed.

>   Bernie

BR,
  Alfred.

P.S.:  Sorry for the long elaborations in this phase, for a short
       conclusion.  These can be re-visited when the topic is
       actually going to be discussed.

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 26 Feb 2010 12:18:20 +0000

Hi Bernie, Alfred, folks,
 Your formulation works for me.
The only concern I had was that some folks might get very "XML-like" and insist on verbose strings regardless of the transport -- as this is machine-processed anyway, that's pointless (IMHO).
Your phrase just gives guidance, and covers that concern.
Remember, it's not clear in which Area this would end up, and there are some spectacularly inefficient ways of sending very little useful information. Let's not do that :).

all the best,
  Lawrence