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

[Mukesh Gupta <[e-mail]>]

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

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