One document matched: draft-brunner-nsis-mbox-fmwk-00.txt
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
| PAFTECH AB 2003-2026 | 2026-04-22 21:34:40 |