Subject: More comments and questions on OSPFv3 security draft

From: Mike Fox <[email-masked]>
Date: Tue, 17 May 2005 13:52:12 -0600

Back in Feburary and March I had a dialog with Vishwas involving some 
questions on the OSPFv3 security draft.  Our security expert has asked for 
some additional clarification, here is his comment: 

My comment is based on the following from RFC 2401 (section 4.1): 

A security association is uniquely identified by a triple consisting
   of a Security Parameter Index (SPI), an IP Destination Address, and a
   security protocol (AH or ESP) identifier.  In principle, the
   Destination Address may be a unicast address, an IP broadcast
   address, or a multicast group address.  However, IPsec SA management
   mechanisms currently are defined only for unicast SAs.  Hence, in the
   discussions that follow, SAs will be described in the context of
   point-to-point communication, even though the concept is applicable
   in the point-to-multipoint case as well.

As noted above, two types of SAs are defined: transport mode and
   tunnel mode.  A transport mode SA is a security association between
   two hosts.

Comment: Certainly an SPD can have a ranged address that points to the 
same SA. This is how you would set up an SPD in a firewall for tunnel mode 
traffic. That is, a range of addresses for a network (not on the firewall) 
can use a single SA. The destination IP address is an IPSec SA endpoint. 
However, the SA must adhere to the definition above. For unicast transport 
mode, I read this to be that the destination address is a single IP 
address not a range. I suggest that the OSPFv3 security draft specify 
exactly how the manual SAs would need to be set up to be compliant. I 
don't think there is anything in RFC 2401 that allows a range of unicast 
IP addresses to be "a unicast address". 

And since it has been a while, here is the string of notes he is 
commenting on: 

Vishwas Manral <[email-masked]>
Sent by: Mailing List <[email-masked]>
03/01/2005 05:59 AM
Please respond to Mailing List
 
        To:     [email-masked]
        cc: 
        Subject:        Re: Questions about OSPF v3 security draft

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

-----------------------------------------------------------------------
Enterprise Network Solutions
-----------------------------------------------------------------------
Research Triangle Park, NC  USA

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 17 May 2005 20:27:53 -0700

Hi Mike,

The quote I refer to is from 2401bis(which is with the IESG), which
replaces 2401.

I would be ok if any clarification is added though.

Thanks,

Vishwas

________________________________

From: Mailing List [mailto:[email-masked]] On Behalf Of Mike
Fox
Sent: Wednesday, May 18, 2005 1:22 AM
To: [email-masked]
Subject: More comments and questions on OSPFv3 security draft

Back in Feburary and March I had a dialog with Vishwas involving some
questions on the OSPFv3 security draft.  Our security expert has asked
for some additional clarification, here is his comment:   

Comment: Certainly an SPD can have a ranged address that points to the
same SA. This is how you would set up an SPD in a firewall for tunnel
mode traffic. That is, a range of addresses for a network (not on the
firewall) can use a single SA. The destination IP address is an IPSec SA
endpoint. However, the SA must adhere to the definition above. For
unicast transport mode, I read this to be that the destination address
is a single IP address not a range. I suggest that the OSPFv3 security
draft specify exactly how the manual SAs would need to be set up to be
compliant. I don't think there is anything in RFC 2401 that allows a
range of unicast IP addresses to be "a unicast address". 

 

03/01/2005 05:59 AM 

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.

Thanks,
Vishwas

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

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 

Regarding

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