[14].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI.
A.1 SNMPv3 Proxy Forwarding
SNMPv3 proxy forwarding (RFC 3413 [13]) provides a standardized
mechanism to configure an intermediate node to forward SNMP messages.
A command generating entity sends requests to a proxy forwarding
entity that forwards the request to a third entity.
One SNMP entity may serve both functions as the SNMP agent to monitor
and configure the node on which it is resident, and as an
intermediate node in a proxy relationship to permit monitoring and
configuration of additional entities.
Each entity is identified by a unique engineID value, specifically to
support proxy between addressing domains and/or trust domains. An
SNMPv3 message contains two engineIDs- one to identify the database
to be used for message security, and one to identify the source (or
target) of the contained data. Message security is applied between
the originator and the proxy, and then between the proxy and the
end-target. The PDU contains the engineID of the node whose data is
contained in the message, which passes end-to-end, unchanged by the
proxy.
SNMPv3 proxy was designed to provide a standard SNMP approach to
inserting an intermediate node in the middle of communications for a
variety of scenarios. SNMPv3 proxy can support crossing addressing
domains, such as IPv4 and IPv6, crossing SNMP version domains, such
as SNMPv3 and SNMPv1, crossing security mechanism domains, such as
DES and AES, and for providing a single point of management contact
for a subset of the network, such as managing a private network
through a NAT device or a VPN endpoint.
A.2 Proxies Versus Application Level Gateways
Proxies are generally preferred to Application Level Gateways for
SNMP. ALGs typically modify the headers and content of messages.
SNMP is a protocol designed for troubleshooting network (mis-)
configurations. Because an operator needs to understand the actual
configuration, the translation of addresses within SNMP data causes
confusion, hiding the actual configuration of a managed device from
the operator. ALGs also introduce security vulnerabilities, and
other complexities related to modifying SNMP data.
SNMP Proxies can modify message headers without modifying the
contained data. This avoids the issues associated with translating
the payload data, while permitting application level translation of
addresses.
The issues of ALGs versus proxies for SNMP Payload Address
Translation are discussed at length in RFC 2962 [27].
Appendix B - RSIP with Tunneling
NAT requires ALGs (Application Layer Gateways) in middleboxes without
MIDCOM, and application modifications or agents for middleboxes with
MIDCOM.
Support for NAT without tunneling could easily be added to the RSIP
control protocol. NAT would be defined as a new, null tunnel type.
Support for the NAT null tunnels could be implemented in hosts, or in
applications or application agents.
If support for NAT null tunnels were implemented in hosts, no
modifications to applications would be required, and no application
agents or ALGs would be required. This has obvious advantages. In
addition to the NAT null tunnel, the host would have to implement an
RSIP / MIDCOM client (or a STUN client) and the middlebox would have
to implement an RSIP / MIDCOM server, or a STUN server would have to
be available _beyond_ the middlebox. Note that the STUN client /
server approach may not work with all types of middleboxes.
If support for NAT null tunnels were NOT implemented in hosts, then
applications would have to be modified, or application agents or ALGs
would have to be implemented. This has the advantage over tunnels
(whether null or not) of not requiring modification to hosts, but
would require the modification of host applications or the
implementation of application agents, both of which would include an
RSIP / MIDCOM client, and the implementation of an RSIP/MIDCOM server
in the middlebox. Again, in some situations, STUN could be used
instead of RSIP / MIDCOM.
Tunneled or not, an RSIP / MIDCOM server is needed in the middlebox.
Tunneled, the host needs to be modified, but not the application.
Untunneled, an agent must be added or the application must be
modified, but there would be no host modifications. The
advantages/disadvantages of tunneling would need to be evaluated in
considering RSIP.
Appendix C - Megaco Modeling Approach
To model the Middlebox functions such as firewall, NAT etc., a new
Middlebox Termination type needs to be defined within Megaco. If
policy-rule overlap or modification by multiple Agents is NOT
required, then a policy rule is equivalent to a Termination (see
Figure 1). The various components of a Policy rule such as filter,
action, life-time, creator etc. are described as various properties
of a Termination. Use of the Virtual Media Gateway (VMG) concept
allows for conflict-free interaction of multiple MA’s with the same
MB.
+-------+ +-------+
| MA-1 | | MA-2 |
| | | |
+-------+ |IF2 +-------+
| | |
+-------------|---------|----------|-----------+
| +---------+ | +-------------+ |
IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3
----------| |Tx|-------+ +---|Ty|--|Tz|----------------
| | +--+ | | | +--+ +--+ | |
| ....| | | +-------------+ |
| +---------+ | |
| +---------------------------------
| Middlebox | IF4
+----------------------------------------------+
Tx: Termination x = Policy rule x
Ty: Termination y = Policy rule y
Tz: Termination z = Policy rule z
MA: MIDCOM Agent
IF: Interface
Figure 1.
If it is required to allow multiple agents manipulate the same
Middlebox resource (e.g., a Policy rule or a filter), the latter
needs to be kept separate from the Termination (the Policy rule is
manipulated by the MA by manipulating the properties of the
associated Termination). For example, if overlapping policy rule
manipulation is required, then a Termination shall be associated with
a single policy rule, but a policy rule may be associated with more
than one Termination. Thus, a Termination can share a policy rule
with another Termination, or have a policy rule partially overlapping
with that of another Termination. This model allows two MAs,
controlling two distinct Terminations (see Figure 2), manipulate the
same or overlapping policy rules. In Figure 2, policy rules 1 and 2
are overlapping and they are shared by MA-1 and MA-2.
+-------+ +-------+
| MA-1 | | MA-2 |
| | | |
+-------+ |IF2 +-------+
| | | MB
+-------------|---------|----------|-----------+
| +-----------+ | +-------------+ |
IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3
------------------|Ty|----+ +---|Tx|--|Tz|----------------
| | +--+ | | | +--+ +--+ | |
| .... | | | | +--/------\---+ |
| +-------|---+ | / \ |
| | +----/----------\------------------
| +------+----+------+ +------+ |IF4
| |Policy1 Policy2 | |Policy| |
| | | | | | 3 | |
| +----+------+------+ +------+ |
+----------------------------------------------+
Tx: Termination x
Ty: Termination y
Tz: Termination z
MA: MIDCOM Agent
IF: Interface
MB: Middlebox
Figure 2.
This requires that the Agent and the Middlebox adhere to the
following principles:
(1) Only one Termination has read/write access to a filter at any
time.
(2) When the policy rule is being modified by a new agent (i.e., not
the one that created the policy) the Middlebox makes a policy
decision and decides whether to accept the requested modification
or not. In the case the modification is accepted the initial
MIDCOM agent may be notified.
Appendix D - Diameter IPFilter Rule
The IPFilterRule format is derived from the OctetString AVP Base
Format. It uses the UTF-8 encoding and has the same requirements as
the UTF8String. Packets may be filtered based on the following
information that is associated with it:
Direction (in or out)
Source and destination IP address (possibly masked)
Protocol
Source and destination port (lists or ranges)
TCP flags
IP fragment flag
IP options
ICMP types
Rules for the appropriate direction are evaluated in order, with the
first matched rule terminating the evaluation. Each packet is
evaluated once. If no rule matches, the packet is dropped if the
last rule evaluated was a permit, and passed if the last rule was a
deny.
IPFilterRule filters MUST follow the format:
action dir proto from src to dst [options]
action permit - Allow packets that match the rule.
deny - Drop packets that match the rule.
dir "in" is from the terminal, "out" is to the
terminal.
proto An IP protocol specified by number. The "ip"
keyword means any protocol will match.
src and dst <address/mask> [ports]
The <address/mask> may be specified as:
ipno An IPv4 or IPv6 number in dotted-
quad or canonical IPv6 form. Only
this exact IP number will match the
rule.
ipno/bits An IP number as above with a mask
width of the form 1.2.3.4/24. In
this case, all IP numbers from
1.2.3.0 to 1.2.3.255 will match.
The bit width MUST be valid for the
IP version and the IP number MUST
NOT have bits set beyond the mask.
For a match to occur, the same IP
version must be present in the
packet that was used in describing
the IP address. To test for a
particular IP version, the bits part
can be set to zero. The keyword
"any" is 0.0.0.0/0 or the IPv6
equivalent. The keyword "assigned"
is the address or set of addresses
assigned to the terminal. For IPv4,
a typical first rule is often
"deny in ip! assigned"
The sense of the match can be inverted by
preceding an address with the not modifier (!),
causing all other addresses to be matched
instead. This does not affect the selection of
port numbers.
With the TCP, UDP and SCTP protocols, optional
ports may be specified as:
{port|port-port}[,ports[,...]]
The ’-’ notation specifies a range of ports
(including boundaries).
Fragmented packets that have a non-zero offset
(i.e., not the first fragment) will never match
a rule that has one or more port
specifications. See the frag option for
details on matching fragmented packets.
options:
frag Match if the packet is a fragment and this is not
the first fragment of the datagram. frag may not
be used in conjunction with either tcpflags or
TCP/UDP port specifications.
ipoptions spec
Match if the IP header contains the comma
separated list of options specified in spec. The
supported IP options are:
ssrr (strict source route), lsrr (loose source
route), rr (record packet route) and ts
(timestamp). The absence of a particular option
may be denoted with a ’!’.
tcpoptions spec
Match if the TCP header contains the comma
separated list of options specified in spec. The
supported TCP options are:
mss (maximum segment size), window (tcp window
advertisement), sack (selective ack), ts (rfc1323
timestamp) and cc (rfc1644 t/tcp connection
count). The absence of a particular option may
be denoted with a ’!’.
established
TCP packets only. Match packets that have the RST
or ACK bits set.
setup TCP packets only. Match packets that have the SYN
bit set but no ACK bit.
tcpflags spec
TCP packets only. Match if the TCP header
contains the comma separated list of flags
specified in spec. The supported TCP flags are:
fin, syn, rst, psh, ack and urg. The absence of a
particular flag may be denoted with a ’!’. A rule
that contains a tcpflags specification can never
match a fragmented packet that has a non-zero
offset. See the frag option for details on
matching fragmented packets.
icmptypes types
ICMP packets only. Match if the ICMP type is in
the list types. The list may be specified as any
combination of ranges or individual types
separated by commas. Both the numeric values and
the symbolic values listed below can be used. The
supported ICMP types are:
echo reply (0), destination unreachable (3),
source quench (4), redirect (5), echo request
(8), router advertisement (9), router
solicitation (10), time-to-live exceeded (11), IP
header bad (12), timestamp request (13),
timestamp reply (14), information request (15),
information reply (16), address mask request (17)
and address mask reply (18).
There is one kind of packet that the access device MUST always
discard, that is an IP fragment with a fragment offset of one. This
is a valid packet, but it only has one use, to try to circumvent
firewalls.
An access device that is unable to interpret or apply a deny rule
MUST terminate the session. An access device that is unable to
interpret or apply a permit rule MAY apply a more restrictive rule.
An access device MAY apply deny rules of its own before the supplied
rules, for example to protect the access device owner’s
infrastructure.
The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the
ipfw.c code may provide a useful base for implementations.
Contributors
The following identifies the key contributors who provided the
primary content for this document in the form of individual documents
for each protocol:
RSIP:
Jim Renkel
SNMP:
Juergen Quittek
NEC Europe Ltd.
EMail: quittek@ccrle.nec.de
David Harrington
Co-chair SNMPv3 WG
EMail: dbh@enterasys.com
Megaco:
Sanjoy Sen
Cedric Aoun
Nortel
EMail: cedric.aoun@nortel.com
Tom Taylor
Nortel
EMail: taylor@nortel.com
Diameter:
Tom Taylor
Nortel
EMail: taylor@nortel.com
COPS:
Cedric Aoun
Nortel
EMail: cedric.aoun@nortel.com
Kwok-Ho Chan
Nortel
EMail: khchan@nortel.com
Louis-Nicolas Hamer
Reinaldo Penno
EMail: rpenno@juniper.net
Sanjoy Sen
Author’s Address
Mary Barnes
Nortel
2201 Lakeside Blvd.
Richardson, TX USA
Phone: 1-972-684-5432
EMail: mary.barnes@nortel.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet
gement