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

From: Joel Jaeggli <[email-masked]>
Date: Fri, 03 Oct 2008 19:26:51 -0700

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: [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
> 

_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

---

From: "Vishwas Manral" <[email-masked]>
Date: Sat, 4 Oct 2008 10:01:37 +0530

Hi Joel,

I agree with you on this!!!

Thanks,
Vishwas

---

From: "Steinthor Bjarnason (sbjarnas)" <[email-masked]>
Date: Mon, 6 Oct 2008 13:02:31 +0200

Hi,

irements-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?
> 
I see the benefit in having a document which recommends which routing
protocol authentication schemes to use.  Having such a document
available, will automatically put pressure on the routing protocol
developers to implement what's missing (in case there are still some
implementations out there which still do not support this).

So, I suggest this document should be adopted by the WG but with a more
"recommend/best practice" focus.

> and I have no reservations for taking that one to our ADs.
> 
Agree 100%

Regards
  Steinthor

---

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Thu, 9 Oct 2008 13:29:27 +0530

Hi,

> implementations out there which still do not support this).

Agree. 

I think this document too falls in the purview of OPSEC as this would
ensure interop between disparate router implementations where at least
one strong crypto algorithm is available that's implemented by all
vendors.

For example, we need to move folks using OSPF away from keyed MD5 and
there should be some document that suggests that. It should also be
noted that an algorithm that's considered strong today can be broken
tomorrow and may have vulnerabilities that can be exploited. In such
cases, we must have a document that vendors/operators can look up
against, before implementing/using a routing protocol security scheme.

This document does exactly that - it, to cite the same example,
discourages people running OSPF from using keyed MD5 (it's a MUST-) and
encourages the use of HMAC-SHA-1 [x] and other stronger algorithms. 

> "recommend/best practice" focus.

It should be a standards track document. Please look at RFC 4307, 4835,
etc. 

> > and I have no reservations for taking that one to our ADs.

True.

Cheers,
Manav

[x] http://tools.ietf.org/html/draft-ietf-ospf-hmac-sha-02
_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec