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

From: Mukesh Gupta <[email-masked]>
Date: Fri, 7 Jan 2005 01:50:40 -0600

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

---

From: Acee Lindem <[email-masked]>
Date: Sun, 9 Jan 2005 14:19:13 -0500

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