Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review

[Acee Lindem <[e-mail]>]

Mukesh Gupta wrote:

>Acee,
>
>Vishwas is right.  I don't think we can mandate a specific algorithm
>in the draft and not have to update it in future.
>
>What about we say something like..
>
>====
>This specification does not mandate specific encryption and 
>authentication algorithms because the recommendation for encryption
>and authentication algorithms changes with time as the algorithms
>are broken and more secure algorithms are invented.
>
>In order to interoperate with each other, the implementations have
>to have at least one common algorithm that the user can choose to
>use for OSPFv3 security.
>
>The implementation MUST allow the user to choose all the encryption
>and authentication algorithm that are MUST in IPsec mandatory to 
>implement algorithms.
>
>The implementation SHOULD allow the user to choose all the encryption
>and authentication algorithm that are SHOULD in IPsec mandatory to 
>implement algorithms.
>  
>
Hi Mukesh,

I see the point - is there a document that updated regularly that 
recommends authentication
and encryption algorithms for use by routing protocols?

Thanks,
Acee

>====
>
>Regards
>Mukesh
>
>  
>
>>-----Original Message-----
>>From: Mailing List [mailto:[e-mail]]On Behalf Of ext
>>Vishwas Manral
>>Sent: Sunday, January 09, 2005 8:17 PM
>>To: [e-mail]
>>Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review
>>
>>
>>Hi Acee,
>>
>>I agree totally with your views. 
>>
>>However examples where algorithms "support has been changed" are: - 
>>
>>"
>>   Old   Old         New
>>   Req.  RFC(s)      Requirement  Algorithm (notes)
>>   ---   ------      -----------  ---------
>>   MUST  2406        SHOULD NOT   DES-CBC [RFC 2405] (1)
>>   MUST  2402 2406   MAY          HMAC-MD5-96 [RFC 2403]
>>   MUST  2402 2406   MUST         HMAC-SHA1-96 [RFC 2404]
>>"
>>
>>Thanks,
>>Vishwas
>>
>>-----Original Message-----
>>From: Mailing List [mailto:[e-mail]] On 
>>Behalf Of Acee
>>Lindem
>>Sent: Monday, January 10, 2005 12:49 AM
>>To: [e-mail]
>>Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review
>>
>>Mukesh, Vishwas,
>>
>>Here is my take. The document should be written in such
>>a way that  it doesn't need to be updated every time the 
>>IPSec algorithm
>>de jour changes.
>>
>>However, I also think the document should specify algorithms with the
>>caveat that they may be updated. IMHO, once an 
>>authentication/encrpytion
>>algorithm is deployed, it is unlikely to be withdrawn from support.
>>Hence,
>>if someone develops a stronger algorithm with lower computational 
>>requirements
>>and it becomes the recommended alogorithm, then implementations will
>>need
>>to support it in ADDITION to what they are currently supporting.
>>
>>Is this possible? Any other opinions?
>>
>>Thanks,
>>Acee
>>
>>
>>Mukesh Gupta wrote:
>>
>>    
>>
>>>Vishwas,
>>>
>>>Comments inline..
>>>
>>> 
>>>
>>>      
>>>
>>>>VM> I do not think you talk about encryption at all when you 
>>>>talk about
>>>>AH. If you check the documents I have pointed to carefully, 
>>>>you will see
>>>>NULL Encryption is a special case of encryption when 
>>>>        
>>>>
>>encryption is not
>>    
>>
>>>>used.
>>>>   
>>>>
>>>>        
>>>>
>>>Would it make more sense if we change the text "NULL encryption" 
>>>to "NULL encryption (for ESP) or no encryption (for AH)" ?
>>>
>>> 
>>>
>>>      
>>>
>>>>Suresh> We are not a fan of DES either for obvious reasons. 
>>>>        
>>>>
>> But as we
>>    
>>
>>>>wanted to start with the weakest algorithm, we started with DES.  We
>>>>wouldn't have to mention DES at all, had IETF/NIST 
>>>>suggested DES as "MUST NOT".
>>>>VM> I still don't see a reason why we should talk about DES at all.
>>>>   
>>>>
>>>>        
>>>>
>>>I still don't understand why we can't use DES as an example of a weak
>>>encryption algorithm.  
>>>
>>>I would like to hear others' opnion about this ?  Acee?
>>>
>>> 
>>>
>>>      
>>>
>>>>Suresh> Mukesh and I discussed this again and we agree that 
>>>>referring to
>>>>the IPsec algorithm draft should be the better way to go.  
>>>>VM> Also not for the authentication you have given the key 
>>>>        
>>>>
>>length and
>>    
>>
>>>>for Encryption you have not(so there is anyway a case of 
>>>>inconsistency).
>>>>   
>>>>
>>>>        
>>>>
>>>Yeah but this will be fixed too if we didn't mention any algorithm
>>>and just pointed to the madatory to implement algos.  Right ?
>>>
>>> 
>>>
>>>      
>>>
>>>>Suresh> What about the following:
>>>>"Replaying these type of packets can make the router spend some
>>>>resources.  Also when the OSPF adjacency is not FULL, replaying 
>>>>database description packets can cause disruption in forming the
>>>>adjacency."
>>>>VM> Its not just forming the adjacency Suresh but the link becoming
>>>>unusable for transit traffic (DoS). In my view you should 
>>>>just refer to
>>>>the vulnerabilities draft and probably put a sentence like 
>>>>        
>>>>
>>the above.
>>    
>>
>>>>   
>>>>
>>>>        
>>>>
>>>We do refer to the vulnerabilities draft after the brief discussion
>>>of the replay vulnerabilities..  So are you ok with putting the
>>>text proposed above and then referring to the vulerabilities draft ?
>>>
>>> 
>>>
>>>      
>>>
>>>>VM> You are right. However I think the aim of the draft is 
>>>>        
>>>>
>>to specify
>>    
>>
>>>>how we should use IPSec (guidelines) as well as specify the default
>>>>behavior(Maybe for all optional parameters we should specify this).
>>>>   
>>>>
>>>>        
>>>>
>>>You are right.  The aim of this draft is to specify how OSPFv3 should
>>>use IPsec but I still fail to understand why we need to 
>>>      
>>>
>>specify things
>>    
>>
>>>that are not related or exposed to OSPF :(
>>>
>>>What exactly do you want to specify about ESN?  Do we want to say
>>>that there is no impact of the usage of ESN by the underlying IPsec
>>>implementation on OSPFv3 security because sequence numbers 
>>>      
>>>
>>are ignored
>>    
>>
>>>while manual keys are used ?
>>>
>>>Regards
>>>Mukesh
>>>
>>> 
>>>
>>>      
>>>
>
>  
>