Hi Mike,
The quote I refer to is from 2401bis(which
is with the IESG), which replaces 2401.
"- Remote IP Address(es) (IPv4 or IPv6): this
is a list of ranges
of IP addresses
(unicast, anycast, broadcast (IPv4 only), or
multicast group).
"
I would be ok if any clarification is added though.
Thanks,
Vishwas
From: Mailing List [mailto:OSPF at PEACH.EASE.LSOFT.COM] On Behalf Of Mike Fox
Sent: Wednesday, May 18, 2005 1:22
AM
To: OSPF at PEACH.EASE.LSOFT.COM
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:
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.
Thanks,
Vishwas
________________________________________
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