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

From: Mukesh Gupta <[email-masked]>
Date: Wed, 29 Dec 2004 15:21:27 -0600

Alex/Bill,

06 version of the OSPFv3 Security draft addresses the 
following comments/issues:

From IESG:
- Discuss about how much protection OSPF has for replay 
  attacks without the security enabled
- Add references to 3602 and 2404
- Analyze and recommend values of rekeying interval and KeyRolloverInterval
- Spell out in the security considerations that one router can impersonate another
- Larger routing security not considered here (refer to rpsec)
  i.e., "What's left to worry about after you deploy this?"
- Refer to rpsec drafts

From authors:
- MUST requirement for hex format keys.  This will significantly 
  increase the entropy of the keys.

We have addressed all the comments from IESG and we think that
this version is ready to be reviewed by IESG again.

Regards
Mukesh & Suresh

> -----Original Message-----
> From: Mailing List [mailto:[email-masked]]On Behalf Of ext
> [email-masked]
> Sent: Wednesday, December 29, 2004 12:41 PM
> To: [email-masked]
> Subject: I-D ACTION:draft-ietf-ospf-ospfv3-auth-06.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Open Shortest Path First IGP 
> Working Group of the IETF.
> 
> 	Title		: Authentication/Confidentiality for OSPFv3
> 	Author(s)	: M. Gupta, N. Melam
> 	Filename	: draft-ietf-ospf-ospfv3-auth-06.txt
> 	Pages		: 15
> 	Date		: 2004-12-29
> 	
> This document describes means/mechanisms to provide 
> authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension 
> Header.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-06.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in 
> the body of the message.  
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-ospf-ospfv3-auth-06.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-06.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

---

From: Bill Fenner <[email-masked]>
Date: Wed, 29 Dec 2004 14:21:54 -0800

Thanks, Mukesh.  I'll review it and put it on the IESG agenda for
January 6th.

  Bill

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 29 Dec 2004 21:09:56 -0800

Hi Mukesh and Suresh,
 
I went through the draft and think it is in pretty good shape now and seems most of my comments are taken care of. However :-
 
1. In the draft you state that there are know known problems of replaying DB packets. Replaying a DB packet can result in the entrie database being exchanged again which is a CPU heavy process.
2. Similar issues with LS request packets.
3.  Though we have addressed the case of specifying some default/supported values, I think we do not do that for all optional parameters. e.g. ESN etc.
4. We can have multiple SA's between two routers. When DSCP is supported should the same SA be used or should multiple SA's be used?
 
Thanks,
Vishwas

________________________________

From: Mailing List on behalf of Mukesh Gupta
Sent: Wed 12/29/2004 1:21 PM
To: [email-masked]
Subject: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review

Alex/Bill,

From IESG:

From authors:

Regards
Mukesh & Suresh

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 29 Dec 2004 21:09:56 -0800

Hi Mukesh and Suresh,

 
Thanks,
Vishwas

Alex/Bill,

From IESG:

From authors:

Regards
Mukesh & Suresh

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 29 Dec 2004 21:55:32 -0800

Hi,
 
Some more minor comments: -
 
1. In "Rekeying Interval" You are giving examples only for ESP, but it is never stated that we are talking only of ESP(and not AH).
2.  You state 
" DES Encryption and HMAC-MD5 Authentication will be more secure
   because of the additional security provided by DES"
but the draft http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-ah-algorithms-02.txt
very clearly states that for AH/ESP we should not use DES(for well known reasons) 
      "SHOULD NOT     DES-CBC [RFC 2405] (3)". I am not sure if we want to mention DES at all.
3. The section 12, is states the mandatory "encryption and authentication algorithms" but does not state the key size to be used for AES-CBC.
4. On another front instead of having one draft specifying both the support as well as the algorithm's used, would we want a seperate draft for supported algorithms. This allows us to change the supported algorithms even when the base OSPFv3 for IPSec stays the same e.g. when vulnerabilities are found in the algorithm or when key sizes have to be made bigger. This is how it is done in the IPSec working group too(where AH/ESP algorithm's have been seperated from the supported algorithms).
 
Thanks,
Vishwas

--------------------------------------------------------------------------------
From: Mailing List on behalf of Vishwas Manral
Sent: Wed 12/29/2004 9:09 PM
To: [email-masked]
Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review

Hi Mukesh and Suresh,
 
Alex/Bill,

---

From: Mukesh Gupta <[email-masked]>
Date: Thu, 30 Dec 2004 16:01:19 -0600

Vishwas,

Thanks for reviewing the draft again.  Please see my comments
inline..

> 1. In the draft you state that there are know known problems 
> of replaying DB packets. Replaying a DB packet can result in 
> the entrie database being exchanged again which is a CPU 
> heavy process.

Though we trusted section 3.2.3 of the draft 
draft-ietf-rpsec-ospf-vuln-01.txt to make those statements,
isn't it true that the duplicate DD packets are just discarded 
if the adjacency is already in FULL state ?

Yes there are resource consumption problems with replayed
LSR packets.  Should we replace text

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

> 3.  Though we have addressed the case of specifying some 
> default/supported values, I think we do not do that for all 
> optional parameters. e.g. ESN etc.

Sorry ! I do not understand which default/supported values 
you are talking about here :(  Could you please be a little
more specific?

> 4. We can have multiple SA's between two routers. When DSCP 
> is supported should the same SA be used or should multiple 
> SA's be used?

Do you see any problems in any way ?  I would leave it to the
administrator if they want to use the same SA or the different
ones.

Regards
Mukesh

---

From: Mukesh Gupta <[email-masked]>
Date: Thu, 30 Dec 2004 16:01:19 -0600

Vishwas,

with

Regards
Mukesh

---

From: Mukesh Gupta <[email-masked]>
Date: Thu, 30 Dec 2004 16:14:23 -0600

Vishwas,

Comments inline...

> 1. In "Rekeying Interval" You are giving examples only for 
> ESP, but it is never stated that we are talking only of 
> ESP(and not AH).

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 ?

> but the draft draft-ietf-ipsec-esp-ah-algorithms-02.txt
> very clearly states that for AH/ESP we should not use DES
> (for well known reasons) "SHOULD NOT DES-CBC [RFC 2405] (3)".
> I am not sure if we want to mention DES at all.

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.

> 3. The section 12, is states the mandatory "encryption 
> and authentication algorithms" but does not state the key 
> size to be used for AES-CBC.

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?

> 4. On another front instead of having one draft specifying 
> both the support as well as the algorithm's used, would we 
> want a seperate draft for supported algorithms. This allows 
> us to change the supported algorithms even when the base 
> OSPFv3 for IPSec stays the same e.g. when vulnerabilities 
> are found in the algorithm or when key sizes have to be 
> made bigger. This is how it is done in the IPSec working 
> group too(where AH/ESP algorithm's have been seperated 
> from the supported algorithms).

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.

Regards
Mukesh

---

From: Mukesh Gupta <[email-masked]>
Date: Thu, 30 Dec 2004 16:14:23 -0600

Vishwas,

Comments inline...

Regards
Mukesh

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 30 Dec 2004 20:34:27 -0800

Hi Mukesh,

My comments prefixed with a VM>.
> 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.

> mandates the usage of AES so it is inline with the other
VM> I do not think we should use examples of schemes, which have been 
mentioned as "SHOULD NOT" by the IETF/NIST.

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

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

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

> you are talking about here :(  Could you please be a little
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.

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?

Thanks,
Vishwas