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

[Vishwas Manral <[e-mail]>]

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