Internet DRAFT - draft-allan-ion-mars-proxy
draft-allan-ion-mars-proxy
Network Working Group David Allan, Nortel
INTERNET DRAFT March 13th, 1998
Expires September 13th, 1998
MARS Proxy
<draft-allan-ion-mars-proxy-00.txt>
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
<draft-armitage-ion-security-01.txt>, October 1997
[7] Hamzeh, K. et. al., "Layer Two Tunneling Protocol 'L2TP'",
Internet Draft, <draft-ietf-pppext-l2tp-08.txt>, 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]
