Re: [OSPF] Re: Stronger Non-IPSec OSPFv2 Authentication

"Vishwas Manral" <vishwas.ietf@gmail.com> Wed, 28 March 2007 23:35 UTC

Return-path: <ospf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWhgN-0006Yi-Np; Wed, 28 Mar 2007 19:35:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWhgM-0006Yd-TX for ospf@ietf.org; Wed, 28 Mar 2007 19:35:58 -0400
Received: from wr-out-0506.google.com ([64.233.184.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWhgK-0002Yu-Hj for ospf@ietf.org; Wed, 28 Mar 2007 19:35:58 -0400
Received: by wr-out-0506.google.com with SMTP id 71so12144wri for <ospf@ietf.org>; Wed, 28 Mar 2007 16:35:56 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mcVC8UREGda8FnnLD0eze6ZOXMOchZpVLH0W55Xy1r5jaDPdqvqE5Ua1g3bjwB7JmaMt2/2j8ZODvSJP5xciZwkwHk4XKj/uJaKlJQoOWwpJ9n6B3FNqRl8I5HKbBzD52S0WfDPIGrp9V4hVqsU7AHZr6Tucr0Xsz9wLszG3+ok=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bk9lkTlyJuaxbvOcpwJTLxyG0/P6o9yovwxwXU7uC/tcNCIKaR+LfQ9RGvOX548Cdne3w5zBt5iZpw42d8pDPzfHvkZiGyU5LpQtwBUUOu7N3khEk8cCnlStFgzrKuIfnROH5rkvaeMJ43+YH400NkdYqu7mIfsACK22bOQ4jZg=
Received: by 10.115.54.1 with SMTP id g1mr3978781wak.1175124955651; Wed, 28 Mar 2007 16:35:55 -0700 (PDT)
Received: by 10.114.24.9 with HTTP; Wed, 28 Mar 2007 16:35:55 -0700 (PDT)
Message-ID: <77ead0ec0703281635i68496a72g755ee8b02b934ae5@mail.gmail.com>
Date: Thu, 29 Mar 2007 05:05:55 +0530
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Acee Lindem <acee@redback.com>
Subject: Re: [OSPF] Re: Stronger Non-IPSec OSPFv2 Authentication
In-Reply-To: <461B1AAF-D2A6-4AF2-BFA8-546B785985C0@redback.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <C784E5DF-DAED-402E-9AC4-D8924E64356A@redback.com> <D5E719B8-D655-4849-867D-C0C675F0F255@redback.com> <C85BF864-9AC3-496A-92C3-16EE7CBE83C0@redback.com> <77ead0ec0703280901v605f3e40kc716ddef3772ab98@mail.gmail.com> <461B1AAF-D2A6-4AF2-BFA8-546B785985C0@redback.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc
Cc: OSPF List <ospf@ietf.org>
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi Acee,

I did hear a similar requirement from Sandy and may be a few others
too regarding this very document.

If we dont hear from others here anymore we can probably look what we
can do for the progress of the draft. Suggestions like the ones you
have given would be helpful.

Thanks,
Vishwas

On 3/28/07, Acee Lindem <acee@redback.com> wrote:
> Hi Vishwas,
>
> To quote the old adage, "You can bring a horse to water but you can't
> make'em drink."
>
> Maybe a document of a more general dealing with IGPs in RPSEC WG
> would be more appropriate. I just don't think we're ever going to
> agree on this document in this WG.
>
> Thanks,
> Acee
> On Mar 28, 2007, at 12:01 PM, Vishwas Manral wrote:
>
> > Hi Acee,
> >
> > Thanks for the comments.
> >
> > I agree we can get stronger authentication, but its of no use unless
> > we specify that in case we want security we MUST support the
> > algorithm. As the number of algorithms increase we need to specify a
> > minimal set of algorithms that need to be supported, else the
> > interoperability between implementations that want to support security
> > is not guarenteed .
> >
> > Also, as has been pointed out earlier, we have seen in IPsec RFC4305
> > as well as RFC4305-bis (of which I am the author), as the computing
> > power increases and security algorithms become vulnerable to new
> > attacks, we do not have to change RFC's that talk about how to use the
> > algorithm. The only RFC that changes is the one that specifies the
> > support levels of various security algorithms.
> >
> > Though it may sound obvious, the support for NULL algorithm states
> > that if we need support for Security we should not use the NULL
> > authentication algorithm.
> >
> > These were the exact lessons learnt in the past in IPsec. I guess we
> > should take care not to repeat the mistakes again.
> >
> > Thanks again,
> > Vishwas
> >
> > On 3/28/07, Acee Lindem <acee@redback.com> wrote:
> >> Speaking as a WG member (so I can state my opinion without having
> >> to be nice
> >> :^):
> >>
> >> I like this option the best since it allows us to get the stronger
> >> authentication without having to agree on the requirements text.
> >> Since it
> >> was presented in Paris, I've never liked the text in
> >> draft-bhatia-manral-crypto-req-ospf-01.txt. While footnotes
> >> have been added to address my concerns, it might be easier not to
> >> try and
> >> agree on this at all.
> >>
> >> I don't like section 3 since, until you read the footnotes, it
> >> implies NULL
> >> and simply authentication MUST NOT be used. Null authentication is
> >> by far
> >> the easiest to administer, the most efficient, and, I'd wagger,
> >> the most
> >> widely deployed. Simple authentication can be useful in situations
> >> where you
> >> simply want to run two communities of OSPF routers on the same
> >> wire. It is
> >> also good for places where you don't want inadvertent
> >> participation in the
> >> OSPF routing domain. You many "trust" the people who have access
> >> to the
> >> physical networks running OSPF or have sufficient motivation for
> >> them to
> >> behave.
> >>
> >> With respect to MD5 authentication - this is currently widely
> >> deployed and
> >> it will take some time to be replaced. Hence, I think the whole
> >> draft could
> >> be replaced by a statement to the effect that "Users desiring
> >> cryptographic
> >> authentication may consider using algorithms x, y, or z due to the
> >> vulnerabilities in MD5. ....".
> >>
> >> Thanks,
> >> Acee
> >>
> >>
> >>
> >>
> >> On Mar 28, 2007, at 8:43 AM, Acee Lindem wrote:
> >>
> >> After discussions with members of the ISIS WG, there is a third
> >> option which
> >> would be to accept
> >> draft-bhatia-manral-white-ospf-hmac-sha-03.txt but not
> >> draft-bhatia-manral-crypto-req-ospf-01.txt. I'd like to
> >> throw that out as an
> >> option.
> >>
> >> Thanks,
> >> Acee
> >>
> >>
> >>
> >> On Mar 27, 2007, at 9:16 AM, Acee Lindem wrote:
> >> These drafts were presented in San Diego and seem to have
> >> considerable
> >> support.
> >>
> >> draft-bhatia-manral-crypto-req-ospf-01.txt
> >> draft-bhatia-manral-white-ospf-hmac-sha-03.txt
> >>
> >> Hence, we plan to make these WG documents unless there is significant
> >> opposition or a compelling reason not to do so.
> >> Thanks,
> >> Acee
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> OSPF mailing list
> >> OSPF@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/ospf
> >>
> >> _______________________________________________
> >> OSPF mailing list
> >> OSPF@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/ospf
> >>
> >>
>
>

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf