Subject: [dbound] Updated orgboundary draft

From: "John R Levine" <[email-masked]>
Date: 9 Nov 2015 18:43:58 +0900

I've updated my old orgboundary draft to address issues that showed up 
recently.  It's sort of like Casey's draft but it's much simpler, and 
every domain publishes its own info in its own namespace.

I added a flag so you can say no boundaries below this one, and it has a 
less kludgy way of allowing different applications to have different 
boundaries.

A boundary check will generally be one DNS lookup if a boundary does not 
permit lower level boundaries, or two if it does.  It uses DNS wildcards 
in a way that is fairly aggressive but as far as I can tell is 100% in 
compliance with the specs and will work on normal name servers.

https://tools.ietf.org/id/draft-levine-orgboundary-03.txt

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "John Levine" <[email-masked]>
Date: 12 Nov 2015 02:11:54 -0000

Not to toot my own horn or anything, but I really think this does most
of what people have said they want DBOUND to do, published in the DNS,
with each domain publishing its own info in the tree it controls, no
new TLDs or other administratively painful changes, provision for
different boundaries for different applications, and most checks in
one or two DNS queries regardless of how deep the name tree is.

What's not to like?

R's,
John

---

From: Casey Deccio <[email-masked]>
Date: Thu, 12 Nov 2015 11:41:19 -0500

Hi John,

> one or two DNS queries regardless of how deep the name tree is.

I've given the draft a detailed read.  In general, the approach is
admittedly very similar to that in
draft-deccio-dbound-organizational-domain-policy (ODUP)  Some differences
are a matter of preference, and others have more technical implications.

- Both drafts use "opt-out" models.

- Terminology concerns (nits):
  - Boundaries vs. policies: both drafts mention boundaries and policies.
While there are similarities, and in particular, policies often utilize
boundaries, they aren't one and the same.  Yet that they seem to be
portrayed as such in the draft.
  - "Organization" (e.g., "belongs to the same organization").  The way I
understand the understand "organization" doesn't coincide with how it is
used in this draft.  I don't think of an organizational boundary as
something associated with a service or policy.  For example, I don't see
how a cookie policy changes the organizational boundary between two
domains.  I see "policy boundary" on occasion.  Perhaps the two simply need
to be reconciled.

- Lookup process - the process is very similar to that in ODUP.  Some
similarities and differences follow:
  - They both have iteration-stopping mechanisms (NXDOMAIN for ODUP;
NOLOWER for the current draft).
  - The current draft begins queries at the TLD, rather than at the root
(well, the _odup TLD anyway).
  - The current draft uses the entire DNS name (plus the _bound label) to
create the qname to be queried; in ODUP, each label is considered
separately.  There are revealing components to both (discussed on the ODUP
draft and in other email threads), but the latter is the more conservative
approach.
  - There is no "default" policy behavior in the current draft; the default
policy behavior in ODUP is current behavior.
  - There is no mechanism for offline lookup in the current draft,
contrasted with the ability to download policy realms (including the
policy-negative realm and other high-profile realms) for local use in the
ODUP draft.
  - Because one record for each service/policy is required, there are
potentially n*m lookups.  So while the performance is O(n) for any given
service, it is O(n*m) for all services/policies.  Some applications would
require understanding of multiple policies.  Contrast this with a hard O(n)
with ODUP, which has a consolidated service list.

- The following is a confusing sentence for "boundary node":
 "the one above the closest node to the root that also belongs to the same
organization as the input domain name."
It is somewhat clarified by the sentence immediately after, but the
qualifiers in the sentence itself are ambiguous.

- Why the use of wildcards?  The time complexity doesn't improve with
this.  It just seems like added complexity, so you can query for the entire
name, rather than label-by-label.  But as, mentioned previously, this is
revealing to higher level DNS authorities.

- What would be the road map to deploy this "now", given existing
application behavior?  This was one of the big reasons for the design of
ODUP: to provide a mechanism that is backwards compatible with existing
behaviors and has a transition path for expansion, with the idea that it is
technically capable of going "now".

Cheers,
Casey

---

From: Casey Deccio <[email-masked]>
Date: Thu, 12 Nov 2015 11:57:53 -0500

Hi John,

On Mon, Nov 9, 2015 at 4:43 AM, John R Levine <[email-masked]> wrote:

> recently.  It's sort of like Casey's draft but it's much simpler, and every
> domain publishes its own info in its own namespace.
>

"Much simpler" is somewhat subjective.  If you could provide some detailed,
objective feedback and comparisons, that would be useful.

Thanks,
Casey

---

From: "John R Levine" <[email-masked]>
Date: 12 Nov 2015 12:05:37 -0500

> revealing to higher level DNS authorities.

Wildcards make the lookup O(1) rather than O(N).  I think that's an 
important difference.

> application behavior?

The obvious approach would be to write some libraries with interfaces 
similar to what people use for the PSL now and swap it in.  I suppose that 
for a while it could default back to the PSL if it doesn't find any BOUND 
records in the DNS.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 12 Nov 2015 12:06:36 -0500

> objective feedback and comparisons, that would be useful.

I think we should let other people look at them.

Regards,

---

From: Casey Deccio <[email-masked]>
Date: Thu, 12 Nov 2015 12:13:31 -0500

Hi John,

> Wildcards make the lookup O(1) rather than O(N).  I think that's an

Big-O notation characterizes the upper bound of algorithmic complexity.
The lookup process is bounded by n iterations.  Wildcards do not change the
upper bound to a constant lookup time.  Just as the NXDOMAIN in ODUP does
not change its time complexity from O(n) to O(1).  The bounding remains
O(n) in the current draft--or O(n*m) if you consider the service lookups.

Casey

---

From: "John R Levine" <[email-masked]>
Date: 12 Nov 2015 12:27:38 -0500

> Big-O notation characterizes the upper bound of algorithmic complexity.

Yes, I know.

My scheme will typically make one or two DNS queries regardless of the 
length of the DNS name.  Yours appears to do a tree walk for each name 
component.

My assumption is that each request is likely to be for a particular 
application.  If you need to enumerate the boundaries for M services, that 
will take M times as long but that doesn't seem like a very common 
situation.

Regards,

---

From: Casey Deccio <[email-masked]>
Date: Thu, 12 Nov 2015 12:38:29 -0500

On Thu, Nov 12, 2015 at 12:27 PM, John R Levine <[email-masked]> wrote:

> length of the DNS name.

What I'm saying is that "typically" does not dictate complexity; worst case
dictates complexity.

> Yours appears to do a tree walk for each name component.
>

As I have mentioned both in this thread and in the draft, iteration stops
at an NXDOMAIN--which if I understand correctly, is the equivalent of
hitting a wildcard response in your draft.  I welcome your detailed read
and review of the ODUP draft.

> will take M times as long but that doesn't seem like a very common

Assumptions are fine.  Commonalities are fine.  But again, if you get into
the realm of bounding algorithmic complexity, it's all about worst case,
upper bounding.  Worst case vs. anticipated performance, given the baseline
behavior, are also discussed in the ODUP draft.

I am belaboring this somewhat because we have drafts whose merits are being
discussed on this mailing list, and one of the concerns that has been
raised is "complexity".  Let's be clear about what that means, so the
comparisons are apples to apples.

Casey