Re: Questions about OSPF v3 security draft

[Vishwas Manral <[e-mail]>]

Hi Mike,

Sorry for the delay. I may be wrong as I have not implemented this myself, however my views are as follows: -

If you see the SPD entry the Remote IP Address can be 
      "- Remote IP Address(es) (IPv4 or IPv6): this is a list of ranges
        of IP addresses (unicast, anycast, broadcast (IPv4 only), or
                multicast group). "
So for OSPF the Multicast as well as the unicast addresses will be used to refer to an SA.

Next Layer Protocol would say OSPF.

That way we will have just one entry for all OSPF packets out of an interface, just as we want it and a similar entry for inbound traffic. I do not see a case of Full Mesh at all. I may be missing the point.

Thanks,
Vishwas
________________________________________
From: Mailing List [mailto:[e-mail]] On Behalf Of Mike Fox
Sent: Friday, February 25, 2005 2:58 AM
To: [e-mail]
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 <[e-mail]> 
Sent by: Mailing List <[e-mail]> 
02/15/2005 12:01 AM 
Please respond to Mailing List 
        
        To:        [e-mail] 
        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:[e-mail]] On Behalf Of Mike Fox
Sent: Friday, February 11, 2005 8:04 PM
To: [e-mail]
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