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