Re: Proposed text for reverse-mapping-considerations draft

On Thu, 31 May 2007, Olafur Gudmundsson wrote:

> 
> I think this text is helpful, to understand where the 'requirement´
> for reverse DNS entries came from. This mechanism was used by ftp
> servers to keep logs and enforce export control on cryptographic
> software 

I don't know of anyone ever using reverse DNS to enforce export control
of crypto software. The only sites that did even note export control
restrictions (eg. MIT for Kerberos), required first reading a notice
containing the export restriction notice in order to obtain a 'secret'
hidden FTP directory.

I note also that using Reverse DNS to implement such controls would be
easily and trivially spoofed, so if it ever _was_ used that way, its an
example of what not to do.

		--Dean

--

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop

Re: Proposed text for reverse-mapping-considerations draft

On Thu, 31 May 2007, Andrew Sullivan wrote:
> 
> The popular TCP Wrapper package was originally conceived to discover
> the network location of an attacker [Venema1992].  It used the reverse
> mapping of a connecting host to provide the hostname of that host in
> its output.

No. Early TCP wrappers just provided logs of activity, and then later to
provide access control. 

 "This paper presents a simple tool to monitor and control incoming
 network traffic. [...]

 "Services  such as finger do not
 require a password, and almost never keep a record of  their
 use.  That  explains  why  all  his  fingering  activity had
 remained unnoticed."

Access control:

 "5.  First extension: access control.
 [...]
     /etc/hosts.deny:

         ALL: terminus.lcs.mit.edu hilltop.rutgers.edu monk.rutgers.edu
         ALL: comserv.princeton.edu lewis-sri-gw.army.mil
         ALL: ruut.cc.ruu.nl 131.211.112.44
         ALL: tip-gsbi.stanford.edu
         ALL: tip-quada.stanford.edu
         ALL: s101-x25.stanford.edu

Re: Proposed text for reverse-mapping-considerations draft

Hello Dean,

On Fri, Jun 01, 2007 at 12:07:48AM -0400, Dean Anderson wrote:
> On Thu, 31 May 2007, Andrew Sullivan wrote:
> > 
> > The popular TCP Wrapper package was originally conceived to discover
> > the network location of an attacker [Venema1992].  
> 
> No. Early TCP wrappers just provided logs of activity, and then later to
> provide access control. 

You may have overlooked the sentence in the paper that says, "I
decided, however, that it would be more productive to maintain the
service and to find out where the finger requests were coming from."
(p1)  In any case, the distinction between "discover the network
location of an attacker" and "provide logs of activity" seems to me to
be mostly one of a matter of narravtive abstraction.  Given that this
is intended to be a quick narrative history, I think the "intentional"
level of abstraction is the right one, so I will leave this alone
unless I hear support from the Working Group for your alternative
gloss.

> The TCP wrapper program did not succeed at stopping nameserver spoofing,
> nor could it. 

I don't believe anyone claimed it did; and if you have evidence that
the proposed text says it did, I would surely like to correct it.

> know that. This is the origin of the reverse DNS "security" myth.

Re: Proposed text for reverse-mapping-considerations draft

At 23:41 -0400 5/31/07, Dean Anderson wrote:

>I don't know of anyone ever using reverse DNS to enforce export control
>of crypto software.

We ("we" referring to my employer in 1997) did.

--

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Sarcasm doesn't scale.

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop

Re: Proposed text for reverse-mapping-considerations draft

I At 11:07 AM -0400 6/1/07, Edward Lewis wrote:
>At 23:41 -0400 5/31/07, Dean Anderson wrote:
>
>>I don't know of anyone ever using reverse DNS to enforce export control
>>of crypto software.
>
>We ("we" referring to my employer in 1997) did.

I can confirm Ed's point that reverse DNS lookup was the technique approved
by appropriate government officials when it was applied to at least some
export controlled software.  I think that 1997 was within the time frame it
was being used but I'm less certain about the dates that it was actually
required since the rule set changed over time - but it was required to make
our early early DNSSEC implementation available on an ftp server and was
considered adequate by the government officials (even though I always
thought that it was a Really Dumb control!).

Russ Mundy

>
>--
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis                                                +1-571-434-5468
>NeuStar
>
>Sarcasm doesn't scale.
>
>_______________________________________________
>DNSOP mailing list
>DNSOP <at> ietf.org

Re: Proposed text for reverse-mapping-considerations draft

At 13:08 -0400 6/1/07, Russ Mundy wrote:

>considered adequate by the government officials (even though I always
>thought that it was a Really Dumb control!).

Well, you could (cynically) argue it was quite effective and 
efficient. And we are speaking from operational experience and not 
conjecture.

It was easy to set up and maintain.  (Low cost solution.)
No one who wanted and should have access was denied. (No false positives.)
No one reported the code being in the wrong hands. (No breaches.)

;)

--

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Sarcasm doesn't scale.

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop

Re: Proposed text for reverse-mapping-considerations draft

On Fri, 1 Jun 2007, Andrew Sullivan wrote:

> Hello Dean,
> 
> On Fri, Jun 01, 2007 at 12:07:48AM -0400, Dean Anderson wrote:
> > On Thu, 31 May 2007, Andrew Sullivan wrote:
> > > 
> > > The popular TCP Wrapper package was originally conceived to discover
> > > the network location of an attacker [Venema1992].  
> > 
> > No. Early TCP wrappers just provided logs of activity, and then later to
> > provide access control. 
> 
> You may have overlooked the sentence in the paper that says, "I
> decided, however, that it would be more productive to maintain the
> service and to find out where the finger requests were coming from."

No; I looked further into the context of that statement, and I cited
that context to you in my previous message: The purpose of the TCP
Wrappers tool was to provide _logs_ for programs which didn't produce
logs and for which source code wasn't available.  I showed you the logs
produced by the tool which were given as examples in the paper.

My draft also points out the flaw of using Reverse DNS for logging, and
so the 1992 TCP-wrappers' tool is discredited in that regard.  This is a
major difference between our drafts: Your draft presents discredited
practices as credulous, while I provide the full context, including the
fact that these practices were discredited.

> What you regard as a myth others regard as a useful clue.

Adopt draft-koch-dnsop-resolver-priming as WG work item?

<hat wg-chair="on">

  This is a call to confirm the decision made at the face to face WG
  meeting in Prague to adopt draft-koch-dnsop-resolver-priming.
  Discussion in Prague showed reasonably strong support and no
  objections, but as always, decisions at face to face meetings are
  subject to confirmation on the mailing list.

  Absent strong objections, I'll ask Peter and his co-author (to be
  appointed, we already have a list of volunteers) to submit the next
  version as draft-ietf-dnsop-resolver-priming-00.

  Please send any comments on this subject within the next week, so
  that Peter and his co-author have time to rev the document before
  the 2 July submission cutoff.

</hat>

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop

Re: Proposed text for reverse-mapping-considerations draft

On Thu, 31 May 2007 17:24:48 -0400 Andrew wrote:
AS> We received a suggestion that a short section outlining the history of
AS> the use of reverse mapping in security contexts would be a good thing
AS> to add to the reverse-mapping-considerations draft.  I have some
AS> proposed text to add.  Before I add it, I'd like to ask for comments.

I think it's useful, but I also think you should have a concluding
paragraph on why it's no longer a recommended practice. Something along
the lines of "as attack became more sophisticated, they included
spoofing reponses to reverse DNS requests, so the attacker appeared to
be coming from a trusted machine."

--

-- 
Robert Story
SPARTA

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop

Comments on draft-ietf-dnsop-as112-ops-00

Hi,

I'd like to send a couple of comments on
draft-ietf-dnsop-as112-ops-00, coming from my experience as an AS112
operator at NaMeX.

1) I don't see anything related to interface configuration of the
192.175.48.{1,6,42} addresses in the draft. I don't know if this is
something which is avoided on purpose (due to the different ways it is
dealt with in different OSs), but as in the rest of the document there
might be an example (such as configuring aliases in FreeBSD). By the
way, we also put the address config in zebra.conf (but if you only
want that as the interface config, then you would probably need to
start first the zebra daemon, then the DNS server, then bgpd).

2) When configuring the DNS server to log the queries, it might be
worth noting that this could be very CPU-intensive (this depends on
the query volume, of course). The same goes for the monitoring tools:
we used bindgraph, but as soon as we opened our transit (jumping from
100 to 700qps) the machine could hardly cope with query logging and
graph generation by bindgraph.

3) s/wwwn.as112.net/www.as112.net/ in section 6.

Hope that helps,

Regards

Daniele.