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 <Vishwas at SINETT.COM> Sent by: Mailing List <OSPF at PEACH.EASE.LSOFT.COM>
03/01/2005 05:59 AM
Please respond to Mailing List
To:
OSPF at PEACH.EASE.LSOFT.COM
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:OSPF at PEACH.EASE.LSOFT.COM] On Behalf Of Mike
Fox
Sent: Friday, February 25, 2005 2:58 AM
To: OSPF at 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 at SINETT.COM>
Sent by: Mailing List <OSPF at PEACH.EASE.LSOFT.COM>
02/15/2005 12:01 AM
Please respond to Mailing List
To: OSPF at 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.
From: Mailing List [mailto:OSPF at PEACH.EASE.LSOFT.COM] On Behalf Of Mike
Fox
Sent: Friday, February 11, 2005 8:04 PM
To: OSPF at 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
-----------------------------------------------------------------------
Enterprise Network Solutions
-----------------------------------------------------------------------
Research Triangle Park, NC USA