One document matched: draft-taylor-midcom-semgen-00.txt
Middlebox Communications (midcom) T. Taylor
Internet Draft Nortel Networks
Document: draft-taylor-midcom-semgen-00.txt
Expires: March 2003 September 2002
General Considerations For MIDCOM Semantics
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [i].
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
This document is written to aid the process of selecting and
completing the definition of the MIDCOM protocol, which will operate
between MIDCOM agents and middleboxes such as firewalls and NATs. It
describes the semantics which the protocol must support. These
semantics are derived from the MIDCOM requirements and the MIDCOM
usage scenarios which helped to inspire the requirements.
This document was derived from draft-taylor-midcom-semantics-00.txt.
The present version incorporates tentative conclusions reached in
discussion at the IETF 54 meeting of the MIDCOM WG. It removes the
concrete expression of the MIDCOM requests, responses, and
notifications in favour of those presented in draft-stiemerling-
midcom-semantics-xx.txt.
Taylor Expires - March 2003 [Page 1]
General Considerations For MIDCOM Semantics Sep 2002
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 [ii].
The notation [X:y] (example [3:2.14]) denotes section y of reference
X.
In message flows, A->M indicates information passed from the MIDCOM
Agent to the Middlebox. M->A indicates information passed from the
Middlebox to the MIDCOM Agent.
Table of Contents
1. Introduction...................................................3
1.1 Terminology.................................................3
1.2 Changes From The Predecessor Documents......................3
1.3 New Issues..................................................4
2. Semantic Implications Of The MIDCOM Framework..................4
2.1 Agent Identity..............................................4
2.2 MIDCOM Session..............................................4
2.3 Filters, Policy Actions, Policy Rules.......................5
2.4 MIDCOM Scenarios............................................7
2.5 MIDCOM Timers..............................................11
3. Semantic Implications Of The MIDCOM Requirements..............11
4. Security Considerations.......................................16
5. References....................................................16
6. Acknowledgments...............................................16
7. Author's Addresses............................................17
Taylor Expires - March 2003 [Page 2]
General Considerations For MIDCOM Semantics Sep 2002
1. Introduction
This document presents the semantics which must be supported by the
MIDCOM protocol. The purpose and framework within which this
protocol will operate are described in [iii]. The detailed
requirements which the protocol must satisfy are described in [iv].
This document first reviews the framework and requirements and draws
out their implications for the semantics of the protocol. It then
summarizes the results as a series of possible information flows
between the MIDCOM agent and middlebox and associated behaviour. It
demonstrates that these proposed information flows do indeed meet the
requirements. Finally it specifies the semantics formally using
ABNF.
1.1 Terminology
"MIDCOM agent" (or simply "agent") and "middlebox" have the meanings
given in [3]. "Agent" in this document always denotes a MIDCOM
agent.
Terminology is inconsistent between the framework and the
requirements documents. This document assumes that the term "policy
rule" defined in [3] is the same concept as "ruleset" in [4]. The
term "rule" is often used to denote "policy rule".
1.2 Changes From The Predecessor Documents
The previous list of issues has been cleared on the basis of
discussion at the MIDCOM meeting at IETF 54. As a result of that
discussion, the following changes have been made in this document:
i) Policy rule takeover is now on an individual policy rule rather
than session basis. To facilitate this, policy rule identifiers
are now specified to be globally unique rather than unique per
session.
ii) Policy rule life has no relationship to the life of the session
in which the rule was created. If the session terminates, the
policy rules created in that session remain until they expire.
iii) A policy rule is assigned to a group (given a group identifier)
when it is created. Group identifiers are also specified to be
globally unique.
iv) Only the "allow" action is supported. The "deny" action is no
longer seen as a requirement. (It is viewed as an
administrative rather than MIDCOM function.)
Taylor Expires - March 2003 [Page 3]
General Considerations For MIDCOM Semantics Sep 2002
v) A policy rule contains only one filter.
vi) Address ranges are supported in filter expressions.
In addition to these changes:
vii) The filter expression has been extended to handle twice-NAT
configurations.
viii) The "Policy Rule Request" operation in the previous version of
this document has been replaced with "Enable Request", to make
clear the restricted scope of the operation. This is a follow-
on from (iv) above.
1.3 New Issues
1.3.1 Purpose Of Groups
There seemed to be some debate over the role of groups. This
document currently assumes that a group is a shortcut reference to
the individual policy rules assigned to it.
2. Semantic Implications Of The MIDCOM Framework
2.1 Agent Identity
The framework speaks of the ability for a MIDCOM Policy Decision
Point to revoke authorization for a MIDCOM Agent [3:2.9], and of
MIDCOM Agent profiles [3:2.11]. For these concepts to be
enforceable, the MIDCOM Agent must be associated with an identifier
which must be presented at least at the start of a MIDCOM session and
which must be associated with its profile.
2.2 MIDCOM Session
[3:2.12] speaks of the MIDCOM session. [3:4] provides a requirement
for a formal information exchange to start up or to terminate a
MIDCOM session. Start-up is initiated by the MIDCOM Agent, while
either the Agent or Middlebox may terminate the session. This
requirement raises the possibility of using a session identifier in
subsequent messages to indicate the session to which each is related.
However, the present document assumes that the Agent (or Middlebox)
identifier and accompanying credentials provide an adequate
representation of the session in messages between the two entities.
Taylor Expires - March 2003 [Page 4]
General Considerations For MIDCOM Semantics Sep 2002
2.3 Filters, Policy Actions, Policy Rules
[3:2.15] defines a policy rule as a combination of one or more
filters and an action. The basic idea is that packets matching the
filter have the action applied to them. The canonical form of the
filter in [3] is the 5-tuple:
{source address, source port, destination address, destination
port, protocol}
The MIDCOM meeting at IETF 54 decided that "deny" actions are
currently out of scope. This decision is obviously subject to
further testing on the Working Group list, but assuming that it
stands, the actions we must define are those that allow flows through
NATs and firewalls.
The 5-tuple shown above is sufficient to identify the packet flows to
be enabled if and only if the internal and external address spaces
are non-overlapping. In the general case there may be such overlap.
To cover this general case, the filter must include a direction, "IN"
or "OUT".
For a pure firewall operation, the filter itself provides enough
information to enable the flow. When the Middlebox performs a NAT or
NAPT operation, however, additional information is needed.
The discussion which follows uses the term "address-port" for
brevity, but address and port should be considered as separate
components to be specified in any concrete policy rule. In
particular, in some situations one of these components may be
specified while the other is left wildcarded.
The possibilities are illustrated in Figure 1.
-------------
| Middlebox |
S | | D
Flow A +--------------------->-------------------+
| |
S D'| | D
Flow B +---------------+----->-------------------+
| |
S | |S' D
Flow C +--------------------->-----+-------------+
| |
S D'| |S' D
Flow D +---------------+----->-----+-------------+
| |
-------------
Taylor Expires - March 2003 [Page 5]
General Considerations For MIDCOM Semantics Sep 2002
Figure 1: Possible Flow Arrangements Through The Middlebox
In Figure 1, Flow A represents a pure firewall operation. The source
and destination for the incoming packets will be passed on without
change in the packets as forwarded.
Flow B represents a typical public-to-private flow through a NAT.
The source is S in both the arriving and forwarded packets, but the
destination is changed from public address-port D' to private
address-port D.
Flow C represents a typical private-to-public flow through a NAT.
The destination is D for the arriving and forwarded packets, but the
source is changed from the private address-port S to the public
address-port S'.
Finally, Flow D represents a twice-NAT situation. Arriving packets
have source address-port S, destination address-port D'. Forwarded
packets have source address-port S', destination address-port D.
To cover all these cases, it is clear that the policy rule has to be
augmented by two more components: the source address-port and the
destination address-port for the forwarded packet.
In some cases it is necessary to enable flows before (typically) the
external address-port is known. Thus the policy rule semantics
should allow the use of an "ANY" wildcard for either S or D in the
notation of Figure 1.
In other cases it is necessary to reserve the address-port binding
without enabling the flow, since it is contrary to local policy to
open a pinhole before the external address is known. The flow is
enabled subsequently when the missing information becomes available.
Thus the semantics of the MIDCOM protocol must allow for two separate
operations: an address-bind request and an enable request, where the
latter may update the policy rule by specifying an S or D address-
port which was wildcarded in the address-bind request. To tie the
two requests together, it is necessary to have a policy rule
identifier which the Middlebox can use to correlate them. Further
requirements on the policy rule identifier are noted below.
Finally, it is sometimes necessary to reserve bindings for a sequence
of destination ports, beginning with a port of specified parity (e.g.
particularly in the case of RTP/RTCP).
Summing up, the complete policy rule consists of a filter part and a
mapping part. The filter part consists of the classical 5-tuple
describing the arriving packet plus the flow direction. The mapping
Taylor Expires - March 2003 [Page 6]
General Considerations For MIDCOM Semantics Sep 2002
part consists of the address and port for the source and destination
of the packet as forwarded, and the port count where a sequence of
ports must be enabled. In addition, the address-bind request may
indicate that the first port of a sequence must have a specified
parity.
2.4 MIDCOM Scenarios
[3:7] presents three scenarios for the operation of the MIDCOM
protocol in mid-session.
Scenario [3:7.1], firewall control
The messaging sequence includes three MIDCOM operations:
a) A->M: Open up the firewall to outgoing flows of RTP and RTCP.
M->A: OK.
b) A->M: Open up the firewall to incoming flows of RTP and RTCP.
M->A: OK.
c) A->M: Close firewall to the previously enabled incoming and
outgoing flows.
M->A: OK.
Operations a) and b) have the semantics of address binding and flow
enabling where the source and destination address-ports in the
mapping part of the rule are identical to the source and destination
address-ports in the filter part. The protocol is UDP, the direction
is OUT in the case of a) and IN in the case of b), and no wildcarding
is necessary because all of the addresses are known at the time of
rule instantiation. Each rule specifies a sequence of two ports.
(Specification of parity is unnecessary because the forwarded
destination port value is specified explicitly in the mapping part.)
Operation c) uninstalls the two rules installed by a) and b).
Scenario [3:7.2], NAPT control
The messaging sequence includes the following MIDCOM operations:
a) A->M: Query Port-BIND for port 5060 incoming to the Middlebox
public address.
M->A: returns Port-BIND.
b) A->M: Query NAT session descriptor for SIP flow from external
to private endpoint (where address of latter came from the
first query).
Taylor Expires - March 2003 [Page 7]
General Considerations For MIDCOM Semantics Sep 2002
M->A: returns session descriptor.
c) A->M: Create NAT sessions for outgoing flows of RTP and RTCP
(adjacent ports). Link sessions to SIP control session.
M->A: returns session descriptor.
d) A->M: Create Port-BINDs for incoming RTP, RTCP flows (adjacent
ports).
M->A: returns Port-BINDs.
e) A->M: Create NAT session for incoming flows of RTP and RTCP
(adjacent ports). Link session to SIP control session.
M->A: returns session descriptor.
f) A->M: end session bundle.
M->A: OK.
Operations a) and b) allow the Agent to determine the private address
of the internal endpoint. In terms of the filter semantics defined
above, these operations are equivalent to a single query requesting
the return of any active Policy Rules for which the filter includes
the following in its scope:
{ source address = Ea (the external endpoint address),
source port = ANY,
destination address = Ma (the external address at the Middlebox),
destination port = 5060,
protocol = ANY,
direction = IN
}
Note the wildcarded protocol in this expression. Presumably the
Middlebox will consult with the MIDCOM PDP to determine the permitted
scope of the query. The returned Policy Rule (probably only one in
this example) should be associated with an identifier so that it can
be referred to in later operations.
Operation c) is similar to operation a) in the previous case, except
that the address-port values in the mapping part of the policy rule
are no longer identical to the corresponding values in the filter
part. The address-binding request has a filter part with the
content:
{ source address = Pa (the internal endpoint address),
source port = ANY,
destination address = CHOOSE,
destination port = CHOOSE,
protocol = UDP,
direction = OUT
Taylor Expires - March 2003 [Page 8]
General Considerations For MIDCOM Semantics Sep 2002
}
The mapping part of the address-binding request is as follows:
{ source address = CHOOSE,
source port = CHOOSE,
destination address = Ea (the external endpoint address),
destination port = <the external endpoint RTP port>,
port count = 2
}
It is unnecessary to specify parity of the first port in the request
because the destination port is specified explicitly.
The Middlebox is expected to supply values for the CHOOSE components
in its reply. In a twice-NAT configuration it will assign a private
address and port to the destination in the filter part; otherwise it
will copy the destination address and port from the mapping part. In
any event it assigns values to the source address and port in the
mapping part. It maintains all of these values as part of the its
record of the policy rule, and applies them when the rule is
activated (flow enabled).
The above expressions for the address-binding filter and mapping
parts in fact provide all the information the Middlebox needs even in
a pure firewall operation. This makes it clear that it is
unnecessary to specify either the filter part destination address-
port or the mapping part source address-port in an address-binding
request. These can be implicitly assumed to be CHOOSE in all cases.
The Middlebox takes appropriate action based on its own
configuration, without the Agent needing to be aware of that
configuration.
Operations d) and e) are semantically equivalent to operation c),
except that they apply in the inbound direction with the appropriate
filter part source address and mapping part destination address-port.
Operations c), d), and e) also require the assignment of the new
rules to the same session bundle as the previously installed SIP
control Policy Rules. This introduces the concept of a session
bundle identifier, which must be supplied at the address-bind stage
in case the session is aborted before the flow is ever activated.
Since it is the Agent that is aware of the scope of a session, the
session bundle identifier is provided in the address-bind request.
Operation f) requires an information exchange where the Agent
supplies the session bundle identifier and requests deactivation of
all rules in the session bundle.
Taylor Expires - March 2003 [Page 9]
General Considerations For MIDCOM Semantics Sep 2002
Scenario [3:7.3]: Middlebox implementing NAPT and firewall
The messaging sequence includes the following MIDCOM operations:
a) A->M: Query Port-BIND for mapped address (assumed known), port
5060.
M->A: returns Port-BIND.
b) A->M: Query NAT session descriptor for SIP flow from external to
private endpoint.
M->A: returns session descriptor.
c) A->M: Create NAT sessions for outgoing flows of RTP and RTCP.
Link sessions to SIP control session.
M->A: returns session descriptor.
d) A->M: Open up the firewall to outgoing flows of RTP and RTCP.
M->A: OK.
e) A->M: Create Port-BINDs for incoming RTP, RTCP flows (adjacent
ports).
M->A: returns Port-BINDs.
f) A->M: Create NAT session for incoming flows of RTP and RTCP.
Link session to SIP control session.
M->A: returns session descriptor.
g) A->M: Open up the firewall to incoming flows of RTP and RTCP.
M->A: OK.
h) A->M: end NAPT session bundle.
M->A: OK.
i) A->M: Close firewall to the previously enabled incoming and
outgoing flows.
M->A: OK.
a) and b) are the same as in the previous case.
c) is equivalent to the address-bind phase of operation c) in the
previous case, while d) corresponds to the flow enabling phase of
that operation. Similarly, e) and f) correspond to the address-bind
phase of operations d) and e) in the previous case, and g)
corresponds to the flow enabling phase of those operations.
Finally, h) and i) are semantically equivalent to deactivation of the
bundle of rules created in the previous steps.
Taylor Expires - March 2003 [Page 10]
General Considerations For MIDCOM Semantics Sep 2002
Summary Of Observations
In summary, the three scenarios have demonstrated the need for
information exchanges supporting querying of instantiated policy
rules against a pattern, activating Policy Rules (generally with
wildcards), creating bundles of Policy rules, deactivating individual
policy rules, and deactivating bundles of Policy Rules.
2.5 MIDCOM Timers
[3:8.3] talks about the potential usefulness of timers in the MIDCOM
protocol, to facilitate resource cleanup. This raises the question
of whether the timer values should be visible to the Agent. Given
that their intended use is to compensate for Agent outages, an
information exchange prior to timer expiry seems indicated.
3. Semantic Implications Of The MIDCOM Requirements
This section reviews the semantic implications of the requirements
documented in [4].
[4:2.1.1]: authorization.
This requirement implies the need for credentials in any request the
Agent sends to the Middlebox, sufficient to allow the latter to
determine the Agent's scope of authority.
[4:2.1.2]: one MIDCOM Agent dealing with multiple Middleboxes
This implies that a parameter must be present in each message coming
from a Middlebox, identifying that Middlebox uniquely. The session
identifier discussed in section 2.2 might serve that purpose, beyond
the initial setup of the session.
[4:2.1.3]: one Middlebox dealing with multiple MIDCOM Agents
Similarly, this implies that a parameter must be present in each
message coming from a MIDCOM Agent, identifying that MIDCOM Agent
instance uniquely. MIDCOM Agent identifiers were discussed in
section 2.1. Again, the session identifier may serve the purpose
after initial session setup.
[4:2.1.4]: deterministic Middlebox behaviour when multiple MIDCOM
Agents interact with it.
This implies several points:
Taylor Expires - March 2003 [Page 11]
General Considerations For MIDCOM Semantics Sep 2002
. well-defined Middlebox behaviour when it processes
requests, particularly when conflicts are encountered;
. the behavioural equivalent of mutual exclusion, such that
requests affecting the same resources (for example,
involving overlapping filter specifications) are required
to be processed serially;
. requests can be of sufficiently large extent that the Agent
can accomplish what it needs in a single request, thus
avoiding deadlock.
[4:2.1.5]: known and stable state
The explanation of this requirement suggests that a request
identifier parameter is needed for each request, that each request
must have a reply, and that the reply must include the request
identifier parameter as well as the result of the request.
The requirement also appears to imply the need for a MIDCOM Agent to
be able to audit the Middlebox state as it relates to requests made
in the past by that Agent. As an optimization, the audit request may
include parameters limiting the scope of the audit. The response
includes a state parameter expressed as a sequence of Policy Rules.
In view of the potential volume of information, provision should be
made for segmentation of the response.
Auditing can be seen as an additional use of the query exchange
documented as part of the scenario analysis in section 2.4.
[4:2.1.6]: Middlebox reporting status
This implies a a need for a Middlebox to send autonomous
notifications to a MIDCOM Agent. It is assumed that [4:2.1.6]
relates to the operational status of the Middlebox as a whole, and
possibly also the state it retains on behalf of a given Agent.
Accordingly, the status notification should be able to express the
following situations:
. Middlebox going out of service
. Middlebox returned to service, having retained all state
(i.e. sessions, Policy Rules and associated timers)
. Middlebox returned to service, state information lost or
stale
. Middlebox congested.
[4:2.1.7]: autonomous reporting of conditions and autonomous actions
The main thrust of the explanation of this requirement is that the
Middlebox be able to report autonomously actions taken with regard to
Taylor Expires - March 2003 [Page 12]
General Considerations For MIDCOM Semantics Sep 2002
particular Policy Rules. The information passed must therefore
include the Policy Rule identifier(s), the action taken, and the
reason for the action.
[4:2.1.8]: mutual authentication
This requirement bears upon session startup in the first place, with
proper follow-up to maintain the integrity of the session in
subsequent messages.
[4:2.1.9]: either entity can terminate a session
This implies a formal exchange to terminate a session. Based on
discussion at IETF 54, the end of a session does not affect the life
of policy rules created during that session.
[4:2.1.10]: MIDCOM Agent can determine success or failure of a
request
This implies that every request must have a reply, and the reply must
indicate the outcome of the request.
[4:2.1.11]: version interworking
There seems to be agreement to include protocol version in each
message, governing the content of that message. It is possible the
initial message of a session should include an additional parameter
listing the versions supported by the originator.
If the protocol has identifiable options the initial message of the
session in each direction should include a parameter indicating what
options the message sender supports.
[4:2.1.12]: deterministic behaviour for overlapping rulesets
There is some dispute over what deterministic means in this case.
The issue is described at length in section 1.2.4 above. In keeping
with existing implementation, we postulate an aggregate model of
Middlebox operation as follows:
a) rules are retained in their original form (including mappings)
rather than aggregated;
b) as each packet passes through the Middlebox, it is checked
against the filter portion of each active rule in turn;
c) if a match is found, the action associated with that rule is
applied;
Taylor Expires - March 2003 [Page 13]
General Considerations For MIDCOM Semantics Sep 2002
d) if no match is found, the default action set by the Middlebox
administrator is applied;
e) rules are evaluated in the order in which they were installed
(first-come, first-served).
For a given sequence of rules this always gives the same per-packet
outcomes. In that sense it is deterministic, even if the Agent
installing a given rule cannot know in advance what the effect of
that rule will be unless it knows the complete sequence of rules
installed at the Middlebox.
[4:2.2.1]: extensibility
It would be possible to add content to the semantic description as a
placeholder for new material, but there doesn't seem to be much point
in doing so.
[4:2.2.2]: control of multiple functions
The semantic content of firewall and NAT/NAPT control have been
captured in the Policy Rule description in section 2.3. This
formulation may also be applicable to other Middlebox types.
[4:2.2.3]: ruleset groups
The need for information exchanges to create such groups (referred to
as session bundles) has been documented above in connection with the
scenarios.
[4:2.2.4]: ruleset lifetime extension
This implies a possible need for several information exchanges:
. allowing the Agent to associate a lifetime (and perhaps a
grace period) with a Policy rule at the time of
installation
. allowing the Agent to audit the remaining lifetime for a
Policy Rule (most reasonably as a parameter of a general
Policy Rule audit capability)
. allowing the Middlebox to indicate when a Policy Rule is
about to expire
. allowing the Agent to reset the remaining lifetime.
[4:2.2.5]: action on unknown attributes
Taylor Expires - March 2003 [Page 14]
General Considerations For MIDCOM Semantics Sep 2002
This requires a sub-field within certain attributes indicating
whether the attribute can be ignored if not understood or stops the
request from being processed. It also implies that the
responses to individual requests must identify components of the
request which have caused failure or which have been ignored.
[4:2.2.6]: failure reasons
A failure reason element must be a potential part of responses.
Possible failure reasons are listed in the next section.
[4:2.2.7]: multiple authorised Agents working on the same ruleset
This implies a requirement that Policy Rule identifiers are unique
within the Middlebox, hence should be assigned by the Middlebox in
the reply to the address-bind request. Of course, this masks a set
of requirements on operations outside of the MIDCOM protocol: sharing
of Policy Rule and possibly session bundle identifiers between
Agents, and authorization of one Agent to operate on policy rules set
up by another one.
[4:2.2.8]: transport of filtering rules
The filters of this semantic analysis are not, of course, the
concrete expression of filters in the protocol itself. This analysis
indicates within which information exchanges filters will have to be
carried.
[4:2.2.9]: matching parity ("oddity")
This requirement has already been recognized and incorporated in the
semantic representation of a Policy Rule filter in section 2.3.
[4:2.2.10]: ranges of ports
Also covered in section 2.3. The requirement extends beyond RTP/RTCP
pairs to sequences of such pairs required for layered encoding.
[4:2.2.11]: contradictory actions for sub-filters
Assuming that the contradictory actions are represented by separate
Policy Rules, and assuming the model of Middlebox operation described
in the discussion of requirement [4:2.1.12], this requirement is met
provided that the rule with the sub-filter is installed before the
main rule. This is an operational requirement given semantics
already defined.
Taylor Expires - March 2003 [Page 15]
General Considerations For MIDCOM Semantics Sep 2002
Requirements For Security
The security-related requirements postulated in [4:2.3] will have
semantic consequences, but the details depend on the chosen
mechanisms.
4. Security Considerations
This draft may receive its own discussion of security considerations,
but for the moment these are well covered by the discussion in [3]
and specific requirements in [4].
5. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan,
"Middlebox communication architecture and framework", draft-
ietf-midcom-framework-07.txt, RFC 3303, August 2002.
[4] R. Swale, P. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox
Communications (midcom) Protocol Requirements", draft-ietf-
midcom-requirements-05.txt, RFC 3304, August 2002.
[5] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
6. Acknowledgments
Cedric Aoun contributed to the initial version of this document,
begun before list discussion of the topic of MIDCOM semantics. The
list discussion itself benefited from interventions by Ben Campbell,
Bob Penfield, Paul Sijben, Martin Stiemerling, Christian Huitema,
Scott Brim, Juergen Quittek, Ted Hardie, John LaCour, Andrew Molitor,
Reinaldo Penno, Sanjoy Sen, Jiri Kuthan, James Renko, Joel Halprin,
Cullen Jennings, and Adina Simu.
Taylor Expires - March 2003 [Page 16]
MIDCOM Semantics September 2002
7. Authors Address
Tom Taylor
Nortel Networks
Ottawa, Canada
Phone: +1 613 736 0961
Email: taylor@nortelnetworks.com
Taylor Expires - March 2003 [Page 17] | PAFTECH AB 2003-2026 | 2026-04-24 10:26:47 |