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

From: Vishwas Manral <[email-masked]>
Date: Thu, 6 Jan 2005 20:26:09 -0800

Hi Suresh,

Suresh> Do you see any difference in terms of difficulty in breaking the
keys for "NULL encryption with MD5 auth with ESP" and "MD5
authentication
with AH"?
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.

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.

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

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.

Suresh> We are using manual keys here so the sequence numbers will be
ignored.  So do we really need to worry about ESN?
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).

Thanks,
Vishwas 

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of
Suresh Melam
Sent: Friday, January 07, 2005 8:03 AM
To: [email-masked]
Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review

Hi Vishwas, 

Comments inline, 

regards,
- suresh

> We wanted to keep the section general without making it 
> specific to ESP or AH.  So when we say "Null encryption with 
> MD5 authentication", it could be used either with ESP or 
> with AH.  Do we need to add more text to make it clearer? 
> Do you any have specific changes in mind ? 
VM> I do not agree when you say NULL encryption it can refer to AH, I
think it means only ESP. NULL Encryption can be treated equivalent to
any other encryption algorithm atleast that is what I know of. 

suresh> AH & ESP differ in the protection provided to different fields
of the packet.  In this section of the draft, we were interested in
comparing the difficulty of breaking the keys, but not really in the
attacks once the keying material is compromised. 
Do you see any difference in terms of difficulty in breaking the keys
for "NULL encryption with MD5 auth with ESP" and "MD5 authentication
with AH"? 

> Well, the draft does not recommend using DES either. We just 
> wanted to compare some non-null encryption schemes with null 
> encryption schemes and we chose des, 3des and AES.  The draft 
> mandates the usage of AES so it is inline with the other 
> IPsec drafts. 
VM> I do not think we should use examples of schemes, which have been 
mentioned as "SHOULD NOT" by the IETF/NIST. 

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

> All the IPsec implementations that support AES for IPsec 
> MUST support 128 bit key size (RFC 3602).  So are we not 
> ok without mentioning the key sizes in this draft and just 
> referring to 3602? 
VM> Mukesh I am comming more from the point of view of 
draft-ietf-ipsec-esp-ah-algorithms-02.txt, which also seems 
to specify the key size. IT is the document for ESP/AH 
specifying mandatory protocols. 
>
> We had taken this approach in previous revs (04, I guess) 
> but Security ADs (Russ) wanted to have at least one algorithm 
> required by this draft just to make sure that the 
> implementations were interoperable.  We added AES/SHA1 
> as mandatory as suggested by Russ. 
VM> I guess I should have been clearer. I agree and infact had asked for
the same thing in my previous review. I am asking is that we have
another companion draft specifying the mandatory algorithms as is done
for IPSec/IKE etc. It helps becuase as and when we move forward and
algorithms change we just need to change that document rather then the
whole IPSec for OSPF document. 

Suresh> IMHO, a companion draft for just this will be an overkill.
Mukesh and I discussed this again and we agree that referring to
the IPsec algorithm draft should be the better way to go.  We also
looked at the 04 version and realized that the related text was not
clear in that version.  We will discuss this with Russ again and see if
we can come up with some text to satisfy us all :)

> "There are no known threats of replaying these type of packets."
> with 
> "There are no known threats of replaying these type of packets 
> except that the receiving router will have to spend some resources 
> to handle these packets." 
VM> I agree, however I think one more point we miss is that, when 
adjacencies are not full the link is not used for transit data traffic.
In the sense its a clear DoS attack where we can make the link unusable.
I have already told the OSPF Vulnerabilities draft authors about the
same. This also causes transient loops because of changing topologies. 

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

> Sorry ! I do not understand which default/supported values 
> you are talking about here :(  Could you please be a little 
> more specific? 
VM> As you stated that Russ specified(and I totally agree) some minimal
options for implementations to interoperate is necessary(and I think the
primary aim of this draft). We should specify if we are using options
Extended Sequence Numbers(ESN) or not at the minimum etc. The reason is
the same for DSCP, check the recent discussion on 
http://www1.ietf.org/mail-archive/web/ipsec/current/index.html I had
with Steve Kent and the changes being made to the IPSec security
architecture document because of that. 

Suresh>  We are using manual keys here so the sequence numbers will be
ignored.  So do we really need to worry about ESN ?

VM> Mukesh, I also noted that recommendation of changes for the MIB is
not made in the draft Would there be any changes to the MIB? 

Suresh>  Is it customary to add a "MIB recommendations" section? In any
case, we should work closely with the MIB draft authors to update the
MIB entries to include the security details.

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 7 Jan 2005 00:48:04 -0800

Hi Mukesh,

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of
Mukesh Gupta
Sent: Friday, January 07, 2005 1:21 PM
To: [email-masked]
Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review

Vishwas,

Comments inline..

> NULL Encryption is a special case of encryption when encryption is not

Would it make more sense if we change the text "NULL encryption" 
to "NULL encryption (for ESP) or no encryption (for AH)" ?
VM> OK.

> 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?
VM> I think examples should not be given of protocols which are on the
"SHOULD NOT" list of IETF/NIST.

> for Encryption you have not(so there is anyway a case of 
Yeah but this will be fixed too if we didn't mention any algorithm
and just pointed to the madatory to implement algos.  Right ?
VM> Yes, however I think we should be specifying a default algorithm for
OSPF(or are you saying you are not specifying any algorithms instead
just directly pointing to the ESP/AH algorithms document).

> 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> As long as you put the text for the DoS case too, I am ok. Else let
us directly point to the vulnerabilities draft without mentioning cases.

> 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 ?
VM> As Suresh rightly said ESN does not make sense with manual keying.
So it is not about ESN alone. DSCP was one example I had pointed out
too.

Thanks and sorry for bothering you,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 9 Jan 2005 20:16:45 -0800

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:[email-masked]] On Behalf Of Acee
Lindem
Sent: Monday, January 10, 2005 12:49 AM
To: [email-masked]
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:

>Regards
>Mukesh

---

From: Mukesh Gupta <[email-masked]>
Date: Sun, 9 Jan 2005 23:47:28 -0600

Vishwas,

Comments inline :)

> to "NULL encryption (for ESP) or no encryption (for AH)" ?

Ok.  We have consensus on one thing :)  We will take care of this
in the next rev.

> "SHOULD NOT" list of IETF/NIST.

I still don't quite agree with you here.  Lets hear from others
on this !  Acee, what is your opinion on this ?

> just directly pointing to the ESP/AH algorithms document).

I will cover this in the separate mail.  I am frankly quite
confused about what we want here :)

> VM> As long as you put the text for the DoS case too, I am 
> ok. Else let us directly point to the vulnerabilities draft without 
> mentioning cases.

Another try on the text :)  How about the following + the already
existing text that refers to the vulnerability draft ?
===
"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 which can lead to DoS attack on the network."
===

> So it is not about ESN alone. DSCP was one example I had pointed out

Would you be kind enough to propose some specific text and the place
in the draft where it should be added ?

> Thanks and sorry for bothering you,

You are not bothering us !  Thanks to you for reviewing the draft 
so many times and spending so much time on the issues.  We appreciate 
it !

Regards
Mukesh

---

From: Mukesh Gupta <[email-masked]>
Date: Mon, 10 Jan 2005 12:00:25 -0600

Mitchell,

Please read all the text and not just the first paragraph ;)

The text does mandate ALL the encryption/authentication algorithms
that are MUST in the IPsec mandatory to implement algorithms.  So
the implementations will be interoperable if they are compliant
with this spec.

Any platform OS that supports IPsec will have to be compliant
with the IPsec mandatory to implement algorithms specfication
and then it is just the matter of exposing all those algorithms
to the OSPFv3 security configuration.  So it is not a big deal
to provide all the algorithms that are MUST in IPsec RFCs.

Regards
Mukesh

> From: Mailing List [mailto:[email-masked]]On Behalf Of ext
> Erblichs
> Sent: Monday, January 10, 2005 4:35 AM
> Wow,
> > 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.
> > 
> 
> 	Sorry, I am lost with this. The devil in me says that
> 	this means to DELAY" this RFC until a SECURE algorithm
> 	that will NEVER need to be changed is identified.
> 
> 	OSPF has specified features and is documented and is changed
> 	in the future with later RFCs.
> 
> 	What is wrong with guaranteeing that at least one algoritm
> 	is specified for interoperability?
> 
> 	Then as better algorithms are identified, then they are
> 	specified in later docs and superseed earlier algorithms.
> 	Then only the first algorithm is a MUST support and later
> 	algorithms need  be a SHOULD supported for later 
> 	compatibility.
> 	Right..
> 	Yes, the full set could be supported, but is probably not
> 	a must, since the first is guaranteed...
> 
> 	Thus, isn't at least one specified so so algorithm better than
> 	guaranteeing  NULL for encryption, etc?
> 
> 	Mitchell Erblich
> 	----------------
> 
> Vishwas Manral wrote:
> > 
> > Hi Mukesh,
> > 
> > I am ok with the text.
> > 
> > Thanks,
> > Vishwas
> > Sent: Monday, January 10, 2005 12:09 PM
> > 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
> > 
> > > From: Mailing List [mailto:[email-masked]]On 
> Behalf Of ext
> > > Vishwas Manral
> > > Sent: Sunday, January 09, 2005 8:17 PM

---

From: Mukesh Gupta <[email-masked]>
Date: Tue, 11 Jan 2005 15:51:07 -0600

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

I don't know of any that is provides recommendations for
routing protocols !

- Mukesh