Network Working Group David Allan, Nortel INTERNET DRAFT March 13th, 1998 Expires September 13th, 1998 MARS Proxy Status Of This Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract: The Point-to-Point Protocol (PPP) [1] has been proposed as an access vehicle for public ATM networks. Support for multicast in this environment via either RAS replication, or a adding MARS client side by side with PPP is problematic on several fronts. This document describes how an ATM attached system can act as a MARS proxy on behalf of a PPP client. This solution circumvents many of the associated problems with respect to VC frugality, scalability, and authentication. Applicability: This specification is intended for those implementations which desire to implement a MARS proxy on behalf of any client base. The original motivation for this work was to augment the capability presented to PPP over ATM clients, however the work has been sufficiently generalized to be extensible to other applications. Allan Expires Sept 13th 1998 [Page 1] Internet Draft MARS Proxy January 22nd,1998 This document should be read as an extension of RFC 2022 and assumes familiarity with RFCs 1112, 2022 and 2236. The focus of this document in describing the MARS proxy is IPv4/IGMP but it is expected that this work could be easily generalized to other protocols. Table of Contents 1. Conventions 3 2. Terminology 3 3. Introduction 3 4. MARS proxy behavior 4 4.1 Transmit Side behavior 5 4.2 Receive Side behavior 5 4.2.1 Joining a multicast group 5 4.2.2 Leaving a Multicast group 6 4.3 Encapsulation 6 5. Proxy client behavior 7 5.1 Modifications to RFC1112 and RFC2236 7 5.2 Reflected packet detection 7 6. MARS Behavior 7 7. Security Provisions 7 7.1 Restriction of Multicast operation to MCS 7 7.2 MARS proxy to MARS/MCS connectivity 8 7.3 Proxy client screening of incoming p2mp VCs 9 8. Fate sharing 10 9. Specific PPP over ATM considerations 10 9.1 PPP over ATM, MARS and L2TP 10 9.2 Backwards compatibility with initial PPP over ATM implementations 11 9.3 MARS cluster LIS Restriction 11 9.4 Multiple 'layer 3 over ATM interfaces' 12 9.5 Collapsed Architecture 12 10. Security Considerations 12 11. Acknowledgments 12 12. References 12 13. Authors Address 13 Allan Expires Sept 13th 1998 [Page 2] Internet Draft MARS Proxy January 22nd,1998 1. Conventions In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST - This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT - This phrase means that the definition is an absolute prohibition of the specification. SHOULD - This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications MUST be understood and carefully weighed before choosing a different course. MAY - This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. 2. Terminology MARS proxy: A MARS client that functions on behalf of one or more ATM endpoints. A potential example would be a broadband RAS. Proxy client: An ATM endpoint serviced by a MARS proxy. 3. Introduction The PPP model traditionally assumes that a session between "peers" consists of a single logical connection (which may consist of multiple physical connections inverse multiplexed). The definition of PPP over ATM [2] (work in progress) and PPP over Frame Relay [3] currently adhere to this convention. This convention also requires that for IP multicast, the Remote Access Server (RAS) function as a multicast router and perform replication of multicast traffic to each PPP attached "destination". This has undesirable scaling properties w.r.t. the consumption of bandwidth in the ATM subnet. This is exacerbated once multiple RAS's are required to service the ATM subnet; more bandwidth is required in the network behind the RASs. However it is only by convention that all IP traffic between PPP "peers" be carried within the PPP session/connection. In the ATM access environment where PPP over ATM has been proposed, one peer will typically be an ISP client, the other an ISP, and the ATM subnet will be Allan Expires Sept 13th 1998 [Page 3] Internet Draft MARS Proxy January 22nd,1998 a public network. If the ISP wished to offer IP based multicast services, it would be desirable for the ISP if only a single multicast source (e.g. MCS) was required to service the ATM subnet, and that the ISP could limit users of the MCS to authenticated clients. The MARS/MCS model [4] has the desirable attribute that all destinations for an IP multicast group in the NMBA subnet can be serviced by a single p2mp tree. However the MARS/MCS model brings significant overhead: * the client host needs to be configured with knowledge of the MARS. Techniques such as ILMI based server discovery are inappropriate. The management of the network cannot have advance knowledge of the PPP peer. * the client needs a p2p VC and is a leaf on the p2mp cluster control VC to participate in the multicast control structure. * the client requires a p2p VC to each MCS to source traffic and is a leaf on a p2mp VC to receive traffic typically for each multicast group. and numerous unsolved issues with respect to authentication of the client (which also renders p2mp VC meshing as per [4] sect. 3.1 inappropriate for this particular application). Much of this configuration and connectivity burden on the client could be alleviated, and the authentication issues addressed if the RAS proxied connectivity to the MARS and MCS on behalf of the PPP client and the set of multicast "destinations" in the ATM subnet could be serviced by p2mp tree(s) rooted in the ISP network. The motivation for this document assumes use of MCSs but the work has been generalized to encompass p2mp meshing as well. 4. MARS proxy behavior The MARS proxy mimics a multicast router ([5] Appendix I) to its set of proxy clients and interworks IGMP (version 1 or version 2) with MARS. The MARS proxy must be able to detect and manage multicast activity for a group via two mechanisms. Either the proxy client issues an IGMP report indicating that it has joined a group and wishes to receive traffic from that group (as a 'destination'), or it has directed a packet to that groups class 'D' address (as a 'source'). This is typically termed 'receive side' and 'transmit side' respectively. A client indicating 'destination' status for a group must have that status periodically re-confirmed via IGMP query messages. The MARS proxy MUST maintain group membership state for each of its proxy clients. This specification provides for both permanent and transient paths to Allan Expires Sept 13th 1998 [Page 4] Internet Draft MARS Proxy January 22nd,1998 both the MARS and the multicast group. 4.1 Transmit side behavior Transmit side behavior is as per [4] sect 5.1. with the following proviso: The MARS proxy MAY not have ATM connectivity to multicast destinations on the ATM subnet (hosts or MCS) for technical or policy reasons. The MARS proxy may be located at the edge of an ATM subnet and have a forwarding path for multicast traffic outside the ATM subnet. Should the MARS have no mapping for the desired class 'D' address, or be configured specifically to provide a MARS_NAK response, the MARS proxy SHOULD have the option to forward the packet outside the ATM subnet OR to silently discard the packet. A MARS proxy implementation may choose to use MARS_REQUEST to dynamically determine availability or may choose to do so via the MARS_GROUPLIST_REQUEST facility. Although there is an expectation that a multicast router will be a MARS client (possibly integrated), the network operator may wish to limit what multicast groups are supported by MARS/MCS (not fully promiscuous) for reasons of tariffs, service differentiation or other, or may wish to restrict direct ATM connectivity from the MARS proxies to an MCS. Non- ATM MCS connectivity (back end via any attached multicast router) can be done transparently without fear of routing loops or reflection problems. This will introduce additional latency when compared with a direct ATM path and requires some administrivia in that filtering of group lists is required for responses to MARS_REQUESTs. Hosts blocked from direct MCS connectivity would receive MARS_NAKS as a response to MARS_REQUESTs. 4.2 Receive side behavior The receiver side behavior of the MARS proxy is as per [4] section 5.2 but with the difference that: - the MARS proxy is a cluster member in that it participates in the cluster control structure. - the MARS proxy is not a group member in that it is not a 'source' nor 'destination' of multicast traffic for any multicast group. It does forward multicast traffic 'sourced' by its set of proxy clients to the set of 'destinations' specified by MARS interaction. An associated difference is that when p2mp meshing is used and a p2mp VC is rooted at the proxy, the set of end points may include proxy clients served by the MARS proxy. 4.2.1 Joining a multicast group Allan Expires Sept 13th 1998 [Page 5] Internet Draft MARS Proxy January 22nd,1998 Unlike a normal MARS client, issuing a MARS_JOIN on behalf of a proxy client may involve modifications to the set of destinations served by a locally rooted p2mp VC (addition of the proxy). When the MARS proxy receives an IGMP_Report from a proxy client it performs the following actions: i) Ensures that it is registered with a MARS. ii) Issues a MARS_JOIN to the currently attached MARS for the requested group. The MARS_JOIN request conforms to [4] sect 5.2.1 with the exception that: - the mar$sha value is set to the ATM address of the proxy client rather than that of the MARS proxy - the mar$spa value is to the layer 3 address of the proxy client rather than the MARS proxy. iii) Upon receipt of MARS_JOIN confirmation, check if there is a pre- existing p2mp VC associated with the group rooted at the MARS proxy. If so, the MARS proxy MUST determine if local ATM connectivity be modified to support the addition of the proxy client. It issues a MARS_REQUEST to determine group membership. The MARS_MULTI responses are audited against the pre-existing p2mp VC and it is appropriately modified. If there is no pre-existing VC then the MARS proxy initiates one as per [4] sect 5.1.3. The MARS_REQUEST step MAY be dispensed with by observing which path the MARS_JOIN confirmation arrives on. If it arrives on the cluster control VC, then p2mp meshing is employed and adding the proxy client is required. If it arrives on the MARS unicast VC (curiously un-named in RFC 2022), then an MCS is employed and no ATM connectivity changes are needed. This is not as authoritative as re-validating the set of 'destinations' but does reduce the amount of traffic and may be an optimization in some circumstances. Some hybrid of the two approaches may be employed to combine robustness with frugality. 4.2.2 Leaving a multicast group When a MARS proxy has issued an IGMP_QUERY to a proxy client and the absence of response indicates that a proxy client has left a multicast group or an explicit IGMPv2_LEAVE is received, the MARS proxy will issue a MARS_LEAVE for the specified proxy client/specified group. 4.3 Encapsulation Multicast sources MUST use type #2 encapsulation as defined in [4] sect 5.5.2. When the MARS proxy is forwarding traffic sourced by its proxy client base, the MARS proxy will insert the address of the proxy client Allan Expires Sept 13th 1998 [Page 6] Internet Draft MARS Proxy January 22nd,1998 as the source ID. For IPv4, this will occupy the first four octets of the 8 octets allocated. The remaining octets should be zeroed. 5.0 proxy client behavior 5.1 Extensions to RFC1112 and RFC2236 The proxy client behavior corresponds to either RFC1112 [5] or RFC 2236 [9] with modifications such that multicast traffic MAY be received over transient p2mp paths. Further elaboration on criteria for accepting incoming p2mp calls and mapping calls to the correct 'layer 3 over ATM' interface is discussed in section 7.3. 5.2 Reflected packet detection Use of a MARS proxy means that the reflected packet problem exists regardless of the multicast topology used (p2mp mesh OR MCS). Use of the CMI (type #1) as a filtering mechanism is inadequate as the CMI has insufficient granularity for a proxy community. Each proxy client is required to examine the type #2 encap. source ID field in each packet received and silently discard all packets originating with itself. 6. MARS behavior The MARS MUST track group memberships by cluster member ID (cmi) to correctly associate the MARS proxy (i.d.'d by the cmi) with the proxy client base. This permits the MARS to correctly perform resource recovery when there is a loss of connectivity between the MARS and the proxy client. So [4] Appendix 'F' sect 1.2 handling of an ERR_L_RELEASE would read: Remove all ATM endpoints associated with the cmi associated with the ERR_L_RELEASE from all groups. 7. Security provisions The following discussion focuses on then problem of securing the ATM end-points on a public network and suggests several strategies for minimizing the number of points that need be secured against unauthorized calls. In general the strategy is to minimize the number of points that are required to accept incoming calls. 7.1 Restriction of Multicast operation to MCS Although the function of a MARS proxy is not limited to operation with an MCS, implementations SHOULD permit administrative limitation of operation to supporting MCS multicast only (as opposed to p2mp meshed). Allan Expires Sept 13th 1998 [Page 7] Internet Draft MARS Proxy January 22nd,1998 The mechanisms to do so are outside the scope of this document. (see also sect. 4.1) 7.2 MARS proxy to MARS/MCS connectivity One issue w.r.t. MARS and MCS is that in a public network, it is useful to secure these ATM end-points from unauthorized access. The entire set of mechanisms for accomplishing this is outside the scope of this document. There are a number of connections to be secured. A MARS proxy is connected to the MARS via the p2p bi-directional control VC and is a leaf on the p2mp cluster control VC. An MCS is connected to the MARS via a p2p control VC and is a leaf on the p2mp server control VC. The MARS proxy will be connected to MCSs of interest via a p2p VC. RFC 2022 [4] sect. 5 suggests that these are transient connections with a recommended time out. However in an environment where a relatively small number of MARS proxies serves a large number of proxy clients for a small number of multicast groups, a provisioned infrastructure is not an unreasonable solution. This specification recommends that the option of PVC connectivity to the MARS be included for the following reasons: * authentication of the proxy would be based on physical connectivity * the community of MARS clients would be relatively small, so scaling the number of p2p and p2mp VCs is not an issue. * the number of hosts serviced by a MARS proxy would be relatively large * when combined with provisioned connectivity to an MCS/MCSs, all transient connections are initiated by the MCS only (L_MULTI_RQ or L_MULTI_ADD). The MARS and MCS are not required to accept incoming calls. PVC connectivity does not imply proxy to MARS connectivity. It is possible for either to lose state. Therefore PVC connectivity comes with the following provisos: 1) The MARS proxy MUST register by issuing a MARS-JOIN after any start up. 2) Upon receipt of a MARS-JOIN, the MARS will assume that it was preceded by a loss of connectivity to the MARS proxy. The MARS will use the cluster member identifier associated with the previous session with the MARS proxy to identify any pre-existing group memberships and tear them down. 3) Upon receipt of a MARS-JOIN, the MARS will assume Cluster Control VC Allan Expires Sept 13th 1998 [Page 8] Internet Draft MARS Proxy January 22nd,1998 connectivity to the MARS client has been pre-established. Similarly for MARS to MCS connectivity 1) The MCS will register by issuing a MARS_MSERV after any startup. 2) The MCS will issue a MARS_REQUEST to re-discover supported group membership and re-establish the p2mp tree. Note that the intent is not to preclude SVC connectivity to the MARS/MCS, only to provide a solution that includes authentication of the client without either "yet-to-be-invented" access control protocols or access lists. 7.3 Proxy client screening of incoming p2mp VCs A proxy client is obliged to accept incoming p2mp calls without an authoritative authentication mechanism. The definition of this is outside the scope of this document. Further, the proxy client is typically not able to determine which IP network the p2mp call(s) originates from in the scenarios where multiple layer 3 over ATM interfaces is being supported. Once a proxy client is a member of a multicast group, it must be prepared to accept an arbitrary number of incoming p2mp calls at arbitrary times during the duration of group membership. Multiple layer 3 interfaces over ATM merely compounds the problem. The chief security vulnerability would be an insertion attack in which a malicious entity masquerades as a p2mp VC to obtain unauthorized access to the proxy client. This assumes some knowledge of the proxy client, and assumes that a separate VC offers opportunities to exploit security vulnerabilities that are not available by other means. To provide a first tier authentication of incoming calls against insertion attacks and to successfully map incoming p2mp calls to the correct layer 3 interface, the root add leaf signalling SHOULD also echo back the layer 3 address of the leaf. P2mp roots (either MARS proxies, hosts or MCSs) compliant with this approach would echo the lower 6 bytes of the mar$spa field in the UNI 3.0/3.1 BHLI field. Where the source protocol address length is less than 6 (as indicated in the mar$spln field), the most significant octets of the BHLI field will be zeroed. Incoming calls with an incorrect BHLI are rejected with a cause of 21 "call rejected" ([8] sect. 5.4.5.15). It is useful to limit the scope of what a malicious insertion attack can accomplish to significantly less than that of the coexisting layer 3 connectivity. This can be performed by several means: Allan Expires Sept 13th 1998 [Page 9] Internet Draft MARS Proxy January 22nd,1998 i) Timing: A proxy client MUST not accept any incoming p2mp calls on a layer 3 over ATM interface while not currently a member of a multicast group. Good security practice suggest that clients SHOULD record information on unexpected incoming call requests. ii) Limiting destination addressability: Packets arriving on a p2mp VC associated with multicast should be filtered according to the destination multicast address. Rejected packets MUST be silently discarded. Good security practice suggests that clients SHOULD record information on discarded packets. iii) Correctly limiting VC capability A p2mp VC is unidirectional, therefore no traffic should be able to be forwarded onto that VC by the proxy client. This MUST be reflected in calling traffic descriptors. Calls in which the backward cell rates are not set to zero MUST be rejected. 8. Fate sharing It is important for network resource management and recovery that multicast group membership by a proxy client be tightly coupled to connectivity between the proxy client and the MARS proxy. One example of this would be the existence of a PPP session between the proxy client and the MARS proxy (specifically an active NCP). Should, by whatever means, the MARS proxy detect loss of connectivity to a proxy client it will issue MARS_LEAVEs for all groups associated with the proxy client. Loss of connectivity between the MARS and MARS proxy is discussed in sect. 4.4. 9. Specific PPP over ATM considerations 9.1 PPP over ATM, MARS and L2TP One scenario of interest is when there is service interworking in the network core and multiple PPP sessions are aggregated into an L2TP [7] (work in progress) tunnel. The assumption is that ATM exit point was an L2TP Access Concentrator (LAC). The following provisos apply: 1) MARS control messages are not routable therefore some direct connectivity is required between a MARS proxy and MARS for control traffic. 2) Where an MCS is employed, direct connectivity between the MARS proxy Allan Expires Sept 13th 1998 [Page 10] Internet Draft MARS Proxy January 22nd,1998 and the MCS is not required. As discussed in sect 4.1, a MARS proxy may forward multicast traffic to the MCS via a non-NBMA path. 3) The MARS proxy requires knowledge of the ATM end-point address of the proxy client. The dialing number in an Incoming Call Request (ICRQ, [7] sect 6.9) would be a suitable mechanism. A PVC architecture between the PPP client and the L2TP LAC could be supported but is outside the scope of this document. 9.2 Backwards compatibility with initial PPP over ATM implementations A desirable goal would be that multicast worked with any combination of proxy client vintage and MARS proxy vintage. There are three scenarios possible: 1) The RAS does not support MARS proxy. The proxy client is a don't care. In this scenario, all multicast traffic will traverse the unicast PPP path. This will be effectively transparent to the end-system. 2) The RAS supports MARS proxy and the proxy client supports MARS proxy p2mp call back. 3) The RAS supports MARS proxy and the proxy client does not support p2mp call back. There are two sub-cases: i) The PPP client cannot handle a p2mp callback. In this scenario, the L_MULTI_ADD will fail with a reason code other than those which suggest retry ([4] sect 5.1.3) and MARS clients/MCSs will silently drop the client from group membership. It is assumed such clients pre-date this specification therefore their behavior cannot be retroactively defined. The proxy client nor the MARS proxy can recover as there is no knowledge of failure. This is an insoluble problem unless the MARS proxy can obtain knowledge of the connectivity failure (true for p2mp mesh, false for MCS). ii) The PPP client accepts p2mp callback but cannot process multicast encapsulated packets. The user is effectively blocked from receiving packets from the multicast group supported by the p2mp VC. 9.3 MARS cluster LIS Restriction A MARS cluster is currently defined as serving a single LIS. The restriction is intended to minimize the problems of interaction of multicast routing protocols and subnet boundaries (pending further research). In, for example the PPP over ATM case, there is no LIS: the end system is reachable via a host route. A PPP connected end system is also typically (but not always) connected as a stub network therefore Allan Expires Sept 13th 1998 [Page 11] Internet Draft MARS Proxy January 22nd,1998 multicast routing topology problems are not expected to emerge. In this particular application this restriction does not apply. The complicated scenario is when an end-system is homed on more than one MARS proxy. This is a topic for further study. 9.4 Multiple 'layer 3 over ATM interfaces' A MARS proxy client will typically be located at a single PPP over ATM RAS and as such the MARS client MAY (not MUST) allow for multiple independent 'layer 3 over ATM' interfaces. 9.5 Collapsed Architecture The MARS architecture defines the different entities and interactions such that each function may be hosted on different platforms. It would be reasonable to suggest that for simplicity, the function of MARS, MCS and multicast router at the edge of the ATM subnet could be collapsed onto a single platform. 10. Security Considerations The focus of the security considerations expressed in this document have assumed a public ATM network. Therefore the mechanisms described herein have been concerned with ensuring hosts/systems who do not have a relationship with the operator/owner of the MARS/MCS infrastructure are obstructed from access to it or authorized proxy clients. Once authorized access to the 'layer 3' network has been established, the security considerations are similar to that both MARS/MCS or of IP multicast in general. The reader is directed to [6] as a discussion of some of the other pertinent security issues with ION protocols. 11. Acknowledgments This design is an extension of work originally proposed at the ADSL forum with Juha Heinanen of Telia, and Petri Helenius of Santa Monica Software. 12. References [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [2] Gross, G. et al, "PPP over AAL5", draft-ietf-pppext-aal5-04.txt, Dec 1997 [3] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996 [4] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996 Allan Expires Sept 13th 1998 [Page 12] Internet Draft MARS Proxy January 22nd,1998 [5] Deering, S., "Host Extensions for IP Multicasting", STD 3, RFC 1112, August 1989 [6] Armitage, G., "Security issues for ION protocols", Internet Draft , October 1997 [7] Hamzeh, K. et. al., "Layer Two Tunneling Protocol 'L2TP'", Internet Draft, , November 1997 [8] ATM Forum, "ATM User-Network Interface Specification Version 3.0", September 1993 [9] Fenner, W., "Internet Group Management Protocol, Version 2", RFC2236, November 1997 13. Author's Address Questions about this memo can also be directed to: Dave Allan Nortel P.O. Box 3511, Station 'C' Ottawa, Ontario CANADA, K2B 5P9 Tel: (613)763-6362 dallan@nortel.ca Allan Expires Sept 13th 1998 [Page 13]