Re: Clarification of when authentication is used

Fred Baker <fbaker@acc.com> Tue, 02 August 1994 23:48 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15764; 2 Aug 94 19:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15757; 2 Aug 94 19:48 EDT
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa20155; 2 Aug 94 19:48 EDT
Received: by atlas.xylogics.com id AA26684 (5.65c/UK-2.1-940401); Tue, 2 Aug 1994 19:48:43 -0400
Received: from fennel.acc.com by atlas.xylogics.com with SMTP id AA05228 (5.65c/UK-2.1-940401); Tue, 2 Aug 1994 19:48:29 -0400
Received: from [129.192.64.5] (coal.acc.com) by fennel.acc.com (4.1/SMI-4.1) id AA03572; Tue, 2 Aug 94 16:45:35 PDT
Message-Id: <9408022345.AA03572@fennel.acc.com>
X-Sender: fbaker@129.192.64.25
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 2 Aug 1994 16:45:43 -0800
To: Gary Scott Malkin <gmalkin@xylogics.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker <fbaker@acc.com>
Subject: Re: Clarification of when authentication is used
Cc: ietf-rip@xylogics.com

At  6:01 PM 8/2/94 -0400, Gary Scott Malkin wrote:
>> I dunno, I would agree with Jeff's assessment: it is information exchange
>> we are authenticating, we shouldn't break the management applications that
>> use RIP Requests to dump route tables. Having said which, seems like the
>> same logic applies to passwords.
>
>But that means there's no way to prevent outsiders from finding out what
>your routing table looks like.  Speaking for myself, I'd don't think that
>is a serious problem.  However, I remember, during the RREQ debates lo
>these many years ago, that some secure sites didn't even want to have to
>decrement the hop count for fear of giving away topology information.

:^)

        "you've left 'advice' and gone to 'meddlin'"

I could imagine some implementations do a lot of things. The thing is,
we've now mixed two very different applications with one mechanism. What
the authentication needs to prevent, IMHO, is bad routing. Maybe secure
implementations add a proprietary knob to disable responding to non-local
requests, or only to certain requestors, I don't know. But that sounds like
a proprietary issue.

=============================================================================
                        "In sound wisdom there are two sides"
                                        Zophar, Job 11:6