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

["Vishwas Manral" <[e-mail]>]

Hi Joel,

I agree with you on this!!!

Thanks,
Vishwas

On 10/4/08, Joel Jaeggli <[e-mail]> wrote:
> Bhatia, Manav (Manav) wrote:
>>
>> I support draft-manral-rpsec-existing-crypto-05 and I think OPSEC is the
>> right home for this draft.
>
>
> Regarding:
>
> http://tools.ietf.org/html/draft-bhatia-manral-igp-crypto-requirements-00
>
> I have concerns about this document making protocol requirements within
> the scope of our charter. Making this a set of protocol best practices I
> think hews more closely to our charter (and doesn't belong in routing).
>
> any thoughts on that?
>
> problems with manual keying seems straight up our alley.
>
> http://tools.ietf.org/html/draft-manral-rpsec-existing-crypto-05
>
> and i have no reservations for taking that one to our ADs.
>
> joelja
>
>> Cheers,
>> Manav
>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]]
>>> On Behalf Of Vishwas Manral
>>> Sent: Wednesday, October 01, 2008 8.44 AM
>>> To: Glen Kent
>>> Cc: [e-mail]
>>> 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 <[e-mail]> 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 <[e-mail]>
>>>> Date: Thu, Aug 21, 2008 at 6:43 AM
>>>> Subject: [OPSEC] additional documents needing a home...
>>>> To: opsec wg mailing list <[e-mail]>
>>>>
>>>>
>>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/opsec
>>>>
>>> _______________________________________________
>>> OPSEC mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/opsec
>>>
>> _______________________________________________
>> OPSEC mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/opsec
>>
>
> _______________________________________________
> OPSEC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsec
>
_______________________________________________
OPSEC mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/opsec