M. Brunner Internet Draft M. Stiemerling Document: draft-brunner-nsis-mbox-fmwk-00.txt NEC Expires: December 2002 June 2002 Middlebox Signaling in a NSIS framework draft-brunner-nsis-mbox-fmwk-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. Abstract The Next Steps in Signaling (NSIS) working group has started looking into signaling for QoS in various cases. In this draft, we show the similarities and differences of signaling for QoS versus signaling for NAT and firewall traversal. It seams that there are quite a number of similarities, which might make sense to use a potential NSIS protocol for NAT and firewall traversal as well. 1. Introduction Even so the NSIS WG (Next Steps in Signaling) has as primary application the signaling for QoS in mind, other types of applications should be possible. In this draft, we look into the scenario, framework, problems, and issues of using a signaling protocol for middlebox traversal, where a middlebox in most cases is a NAT or firewall. One of the requirements in NSIS [NSIS-REQ] is that the signaling protocol must be independent of the service requested. The thinking definitely goes into the direction to request end-to-end or edge-to- edge QoS from IP networks. However, the service might be "open me Brunner,StiemerlingInformational - Expires December 2000 1 Middlebox signaling is a NSIS framework June 2002 the data path through all the firewalls through the network to host X". Also this type of service is running end-to-end. See also [TIST] for a proposal to use RSVP for NAT and Firewall traversal. 2. Conventions used in this document 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 [1]. 3. Scenario Lets assume the following scenario. We have application instances, both behind firewalls, but connected via the open, public Internet. Furthermore, the application can somehow request firewall traversal from the NSIS agent. The NSIS agent then signals this request to the other end. Each firewall in the middle must provide that traversal service in order to get an end-to-end path. Application Application +----+ +----+ | +------------------------------------------------------+ | +-+--+ +-+--+ | | | NSIS Agents | +-+--+ +----+ +-----+ +-+--+ | +--------+ +----------------------------+ +-----+ | +-+--+ +-+--+ +--+--+ +-+--+ | | ------ | | | | //// \\\\\ | | +-+--+ +-+--+ |/ | +-+--+ +-+--+ | | | | | Internet | | | | | | +--------+ +-----+ +----+ +-----+ | +----+ +----+ |\ | +----+ +----+ \\\\ ///// sender firewall ------ firewall receiver Figure 1: Firewall Traversal Scenario 4. Similarities between signaling for QoS and for NAT/Firewall traversal In the following we list some similarities between signaling for QoS and signaling for NAT/Firewall traversal. 4.1. End-to-end significance Also in the case of NAT/firewall traversals, we need to have the end-to-end significance since more than one NAT/Firewall might be in the path between a data sender and a data receiver. Brunner,StiemerlingInformational - Expires December 2000 2 Middlebox signaling is a NSIS framework June 2002 4.2. Relationship with routing The data path is following the "normal" routes in both cases. The devices along the data path are those providing the service in one- way or the other. The signaling protocol needs then at least to follow the same network domains then the data path does. 4.3. Dynamic state installation and maintenance For NAT/Firewall traversal, the time frame of pin holing is the same as for QoS. The service must be provided for the time of a data transfer. And for more static behavior both can also be provisioned statically. 4.4. 3rd party requestors 3rd party requestors are network entities, which do not send date and do not receive data. However, data and/or signaling packets rd might pass through that entity. So also such 3 party requestors might want to initiate a service request (NAT/Firewall traversal request for data) 5. Differences between signaling for QoS and for NAT/Firewall traversal 5.1. Interaction with accounting and billing The issue about how to charge for the service are quite different. In the QoS case, a provider would like to make money by providing enhanced services in various qualities and various prices. In the Firewall case, the provider (the one owning the firewall) wants to restrict the access due to security considerations not to make money, but more for not loosing money in case of breaking in. Or there are political, organizational, or business problems to get enough IP address in the NAT case. So the motivation for the service is different, which might impact also the protocol behaviour. 5.2. Affected Parts of the Network NATs and Firewalls tend to be located at the edge of the network, where QoS affects the complete end-to-end path. In the QoS case, all networks on a path must provide QoS in order to get end-to-end QoS. In the NAT/Firewall case, only some of the domains/nodes are affected, where the big rest does not need to care. 5.3. Traversing NSIS unaware domains In the case of QoS, the signaling for QoS should still work, even if it traverses QoS unaware domains. The thinking behind this is that we hope to get the best even if traversing unaware domains. However, for guaranteed services, where somebody pays for the service, this assumption does not hold. Brunner,StiemerlingInformational - Expires December 2000 3 Middlebox signaling is a NSIS framework June 2002 For firewalls, a NSIS unaware firewall should actually reject such a service request. We believe this is easily possible by normal firewall functionality. 6. Problems and Challenges 6.1. Authentication Since a firewall has security functionality, strong authentication is a must. 6.2. Admission Control Most time the people inside the firewall-protected domain are more trusted then the outside people. This implies that the data sender and the data receiver actually must tell their respective firewall that it should open a pinhole. It is in general not appropriate to open the pinhole from the outside, also when strong security mechanisms are in place. 6.3. Directional Property A firewall has a directional property. Hosts are sitting behind a firewall, or hosts are in the intra-net. Others are outside the firewall. So from a security point of view, the way NSIS signaling messages enters the NSIS agent of a firewall (see Figure 1) might be important, because different policies might apply for authentication and admission control. 6.4. Traversing NSIS unaware domains As shown in the previous section, the problem is that NSIS unaware firewalls should reject that kind of service request. Most likely in NSIS unaware firewalls, the NSIS protocol is rejected anyway, so this does not seam to be a real problem in most cases. But this is a deployment problem, since all firewalls along the path must be NSIS aware in order to get an open path. 6.5. Multi-homed networks This is a general problem for all kinds of receiver initiated service requests. Because the signaling receiver in general does not know the path data arrives from the sender. 6.6. Addressing Also a more general problem of NATs is the addressing of the end- point. NSIS signaling can only contain publicly known addresses, which are in reality not known by an initiator of NSIS signaling. When NSIS signaling contain receiver addresses in the signaling message payloads, then the NSIS agent must transform them as well. Brunner,StiemerlingInformational - Expires December 2000 4 Middlebox signaling is a NSIS framework June 2002 However, this is one of cases, where a NSIS aware NATs also help for other types of signaling e.g. for QoS. 7. Security Considerations Brunner,StiemerlingInformational - Expires December 2000 5 Middlebox signaling is a NSIS framework June 2002 8. References [NSIS-REQ] M. Brunner et al. "Requirements for QoS Signaling Protocols", draft-ietf-nsis-req-02.txt, May 2002. [TIST] M. Shore, "The TIST (Topology-Insensitive Service Traversal) Protocol", draft-shore-tist-prot-00.txt, May 2002. 1 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 9. Author's Addresses Marcus Brunner, Martin Stiemerling Network Laboratories, NEC Europe Ltd. Adenauerplatz 6 D-69115 Heidelberg Germany Phone: _+49 6221 905 110 Email: [brunner| Martin.Stiemerling]@ccrle.nec.de Brunner,StiemerlingInformational - Expires December 2000 6