Re: Questions about OSPF v3 security draft

Vishwas Manral <Vishwas@SINETT.COM> Tue, 01 March 2005 11:08 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12374 for <ospf-archive@LISTS.IETF.ORG>; Tue, 1 Mar 2005 06:08:06 -0500 (EST)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00FB97B1@cherry.ease.lsoft.com>; Tue, 1 Mar 2005 6:08:06 -0500
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59809696 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 1 Mar 2005 06:08:04 -0500
Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 1 Mar 2005 06:04:39 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51E4E.762411A3"
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Thread-Topic: Questions about OSPF v3 security draft
thread-index: AcUauTfThfjJMmqZQmOoBQu1s8WJNADlknoA
Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B26A1FDC@sinett-sbs.SiNett.LAN>
Date: Tue, 01 Mar 2005 03:04:38 -0800
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Vishwas Manral <Vishwas@SINETT.COM>
Subject: Re: Questions about OSPF v3 security draft
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Hi Mike,

 

I forgot to mention, we do know a lot of issues with the security
provided using the manual keying methods. We had a long discussion with
the Security as well as Routing AD's and now in a stage of working to
bring out a draft on the issues as a first step and the probably work on
possible solutions.

 

Thanks,

Vishwas

________________________________

From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike
Fox
Sent: Friday, February 25, 2005 2:58 AM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: Questions about OSPF v3 security draft

 


Vishwas, 

I shared your response with our security expert and here is his
response: 

What we need to know is whether the paragraph is referring to unicast. "
What it means is we will use the same crypto-algorithm and keys for all
traffic to a neighbor over an interface." If this comment is referring
to unicast, the point remains is that there will be multiple SAs. We
will not be able to adhere to the figure 3 requirements for unicast, and
there will be full meshing of SAs required between all communicating
OSPFs. Not so bad if using IKE. Really bad if using manual SAs.   

Here is the thread of notes being referred to (since it's been a couple
of weeks): 

 

Vishwas Manral <Vishwas@SINETT.COM> 
Sent by: Mailing List <OSPF@PEACH.EASE.LSOFT.COM> 

02/15/2005 12:01 AM 
Please respond to Mailing List 

        
        To:        OSPF@PEACH.EASE.LSOFT.COM 
        cc:         
        Subject:        Re: Questions about OSPF v3 security draft




Hi Mike, 
  
I think both the authors are on leave, so they will probably reply
later. 
  
However regarding the first point, I agree the wording should be
clearer. However what it means is we will use the same crypto-algorithm
and keys for all traffic to a neighbor over an interface. 
  
Regarding the second point, I think I too have brought the issue on this
list and the reply I think was that the draft does not prohibit the use
of IKE for unicast flows. 
 

Thanks, 
Vishwas 

 

________________________________


From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike
Fox
Sent: Friday, February 11, 2005 8:04 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Questions about OSPF v3 security draft 
  

Regarding
http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt,
and the previous drafts, a couple of questions have come up in our shop.


1) Section 7, 2nd paragraph says "the implementations MUST use manually
configured keys with same SA for inbound and outbound traffic (as shown
in figure 3).  I assume the "same SA" MUST rule applies to multicast
traffic only and not unicast traffic. This is because an SA is defined
as an SPI, security protocol (AH or ESP), and destination IP address.
For unicast addresses, by definition there will be as many SAs as there
are unicast destination addresses. Therefore, I don't think it is
possible to apply this MUST rule given the current IPSec definition (RFC
2401 section 4.1) of an SA for unicast. Assuming the intention of the
draft was to apply only to multicast and given the number of potential
SAs carrying unicast traffic, it would seem that using IKE to setup the
SAs dynamically would be a reasonable alternative to manual keying.     
 
2)Section 9, 2nd paragraph discusses setting up a "secure IPSec channel
dynamically once it acquires the required information".  Since this
traffic is unicast only, IKE could easily set up the required SAs
without knowing the specific IP addresses in advance. Creating SAs
dynamically do not fit easily within scope of manual SA functional
capabilities. Why not use IKE for this traffic? Is this an acceptable
option?   

Mike