Subject: draft-warnicke-network-dns-resolution-02.txt

From: Randy Bush <[email-masked]>
Date: Thu, 3 Jul 2003 14:54:50 -0700

is dnsop tracking this?  should the wg take responsibility for it,
either as a wg document, if you like it and think it can be worked
to become product.  or as a "wg has reviewed this document and is
in doubt that it is a useful idea."  or whatever.

randy

#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Rob Austein <[email-masked]>
Date: Thu, 03 Jul 2003 22:48:26 -0400

> in doubt that it is a useful idea."  or whatever.

I'd have to check my notes to be certain, but I think that the WG
discussed this in San Francisco and decided not to make it a WG doc.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Peter Koch <[email-masked]>
Date: Sat, 05 Jul 2003 22:53:24 +0200

Rob Austein <[email-masked]> wrote

> discussed this in San Francisco and decided not to make it a WG doc.

not having been in San Francisco I do not know what the decision(oops?) was
based upon, but here are some comments and more detailed remarks below:

While I'd agree that it would be nice to have an updated version of RFC 1101,
i'm not sure I understand the problem the draft really tries to address.
From what i guess it does, the solution IMHO seems too complicated to work
in practice. Additional information regarding the motivation of this kind
of solution would be welcome.
As an example: Is the proposed algorithm intended to be processed from
inside the particular network or from the outside? If the latter, then why?

The proposed method should support the address of the 'first hop router',
but there's nothing in the draft that restricts the algorithm to this
problem domain. It's broad enough to be applied to other services, which
is OK on the one hand, but on the other it means that here's another
approach to the service location problem. DNS is not really the best approach
to locally scoped service location.

So, it's not clear to me why the problem is tried to be solved via DNS in the
first place. For the algorithm to work, the asking system needs to contact a
resolver, i.e. it needs to know that system's address (unless link local name
resolution is used). Also, it needs an IP address and a working interface,
usually including a subnet mask (unless the local environment supports proxy
ARP). So, why does the system need to determine the/a router's address?
And even if it needs that address, why would it have to first find the
subnet mask? What about using DHCP?

Finally, due to the way the intermediate names are constructed, the
suggested algorithm would need too many additional zones, at least domain
names, including some, which can only be instantiated with cooperation
from upper level zones. IMHO this is affords too much interaction to be
used "out there".

So, finally, based on the information currently available I'd agree that the
draft not be adopted by the WG. An update of RFC 1101 would be interesting,
though.

Please find more detailed comments below (quoting from the draft).

-Peter

.............................................................................

>    host.  It would be useful to have a standard mechanism for such
>    a host to find the first-hop router(s).

If such host could be instructed to contact a particular resolver, why
can't it be told the address of it's router?

>    DNS-based mechanisms have been defined for the resolution of router
>    addresses for classful networks (RFC 1035 [1]) and of subnets (RFC

Is that "A" records? Otherwise I can't see what RFC 1035 does to answer
this particular question.

>    network.  This RFC also specifies an extension to the method of RFC
>    2317 to support delegation at non-octet boundaries.

RFC 2317 doesn't need this extension, because in the case the prefix length
is less than 24, you'd just delegate and populate a separate zone per octet.
You'll cover a single "network" by multiple zones, but that doesn't matter.
And that practice pre-dates RFC 2317.

So, the problem is: ``given an IP address, find "the" first hop router for
that address''
Who is to ask that question? I guess it's the system itself, but then,
why would it be necessary to answer that question by means of DNS instead
of, say, DHCP?

>    networkdomainname = maskedoctet "." *( decimaloctet / maskedoctet ".")
>                         ".in-addr.arpa."

That should read "in-addr.arpa". The first "." is already provided by the
other rule elements. The last is unnecessary because domain names don't end
in dots.

>    decimaloctet = ( *1("1") DIGIT DIGIT ) /
>                    ( "2" ( "1" / "2" / "3" / "4" ) DIGIT ) /
>                    ( "2" "5" ( "1" / "2" /"3" / "4" / "5" ) )

An element covering a single DIGIT is missing, and this rule would allow a
leading zero in e.g. "00". Either the rule would have to be extended or
the restrictions could be dealt within a comment (see definition of
"IPv4-address-literal" in RFC 2821.

>    A "-" is used as a delimiter in a maskedoctet instead of a "/" as in
>    RFC 2317 out of concern about compatibility with existing DNS
>    servers, many of which do not consider "/" to be a valid character in
>    a hostname.

That's not a matter of the server's opinion. On the other hand, it's only
relevant if address records have to be associated with a name (i.e., it's
really a hostname). That's not the case in this draft, so "/" could be
used (but see below).

>    In RFC 2317 there is no mechanism for non-octet boundary delegation.

And that's not necessary there, see above.

>    1.  Take the initial IP address x.y.z.w and create a candidate
>        network by assuming a 24 bit subnet mask.  Thus the initial
>        candidate network is x.y.z.0/24.

Why doesn't the system know the subnet mask for this interface? Is it
supposed to be multihomed?

>    4.  If the PTR records returned from looking up the candidate domain
>        name  are of the form of a domain name for a network as defined
>        previously (Section 2), then for each PTR record reduce that
>        returned domain name to the canonical form
>        p1-q1.z1.y1.x1.in-addr.arpa.  This represents a network
>        x1.y1.z.1.p1/q1.
               ~~~
Delete dot ----/

>        1.  If no candidate network PTR lookup for this IP address has
>            succeeded in the past and the netmask for the last candidate

What does the term "in the past" mean in this context? Is the system
supposed to keep state across multiple invocations of this algorithm?

>        2.  If no candidate network PTR lookup for this IP address has
>            succeeded in the past and the netmask for the last candidate
>            network was not 24 of 16 bits long, then increase the netmask

s/of/or/;

> 4.2 Example

[...]

>    7.   Lookup the PTR records for 0-16.15.10.in-addr.arpa.
>    8.   Lookup returns:
> 
>         1.  0-17.15.10.in-addr.arpa.
>         2.  128-18.15.10.in-addr.arpa.
>         3.  192-18.15.10.in-addr.arpa.

Obviously you need the cooperation of and interaction with the maintainer of
the /16 for this to work. That might even be an RIR!

>    0-17.15.10.in-addr.arpa.    IN  NS 10.15.0.50
>    128-18.15.10.in-addr.arpa.  IN  NS 10.15.128.50
>    192-18.15.10.in-addr.arpa.  IN  NS 10.15.192.50

The single NS RR per zone is due to brevity, I guess; but IP addresses
should not be used in the RDATA. It violates the protocol and although
the intention is almost obvious, errors like this are too easily copied.

>    In entity B's DNS zone files:
> 
>    ;; provide entries for the subnets of 10.15.128.0/18
> 
>    128-18.15.10.in-addr.arpa. IN PTR 128-19.128-18.15.10.in-addr.arpa.
>    128-18.15.10.in-addr.arpa. IN PTR 0-25.160.128-18.15.10.in-addr.arpa.
>    128-18.15.10.in-addr.arpa. IN PTR \
>                                    128-25.160.128-18.15.10.in-addr.arpa.
>    128-18.15.10.in-addr.arpa. IN PTR 0-24.161.128-18.15.10.in-addr.arpa.
>    128-18.15.10.in-addr.arpa. IN PTR 162-23.128-18.15.10.in-addr.arpa.
> 

The list is incomplete. 10.15.128/18 was further split into 10.15.128/19
an others, so you also need entries for "128-19.15.10.in-addr.arpa" and more.
So, the /16 reverse maintainer is again to be involved. I'd expect some
operational difficulties with this scheme. Instead one could try to make the
prefix part of the hierarchy, i.e. "/18.128.15.10.in-addr.arpa".
An APL RR might be more efficient than a large PTR RRSet.

>    ;; provide entries pointing to non in-addr.arpa hostnames for
>    ;; terminal network
>    162-23.128-18.15.10.in-addr.arpa.  IN  PTR gw1.example.com.
>    162-23.128-18.15.10.in-addr.arpa.  IN  PTR gw2.example.com.

Why are these owner names not reduced?

_end_

---

From: Randy Bush <[email-masked]>
Date: Sat, 5 Jul 2003 17:03:34 -0700

> not having been in San Francisco I do not know what the decision(oops?)
> was based upon, but here are some comments and more detailed remarks
> below:
> ...
> So, finally, based on the information currently available I'd agree that
> the draft not be adopted by the WG. An update of RFC 1101 would be
> interesting, though.

<ad hat on>

what i would most appreciate is one of
  o a statement by the wg that this is being taken on as a work item
  o a statement by the wg that this is NOT being taken on as a work
    item, but the wg has no problem with its publication as info
  o a statement by the wg that this should not be published for some
    stated set of reasons, or that it could be published but with a
    warning (text included).

randy, just tryin' to process a document

---

From: Alain Durand <[email-masked]>
Date: Mon, 07 Jul 2003 14:48:01 -0700

>randy, just tryin' to process a document
Speaking as a wg participant:
This document only talks about IPv4 and address issues
that are key for IPv6 and are beeing addressed by the wg
in the general discussion on reverse DNS for IPv6.
Thus I would recommend against the publication of this document
in its current form.

    - Alain.

---

From: Edward Warnicke <[email-masked]>
Date: Mon, 7 Jul 2003 23:46:24 -0400 (EDT)

Peter,
	Would this make more sense if I were to point out that
I screwed up the last edit of the last sentence of paragraph 1
in the Introduction.  It reads:

"It would be useful to have a standard mechanism for such
 a host to find the first-hop router(s)."

The implication is that a host would be using the method of the draft
 to look up information about itself.  This is incorrect.  Rather that
 sentence should be replaced by:

 "It may be necessary for a third party server in the network to
 request some service related to the host from the first-hop router(s) for
 that host.  It would be useful to have a standard mechanism for such a
 server to find the first-hop router(s)"

The application I'd originally written the draft to deal with was
identification of the first-hop router as the intercept access point
for Lawful Intercept ( wiretapping ).  The intention is *not* for
a host to use this method to discover anything, but rather for
*other* servers in the network to use this method to be able to
discover the IP address of the first-hop router(s) so that they may
request some service from the first-hop router(s) related to the host.
Some method of identifying the intercept access point is necessary
for Lawful Intercept.

Does the above change in language clear up some of the confusion?

More comments inline...

> of solution would be welcome.

The initial motivation for this draft was that I encountered some attempts
to use RFC 1101 to allow identification of the first-hop router(s) for a
host in order to request Lawful Intercept services ( wiretapping ) of the
host by the first-hop router(s).

> from upper level zones. IMHO this is affords too much interaction to be

Cooperation of the upstream zones will sometimes be necessary, but care
has been taken to limit the amount of cooperation needed.

> Please find more detailed comments below (quoting from the draft).

See comment above about this being an error introduced in the most
recent edit.  This is *not* a method for a host to discover anything
about itself, but rather a method for other servers in the network to
discover the first-hop router(s) of a host.

> this particular question.

I was mostly refering to RFC 1035 section 3.5 paragraphs 5,6, and 8.

> And that practice pre-dates RFC 2317.

You are correct RFC 2317 doesn't need this extension for it's application
because it is dealing with using PTR records to map from an
IP number to a hostname ( the hostname of that IP address ).

For my application I need to be able to cleanly delegate on non-octet
boundaries in aggregate.

> why would it be necessary to answer that question by means of DNS instead

Some other server in the network is asking this question, like a mediation
device seeking to start a tap on a host using the hosts first hop gateway.

> other rule elements. The last is unnecessary because domain names don't end

You are correct.  I will fix the error.

> "IPv4-address-literal" in RFC 2821.

You are correct.  I will fix the error ( thanks for the pointer to 2821 :)

> really a hostname). That's not the case in this draft, so "/" could be

Browsing lightly through the source for bind 8.3.0 it looks like
the rdata associated with ptr records is judged OK or not by ns_nameok
as being of context hostname_ctx, which causes it to drop through to
res_hnok, which checks the hostname in such a way as to allow allow
alphachar, digitchar, and hyphenchar, but not "/".  Perhaps I'm
misreading ( I only browsed lightly ), but it looks like there is some
potential for confusing bind 8.3 with RDATA for a PTR record that contains
a "/".  Would I rather use the "/" character?  Yes.  But I wasn't willing
to risk issues with DNS implementations over the issue.

> supposed to be multihomed?

Again, the host knows it's subnet, another server in the network needs to
look it up.  My fault for causing this confusion.

> >        p1-q1.z1.y1.x1.in-addr.arpa.  This represents a network

You are correct again, I will correct the error.

> supposed to keep state across multiple invocations of this algorithm?

No.  In the past means as part of the same lookup process.  The resolution
of the IP address of the first-hop router for a host may span multiple DNS
lookups.  The algorithm *does* require maintaining state across multiple
DNS lookups, but not across multiple first-hop router resolutions.

> >            network was not 24 of 16 bits long, then increase the netmask

You are correct.  I will fix the error.

> the /16 for this to work. That might even be an RIR!

Yes, you will need the cooperation of your upstream zone.  Care was taken
to minimize the number of entries the upstream DNS would need to provide,
and to limit the churn of those records.

> the intention is almost obvious, errors like this are too easily copied.

You are correct that the single NS is for brevity.  You are correct that
I used the incorrect RDATA type for the NS record.  I will fix the error.

> An APL RR might be more efficient than a large PTR RRSet.

Actually... the list is not incomplete here ( although it is further on ).
The 10.15.128/19 and others are subnetted from the 10.15.128/18 and
therefore are *not* the concern of the owner of the 10.15/16.  The
10.15/16 doesn't need to know anything about the way the 10.15.128/18 is
subnetted, because any RR for that subnetting will be off of the
128-18.15.10.in-addr.arpa. shim domain.  You see this in the entry:

where the 10.15.128/19 subnet is represented by the
128-19.128-18.15.10.in-addr.arpa. domain name.

For reasons of brevity I did not show the RR for
128-19.128-18.15.10.in-addr.arpa. in entity B's DNS tables as it isn't
pursued further in the example.

> Why are these owner names not reduced?

The names aren't reduced because that would require more work on behalf
of the 10.15/16 owner.  162-23.15.10.in-addr.arpa. would require more
RR entries be made by the 10.15/16 owner.  As you've pointed out
( correctly ) this is likely to make them grumpy :)  That's why
the shim zone is used.  It also means that if the owner of the
10.15.128/18 owner changes their subnetting it makes no difference
in what the upstream provider needs in their DNS tables.

I put a fair bit of thought into reducing the number of RR entries the
upstream provider would need to provision, and into reducing the
need for the upstream provider to change those entries if the
subnetting of the delegated network changed.

In the current scheme, when an upstream provider delegates a network
downstream, they would have to create:

1		PTR record entry for the delegating network
		( 0-16.15.10.in-addr.arpa.  IN  PTR 128-18.15.10.in-addr.arpa. )
1 or more 	NS records for the shim domain
		( 128-18.15.10.in-addr.arpa.  IN  NS ns1.example.net )
0 or more 	glue records for the NS records

So delegating a network requires 1 + n + m  where n is the number of NS
for the shim domain and m is the number of needed glue records.

Thank you very much for taking the time to provide such a detailed
critique, it has been quite helpful.  Hopefully I've answered ( or
acknowledged ) your criticism adequately.  If not, let me know.

Ed

---

From: Brad Knowles <[email-masked]>
Date: Tue, 8 Jul 2003 10:35:17 +0300

>  Some method of identifying the intercept access point is necessary

	For a purely US-only application, or for an application where the 
source country, target country, and all intervening countries have 
similar laws, I think that might potentially be a valid use.

	However, in the modern Internet, I don't think that really has 
much application.  I don't think anyone is about to do anything that 
would allow anyone else to request that their router provide 
arbitrary "lawful intercept" services for some unknown party in some 
other country.

	Who knows when this kind of information might be used for 
corporate or gov't espionage, or frequently and casually abused by 
people with the necessary access, who probably don't even have to be 
real law enforcement officers, regardless of how corrupt the police 
department may be?

	And if you can't get broad adoption of this sort of feature, then 
what possible use could it serve?

	I'm sorry.  Given what we've learned so far about this, I would 
argue most vehemently that we should do everything within our power 
to actively kill this proposal, and not just decide whether or not to 
passively fail to support it.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Edward Warnicke <[email-masked]>
Date: Tue, 8 Jul 2003 08:51:22 -0400 (EDT)

I seem to have miscommunicated.  I am in no way suggesting that a router
provide arbitrary "lawful intercept" services for some unknown
party in some other country.  Please see
http://www.ietf.org/internet-drafts/draft-baker-slem-architecture-01.txt

You may also find the previous thread on this draft informative:
http://www.cafax.se/dnsop/maillist/2003-02/msg00058.html

Ed

---

From: Brad Knowles <[email-masked]>
Date: Tue, 8 Jul 2003 18:32:58 +0300

>  http://www.ietf.org/internet-drafts/draft-baker-slem-architecture-01.txt

	Okay, fair enough.  But if you want to get wide availability of 
this feature, you have to give people a reason to actively want to 
provide this information.

	Since many sites may not have fully secured their routers, if 
they identify the first hop router for each netblock they own, then 
there is the risk that people will make a stronger and more concerted 
attack on that router, perhaps trying to subvert or abuse features 
that may have been included and turned on by default.

	IMO, this is like revisiting the whole WKS idea all over again. 
In the early days of the Internet, that was good.  But in the modern 
days where publishing any additional information about your system 
may result in an increased security exposure, I just can't see 
something like this being broadly useful or widely adopted. 
Moreover, I see this opening up whole new cans of worms that I don't 
think we want to even think about.

---

From: Ed Warnicke <[email-masked]>
Date: Wed, 09 Jul 2003 14:13:57 -0400

> provide this information.

True.  In the Lawful Intercept application there are legal requirements 
that the network owner provide wire tapping services ( usually when
presented with a warrant, your local laws may vary ).  This requirement 
can be fulfilled in a number of ways, but clearly service providers
would like to comply with legal requirements in the least expensive 
possible way.  Many of the mediation devices that provide the intelligence
behind doing the tapping will be supplied by third party vendors.  If 
these third party vendors must integrate their mediation devices separately
to the OSS system of each service provider to obtain information about 
the first-hop router(s) this could be quite expensive.  If the mediation
device vendors can integrate against a particular use of the existing 
DNS system, this should be much less expensive.  If it saves service
providers money, they will implement it.  If it doesn't they won't.  
Likewise, if other applications arise, if they are compelling to the parties
in a position to implement the draft it will be implemented, otherwise 
it won't.

>
>     Since many sites may not have fully secured their routers, if they 
> identify the first hop router for each netblock they own, then there 
> is the risk that people will make a stronger and more concerted attack 
> on that router, perhaps trying to subvert or abuse features that may 
> have been included and turned on by default.
>
This is a good point, and one that has been brought up before.  There 
are ways of controlling the distribution of RR from a particular edge 
network
if the network owner is concerned.  I also mentioned this issue in the 
Security Considerations section of the draft. 

Ed

---

From: Brad Knowles <[email-masked]>
Date: Thu, 10 Jul 2003 02:11:03 +0400

At 2:13 PM -0400 2003/07/09, Ed Warnicke wrote:

>                                                        This requirement
>  possible way.

	Note that there are many facets to the term "expensive" in this 
context.  We can only address a small subset of them, and I believe 
that there are other factors which are dominant but on which we 
cannot have any impact.

>                             If the mediation device vendors can
>  integrate against a particular use of the existing DNS system,
>  this should be much less expensive.

	Not true.  At least, not entirely true.

	What you really need is a standard.  But that standard doesn't 
necessarily have to have anything whatsoever to do with the DNS. 
Until you can convince me that there is no other possible way that 
this issue can be addressed (other than using the DNS), you're going 
to have an uphill battle.

	Moreover, since we're talking about a mechanism that would be 
pretty much purely dictated by the US gov't, I think you would find 
very strong opposition to incorporating anything remotely related to 
it into an International standard protocol, such as the DNS.

>  network if the network owner is concerned.  I also mentioned this issue
>  in the Security Considerations section of the draft.

	Sorry, I don't buy this for a moment.  There are way, way too 
many nameservers out there that are public recursive/caching 
nameservers which could be abused to provide this sort of information 
to external parties.

	Moreover, not only are these nameservers configured in such a way 
as to allow this information to escape, they are also vulnerable to 
cache pollution and poisoning, which could be far, far worse in the 
context of anyone actually depending on the information returned by 
these machines for law enforcement purposes, and where real lives 
could literally be on the line.

	You're talking about relying on a "security mechanism" that is 
leaky enough to allow entire galaxies to pass through, and probably 
even small universes.

	You've got to have something better that can't be simply blown 
out of the water by a single poorly set up nameserver, or a small 
collection of poorly set up nameservers.

	Of course, probably something like 99% of all nameservers are 
public recursive/caching and vulnerable to cache pollution/poisoning. 
Certainly, my own survey of the gTLD, ccTLD, and root nameservers 
indicates that over 50% of all the ccTLD, gTLD, and root nameservers 
are open public recursive/caching nameservers, affecting almost 80% 
of all the TLDs in the world (see 
<http://www.shub-internet.org/brad/papers/dnscomparison/>).  And 
these are supposedly the best-run nameservers in the world.  What is 
the rest of the world like?