|
List Info
Thread: Review of draft-ietf-msec-ipsec-extensions-01
|
|
| Review of
draft-ietf-msec-ipsec-extensions-01 |
|
2006-06-15 10:04:55 |
Hi all,
[Disclaimer: Reviewing as an MSEC contributor. Ran or I
will have to
do a "WG chair" review some time before
forwarding this to the IESG.]
I reviewed the first 5 sections. You have a lot of stuff on
NATs and
NATs are boring to me. I will review that some other time.
Lakshminath
>MSEC Working Group
B. Weis
>Internet-Draft
Cisco Systems
>Expires: August, 2006
G. Gross
>
IdentAware Security
>
D. Ignjatic
>
Polycom
>
February, 2006
>
> Multicast Extensions to the Security Architecture
for the Internet
> Protocol
>
draft-ietf-msec-ipsec-extensions-01.txt
<snip>
>Abstract
>
> The Security Architecture for the Internet Protocol
[RFC4301]
> describes security services for traffic at the IP
layer. That
> architecture primarily defines services for Internet
Protocol (IP)
> unicast packets, as well as manually configured IP
multicast packets.
> This document further defines the security services
for IP multicast
> packets within that Security Architecture.
I think the last sentence needs to be revised. If 4301
supports
security services for manually configured IP multicast,
perhaps this
draft specifies dynamically keyed multicast security
services using
IPsec? What else?
><snip>
>Table of Contents
>
>1.0
Introduction................................................
.......2
> 1.1
Scope.......................................................
.....3
> 1.2
Terminology.................................................
.....3
>2.0 Overview of IP Multicast
Operation.................................5
>3.0 Security Association
Modes.........................................5
> 3.1 Tunnel Mode with Address
Preservation............................6
>4.0 Security
Association...............................................7
> 4.1 Major IPsec
Databases............................................7
> 4.1.1 Security Policy Database
(SPD)...............................7
> 4.1.2 Security Association Database
(SAD)..........................7
> 4.1.3 Peer Authorization Database
(PAD)............................8
> 4.1.4 Group Security Association
(GSA).............................9
GSA is not a database, is it? Perhaps this belongs in
4.1.2?
> 4.2 Data Origin
Authentication......................................11
> 4.3 Group SA and Key
Management.....................................11
> 4.3.1 Co-Existence of Multiple Key Management
Protocols...........11
> 4.3.2 New Security Association
Attributes.........................12
>5.0 IP Traffic
Processing.............................................12
> 5.1 Outbound IP Multicast Traffic
Processing........................12
> 5.2 Inbound IP Multicast Traffic
Processing.........................12
>6.0 Networking
Issues.................................................12
> 6.1 Network Address
Translation.....................................13
> 6.1.1 SPD Losses Synchronization with Internet
Layer's State......13
> 6.1.2 Secondary Problems Created by NAT
Traversal.................14
> 6.1.3 Avoidance of NAT Using an IPv6 Over IPv4
Network............15
> 6.1.4 GKMP/IPsec Multi-Realm IPv4 NAT
Architecture................16
Is NAT the only issue? If so, I suggest moving 6.1 up to
6.0
level. I guess more on this in the actual text.
>7.0 Security
Considerations...........................................19
>8.0 IANA
Considerations..............................................
.19
>9.0
Acknowledgements............................................
......19
>10.0
References..................................................
.....19
> 10.1 Normative
References...........................................19
> 10.2 Informative
References.........................................20
>Appendix A - Multicast Application Service
Models.....................22
I am not reviewing the Appendix in this round. (Too tired!
 )
> A.1 Unidirectional Multicast
Applications...........................22
Is this mcast only?
> A.2 Bi-directional Reliable Multicast
Applications..................22
Is this mcast, with a reverse channel?
> A.3 Any-To-Any Multicast
Applications...............................23
Multi-sender mcast?
>Author's
Address.....................................................
.24
>Intellectual Property
Statement.......................................25
>Copyright
Statement...................................................
25
>
>1.0 Introduction
>
> The Security Architecture for the Internet Protocol
[RFC4301]
> provides security services for traffic at the IP
layer. It describes
>
>
>Weis, et al. Expires August, 2006
[Page 2]
>
>Internet-Draft Multicast Extensions to RFC 4301
June, 2005
><snip>
>Some support for IP
> packets with a multicast address in the IP
destination field is
> supported, but only with manual keying, and only
between IPsec
> devices acting as hosts.
Please rewrite that sentence. The word
"support" is repeated.
> This document describes extensions to RFC 4301 that
further define
> the IPsec security architecture for groups of IPsec
devices to share
> SAs. In particular, it supports SAs with traffic
selectors that
> include a multicast address in the IP destination
field, and results
> in an IPsec packet with an IP multicast address in
the IP destination
> field. It also describes additional semantics for
IPsec Group Key
> Management Protocol (GKMP) Subsystems.
GKMP is RFC 2093. I'd rather we not reuse that acronym.
Perhaps IPsec with GSAs or something like that is more
generic?
>1.1 Scope
>
> The IPsec extensions described in this document
support IPsec
> Security Associations that result in IPsec packets
with IPv4 or IPv6
> multicast group addresses as the destination
address. Both Any-Source
> Multicast (ASM) and Source-Specific Multicast (SSM)
[RFC3569]
> [RFC3376] group addresses are supported.
>
> These extensions also support Security Associations
with IPv4
> Broadcast addresses that result in an IPv4 Broadcast
packet,
Does this mean link level or subnet level broadcast? Please
clarify.
> and IPv6
> Anycast addresses [RFC2526]that result in an IPv6
Anycast packet.
Really? I am surprised that you are covering anycast. Will
look for
more details later in the I-D.
> These destination address types share many of the
same
> characteristics of multicast addresses because there
may be multiple
> receivers of a packet protected by IPsec.
>
> The IPsec Architecture does not make requirements
upon entities not
s/Architecture/architecture
> participating in IPsec (e.g., network devices
between IPsec
> endpoints). As such, these multicast extensions do
not require
> intermediate systems in a multicast enabled network
to participate in
> IPsec. In particular, no requirements are placed on
the use of
> multicast routing protocols (e.g., PIM-SM [RFC2362])
or multicast
> admission protocols (e.g., IGMP [RFC3376].
>
> All implementation models of IPsec (e.g.,
"bump-in-the-stack", "bump-
> in-the-wire") are supported.
Nice and limited scope. I like it. (Except for the anycast
stuff of course).
>1.2 Terminology
>
>
>
>
>Weis, et al. Expires August, 2006
[Page 3]
>
>Internet-Draft Multicast Extensions to RFC 4301
June, 2005
>
>
> The key words "MUST", "MUST
NOT", "REQUIRED", "SHALL",
"SHALL NOT",
> "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and
"OPTIONAL" in this
> document are to be interpreted as described in RFC
2119 [RFC2119].
>
>
> The following key terms are used throughout this
document.
>
> Any-Source Multicast (ASM)
> The Internet Protocol (IP) multicast service
model as defined in
> RFC 1112 [RFC1112]. In this model one or more
senders source
> packets to a single IP multicast address. When
receivers join the
> group, they receive all packets sent to that IP
multicast address.
> This is known as a (*,G) group.
>
> Group Controller Key Server (GCKS)
> A Group Key Management Protocol (GKMP) server
that manages IPsec
Could we not use something like "A group key server
that ..."?
I am trying to get you to delete the use of GKMP and the
notion of
GKMP as a keyword in this document.
> state for a group. A GCKS authenticates and
provides the IPsec SA
> policy and keying material to GKMP group members.
>
> Group Key Management Protocol (GKMP)
> A key management protocol used by a GCKS to
distribute IPsec
> Security Association policy and keying material.
A GKMP is used
> when a group of IPsec devices require the same
SAs. For example,
> when an IPsec SA describes an IP multicast
destination, the sender
> and all receivers must have the group SA.
Not sure about the latter part of the above para. Access
controlled
groups would require that all members (or receivers) to join
the
group via IGMP and request GSA from the GCKS. So, I don't
think it
really depends on the IP multicast destination (address?)
per
se. How about something like "members of a secure
group?"
> Group Key Management Protocol Subsystem
> A subsystem in an IPsec device implementing a
Group Key Management
> Protocol. The GKMP Subsystem provides IPsec SAs
to the IPsec
> subsystem on the IPsec device.
Why not use the notion of GSA with the third SA, the Data
security
SA, being the IPsec SA? 4046 would be a good guide there.
> Group Member
> An IPsec device that belongs to a group. A Group
Member is
> authorized to be a Group Speaker and/or a Group
Receiver.
I am not too crazy about this definition. Secure group
members don't
necessarily have to implement IPsec, right?
> Group Owner
> An administrative entity that chooses the policy
for a group.
>
> Group Security Association (GSA)
> A collection of IPsec Security Associations (SAs)
and GKMP
> Subsystem SAs necessary for a Group Member to
receive key updates.
> A GSA describes the working policy for a group.
GSA is defined in 4046, no?
> Group Receiver
> A Group Member that is authorized to receive
packets sent to a
> group by a Group Speaker.
>
> Group Speaker
> A Group Member that is authorized to send packets
to a group.
><snip>
> Tunnel Mode with Address Preservation
> A type of IPsec tunnel mode used by security
gateway
> implementations when encapsulating IP multicast
packets such that
> they remain IP multicast packets. This mode is
necessary for IP
> multicast routing to correctly route IP multicast
packets
> protected by IPsec.
This probably deserves more description, perhaps that comes
latter?
>2.0 Overview of IP Multicast Operation
>
> IP multicasting is a means of sending a single
packet to a "host
> group", a set of zero or more hosts identified
by a single IP
> destination address. IP multicast packets are UDP
data packets
> delivered to all members of the group with either
"best-effort"
> [RFC1112], or reliable delivery (e.g., NORM)
[RFC3940].
>
> A sender to an IP multicast group sets the
destination of the packet
> to an IP address allocated to be used for IP
multicast. Allocated IP
> multicast addresses are defined in RFC 3171
[RFC3171]. Potential
> receivers of the packet "join" the IP
multicast group by registering
> with a network routing device, signaling its intent
to receive
> packets sent to a particular IP multicast group.
4291 IPv6 addressing architecture and 2375 are additional
references
to include here.
> Network routing devices configured to pass IP
multicast packets
> participate in multicast routing protocols (e.g.,
PIM-SM) [RFC2362].
> Multicast routing protocols maintain state regarding
which devices
> have registered to receive packets for a particular
IP multicast
> group.
Your sentence below is more precise than the one above. I
think
device level information is not kept, instead the presence
of absence
of receivers (one is as good as a thousand) on an interface
basis is
maintained.
>When a router receives an IP multicast packet, it
forwards a
> copy of the packet out each interface for which
there are known
> receivers.
>
>3.0 Security Association Modes
>
> IPsec supports two modes of use: transport mode and
tunnel mode. In
> transport mode, IP Authentication Header (AH)
[RFC4302] and IP
> Encapsulating Security Payload (ESP) [RFC4303]
provide protection
> primarily for next layer protocols; in tunnel mode,
AH and ESP are
> applied to tunneled IP packets.
>
> A host implementation of IPsec using the multicast
extensions MAY use
> both transport mode and tunnel mode to encapsulate
an IP multicast
both or either?
><snip>
>3.1 Tunnel Mode with Address Preservation
I can appreciate the requirement, I think. If I am not
mistaken,
wouldn't there be three cases here? There could be a
sender which
cannot IPsec encapsulate and relies on a GW to encrypt and
all
members/receivers can decapsulate IPsec on their own. In
the second
case, a GW decapsulates for some or all members. Finally a
combination of the two.
Would there be implications on the GW to join the multicast
in the
reception case?
It would also be worthwhile to have before and packet
headers as in
4302 and 4303.
Would header compression be possible, given that the inner
and outer
headers might be the same?
>4.0 Security Association
>
>4.1 Major IPsec Databases
>
> The following sections describe the GKMP Subsystem
and IPsec
> extension interactions with the major IPsec
databases. Major IPsec
> databases need to be expanded in order to fully
support multicast.
>
>4.1.1 Security Policy Database (SPD)
><snip>
> SPD entries created by a GCKS may be assigned
identical SPIs to SPD
> entries created by IKEv2 [RFC4306]. This is not a
problem for the
> inbound traffic as the appropriate SAs can be
matched using the
> algorithm
State the section number to avoid ambiguity.
>described in RFC 4301. In addition, SAs with identical
SPI
> values but not manually keyed can be differentiated
because they
> contain a link to their parent SPD entries. However,
the outbound
> traffic needs to be matched against the SPD
selectors so that the
> appropriate SA can be created on packet arrival.
IPsec
> implementations that support multicast SHOULD use
the destination
Why not MUST? Please state the exceptions to the SHOULD if
there are any.
> address as the additional selector and match it
against the SPD
> entries marked "sender only".
>
>4.1.2 Security Association Database (SAD)
>
> The Security Association Database (SAD) can support
multicast SAs, if
> manually configured. An outbound multicast SA has
the same structure
>
>Weis, et al. Expires August, 2006
[Page 7]
>
>Internet-Draft Multicast Extensions to RFC 4301
June, 2005
>
>
> as a unicast SA. The source address is that of the
sender and the
> destination address is the multicast group address.
An inbound,
> multicast SA must be configured with the source
addresses of each
> peer authorized to transmit to the multicast SA in
question. The SPI
> value for a multicast SA is provided by a GCKS, not
by the receiver,
> as for a unicast SA. This is similar to the unicast
case and does not
> require changes to SAD.
> However, the SPD needs a mechanism for automatic
multicast SA
> creation.
The above text seems like the text in 4301. Is this a
placeholder?
>4.1.3 Peer Authorization Database (PAD)
><snip>
> The PAD MUST provide a management interface
capability that allows an
> administrator to enforce that the scope of a GKMP
group's policy
> specified SPD/SAD modifications are restricted to
only those traffic
> data flows that belong to that group. This
authorization MUST be
> configurable at GKMP group granularity. In the
inverse direction, the
> PAD management interface MUST provide a mechanism(s)
to enforce that
> IKEv2 security associations do not negotiate traffic
selectors that
> conflict or override GKMP group policies. An
implementation SHOULD
> offer PAD configuration capabilities that authorize
the GKMP policy
> configuration mechanism to set security policy for
other aspects of
> an endpoint's SPD/SAD configuration, not confined
to its group
> security associations. This capability allows the
group's policy to
> inhibit the creation of back channels that might
otherwise leak
> confidential group application data.
I am not sure about the normative language above. I looked
at the
PAD stuff in 4301 and normative language was used quite
sparingly. We should probably discuss this more.
>
>
> - The Group Speaker's "trailing edge" SA
is the oldest security
> association in use by the group for that speaker.
All authorized
> Group Members can receive and decrypt data for
this SA, but the
> Group Speaker does not transmit new data using the
"trailing edge"
> SA after it has transitioned to the "leading
edge GSA". The
> trailing edge SA is deleted by the group's
endpoints according to
> group policy (e.g., after a defined period has
elapsed)"
So by this, may I assume that multiple (more than two) IPsec
SAs are
allowed to exist simultaneously?
<snip>
>Implementations MAY offer a Group
> Owner management interface option to enable/disable
re-key rollover
> continuity for a particular group This specification
requires that a
Missing a period above.
> GKMP/IPsec implementation MUST support at least two
concurrent GSA
> per Group Speaker and this re-key rollover
continuity algorithm.
I see that you are mandating the existence of multiple
simultaneous
IPsec SAs. Please make it a SHOULD. I know of at least one
use case
where rekeying would involve stopping transmission/reception
and
restarting after a new SA has been established.
>4.2 Data Origin Authentication
>
> As defined in [RFC3401], data origin authentication
is a security
> service that verifies the identity of the claimed
source of data.
> While HMAC authentication methods are often used to
provide data
> origin authentication, they are not sufficient to
provide data origin
> authentication for groups. With an HMAC, every group
member can use
> the HMAC key to create a valid authentication tag
whether or not they
> are the authentic origin.
>
> When the property of data origin authentication is
required for an
> IPsec SA distributed from a GKCS, an authentication
transform where
> the originator keeps a secret should be used. Two
possible algorithms
> are TESLA [RFC4082] or RSA [RFC4359].
>
> In some cases, (e.g., digital signature
authentication transforms)
> the processing cost of the algorithm is
significantly greater than an
> HMAC authentication method. To protect against
denial of service
> attacks from device that is not authorized to join
the group, the
> IPsec SA using this algorithm may be encapsulated
with an IPsec SA
> using an HMAC authentication algorithm. However,
doing so requires
> the packet to be sent across the IPsec boundary for
additional
> inbound processing [RFC4301, Section 5.2].
Not sure I understand the last two sentences. Please
explain. I can
appreciate the use of two auth tags, but not the concept of
two IPsec
SAs to do so.
>4.3 Group SA and Key Management
>
>4.3.1 Co-Existence of Multiple Key Management Protocols
><snip>
>4.3.2 New Security Association Attributes
>
> A number of new security association attributes are
defined in this
Two, really!
> document. Each GKMP supporting this architecture
MUST support the
> following list of attributes described elsewhere in
this document.
>
> - Address Preservation (Section 3.1). This attribute
describes
> whether address preservation is to be applied to the
SA on the source
> address, destination address, or both source and
destination
> addresses.
>
> - Direction attribute (Section 4.1.1). This
attribute describes
> whether the SPD direction is to be symmetric,
receiver only, or
> sender only.
Why are these listed again?
>5.0 IP Traffic Processing
>
> Processing of traffic follows [RFC4301, Section 5],
with the
> additions described below when these IP multicast
extensions are
> supported.
All of this probably belongs earlier. I have asked earlier
about hdr
removal when the inner and outer addresses are the same.
That was
proposed elsewhere and perhaps should be considered here.
<snip>
>6.0 Networking Issues
>
>
>
>Weis, et al. Expires August, 2006
[Page 12]
>
>Internet-Draft Multicast Extensions to RFC 4301
June, 2005
>
I ran out of steam here. I will do the rest some other time
(may be
tomorrow or something).
_______________________________________________
msec mailing list
msec securemulticast.org
http://
six.pairlist.net/mailman/listinfo/msec
|
|
| Review of
draft-ietf-msec-ipsec-extensions-01 |
|
2006-06-15 09:23:00 |
Hi Lakshminath,
thank you for taking the time to review the draft. in the
interest of
clarity, I'd like to suggest that we split our responses
into separate
threads, each with their own subject line. Brian, Dragan,
and I will
confer about our replies, and then post to the list. plz
stay tuned...
br
George
On Thu, 15 Jun 2006, Lakshminath Dondeti wrote:
> Hi all,
>
> [Disclaimer: Reviewing as an MSEC contributor. Ran or
I will have to
> do a "WG chair" review some time before
forwarding this to the IESG.]
>
> I reviewed the first 5 sections. You have a lot of
stuff on NATs and
> NATs are boring to me. I will review that some other
time.
>
> Lakshminath
>
> >MSEC Working Group
B. Weis
> >Internet-Draft
Cisco Systems
> >Expires: August, 2006
G. Gross
> >
IdentAware Security
> >
D. Ignjatic
> >
Polycom
> >
February, 2006
> >
> > Multicast Extensions to the Security
Architecture for the Internet
> > Protocol
> >
draft-ietf-msec-ipsec-extensions-01.txt
>
> <snip>
>
>
> >Abstract
> >
> > The Security Architecture for the Internet
Protocol [RFC4301]
> > describes security services for traffic at the
IP layer. That
> > architecture primarily defines services for
Internet Protocol (IP)
> > unicast packets, as well as manually configured
IP multicast packets.
> > This document further defines the security
services for IP multicast
> > packets within that Security Architecture.
>
> I think the last sentence needs to be revised. If 4301
supports
> security services for manually configured IP multicast,
perhaps this
> draft specifies dynamically keyed multicast security
services using
> IPsec? What else?
>
> ><snip>
>
>
> >Table of Contents
> >
> >1.0
Introduction................................................
.......2
> > 1.1
Scope.......................................................
.....3
> > 1.2
Terminology.................................................
.....3
> >2.0 Overview of IP Multicast
Operation.................................5
> >3.0 Security Association
Modes.........................................5
> > 3.1 Tunnel Mode with Address
Preservation............................6
> >4.0 Security
Association...............................................7
> > 4.1 Major IPsec
Databases............................................7
> > 4.1.1 Security Policy Database
(SPD)...............................7
> > 4.1.2 Security Association Database
(SAD)..........................7
> > 4.1.3 Peer Authorization Database
(PAD)............................8
> > 4.1.4 Group Security Association
(GSA).............................9
>
> GSA is not a database, is it? Perhaps this belongs in
4.1.2?
>
> > 4.2 Data Origin
Authentication......................................11
> > 4.3 Group SA and Key
Management.....................................11
> > 4.3.1 Co-Existence of Multiple Key Management
Protocols...........11
> > 4.3.2 New Security Association
Attributes.........................12
> >5.0 IP Traffic
Processing.............................................12
> > 5.1 Outbound IP Multicast Traffic
Processing........................12
> > 5.2 Inbound IP Multicast Traffic
Processing.........................12
> >6.0 Networking
Issues.................................................12
> > 6.1 Network Address
Translation.....................................13
> > 6.1.1 SPD Losses Synchronization with Internet
Layer's State......13
> > 6.1.2 Secondary Problems Created by NAT
Traversal.................14
> > 6.1.3 Avoidance of NAT Using an IPv6 Over IPv4
Network............15
> > 6.1.4 GKMP/IPsec Multi-Realm IPv4 NAT
Architecture................16
>
> Is NAT the only issue? If so, I suggest moving 6.1 up
to 6.0
> level. I guess more on this in the actual text.
>
> >7.0 Security
Considerations...........................................19
> >8.0 IANA
Considerations..............................................
.19
> >9.0
Acknowledgements............................................
......19
> >10.0
References..................................................
.....19
> > 10.1 Normative
References...........................................19
> > 10.2 Informative
References.........................................20
> >Appendix A - Multicast Application Service
Models.....................22
>
> I am not reviewing the Appendix in this round. (Too
tired! )
>
> > A.1 Unidirectional Multicast
Applications...........................22
>
> Is this mcast only?
>
> > A.2 Bi-directional Reliable Multicast
Applications..................22
>
> Is this mcast, with a reverse channel?
>
> > A.3 Any-To-Any Multicast
Applications...............................23
>
> Multi-sender mcast?
>
> >Author's
Address.....................................................
.24
> >Intellectual Property
Statement.......................................25
> >Copyright
Statement...................................................
25
> >
> >1.0 Introduction
> >
> > The Security Architecture for the Internet
Protocol [RFC4301]
> > provides security services for traffic at the
IP layer. It describes
> >
> >
> >Weis, et al. Expires August, 2006
[Page 2]
> >
> >Internet-Draft Multicast Extensions to RFC 4301
June, 2005
>
> ><snip>
>
> >Some support for IP
> > packets with a multicast address in the IP
destination field is
> > supported, but only with manual keying, and
only between IPsec
> > devices acting as hosts.
>
> Please rewrite that sentence. The word
"support" is repeated.
>
>
> > This document describes extensions to RFC 4301
that further define
> > the IPsec security architecture for groups of
IPsec devices to share
> > SAs. In particular, it supports SAs with
traffic selectors that
> > include a multicast address in the IP
destination field, and results
> > in an IPsec packet with an IP multicast address
in the IP destination
> > field. It also describes additional semantics
for IPsec Group Key
> > Management Protocol (GKMP) Subsystems.
>
> GKMP is RFC 2093. I'd rather we not reuse that
acronym.
>
> Perhaps IPsec with GSAs or something like that is more
generic?
>
>
> >1.1 Scope
> >
> > The IPsec extensions described in this document
support IPsec
> > Security Associations that result in IPsec
packets with IPv4 or IPv6
> > multicast group addresses as the destination
address. Both Any-Source
> > Multicast (ASM) and Source-Specific Multicast
(SSM) [RFC3569]
> > [RFC3376] group addresses are supported.
> >
> > These extensions also support Security
Associations with IPv4
> > Broadcast addresses that result in an IPv4
Broadcast packet,
>
> Does this mean link level or subnet level broadcast?
Please clarify.
>
> > and IPv6
> > Anycast addresses [RFC2526]that result in an
IPv6 Anycast packet.
>
> Really? I am surprised that you are covering anycast.
Will look for
> more details later in the I-D.
>
> > These destination address types share many of
the same
> > characteristics of multicast addresses because
there may be multiple
> > receivers of a packet protected by IPsec.
> >
> > The IPsec Architecture does not make
requirements upon entities not
>
> s/Architecture/architecture
>
> > participating in IPsec (e.g., network devices
between IPsec
> > endpoints). As such, these multicast extensions
do not require
> > intermediate systems in a multicast enabled
network to participate in
> > IPsec. In particular, no requirements are
placed on the use of
> > multicast routing protocols (e.g., PIM-SM
[RFC2362]) or multicast
> > admission protocols (e.g., IGMP [RFC3376].
> >
> > All implementation models of IPsec (e.g.,
"bump-in-the-stack", "bump-
> > in-the-wire") are supported.
>
> Nice and limited scope. I like it. (Except for the
anycast stuff of course).
>
>
> >1.2 Terminology
> >
> >
> >
> >
> >Weis, et al. Expires August, 2006
[Page 3]
> >
> >Internet-Draft Multicast Extensions to RFC 4301
June, 2005
> >
> >
> > The key words "MUST", "MUST
NOT", "REQUIRED", "SHALL",
"SHALL NOT",
> > "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and
"OPTIONAL" in this
> > document are to be interpreted as described in
RFC 2119 [RFC2119].
> >
> >
> > The following key terms are used throughout
this document.
> >
> > Any-Source Multicast (ASM)
> > The Internet Protocol (IP) multicast service
model as defined in
> > RFC 1112 [RFC1112]. In this model one or
more senders source
> > packets to a single IP multicast address.
When receivers join the
> > group, they receive all packets sent to that
IP multicast address.
> > This is known as a (*,G) group.
> >
> > Group Controller Key Server (GCKS)
> > A Group Key Management Protocol (GKMP)
server that manages IPsec
>
> Could we not use something like "A group key
server that ..."?
>
> I am trying to get you to delete the use of GKMP and
the notion of
> GKMP as a keyword in this document.
>
> > state for a group. A GCKS authenticates and
provides the IPsec SA
> > policy and keying material to GKMP group
members.
> >
> > Group Key Management Protocol (GKMP)
> > A key management protocol used by a GCKS to
distribute IPsec
> > Security Association policy and keying
material. A GKMP is used
> > when a group of IPsec devices require the
same SAs. For example,
> > when an IPsec SA describes an IP multicast
destination, the sender
> > and all receivers must have the group SA.
>
> Not sure about the latter part of the above para.
Access controlled
> groups would require that all members (or receivers) to
join the
> group via IGMP and request GSA from the GCKS. So, I
don't think it
> really depends on the IP multicast destination
(address?) per
> se. How about something like "members of a
secure group?"
>
>
> > Group Key Management Protocol Subsystem
> > A subsystem in an IPsec device implementing
a Group Key Management
> > Protocol. The GKMP Subsystem provides IPsec
SAs to the IPsec
> > subsystem on the IPsec device.
>
> Why not use the notion of GSA with the third SA, the
Data security
> SA, being the IPsec SA? 4046 would be a good guide
there.
>
>
> > Group Member
> > An IPsec device that belongs to a group. A
Group Member is
> > authorized to be a Group Speaker and/or a
Group Receiver.
>
> I am not too crazy about this definition. Secure group
members don't
> necessarily have to implement IPsec, right?
>
>
> > Group Owner
> > An administrative entity that chooses the
policy for a group.
> >
> > Group Security Association (GSA)
> > A collection of IPsec Security Associations
(SAs) and GKMP
> > Subsystem SAs necessary for a Group Member
to receive key updates.
> > A GSA describes the working policy for a
group.
>
> GSA is defined in 4046, no?
>
>
> > Group Receiver
> > A Group Member that is authorized to receive
packets sent to a
> > group by a Group Speaker.
> >
> > Group Speaker
> > A Group Member that is authorized to send
packets to a group.
>
> ><snip>
>
>
> > Tunnel Mode with Address Preservation
> > A type of IPsec tunnel mode used by security
gateway
> > implementations when encapsulating IP
multicast packets such that
> > they remain IP multicast packets. This mode
is necessary for IP
> > multicast routing to correctly route IP
multicast packets
> > protected by IPsec.
>
> This probably deserves more description, perhaps that
comes latter?
>
>
> >2.0 Overview of IP Multicast Operation
> >
> > IP multicasting is a means of sending a single
packet to a "host
> > group", a set of zero or more hosts
identified by a single IP
> > destination address. IP multicast packets are
UDP data packets
> > delivered to all members of the group with
either "best-effort"
> > [RFC1112], or reliable delivery (e.g., NORM)
[RFC3940].
> >
> > A sender to an IP multicast group sets the
destination of the packet
> > to an IP address allocated to be used for IP
multicast. Allocated IP
> > multicast addresses are defined in RFC 3171
[RFC3171]. Potential
> > receivers of the packet "join" the
IP multicast group by registering
> > with a network routing device, signaling its
intent to receive
> > packets sent to a particular IP multicast
group.
>
> 4291 IPv6 addressing architecture and 2375 are
additional references
> to include here.
>
>
> > Network routing devices configured to pass IP
multicast packets
> > participate in multicast routing protocols
(e.g., PIM-SM) [RFC2362].
> > Multicast routing protocols maintain state
regarding which devices
> > have registered to receive packets for a
particular IP multicast
> > group.
>
> Your sentence below is more precise than the one above.
I think
> device level information is not kept, instead the
presence of absence
> of receivers (one is as good as a thousand) on an
interface basis is
> maintained.
>
> >When a router receives an IP multicast packet, it
forwards a
> > copy of the packet out each interface for which
there are known
> > receivers.
> >
> >3.0 Security Association Modes
> >
> > IPsec supports two modes of use: transport mode
and tunnel mode. In
> > transport mode, IP Authentication Header (AH)
[RFC4302] and IP
> > Encapsulating Security Payload (ESP) [RFC4303]
provide protection
> > primarily for next layer protocols; in tunnel
mode, AH and ESP are
> > applied to tunneled IP packets.
> >
> > A host implementation of IPsec using the
multicast extensions MAY use
> > both transport mode and tunnel mode to
encapsulate an IP multicast
>
> both or either?
>
> ><snip>
>
>
> >3.1 Tunnel Mode with Address Preservation
>
> I can appreciate the requirement, I think. If I am not
mistaken,
> wouldn't there be three cases here? There could be a
sender which
> cannot IPsec encapsulate and relies on a GW to encrypt
and all
> members/receivers can decapsulate IPsec on their own.
In the second
> case, a GW decapsulates for some or all members.
Finally a
> combination of the two.
>
> Would there be implications on the GW to join the
multicast in the
> reception case?
>
> It would also be worthwhile to have before and packet
headers as in
> 4302 and 4303.
>
> Would header compression be possible, given that the
inner and outer
> headers might be the same?
>
>
> >4.0 Security Association
> >
> >4.1 Major IPsec Databases
> >
> > The following sections describe the GKMP
Subsystem and IPsec
> > extension interactions with the major IPsec
databases. Major IPsec
> > databases need to be expanded in order to fully
support multicast.
> >
> >4.1.1 Security Policy Database (SPD)
>
> ><snip>
>
> > SPD entries created by a GCKS may be assigned
identical SPIs to SPD
> > entries created by IKEv2 [RFC4306]. This is not
a problem for the
> > inbound traffic as the appropriate SAs can be
matched using the
> > algorithm
>
> State the section number to avoid ambiguity.
>
> >described in RFC 4301. In addition, SAs with
identical SPI
> > values but not manually keyed can be
differentiated because they
> > contain a link to their parent SPD entries.
However, the outbound
> > traffic needs to be matched against the SPD
selectors so that the
> > appropriate SA can be created on packet
arrival. IPsec
> > implementations that support multicast SHOULD
use the destination
>
> Why not MUST? Please state the exceptions to the
SHOULD if there are any.
>
> > address as the additional selector and match it
against the SPD
> > entries marked "sender only".
> >
> >4.1.2 Security Association Database (SAD)
> >
> > The Security Association Database (SAD) can
support multicast SAs, if
> > manually configured. An outbound multicast SA
has the same structure
> >
> >Weis, et al. Expires August, 2006
[Page 7]
> >
> >Internet-Draft Multicast Extensions to RFC 4301
June, 2005
> >
> >
> > as a unicast SA. The source address is that of
the sender and the
> > destination address is the multicast group
address. An inbound,
> > multicast SA must be configured with the source
addresses of each
> > peer authorized to transmit to the multicast SA
in question. The SPI
> > value for a multicast SA is provided by a GCKS,
not by the receiver,
> > as for a unicast SA. This is similar to the
unicast case and does not
> > require changes to SAD.
> > However, the SPD needs a mechanism for
automatic multicast SA
> > creation.
>
> The above text seems like the text in 4301. Is this a
placeholder?
>
>
> >4.1.3 Peer Authorization Database (PAD)
>
> ><snip>
>
>
> > The PAD MUST provide a management interface
capability that allows an
> > administrator to enforce that the scope of a
GKMP group's policy
> > specified SPD/SAD modifications are restricted
to only those traffic
> > data flows that belong to that group. This
authorization MUST be
> > configurable at GKMP group granularity. In the
inverse direction, the
> > PAD management interface MUST provide a
mechanism(s) to enforce that
> > IKEv2 security associations do not negotiate
traffic selectors that
> > conflict or override GKMP group policies. An
implementation SHOULD
> > offer PAD configuration capabilities that
authorize the GKMP policy
> > configuration mechanism to set security policy
for other aspects of
> > an endpoint's SPD/SAD configuration, not
confined to its group
> > security associations. This capability allows
the group's policy to
> > inhibit the creation of back channels that
might otherwise leak
> > confidential group application data.
>
> I am not sure about the normative language above. I
looked at the
> PAD stuff in 4301 and normative language was used quite
> sparingly. We should probably discuss this more.
>
>
> >
> >
> > - The Group Speaker's "trailing
edge" SA is the oldest security
> > association in use by the group for that
speaker. All authorized
> > Group Members can receive and decrypt data
for this SA, but the
> > Group Speaker does not transmit new data
using the "trailing edge"
> > SA after it has transitioned to the
"leading edge GSA". The
> > trailing edge SA is deleted by the group's
endpoints according to
> > group policy (e.g., after a defined period
has elapsed)"
>
> So by this, may I assume that multiple (more than two)
IPsec SAs are
> allowed to exist simultaneously?
>
> <snip>
>
> >Implementations MAY offer a Group
> > Owner management interface option to
enable/disable re-key rollover
> > continuity for a particular group This
specification requires that a
>
> Missing a period above.
>
> > GKMP/IPsec implementation MUST support at least
two concurrent GSA
> > per Group Speaker and this re-key rollover
continuity algorithm.
>
> I see that you are mandating the existence of multiple
simultaneous
> IPsec SAs. Please make it a SHOULD. I know of at
least one use case
> where rekeying would involve stopping
transmission/reception and
> restarting after a new SA has been established.
>
>
>
> >4.2 Data Origin Authentication
> >
> > As defined in [RFC3401], data origin
authentication is a security
> > service that verifies the identity of the
claimed source of data.
> > While HMAC authentication methods are often
used to provide data
> > origin authentication, they are not sufficient
to provide data origin
> > authentication for groups. With an HMAC, every
group member can use
> > the HMAC key to create a valid authentication
tag whether or not they
> > are the authentic origin.
> >
> > When the property of data origin authentication
is required for an
> > IPsec SA distributed from a GKCS, an
authentication transform where
> > the originator keeps a secret should be used.
Two possible algorithms
> > are TESLA [RFC4082] or RSA [RFC4359].
> >
> > In some cases, (e.g., digital signature
authentication transforms)
> > the processing cost of the algorithm is
significantly greater than an
> > HMAC authentication method. To protect against
denial of service
> > attacks from device that is not authorized to
join the group, the
> > IPsec SA using this algorithm may be
encapsulated with an IPsec SA
> > using an HMAC authentication algorithm.
However, doing so requires
> > the packet to be sent across the IPsec boundary
for additional
> > inbound processing [RFC4301, Section 5.2].
>
> Not sure I understand the last two sentences. Please
explain. I can
> appreciate the use of two auth tags, but not the
concept of two IPsec
> SAs to do so.
>
>
> >4.3 Group SA and Key Management
> >
> >4.3.1 Co-Existence of Multiple Key Management
Protocols
>
> ><snip>
>
>
> >4.3.2 New Security Association Attributes
> >
> > A number of new security association attributes
are defined in this
>
> Two, really!
>
> > document. Each GKMP supporting this
architecture MUST support the
> > following list of attributes described
elsewhere in this document.
> >
> > - Address Preservation (Section 3.1). This
attribute describes
> > whether address preservation is to be applied
to the SA on the source
> > address, destination address, or both source
and destination
> > addresses.
> >
> > - Direction attribute (Section 4.1.1). This
attribute describes
> > whether the SPD direction is to be symmetric,
receiver only, or
> > sender only.
>
> Why are these listed again?
>
>
> >5.0 IP Traffic Processing
> >
> > Processing of traffic follows [RFC4301, Section
5], with the
> > additions described below when these IP
multicast extensions are
> > supported.
>
> All of this probably belongs earlier. I have asked
earlier about hdr
> removal when the inner and outer addresses are the
same. That was
> proposed elsewhere and perhaps should be considered
here.
> <snip>
>
>
> >6.0 Networking Issues
> >
> >
> >
> >Weis, et al. Expires August, 2006
[Page 12]
> >
> >Internet-Draft Multicast Extensions to RFC 4301
June, 2005
> >
>
> I ran out of steam here. I will do the rest some other
time (may be
> tomorrow or something).
>
> _______________________________________________
> msec mailing list
> msecsecuremulticast.org
> http://
six.pairlist.net/mailman/listinfo/msec
>
_______________________________________________
msec mailing list
msecsecuremulticast.org
http://
six.pairlist.net/mailman/listinfo/msec
|
|
| Review of
draft-ietf-msec-ipsec-extensions-01 |
|
2006-06-15 18:15:57 |
Hi Lakshminath,
Thanks for the detailed review! I'll do a quick pass over
them and we'll
come up with answers ASAP. Quick comment on the GKMP acronym
-- I don't
think we knew it referred to a particular protocol and can
easily change
it I imagine.
Thanks,
Brian
Lakshminath Dondeti wrote:
> Hi all,
>
> [Disclaimer: Reviewing as an MSEC contributor. Ran or
I will have to do
> a "WG chair" review some time before
forwarding this to the IESG.]
>
> I reviewed the first 5 sections. You have a lot of
stuff on NATs and
> NATs are boring to me. I will review that some other
time.
>
_______________________________________________
msec mailing list
msecsecuremulticast.org
http://
six.pairlist.net/mailman/listinfo/msec
|
|
| GKMP acronym, was Re: Review of
draft-ietf-msec-ipsec-extensions-01 |
|
2006-06-19 15:58:34 |
Hi Lakshminath,
this e-mail focuses on your comment regarding the GKMP
acronym. future
e-mails will respond wrt/ to other your comments.
inline below....
On Thu, 15 Jun 2006, Lakshminath Dondeti wrote:
<snip until first occurance of GKMP acronym>
> > This document describes extensions to RFC 4301
that further define
> > the IPsec security architecture for groups of
IPsec devices to share
> > SAs. In particular, it supports SAs with
traffic selectors that
> > include a multicast address in the IP
destination field, and results
> > in an IPsec packet with an IP multicast address
in the IP destination
> > field. It also describes additional semantics
for IPsec Group Key
> > Management Protocol (GKMP) Subsystems.
>
> GKMP is RFC 2093. I'd rather we not reuse that
acronym.
>
> Perhaps IPsec with GSAs or something like that is more
generic?
To align with RFC4046, we will edit the MSEC IPsec
extensions document to
use either the term "GKM protocol" or "GKM
subsystem" as appropriate.
Note that RFC4046 defines the acronym "GKM" in
its section 1. We will also
add a qualifying sentence to say that "GKM
protocol" is a generic term,
not intended to refer to any particular group key management
protocol.
br,
George
_______________________________________________
msec mailing list
msecsecuremulticast.org
http://
six.pairlist.net/mailman/listinfo/msec
|
|
| Review of
draft-ietf-msec-ipsec-extensions-01 |
|
2006-06-26 11:11:07 |
Hi Laksminath,
Brian, Dragan, and I have worked off-list the last week to
accomodate many
of your comments and also some issues that we detected as
co-authors. we
have issued a v02 of the ID that will publish shortly.
although we felt we
could revise the text to reflect your feedback in most
cases, there were
some instances where we need to follow up with discussion or
clarifying
questions. for these, we could introduce any additional
revisions in v03
after the Montreal IETF.
I will spin off a few e-mails shortly for those of your
comments that we
have a need to discuss/clarify....
br,
George
_______________________________________________
msec mailing list
msecsecuremulticast.org
http://
six.pairlist.net/mailman/listinfo/msec
|
|
| tunnel mode w/ address preservation use
cases, was Review of
draft-ietf-msec-ipsec-extensions-01 |
|
2006-06-26 11:41:08 |
Hi Lakshminath,
as promised, the first of several topic specific e-mails...
On Thu, 15 Jun 2006, Lakshminath Dondeti wrote:
<snip for brevity>
> >3.1 Tunnel Mode with Address Preservation
>
> I can appreciate the requirement, I think. If I am not
mistaken,
> wouldn't there be three cases here? There could be a
sender which
> cannot IPsec encapsulate and relies on a GW to encrypt
and all
> members/receivers can decapsulate IPsec on their own.
In the second
> case, a GW decapsulates for some or all members.
Finally a
> combination of the two.
We could easily get tangled up in explaining the many use
cases. This
section really should only define the semantics, not the use
cases. If you
think the use cases need to be identified, I would suggest
that you
prepare some text that we can put into an appendix.
>
> Would there be implications on the GW to join the
multicast in the
> reception case?
Clearly, the decapsulating security gateway has to be either
a multicast
router or IGMP proxy or multicast leaf node for the
multicast group in
order to receive the data stream. are you saying we should
explicitly say
that?
>
> It would also be worthwhile to have before and packet
headers as in
> 4302 and 4303.
maybe we can add this into v03.
> Would header compression be possible, given that the
inner and outer
> headers might be the same?
Compression was identified as an SA attribute in RFC2407,
but RFC4301 only
briefly mentions compression in section 3.1. Does the
compression that you
are talking about resemble Nikander's proposed BEET mode?
In any case, there is nothing in RFC4301 that would stop a
GKM protocol
from negotiating tunnel mode header compression, but that
would be a
separate and future specification from this one.
br,
George
_______________________________________________
msec mailing list
msecsecuremulticast.org
http://
six.pairlist.net/mailman/listinfo/msec
|
|
| multiple IPsec SA in support of rekey
rollover |
|
2006-06-26 12:14:51 |
Hi Lakshminath,
On Thu, 15 Jun 2006, Lakshminath Dondeti wrote:
<snip>
> > association in use by the group for that
speaker. All authorized
> > Group Members can receive and decrypt data
for this SA, but the
> > Group Speaker does not transmit new data
using the "trailing edge"
> > SA after it has transitioned to the
"leading edge GSA". The
> > trailing edge SA is deleted by the group's
endpoints according to
> > group policy (e.g., after a defined period
has elapsed)"
>
> So by this, may I assume that multiple (more than two)
IPsec SAs are
> allowed to exist simultaneously?
Yes.
> <snip>
>
> >Implementations MAY offer a Group
> > Owner management interface option to
enable/disable re-key rollover
> > continuity for a particular group This
specification requires that a
>
> Missing a period above.
ok.
>
> > GKMP/IPsec implementation MUST support at least
two concurrent GSA
> > per Group Speaker and this re-key rollover
continuity algorithm.
>
> I see that you are mandating the existence of multiple
simultaneous
> IPsec SAs. Please make it a SHOULD. I know of at
least one use case
> where rekeying would involve stopping
transmission/reception and
> restarting after a new SA has been established.
The rekey rollover algorithm is a fairly fundemental MSEC
inter-op
requirement. Unlike a pair-wise unicast SA that negotiate
policies, we
are constrained to support only homogeneous groups (unless
you consider
moving composite groups back into the MSEC IPsec draft).
If even one endpoint does not implement the rekey rollover
algorithm, then
the performance of the whole group is degraded because we
are forced to
either saddle the group with the handicap of the least
common denominator
or else exclude those candidate members who don't implement
the SHOULD.
The use case you cite is at odds with the major motivation
for MSEC IPsec
service, continous reliable real-time delivery of secured
content.
Interrupting that delivery by dropping packets or stopping
packet
transmission for the duration of a rekey operation would
preclude
multi-vendor support of the reliable real-time service
objective.
br,
George
_______________________________________________
msec mailing list
msecsecuremulticast.org
http://
six.pairlist.net/mailman/listinfo/msec
|
|
[1-7]
|
|