One document matched: draft-holbrook-ssm-scoping-00.txt

INTERNET-DRAFT             Scoping Filters for SSM           H. Holbrook
Expires Apr 19, 2004                                       Cisco Systems
                                                             19 Oct 2003


             Scoping Filters for Source-Specific Multicast
                  <draft-holbrook-ssm-scoping-00.txt>


Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

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."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

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 [RFC 2119].



















Holbrook                                                        [Page 1]

INTERNET-DRAFT           Scoping Filters for SSM             19 Oct 2003


Abstract

This document describes a method of providing scope-limited Source-
Specific Multicast (SSM) channels by filtering at boundary routers.  The
filtering prevents SSM traffic from being forwarded through a scope
boundary.  Each administrative domain that wishes to enforce scoping can
choose the sub-range of SSM channels that it wishes to scope -- no
globally-scoped address range is defined.  The method described here
does not require extending the current SSM range allocation to include a
new "scoped SSM" range.  The method described is primarily intended to
provide scoping for IPv4 SSM channels, since IPv6 integrates multicast
scoping into the basic addressing architecture.

1.  Introduction

Source-specific multicast [SSM] provides a number of benefits for hosts
and network administrators.  It greatly increases the number of
available multicast addresses, and in doing so allows hosts to
autonomously allocate addresses without deferring to a global allocation
authority.  Its more straightforward protocol operation (when compared
with Any-Source Multicast or ASM) is expected to allow for more
transparent network management and easier debugging.

RFC 2365 [RFC2365] describes a scheme by which Any-Source Multicast
addresses can be "scoped" so that they are unique within a single
topological subset of the Internet.  [IPV6-SCOPE] describes a similar
scheme for IPv6.  As of this writing, IPv4 addresses in the range 239/8
are allocated by IANA as scoped ASM multicast addresses.  Scoped
addresses are essential for many reasons with ASM (particularly for
IPv4) -- they allow multicast address allocation to be performed locally
within the scoped domain, relying on a purely local allocation policy,
and they avoid the need to defer to an Internet-wide address allocation
mechanism to ensure that addresses are uniquely assigned to
applications.  (Today, allocations of globally-routable addresses are
either done manually or using GLOP [RFC3180].)  In addition to providing
localized allocation, any traffic sent to a scoped address must be
contained within some region of the network that is "close to" the
originator of the traffic.

Unlike ASM, scoping is not required for SSM in order to ease the address
allocation problem.  SSM solves this problem by allowing the same
channel destination addresses to be simultaneously used by different
sources.  The traffic containment provided by the use of scoped
addresses is useful for SSM in some cases.  Some example scenarios where
it may be useful are:

  SSM traffic is not allowed to exit an enterprise network except when
  sourced by some set of "blessed" externally-visible servers.



Holbrook                                                        [Page 2]

INTERNET-DRAFT           Scoping Filters for SSM             19 Oct 2003


  SSM channels are used internally to distribute routing information
  internally within a routing domain.  This traffic must not be allowed
  to exit the routing domain.

This document describes how the administrator of a network can scope
some subset (possibly all) of the existing SSM address range for traffic
sourced within that network without impacting the ability to receive
externally-sourced channels.  This solution does not require extending
the existing SSM address space.

2.  Defining Scoping for SSM

A set of router interfaces is used to define a "scope boundary."  Each
interface that is part of the scope boundary is called a "boundary
interface."  A set of channel addresses R ("the scoped channel range")
is associated with the scope boundary.  Filtering at each boundary
router ensures that no packet sent on any channel in R is allowed to
pass out of any of the boundary interfaces.  If the set of boundary
interfaces completely encloses a region (i.e., there are no "holes" in
the boundary) then no SSM traffic from R can escape the region.

This solution has the following properties:

2.1.  Flexible egress filtering

It allows the scope boundary to filter all outgoing SSM traffic matching
a range of source addresses, a range of destination addresses, or both.

2.2.  No ingress filtering

It does not limit the ability of systems inside the scope boundary to
receive SSM traffic sent by sources outside the domain.

It is important to emphasize that SSM scope filtering blocks traffic
going *out of* the scoped region, but not traffic coming into it.  This
is distinct from ASM scope zones in which bidirectional filtering is
applied at a scope boundary.

2.3.  No global agreement

It does not require any global agreement of the SSM scoped range.  It is
not necessary for the IETF to designate one specific range as a
"blessed" SSM scoped range.  Scoping can be applied within the existing
allocated SSM range.







Holbrook                                                        [Page 3]

INTERNET-DRAFT           Scoping Filters for SSM             19 Oct 2003


2.4.  No extension of the IPv4 SSM address range

Scoping can be performed withing the existing IPv4 address range
allocated to SSM (232/8).  This simplifies hosts and routers (compared
to a solution in which a new scoped range is allocated) by avoiding the
need to communicate, agree upon, and configure some new address range
not in 232/8 to have SSM semantics.

3.  Specifying the scoped channel range

A scoped channel range R defines a subset of all possible SSM channels.
A scoped range may be defined by specifying a set of source addresses, a
set of destination addresses, or a set of channels.  Some possible
scoped ranges:


    All channels with destination address in 232.0.0.0/8

    All channels with destination address in 232.239.0.0/16

    All channels with source address in 10.0.0.0/8

    All channels with source address in 192.168.0.0/16 or
    192.168.239.0/24

    All channels with source address not in 192.168.0.0/16

    All channels with source address in 192.168.0.0/16 and destination
    address in 232.239.0.0/16


4.  Implementing SSM scoping

Traffic scoping is ensured by simply configuring the scope boundary
routers to prevent traffic in the scoped range R from exiting the scoped
region.  A boundary router ignores any reception request (PIM-SSM join
and/or IGMP/MLD reports) for any channel in the scoped range R that
arrives on any interface that is part of the scope boundary.

A reception request (joins and IGMP/MLD messages) for a channel in the
scoped range R is permitted out a boundary interface without hindrance,
and any SSM traffic received on a scoped interface is allowed to pass
into the scoped region normally.

4.1.  Scoping for a stub region

A set of boundary interfaces enclose a "stub region" if they do not
provide transit for multicast traffic.  That is, there exists no SSM



Holbrook                                                        [Page 4]

INTERNET-DRAFT           Scoping Filters for SSM             19 Oct 2003


channel with a source outside the scoped region for which the delivery
path to some receiver also outside the scoped region passes through some
boundary interface.

In a stub region, there are no restrictions on the allowed form of the
scoped channel range R.  The scope boundary may include the entire SSM
destination address range, some subset of the SSM destination address
range, or some subset of the SSM channels selected by sources and
destinations.

4.2.  Scoping for a transit network

A group of scope boundary interfaces are part of a transit network if
some SSM channel may be required to pass through the scoped region on
its way to some potential receiver.  In this case, the traffic must
enter through one boundary interface and exit through another.

If the scoped region is also a transit network, the scoped range R must
be qualified by a set of source addresses that are known to be contained
within the scoped region.  If the scoped range is not thus qualified,
then SSM traffic sent by sources outside the region will not be allowed
to transit the region.


5.  Deployment considerations

It is expected that the network administrator who defines an SSM scoped
region knows whether the region is a stub or transit region, and can
thus properly select the channel range.  Similarly, it is expected that
the internal host address range is known.

In a stub network, it may be desirable to prevent *any* traffic from
exiting through the scoped boundary except that from a small number of
"blessed" sources.  These might represent servers that specifically
provide externally-visible content, similar to an externally-facing web
server.

A simple method to advertise the scoped (or unscoped) address range
might be to place it on a web page.

In order to implement a complete solution of scoping, an address
allocation API for SSM is required that allows an application to request
a channel address from within the scoped address range.  As the
operating system has (as of yet) no means to know the scoped range, an
application that wishes to source scoped SSM traffic must provide the
scoped range to the operating system when requesting a channel address.
This API is defined in a related document [TBD].




Holbrook                                                        [Page 5]

INTERNET-DRAFT           Scoping Filters for SSM             19 Oct 2003


6.  Security Considerations

This document does not consider mechanisms that ensure that there are no
"leaks" from the scoped region, or that ensure all border routers are
consistently configured like [MZAP].  Thus, the "tightness" of the scope
boundary depends on proper configuration by the network administrator.

The mere act of advertising that some range R is scoped (on a web page,
for instance) does not ensure that the scoped range is actually
enforced.  Thus if scoping is used as a security mechanism, an attacker
may attempt to elicit a source to send confidential information to an
unscoped address by trying to trick a sender to sending to a an unscoped
address.

The method described in this document should not be considered as an
alternative to strong encryption techniques [IPSEC] when strong
guarantees of traffic containment are required.  Rather, it may be used
in addition to such techniques or as a way of limiting the usage of
network resources on some interfaces.

7.  IANA Considerations

This document defines no new address spaces and does not impact IANA.

8.  IPv6 Considerations

(Note: this section will be integrated with the document in a later
revision.)

IPv6 provides administrative scoping through the use of the "scope"
field in the SSM channel destination address [RFC3513, RFC3306].  An
application that wishes to scope-limit its IPv6 SSM traffic can select
an appropriately scoped address.  A configured multicast scope boundary
blocks traffic sent to a scoped address, per the rules in [IPV6-SCOPE].
The scoping rules for the source (unicast) IPv6 address are only defined
for link-local and global addresses, to date.

The address scoping methods described in RFCs 3513 and 3306 block all
SSM channels of a particular scope at a boundary router for that scope.
By contrast, the methods described in this document selectively block
only a subset of all channel addresses at a scope boundary.  The method
described here applies to addresses with no inherent scope (other than
the global scope) -- the range over which a channel is routed is
determined only by the scope boundaries that filter it.

It remains to be decided if the mechanisms described in this document
will be useful for IPv6, or if the existing methods of [IPV6-SCOPE] are
sufficient.  For example, it remains to be decided if it is desirable to



Holbrook                                                        [Page 6]

INTERNET-DRAFT           Scoping Filters for SSM             19 Oct 2003


scope-limit an (S,G) channel when S is a global IPv6 address and G is a
multicast address with global scope,

9.  Summary

This document describes a simple mechanism to ensure that systems
outside of the scope boundary cannot receive SSM traffic sourced from
inside it.  It requires configuration of unidirectional traffic filters
on the set of boundary routers that form the scoped region boundary.
Scoping can be applied to any subset of the SSM destination address
range without compromising the ability of hosts inside the scoped
boundary to receive SSM traffic sent by outside sources.  The scoped
channel range need not be qualified to a particular set of source
addresses, except in the case of a transit network.  The source address
range can be chosen autonomously by the network that desires scoping
within the existing allocated SSM range.

10.  Acknowledgments

11.  Normative References

[RFC3306] B. Haberman, D. Thaler. Unicast-Prefix-based IPv6 Multicast
Addresses. August 2002.

[RFC3513] R. Hinden, S. Deering. Internet Protocol Version 6 (IPv6)
Addressing Architecture.  April 2003.

[SSM] H. Holbrook, B. Cain. Source-Specific Multicast.  Work in
Progress.  October 2003.

12.  Informative References

[IPSEC] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol.", RFC 2401.

[IPV6-SCOPE] S. Deering, B. Haberman, T. Jinmei, E. Nordmark, A. Onoe,
B. Zill.  IPv6 Scoped Address Architecture.  Work in Progress.  June
2003.

[RFC2365] D. Meyer. Administratively Scoped IP Multicast.  July 1998.

[RFC2776] M. Handley, D. Thaler, R. Kermode.  Multicast-Scope Zone
Announcement Protocol (MZAP). February 2000.

[RFC3180] D. Meyer, P. Lothberg.  GLOP Addressing in 233/8. September
2001, RFC 3180.





Holbrook                                                        [Page 7]

INTERNET-DRAFT           Scoping Filters for SSM             19 Oct 2003


Authors' Addresses

     Hugh Holbrook
     Cisco Systems
     170 W. Tasman Drive
     San Jose, CA 95134
     holbrook@cisco.com


Intellectual Property Rights Notice

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to  pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights.  Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11.  Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard.  Please address the information to the IETF Executive
Director.

Full Copyright Statement

Copyright (C) The Internet Society (2002).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.




Holbrook                                                        [Page 8]

INTERNET-DRAFT           Scoping Filters for SSM             19 Oct 2003


The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.

This document expires Apr 19, 2004.








































Holbrook                                                        [Page 9]