Subject: Re: [OPSEC] additional documents needing a home...

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Wed, 1 Oct 2008 09:53:18 +0530

I support draft-manral-rpsec-existing-crypto-05 and I think OPSEC is the
right home for this draft.

Cheers,
Manav

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Vishwas Manral
> Sent: Wednesday, October 01, 2008 8.44 AM
> To: Glen Kent
> Cc: [email-masked]
> Subject: Re: [OPSEC] additional documents needing a home...
> 
> Hi Joel,
> 
> I wanted to know your opinion of the consensus, and it was for
> allowing the work in the OPSEC WG?
> 
> Thanks,
> Vishwas
> 
> On 8/25/08, Glen Kent <[email-masked]> wrote:
> > I strongly believe that drafts draft-ietf-rpsec-bgp-session-sec-req
> > and draft-manral-rpsec-existing-crypto-05 very much belong here in
> > OPSEC.
> >
> > Glen
> >
> > ---------- Forwarded message ----------
> > From: Joel Jaeggli <[email-masked]>
> > Date: Thu, Aug 21, 2008 at 6:43 AM
> > Subject: [OPSEC] additional documents needing a home...
> > To: opsec wg mailing list <[email-masked]>
> >
> >
> > Folks,
> >
> > Dave Ward has proposed adding:
> >
> > Michael Behringer's rpsec draft
> >
> > http://tools.ietf.org/html/draft-ietf-rpsec-bgp-session-sec-req-01
> >
> >   Abstract
> >
> >   The document "BGP security requirements" 
> (draft-ietf-rpsec-bgpsecrec)
> >   specifies general security requirements for BGP.  
> However, specific
> >   security requirements for single BGP sessions, i.e., the 
> connection
> >   between two BGP peers, are only touched on briefly in the section
> >   "transport layer protection".  This document expands on this
> >   particular aspect of BGP security, defining the security 
> requirements
> >   between two BGP peers.
> >
> > which as was presented in opsec in ireland
> >
> > and
> >
> >
> > http://tools.ietf.org/html/draft-manral-rpsec-existing-crypto-05
> >
> >   Abstract
> >
> >   Routing protocols are designed to use cryptographic mechanisms to
> >   authenticate data being received from a neighboring 
> router to ensure
> >   that it has not been modified in transit, and actually originated
> >   from the neighboring router purporting to have 
> originating the data.
> >   Most of the cryptographic mechanisms defined to date rely on hash
> >   algorithms applied to the data in the routing protocol 
> packet, which
> >   means the data is transported, in the clear, along with a 
> signature
> >   based on the data itself.  These mechanisms rely on the manual
> >   configuration of the keys used to seed, or build, these hash based
> >   signatures.  This document outlines some of the problems 
> with manual
> >   keying of these cryptographic algorithms.
> >
> >
> > 
> http://tools.ietf.org/html/draft-bhatia-manral-igp-crypto-requ
> irements-00
> >
> >   Abstract
> >
> >   The interior gateway routing protocols OSPFv2 [RFC2328], 
> IS-IS [ISO]
> >   [RFC1195] and RIP [RFC2453] currently define clear text and MD5
> >   [RFC1321] algorithms for authenticating their protocol 
> packets. There
> >   have recently been documents adding support of the SHA 
> family of hash
> >   algorithms for authenticating routing protocol packets 
> for RIP, IS-IS
> >   and OSPF.
> >
> >   To ensure interoperability between disparate 
> implementations, it is
> >   imperative that we specify a set of 
> mandatory-to-implement algorithms
> >   thereby ensuring that there is at least one algorithm that all
> >   implementations will have available.
> >
> >
> >
> > which were not...
> >
> > As these document existing practice or problems with 
> existing protocols
> > I think it is conceivable that this work would fall within 
> our proposed
> > and soon to be official charter.
> >
> > I would like to hear some opinions on the subject. there was some
> > discussion of the first document during the opsec wg meeting and I
> > believe that the record shows some support for and against 
> housing it in
> > opsec.
> >
> > thanks
> > joelja
> > _______________________________________________
> > OPSEC mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/opsec
> >
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec
> 
_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec