Subject: draft-ietf-dnsop-inaddr-required-02.txt

From: Daniel Senie <[email-masked]>
Date: Mon, 03 Sep 2001 11:18:36 -0400

The minutes from the London meeting were just posted. I'd told the chair 
well in advance that I would not be at the meeting. My work and travel 
schedule often do not permit me to make all 3 IETF meetings in a given year.

At the previous meeting the chair asked if there was interest in the draft, 
and there appeared strong support. I've received a LOT of comments and 
feedback on this draft, and there seems to be support. I am confused by the 
chair's comments, as reported by the scribe, that if there isn't strong 
support, the draft will be discarded.

If the WG doesn't have any interest in this draft, I will resubmit it once 
again as an independent submission. It's not going to be "discarded" as 
such. I will continue to push this document with or without the WG.

Whether the document's focus is the same as it originally was is arguable. 
At Minneapolis, there was strong support for having the document discourage 
the use of INADDR as a security mechanism, yet continue to push people to 
implement INADDR.

I'd like to get a sense of whether the WG wants me to continue this 
document under the auspices of the group, or take it back to individual 
contribution status, where it started.

-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 3 Sep 2001 17:31:56 +0200 (MEST)

> contribution status, where it started.

I support this draft and think that is important. however, if possible,
I'd like to see it discussing both IPv4 and IPv6 reverse.

	jakob

---

From: Edward Lewis <[email-masked]>
Date: Mon, 3 Sep 2001 12:19:29 -0400

>support, the draft will be discarded.

My take on the comments regarding this draft was that the chair wants to
hear a "non-security" reason why a reverse map is required.  In other
words, the rationales based upon some legacy applications performing
authorizations based on the reverse lookup are not sufficient to require
reverse map.

IMHO,  there are two things for the group (of supporters) can do.  One is
to document reasons that WG chair will find acceptable.  The other is to
argue more strongly that security-based reasons are sufficient.

Personally - I don't understand why security reasons are insufficient.  I
am saying this not in disagreement, but from a lack of understanding.
(Perhaps I need to search the archives when I have better bandwidth.)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

---

From: Johan Ihren <[email-masked]>
Date: 05 Sep 2001 14:16:25 +0200

> (Perhaps I need to search the archives when I have better bandwidth.)

As I see it, the issue is not that security reasons per se is
insufficient cause to promote the draft, but that those security
reasons are mostly false.

That said, I am also in favour of the draft, but I think that the
request for a "non-security reason" is valid.

Regards,

Johan

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 12 Sep 2001 22:01:42 -0400

I oppose adoption/advancement of the draft. Not only are the security
justifications null and void, I think they actually *detract* from the other
justifications inasmuch as they promote/encourage bad security practices and/or
risk creating a False Sense of Security. I have personal experience of this
since many people here have in the past adopted use of the inherently-insecure
"r-series" commands (rlogin, rsh, etc.) based partly on the fact that we
provide consistent and reliable in-addr.arpa mappings in our internal DNS.
Using IP addresses in the .rhosts files would have been more
maintenance-intensive for these individuals and made this choice less palatable
for them.

in-addr.arpa mappings are a *convenience*. Every organization should be free to
decide for themselves whether the convenience of in-addr.arpa mappings is worth
the time, effort and ultimately the cost of setting up and maintaining them.
Mandating something that is not (or *should*not* be, see comments about
security above) necessary for interoperability, and which many folks will just
ignore anyway seems like a waste of time and effort and makes DNSOP look
foolish or at least out of touch with reality.

- Kevin

---

From: Daniel Senie <[email-masked]>
Date: Wed, 12 Sep 2001 23:09:34 -0400

At 10:01 PM 9/12/01, Kevin Darcy wrote:
>risk creating a False Sense of Security.

Umm, the draft SAYS as much. Please read the present version of the document.

>  I have personal experience of this

I completely agree with you, and the present version of the draft agrees 
with you.

There ARE applications which do rely on these mappings. That is something 
this draft, once published, might help to remedy.

Please read and suggest additional language to help further encourage folks 
to NOT rely on IN-ADDR. If it makes sense, the title of the document could 
be adjusted.