Internet DRAFT - draft-atwood-pim-sigmp
draft-atwood-pim-sigmp
PIM W. Atwood
Internet-Draft B. Li
Intended status: Standards Track Concordia University/CSE
Expires: January 5, 2015 July 4, 2014
Secure Internet Group Management Protocol
draft-atwood-pim-sigmp-01
Abstract
This document specifies a Secure Internet Group Management Protocol
(SIGMP), which is an extension to IGMP to enforce receiver access
control for secured multicast groups. In SIGMP, only the hosts
operated by authorized end users are permitted to report their
interest in secured groups. IPsec is used to filter the messages
that report or query the interest in secured groups. SIGMP provides
two working modes that are fully compatible with IGMP v2 and IGMP v3
respectively.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Atwood & Li Expires January 5, 2015 [Page 1]
Internet-Draft SIGMP July 2014
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of SIGMP . . . . . . . . . . . . . . . . . . . . . . 4
3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Router Operations . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Router Operations Compatible with IGMP v2 . . . . . . . . 5
4.1.1. Router Operations for a Received Report . . . . . . . 5
4.2. Router Operations Compatible with IGMP v3 . . . . . . . . 7
4.2.1. Router Operations on a Received Report . . . . . . . 7
5. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Host Operations Compatible with IGMP v2 . . . . . . . . . 8
5.1.1. Conditions for Unsolicited Report . . . . . . . . . . 8
5.1.2. Host Operations for a Received Query . . . . . . . . 8
5.2. Host Operations Compatible with IGMP v3 . . . . . . . . . 9
5.2.1. Host Operations for a Received General Query . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
The Internet Group Management Protocol (IGMP) is used by IPv4 systems
(hosts and routers) to report their IP multicast group memberships to
any neighboring multicast routers. There are two popular versions:
IGMP v2, as specified in [RFC2236] and IGMP v3, as specified in
[RFC3376]. However, both versions establish a fully "open" multicast
network, where any host can join any multicast group as a recipient
without receiver access control.
This document specifies a Secure Internet Group Management Protocol
(SIGMP) working in a "hybrid" multicast network. In a hybrid
network, multicast groups are classified into two categories: open
groups and secured groups. Open groups refer to multicast groups
that any host can join unconditionally as a receiver. Secured groups
refer to multicast groups with receiver access control, e.g., only
hosts operated by authenticated and authorized end users are
permitted to join as receivers. SIGMP retains most mechanisms of
IGMP and enforces receiver access control to secured groups in a
multicast network. On the one hand, any host could report its
Atwood & Li Expires January 5, 2015 [Page 2]
Internet-Draft SIGMP July 2014
interest in open groups freely as in IGMP. On the other hand, only
hosts operated by the authenticated and authorized end users are
permitted to report their interest in secured groups.
Instead of a new specific mechanism, SIGMP uses IPsec [RFC4301] to
implement receiver access control to secured groups at the IP layer.
Some Security Associations (SAs) are created to secure the SIGMP
packets that are used to report or query secured groups. The packets
coming from the unauthorized hosts will be discarded by the IPsec
subsystem if they are used to report or query interest in secured
groups.
1.1. Terminology
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].
It is assumed that the reader is familiar with the defining documents
for IGMP [RFC2236] and [RFC3376]. Unless otherwise noted, terms
defined in these documents are used with the same meaning in this
one.
In addition, the following terms are used in this document.
open group: A multicast group without receiver access control. Any
host can unconditionally join any open group as a receiver, e.g. the
data in a open group can be received by any host.
secured group: A multicast group with receiver access control. Only
hosts operated by authenticated and authorized end users are
permitted to join a secured group as a receiver, e.g. the data in a
secured group can only be received by hosts operated by authenticated
and authorized end users.
1.2. Assumptions
In order to focus on the actions of group membership (e.g., joining
and leaving groups), the following topics are assumed to be discussed
elsewhere:
1. how to distinguish between secured groups and open groups;
2. how to authenticate and authorize the operators of the devices
(hosts and routers);
Atwood & Li Expires January 5, 2015 [Page 3]
Internet-Draft SIGMP July 2014
3. how to distribute the necessary Security Associations to
participant devices (hosts and routers).
The existence of the group property (secured or open) defines the
hybrid nature of the environment in which SIGMP works. A variety of
existing protocols (e.g., LDAP) can be used to enquire as to the
status of a particular multicast group.
The hosts that show interest in secured groups MUST be operated by
authenticated and authorized end users. One approach to the task of
authentication and authorization of end users is based on the use of
PANA [RFC5191] and EAP [RFC3748], and is described in
[I-D.atwood-mboned-mrac-req], [I-D.atwood-mboned-mrac-arch] and
draft-atwood-mboned-pana (not yet published).
A coordination protocol may be needed to manage and distribute the
Security Associations (SAs) for secured groups among the routers and
the hosts that correspond to authenticated and authorized end users.
One set of possible procedures for SA creation and maintenance is
specified in draft-atwood-pim-gsam (not yet published).
2. Overview of SIGMP
SIGMP is an extension to IGMP and performs receiver access control
for groups in a multicast network. It retains most mechanisms of
IGMP and has two working modes: 1) mode compatible with IGMP v2 and
2) mode compatible with IGMP v3. It works in either mode and is
transparent for hosts that support only IGMP, i.e., that do not
support SIGMP. In addition, SIGMP uses IPsec to secure part of its
packets. For an open group, it delivers the data to any host
unconditionally as IGMP does. However, for a secured group, SIGMP
only delivers the data to the hosts that have established SAs in the
IPsec subsystem in order to perform access control.
In a network segment, hosts show their interest in secured groups
using IPsec protected packets although their interest for open groups
is still reported using unprotected packets. Similarly, routers
query the membership interest for a secured group using IPsec
protected packets, although the general query and the query for the
membership of open groups are performed using unprotected packets.
In general, the packets in SIGMP are classified into four categories,
which are Query for Open Group (OGQ), Query for Secured Group (SGQ),
Report for Open Group (OGR) and Report for Secured Group (SGR). OGQ
and SGQ are sent by the the Querier and are used to learn the
membership of open groups (or all groups for general query) and
secured groups respectively. In detail, OGQ includes general query,
specific-group query for open group and group-and-source-specific
Atwood & Li Expires January 5, 2015 [Page 4]
Internet-Draft SIGMP July 2014
query for the source of open group. SGQ includes specific-group
query for secured group and group-and-source-specific query for the
source of secured group. OGR and SGR are sent by hosts and used to
report the membership of open groups and secured groups respectively.
In detail, OGR includes report to specific-group query for open
group, report to group-and-source-specific query for the source of
open group, unsolicited report for open group and part of reports to
general query. SGR includes report to specific-group query for
secured group, report to group-and-source-specific query for the
source of secured group, unsolicited report for secured group and
part of reports to general query. SGQ and SGR are protected by IPsec
at IP layer while OGQ and OGR are delivered without IPsec protection.
The destination address of packets in IP layer is specified as
follows. In SGQ and SGR, the destination address is a secured group
address. In OGQ, it is 224.0.0.1 if the packet is general query and
otherwise it is an open group address. In OGR, it is 224.0.0.22 if
the packet is the report to general query compatible with IGMP v3 and
otherwise it is an open group address. The two addresses of
224.0.0.1 and 224.0.0.22 are the open group addresses. NOTE: When
SIGMP works in the mode compatible with IGMP v3, the response to a
general query contains zero or one OGR and zero or more SGR. It is
described in detail in Section 5.2.1.
3. Packet Format
The packet format of SIGMP is identical to the packet format for
IGMP. In detail, the format is the same as IGMP v2 when SIGMP works
in the mode compatible with IGMP v2. The format is the same as IGMP
v3 when SIGMP works in the mode compatible with IGMP v3.
4. Router Operations
Router operations in SIGMP are based on router operations in IGMP.
However, some additional operations must be appended since access
control to secured groups is extended into SIGMP. This section
describes the additional operations for the two working modes.
4.1. Router Operations Compatible with IGMP v2
The additional router operations focus on the operations for a
received report.
4.1.1. Router Operations for a Received Report
On receiving a report, a router checks the group address in the
received report. If the group address indicates an open group, the
report is considered as an OGR. A router will process an OGR as it
Atwood & Li Expires January 5, 2015 [Page 5]
Internet-Draft SIGMP July 2014
does that in IGMP v2 directly. Otherwise, the received report is an
SGR that SHOULD just have been authenticated (and decrypted) by the
IPsec subsystem (e.g., AH [RFC4302]). For SGR, a router must perform
two verifications: address consistency and SA existence.
In the address consistency verification, a router compares two
addresses: the group address in the SIGMP report and the destination
address in the IP header. The verification fails if the two
addresses are not the same. In the failure case, the sender of the
IGMP Report has attempted to hide a request for a specific group
(probably a secured group) in an IGMP Report for a different group
(probably an open group). This will cause the IPsec subsystem to
deliver the IGMP Report without requiring it to be protected.
Therefore a router must discard the report if this address
consistency verification fails.
In the SA existence verification, a router checks whether SAs have
been established for the secured group whose address is contained in
the received report. The verification fails if there are no valid
SAs for the group in the router's IPsec subsystem. Since the IPsec
subsystem is used to enforce the access control, no access to a
secured group is permitted until its SAs have been established.
Therefore a router must discard the report if this verification
fails.
If the two verifications succeed on SGR, a router will proceed to
update the group memberships and refresh the timers as it does in
IGMP v2. In summary, the router operations for a received report are
shown in Table 1.
+---+-------------+------------------+------------+-----------------+
| # | Group | Address | SA | Operations for |
| | Address | Consistency | Existence | Report |
+---+-------------+------------------+------------+-----------------+
| 1 | Open | - | - | Process as IGMP |
| | | | | v2 |
| 2 | Secured | No | - | Discard |
| 3 | Secured | Yes | No | Discard |
| 4 | Secured | Yes | Yes | Process as IGMP |
| | | | | v2 |
+---+-------------+------------------+------------+-----------------+
Table 1: Router Operations for a Received Report for the Mode
Compatible with IGMP v2
Atwood & Li Expires January 5, 2015 [Page 6]
Internet-Draft SIGMP July 2014
4.2. Router Operations Compatible with IGMP v3
The additional router operations still focus on the operations for a
received report. However, there is a little difference between the
operations in the mode compatible with IGMP v3 and the operations in
the mode compatible with IGMP v2, since the formats of received
reports in the two modes are different.
4.2.1. Router Operations on a Received Report
On receiving a report, a router checks the number of group records in
the report. If the number is more than one, it indicates that the
report is an OGR, but not an SGR, since only one group record is
included in an SGR. In this case, every group record in the report
must be verified further as follows. A router checks the multicast
address in the group record. If the multicast address is an open
group address, a router will process the group record as it does in
IGMP v3. Otherwise, a secured group address is in the group record
and a router must discard the group record. The OGR including more
than one group records is not protected by IPsec systems and is not
permitted to contain any information related to any secured group.
In contrast, if the number of the group records is just one, a router
still checks the multicast address in the single group record. If
the multicast address indicates an open group address, the received
report is considered as an OGR and a router will process the group
record as it does that in IGMP v3 directly. Otherwise, the received
report SHOULD be an SGR that SHOULD just be authenticated (and
decrypted) by the IPsec subsystem. For the single group record in
the SGR, a router must perform two verifications, address consistency
and SA existence, similar to Section 4.1.
In the address consistency verification, a router compares two
addresses: the multicast address in the group record of the SIGMP
report and the destination address in the IP header. A router must
discard the report if the two addresses are not the same.
In SA existence verification, a router checks whether SAs have been
established for the secured group whose address is contained in the
group record of the received report. A router must discard the
report if there are no SAs established in the router's IPsec
subsystem.
If the two verifications succeed on an SGR, a router will proceed to
update the group memberships and refresh the timers as it does in
IGMP v3. In summary, router operations for a received report are
shown in Table 2.
Atwood & Li Expires January 5, 2015 [Page 7]
Internet-Draft SIGMP July 2014
+---+---------+------------+-------------+-----------+--------------+
| # | #Group | Multicast | Address | SA | Operations |
| | record | Address in | Consistency | Existence | for Group |
| | in | Group | | | Record |
| | report | Record | | | |
+---+---------+------------+-------------+-----------+--------------+
| 1 | >1 | Open | - | - | Process as |
| | | | | | IGMP v2 |
| 2 | >1 | Secured | - | - | Discard |
| 3 | =1 | Open | - | - | Process as |
| | | | | | IGMP v2 |
| 4 | =1 | Secured | No | - | Discard |
| 5 | =1 | Secured | Yes | No | Discard |
| 6 | =1 | Secured | Yes | Yes | Process as |
| | | | | | IGMP v2 |
+---+---------+------------+-------------+-----------+--------------+
Table 2: Router Operations for a Received Report for Mode Compatible
with IGMP v3
5. Host Operations
Host operations in SIGMP are based on host operations in IGMP.
However, some additional operations must be appended since access
control to secured group is extended into SIGMP. This section
describes the additional operations for the two working modes.
5.1. Host Operations Compatible with IGMP v2
The additional host operations focus on the conditions for
unsolicited report and the operations for a received query.
5.1.1. Conditions for Unsolicited Report
Before creating an unsolicited report, a host must check the reported
group. If the report group is open, a host will do as in IGMP v2.
If secured, a host must continue to check whether SAs have been
established for the secured group. If no SA is defined for this
group address, a host MUST return an error indication to the issuer
of the request that provoked the unsolicited report. [[Is this the
right behavior?]]
5.1.2. Host Operations for a Received Query
On receiving the query, a host does the additional operation as a
router does in Section 4.2.1.
Atwood & Li Expires January 5, 2015 [Page 8]
Internet-Draft SIGMP July 2014
5.2. Host Operations Compatible with IGMP v3
The additional host operations focus on three aspects: 1) the
conditions for unsolicited report, 2) the operations for a received
non-general query and 3) the operations for a received general query.
The first two are identical to those described in Section 5.1.1 and
Section 5.1.2. In this subsection, only the last case is explained.
5.2.1. Host Operations for a Received General Query
When it determines to respond to a general query, a host creates zero
or one OGR and zero or more SGR in SIGMP instead of one report in
IGMP v3. The OGR reports the current state of all the open groups
that the host is interested in. Each SGR reports the current state
of one secured group that the host in interested in.
At the IP layer, the destination address of OGR is 224.0.0.22. In
contrast, at the IP layer the destination addresses of SGRs are the
secured group addresses. Since IPsec has established SAs for secured
groups, SGRs will be protected and the OGR will not.
6. IANA Considerations
The protocol number of SIGMP is the same as IGMP.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
7.2. Informative References
Atwood & Li Expires January 5, 2015 [Page 9]
Internet-Draft SIGMP July 2014
[I-D.atwood-mboned-mrac-arch]
william.atwood@concordia.ca, w., Li, B., and S. Islam,
"Architecture for IP Multicast Receiver Access Control",
draft-atwood-mboned-mrac-arch-00 (work in progress),
October 2013.
[I-D.atwood-mboned-mrac-req]
william.atwood@concordia.ca, w., Islam, S., and B. Li,
"Requirements for IP Multicast Receiver Access Control",
draft-atwood-mboned-mrac-req-00 (work in progress),
October 2013.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008.
Authors' Addresses
William Atwood
Concordia University/CSE
1455 de Maisonneuve Blvd, West
Montreal, QC H3G 1M8
Canada
Phone: +1(514)848-2424 ext3046
Email: william.atwood@concordia.ca
URI: http://users.encs.concordia.ca/~bill
Bing Li
Concordia University/CSE
1455 de Maisonneuve Blvd, West
Montreal, QC H3G 1M8
Canada
Email: leebingice@gmail.com
Atwood & Li Expires January 5, 2015 [Page 10]
